From nobody Mon Sep 1 00:13:33 2014 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 0FACA1A00DA for ; Mon, 1 Sep 2014 00:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 P-4vg99PCXYJ for ; Mon, 1 Sep 2014 00:13:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 252BC1A00DD for ; Mon, 1 Sep 2014 00:13:27 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0LsS1m-1YQNWj0IJ6-0121pe; Mon, 01 Sep 2014 09:13:25 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <53F35B44.1090808@gmail.com> Date: Mon, 1 Sep 2014 10:13:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:sRXsxGl3/GZSRZtlqPnBRlKnBm/xvihKK9qAQeWoffA JCN6ZhDJM/KNIQTOAS1OIYcag2aSVMGZvRLX188dBhuOn9RaRe 2ZsKtqpvz5dd3apugIqiZqeFk61wy5kLFuE1K+01KI5hihmFlU k8iCvZx8zigjxJVjCWWUNYiDQbAe1vL1a1yGz7QqT6kwukYf4u PlsT6t+Ay7RQwDQkABrS0DzEHXT7/+IKCqmUHYsCZbRBGkMDKr wxMBddzR9eUZKdjZAk44ogC1jv9sEVhbewDGZLHCEynC34hnCt +cNuF1ZNDMVpR7gv5mMGKGx8Skv/YphBeqTNp6wNsVRH/p8qKy mpc4x+9mpjgf7w4zCOcFjZ09+LX0zyI7ignoKyojhPp6zYOXIU qbvD2LWk69ypA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/dH_d0FlAm3pPi2MpyswPn1lvL60 Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 01 Sep 2014 07:13:31 -0000 > Okay, we are not going to define how the existing 3FPP system works - = that knowledge is assumed. What I thought goes into the document, for = example, in the case of 3GPP system would be identifying the = architecture changes or modifications needed. If the deployment model = assumes all network functions are virtualized, the document states that = and lays out the architecture based on that. Satoru's & Ryuji's vEPC = deployment model (based on their solution) is IMHO a good example of = what could be documented. The similar applies for other system = architectures such as SP Wi-Fi etc. >=20 Jouni, The "architecture changes" would be based on the a "specific solution". = So, as part of describing a solution one can be talking about what you = are suggesting above. But I don't understand how we can be talking about = "deployment models and scenarios" before we agree on the solutions. Alper >>>>> o Enhanced mobility anchoring: define protocol solutions for a >>>>> gateway and mobility anchor assignment and mid-session = mobility >>>>> anchor switching that go beyond what has been specified, for >>>>> example, in RFC 6097, 6463, and 5142. Traffic steering >>>>> associated with the anchor switch is also in-scope if deemed >>>>> appropriate. >>>>>=20 >>>>> o Forwarding path and signaling management: the function >>>>> that handles mobility management signaling interacts with = the >>>>> DMM network elements for managing the forwarding state >>>>> associated with a mobile node's IP traffic. These two = functions >>>>> may or may not be collocated. Furthermore, the forwarding = state >>>>> may also be distributed into multiple network elements = instead >>>>> of a single network element (e.g., anchor). Protocol = extensions >>>>> or new protocols will be specified to allow the above = mentioned >>>>> forwarding path and signalling management. >>>>>=20 >>>>=20 >>>> I cannot separate "mobility anchoring" from "fwding path and >>>> signaling management". >>>> Wherever you want to set your anchor or move your anchor to, you'd >>>> need signaling >>> > and setting up data path. The two are inseparable. >>>> Having said that, I'm OK to keep the current work item descriptions >>>> and finalize >>> > rechartering. Once we have detailed discussions about the = breakdown >>> of the work, we >>> > can come back and refine the goals and milestones (as already = stated >>> below [*]). >>>=20 >>> The enhanced mobility anchoring above is/was rather MIP type = solutions >>> influenced with "anchors" like we understand today, while the >>> "forwarding path and signaling management" was meant for more future >>> oriented solutions where the forwarding path does not necessarily = have >>> anything mobility specific etc. >>>=20 >>=20 >> (Just FYI: It's not possible to gather what you are saying from = reading >> the charter. Different people reading the charter may not have the = same >> understanding. But like I said, this is just FYI, I can live with = this >> text until we come back and refine it later). >=20 > Ok. I'll try to clarify the point the text tries to make. >=20 > - Jouni >=20 >>=20 >> Thanks. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>> Any other opinions on collapsing these two? >>>=20 >>> - Jouni >>>=20 >>>>> o Exposing mobility state to mobile nodes and network nodes: >>>>> define solutions that allow, for example, mobile nodes to = select >>>>> either a care-of address or a home address depending on an >>>>> application' mobility needs. In order to enable this >>>>> functionality, the network-side control functions and other >>>>> networking nodes must also be able to exchange appropriate >>>>> control information, as well as to the mobile nodes and = their >>>>> applications. >>>>>=20 >>>>> The working group may decide to extend the current milestones = based on >>>>> the new information and knowledge gained during working on other >>>>> documents listed in the initial milestones. [*] >>>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Possible new documents and >>>>> milestones must still fit into the overall DMM charter scope as = outlined >>>>> above. >>>>>=20 >>>>> Goals and Milestones: >>>>>=20 >>>>> Feb 2015 - Submit 'The deployment models and scenarios' as a = working >>>>> group document(s). To be Informational RFC. >>>>>=20 >>>>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group >>>>> document. To be Proposed Standard. >>>>>=20 >>>>> Feb 2015 - Submit 'Forwarding path and signaling management' as a >>>>> working group document. To be Proposed Standard. >>>>>=20 >>>>> May 2015 - Submit 'Exposing mobility state to mobile nodes and = network >>>>> nodes' as a working group document(s). To be Proposed >>>>> Standard. >>>>>=20 >>>>>=20 >>>>> May 2015 - Submit 'The deployment models and scenarios' submitted = to >>>>> the IESG. To be Informational RFC. >>>>>=20 >>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to the = IESG. >>>>> To be Proposed Standard. >>>>>=20 >>>>> Jun 2015 - Submit 'Forwarding path and signaling management' = submitted >>>>> to the IESG. To be Proposed Standard. >>>>>=20 >>>>> Oct 2015 - Submit 'Exposing mobility state to mobile nodes and = network >>>>> nodes' submitted to the IESG. To be Proposed Standard. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti: >>>>>> The webex sessions have been cancelled in accordance of better = IETF >>>>>> process compliancy. New dates will be announced rougghly two = weeks >>>>>> ahead >>>>>> of tomorrow. >>>>>>=20 >>>>>> You can (and should) still actively send edits to the list and = I'll >>>>>> update the text accordingly. Maybe we manage to get ready even >>>>>> without a >>>>>> call! >>>>>>=20 >>>>>> - Jouni & Dapeng >>>>>>=20 >>>>>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti: >>>>>>> Folks, >>>>>>>=20 >>>>>>> The latest charter draft can be found here: >>>>>>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>>>>>=20 >>>>>>>=20 >>>>>>> The deadline for the text chnges are 31st July. I'll setup a = call for >>>>>>> next week so that those who want to dial in and have verbal = commenting >>>>>>> can do that. In a meanwhile, email works as usual for updates = and >>>>>>> comments on the text. The actual milestone dates are to be done >>>>>>> last but >>>>>>> suggestions are more than welcome. >>>>>>>=20 >>>>>>> - Jouni & Dapeng >>>>>=20 >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>=20 >>=20 From nobody Mon Sep 1 00:50:59 2014 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 21DB11A0172 for ; Mon, 1 Sep 2014 00:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.306 X-Spam-Level: ** X-Spam-Status: No, score=2.306 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 XZ2WrRXovtgQ for ; Mon, 1 Sep 2014 00:50:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 F19E51A0174 for ; Mon, 1 Sep 2014 00:50:51 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0Lyk9B-1YSGcC3eQZ-01694w; Mon, 01 Sep 2014 09:50:50 +0200 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_3BF31B92-2924-4D21-8527-039FD3569A30" Date: Mon, 1 Sep 2014 10:50:50 +0300 Message-Id: To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:1yadhGa4EBTMmlqPUhD0nee39O9zam/xhpVj4TUvOyQ 2v/85ZUbKrUUrpc7eVBwDPvRXOnk3Q8wgJm/X2N8sL3FmVlkyp SpFY6l1tJMFPNSH5vMdb8AaiLSQX6TuT4X7sRUd2uvykGYTN08 ZJQWRZWHTEjhTVvnFCIKALqlghHJexCZI3I1joz0AqfyXSdDEj uRd9PFxqtYHV0ppTsJhsknzaiLtcMz4uL2WDTF+TQUAEmVUGiS yGbSbVF6PPpMVAY+waIk4n+cAklVjNWw1ghg8JWGIEt/cmh5QN VE/Gh3f/I99yukXExatwzZNrym2wEX+/b9GU90gk6284yLW9zg RLs0NxuSVJnIsfvVApR4+HWSJYrGABu7SA3iVHLs48FFSi7Rxo K60bxpk7OQQ5A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/c_1s1IVV9_nXct_7-X4P3fyxWSE Subject: [DMM] 3GPP CSIPTO 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, 01 Sep 2014 07:50:56 -0000 --Apple-Mail=_3BF31B92-2924-4D21-8527-039FD3569A30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear DMMers, Here's an update on 3GPP SA1 CSIPTO work=85 Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting SA1 = has completed the CSIPTO normative work. As you might remember, SA1 is in charge of defining service = requirements. The next step for CSIPTO is to initiate a work item in SA2. And here's a copy-paste of the normative requirements (accepted doc is = S1-143607.zip): Some types of services (e.g. streaming services, VOIP, VPN, HTTPS-Based = Services) cannot tolerate a change of IP address of the UE without = disruption of the service. SIPTO can be performed with or without coordination between the UE and = the network. The following requirements apply to coordinated SIPTO: - The 3GPP system shall be able to support multiple connections that = are associated with the same defined IP network where each connection = may or may not support IP address preservation. - The 3GPP system shall be able to determine if an IP flow requires = IP address preservation or not. Based on this determination, the 3GPP = network shall be able to offload selected IP traffic in coordinated = manner between UE and the network, in order to minimize service = disruption. - The 3GPP system shall be able to detect when a connection becomes = suboptimal and decide when to establish a new optimal connection to the = same defined IP network or use an existing connection. Note 1: The definition of optimal and suboptimal can be based on a = number of implementation criteria like geography, topology and load = balancing etc. - The 3GPP system shall minimize the number of connections of a UE = without disrupting the UE=92s services, e.g. to ensure economical use of = network resources. - The 3GPP system shall be able to ensure that the actual average = aggregate bit rate for IP flows of packet data network connections = associated with the same packet data network does not significantly = exceed the subscribed aggregate maximum bit rate for this packet data = network when two connections are used with the same defined IP network. Note 2: Requirements for Coordinated SIPTO do not apply to IMS.= --Apple-Mail=_3BF31B92-2924-4D21-8527-039FD3569A30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = DMMers,

Here's an update on 3GPP SA1 CSIPTO = work=85

Two weeks ago there was an SA1 meeting = (SA1#67), and in that meeting SA1 has completed the CSIPTO normative = work.
As you might remember, SA1 is in charge of defining = service requirements.

The next step for CSIPTO = is to initiate a work item in = SA2.


And here's a = copy-paste of the normative requirements (accepted doc is S1-143607.zip):


=

Some types of services (e.g. streaming services, VOIP, VPN, HTTPS-Based Services) = cannot tolerate a change of IP address of the UE without disruption of the = service.

SIPTO can be performed with or without coordination between the UE and the = network. The following requirements apply to coordinated SIPTO: =

-     The 3GPP system = shall be able to support multiple connections that are associated with the same = defined IP network where each connection may or may not support IP address = preservation.

-     The 3GPP system = shall be able to determine if an IP flow requires IP address preservation or not. = Based on this determination, the 3GPP network shall be able to offload selected = IP traffic in coordinated manner between UE and the network, in order to = minimize service disruption.

-      The 3GPP system = shall be able to detect when a connection becomes suboptimal and decide when to = establish a new optimal connection to the same defined IP network or use an existing = connection.

Note 1: The definition of optimal and suboptimal can be based on a = number of implementation criteria like geography, topology and load balancing = etc.

-     = The 3GPP system shall minimize the number of connections of a UE without disrupting the UE=92s = services, e.g. to ensure economical use of network resources.

-     = The 3GPP system = shall be able to ensure that the actual average aggregate bit rate for IP flows of packet data network connections = associated with the same packet data network does not significantly exceed the = subscribed aggregate maximum bit rate for this packet data network when two = connections are used with the same defined IP network.

Note 2:  = Requirements for Coordinated SIPTO do not apply to IMS.

= --Apple-Mail=_3BF31B92-2924-4D21-8527-039FD3569A30-- From nobody Mon Sep 1 01:25:17 2014 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 D19801A01D0 for ; Mon, 1 Sep 2014 01:25:15 -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 3HlX3keeeLmJ for ; Mon, 1 Sep 2014 01:25:13 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF5E1A01CA for ; Mon, 1 Sep 2014 01:25:12 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id 10so5593049lbg.3 for ; Mon, 01 Sep 2014 01:25:10 -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=fWkIYy60xf+4EA3FL4aVafP1eMlBcLwUreV3wOeZWuE=; b=xfNI9PyGOxLyu4h8/zt09vbNRwoH/dkj3V9wZ9XtOZT2vxklVrYXrGIudFmuYVD56N OrULaDLHjXiASrm3jV4HIdde8axbU2gDLPXohsnYAlWX7qtODqEO9gEiGmcBEGxNfUHb BSNH2xUOxNMrrGQzyPQWq5oOH3N6N4osVmM/LbOrq1c5cj3PaWG5MzJywolQneEaVTGY c6Bmlhu/Li0Su9oiMq90ltSVlJNHnFaV9kPsH0TYodyLioLTVzAnQFVwdXvqlnStJDAP wyKRaV4sL4MdUD4y/MJ4x7/cFaHKcVZ9qGXrQXWkX8KyFNFFwAMh7IAOlFO4ZfzdtqLG VxXg== X-Received: by 10.152.43.81 with SMTP id u17mr15280660lal.50.1409559910635; Mon, 01 Sep 2014 01:25:10 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:2423:d50f:b7a:bc0c? ([2001:1bc8:101:f101:2423:d50f:b7a:bc0c]) by mx.google.com with ESMTPSA id j10sm194030lbb.34.2014.09.01.01.25.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Sep 2014 01:25:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> Date: Mon, 1 Sep 2014 11:25:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/kOoEOZPISVGQYLPf9S2krXjDnqs Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 01 Sep 2014 08:25:16 -0000 Alper, I hear your concern. Anyway, the division here is similar to (3GPP) = stage-2 and stage-3 work. The ""deployment models and scenarios" are the = stage-2 descriptions and then we also need the protocol level solutions = that are in separate documents. Makes sense? - Jouni On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: >> Okay, we are not going to define how the existing 3FPP system works - = that knowledge is assumed. What I thought goes into the document, for = example, in the case of 3GPP system would be identifying the = architecture changes or modifications needed. If the deployment model = assumes all network functions are virtualized, the document states that = and lays out the architecture based on that. Satoru's & Ryuji's vEPC = deployment model (based on their solution) is IMHO a good example of = what could be documented. The similar applies for other system = architectures such as SP Wi-Fi etc. >>=20 >=20 > Jouni, >=20 > The "architecture changes" would be based on the a "specific = solution". So, as part of describing a solution one can be talking about = what you are suggesting above. But I don't understand how we can be = talking about "deployment models and scenarios" before we agree on the = solutions. >=20 > Alper >=20 >=20 >=20 >=20 >>>>>> o Enhanced mobility anchoring: define protocol solutions for a >>>>>> gateway and mobility anchor assignment and mid-session = mobility >>>>>> anchor switching that go beyond what has been specified, for >>>>>> example, in RFC 6097, 6463, and 5142. Traffic steering >>>>>> associated with the anchor switch is also in-scope if deemed >>>>>> appropriate. >>>>>>=20 >>>>>> o Forwarding path and signaling management: the function >>>>>> that handles mobility management signaling interacts with = the >>>>>> DMM network elements for managing the forwarding state >>>>>> associated with a mobile node's IP traffic. These two = functions >>>>>> may or may not be collocated. Furthermore, the forwarding = state >>>>>> may also be distributed into multiple network elements = instead >>>>>> of a single network element (e.g., anchor). Protocol = extensions >>>>>> or new protocols will be specified to allow the above = mentioned >>>>>> forwarding path and signalling management. >>>>>>=20 >>>>>=20 >>>>> I cannot separate "mobility anchoring" from "fwding path and >>>>> signaling management". >>>>> Wherever you want to set your anchor or move your anchor to, you'd >>>>> need signaling >>>>> and setting up data path. The two are inseparable. >>>>> Having said that, I'm OK to keep the current work item = descriptions >>>>> and finalize >>>>> rechartering. Once we have detailed discussions about the = breakdown >>>> of the work, we >>>>> can come back and refine the goals and milestones (as already = stated >>>> below [*]). >>>>=20 >>>> The enhanced mobility anchoring above is/was rather MIP type = solutions >>>> influenced with "anchors" like we understand today, while the >>>> "forwarding path and signaling management" was meant for more = future >>>> oriented solutions where the forwarding path does not necessarily = have >>>> anything mobility specific etc. >>>>=20 >>>=20 >>> (Just FYI: It's not possible to gather what you are saying from = reading >>> the charter. Different people reading the charter may not have the = same >>> understanding. But like I said, this is just FYI, I can live with = this >>> text until we come back and refine it later). >>=20 >> Ok. I'll try to clarify the point the text tries to make. >>=20 >> - Jouni >>=20 >>>=20 >>> Thanks. >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>> Any other opinions on collapsing these two? >>>>=20 >>>> - Jouni >>>>=20 >>>>>> o Exposing mobility state to mobile nodes and network nodes: >>>>>> define solutions that allow, for example, mobile nodes to = select >>>>>> either a care-of address or a home address depending on an >>>>>> application' mobility needs. In order to enable this >>>>>> functionality, the network-side control functions and other >>>>>> networking nodes must also be able to exchange appropriate >>>>>> control information, as well as to the mobile nodes and = their >>>>>> applications. >>>>>>=20 >>>>>> The working group may decide to extend the current milestones = based on >>>>>> the new information and knowledge gained during working on other >>>>>> documents listed in the initial milestones. [*] >>>>>=20 >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Alper >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> Possible new documents and >>>>>> milestones must still fit into the overall DMM charter scope as = outlined >>>>>> above. >>>>>>=20 >>>>>> Goals and Milestones: >>>>>>=20 >>>>>> Feb 2015 - Submit 'The deployment models and scenarios' as a = working >>>>>> group document(s). To be Informational RFC. >>>>>>=20 >>>>>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working = group >>>>>> document. To be Proposed Standard. >>>>>>=20 >>>>>> Feb 2015 - Submit 'Forwarding path and signaling management' as a >>>>>> working group document. To be Proposed Standard. >>>>>>=20 >>>>>> May 2015 - Submit 'Exposing mobility state to mobile nodes and = network >>>>>> nodes' as a working group document(s). To be Proposed >>>>>> Standard. >>>>>>=20 >>>>>>=20 >>>>>> May 2015 - Submit 'The deployment models and scenarios' submitted = to >>>>>> the IESG. To be Informational RFC. >>>>>>=20 >>>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to the = IESG. >>>>>> To be Proposed Standard. >>>>>>=20 >>>>>> Jun 2015 - Submit 'Forwarding path and signaling management' = submitted >>>>>> to the IESG. To be Proposed Standard. >>>>>>=20 >>>>>> Oct 2015 - Submit 'Exposing mobility state to mobile nodes and = network >>>>>> nodes' submitted to the IESG. To be Proposed Standard. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti: >>>>>>> The webex sessions have been cancelled in accordance of better = IETF >>>>>>> process compliancy. New dates will be announced rougghly two = weeks >>>>>>> ahead >>>>>>> of tomorrow. >>>>>>>=20 >>>>>>> You can (and should) still actively send edits to the list and = I'll >>>>>>> update the text accordingly. Maybe we manage to get ready even >>>>>>> without a >>>>>>> call! >>>>>>>=20 >>>>>>> - Jouni & Dapeng >>>>>>>=20 >>>>>>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti: >>>>>>>> Folks, >>>>>>>>=20 >>>>>>>> The latest charter draft can be found here: >>>>>>>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The deadline for the text chnges are 31st July. I'll setup a = call for >>>>>>>> next week so that those who want to dial in and have verbal = commenting >>>>>>>> can do that. In a meanwhile, email works as usual for updates = and >>>>>>>> comments on the text. The actual milestone dates are to be done >>>>>>>> last but >>>>>>>> suggestions are more than welcome. >>>>>>>>=20 >>>>>>>> - Jouni & Dapeng >>>>>>=20 >>>>>> _______________________________________________ >>>>>> dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>=20 >>>=20 >=20 From nobody Mon Sep 1 06:25:27 2014 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 6BC4C1A0407 for ; Mon, 1 Sep 2014 06:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 I86vKTs4PlCC for ; Mon, 1 Sep 2014 06:25:23 -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 7A9811A0406 for ; Mon, 1 Sep 2014 06:25:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F235C107D7C; Mon, 1 Sep 2014 15:25:20 +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 mnnIJW4fpe-P; Mon, 1 Sep 2014 15:25:20 +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 CD5DC107D38; Mon, 1 Sep 2014 15:25:16 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.182]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 1 Sep 2014 15:25:16 +0200 From: Marco Liebsch To: Alper Yegin , "dmm@ietf.org" Thread-Topic: [DMM] 3GPP CSIPTO Thread-Index: AQHPxbmCbyq4sm/UWUmphplsxG5zipvsE8Lg Date: Mon, 1 Sep 2014 13:25:16 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D919A33D5@PALLENE.office.hd> References: 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_69756203DDDDE64E987BC4F70B71A26D919A33D5PALLENEofficehd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/UUm5FiJAcNZL9Eds98qvPXrGlVs Subject: Re: [DMM] 3GPP CSIPTO 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, 01 Sep 2014 13:25:26 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D919A33D5PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alper, thanks for posting the update. One clarifying question on the following ser= vice requirement: 'The 3GPP system shall minimize the number of connections of a UE without d= isrupting the UE's services, e.g. to ensure economical use of network resources' Can this be understood as the number of connections, which is to be minimiz= ed, is equal to the number of mobility session and associated IP addresses? Is this to minimize the states in the network, or is the intention to limit= the control-plane signaling with the mobile device to setup/teardown the connection? Thanks for your feedback in advance, marco From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Montag, 1. September 2014 09:51 To: dmm@ietf.org Subject: [DMM] 3GPP CSIPTO Dear DMMers, Here's an update on 3GPP SA1 CSIPTO work... Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting SA1 ha= s completed the CSIPTO normative work. As you might remember, SA1 is in charge of defining service requirements. The next step for CSIPTO is to initiate a work item in SA2. And here's a copy-paste of the normative requirements (accepted doc is S1-1= 43607.zip): Some types of services (e.g. streaming services, VOIP, VPN, HTTPS-Based Ser= vices) cannot tolerate a change of IP address of the UE without disruption = of the service. SIPTO can be performed with or without coordination between the UE and the = network. The following requirements apply to coordinated SIPTO: - The 3GPP system shall be able to support multiple connections that ar= e associated with the same defined IP network where each connection may or = may not support IP address preservation. - The 3GPP system shall be able to determine if an IP flow requires IP = address preservation or not. Based on this determination, the 3GPP network = shall be able to offload selected IP traffic in coordinated manner between = UE and the network, in order to minimize service disruption. - The 3GPP system shall be able to detect when a connection becomes su= boptimal and decide when to establish a new optimal connection to the same = defined IP network or use an existing connection. Note 1: The definition of optimal and suboptimal can be based on a num= ber of implementation criteria like geography, topology and load balancing = etc. - The 3GPP system shall minimize the number of connections of a UE with= out disrupting the UE's services, e.g. to ensure economical use of network = resources. - The 3GPP system shall be able to ensure that the actual average aggre= gate bit rate for IP flows of packet data network connections associated wi= th the same packet data network does not significantly exceed the subscribe= d aggregate maximum bit rate for this packet data network when two connecti= ons are used with the same defined IP network. Note 2: Requirements for Coordinated SIPTO do not apply to IMS. --_000_69756203DDDDE64E987BC4F70B71A26D919A33D5PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 <= /p>

thanks for posting the up= date. One clarifying question on the following service requirement:

 <= /p>

‘The 3GPP system= shall minimize the number of connections of a UE without disrupting the UE’s services, e.g. to ensure economical use of network resources= ’

 <= /p>

Can this be understood as= the number of connections, which is to be minimized, is equal to the
number of mobility session and associated IP addresses?

 <= /p>

Is this to minimize the s= tates in the network, or is the intention to limit the control-plane
signaling with the mobile device to setup/teardown the connection?

 <= /p>

Thanks for your feedback = in advance,

marco

 <= /p>

 <= /p>

 <= /p>

From: dmm [mai= lto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Montag, 1. September 2014 09:51
To: dmm@ietf.org
Subject: [DMM] 3GPP CSIPTO

 

Dear DMMers,

 

Here's an update on 3GPP SA1 CSIPTO work…=

 

Two weeks ago there was an SA1 meeting (SA1#67), and= in that meeting SA1 has completed the CSIPTO normative work.

As you might remember, SA1 is in charge of defining = service requirements.

 

The next step for CSIPTO is to initiate a work item = in SA2.

 

 

And here's a copy-paste of the normative requirement= s (accepted doc is S1-143607.zip):=

 

 

Some types of services (e.g. streaming services, VOIP,= VPN, HTTPS-Based Services) cannot tolerate a change of IP address of the U= E without disruption of the service.

SIPTO can be performed with or without= coordination between the UE and the network. The following requirements ap= ply to coordinated SIPTO:

- &nb= sp;   The 3GPP system shall be able to support multip= le connections that are associated with the same defined IP network where e= ach connection may or may not support IP address preservation.

- &nb= sp;   The 3GPP system shall be able to determine if a= n IP flow requires IP address preservation or not. Based on this determinat= ion, the 3GPP network shall be able to offload selected IP traffic in coord= inated manner between UE and the network, in order to minimize service disruption.

-      The 3GPP system shall be able to detect when a connect= ion becomes suboptimal and decide when to establish a new optimal connectio= n to the same defined IP network or use an existing connection.=

Note 1:  &n= bsp;   The definition of optimal and suboptimal can be based on a= number of implementation criteria like geography, topology and load balanc= ing etc.

- &n= bsp;   The 3GPP system shall minimize the number of co= nnections of a UE without disrupting the UE’s services, e.g. to ensur= e economical use of network resources.

- &n= bsp;   The 3GPP system shall be able to ensure that th= e actual average aggregate bit rate for IP flows of packet data network con= nections associated with the same packet data network does not significantl= y exceed the subscribed aggregate maximum bit rate for this packet data network when two connections are use= d with the same defined IP network.

Note 2:  Requirements for Coordinated SIPTO do not apply to= IMS.

--_000_69756203DDDDE64E987BC4F70B71A26D919A33D5PALLENEofficehd_-- From nobody Mon Sep 1 08:06:07 2014 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 D62531A0ACC for ; Mon, 1 Sep 2014 08:06:04 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 pciyCWNcNEOf for ; Mon, 1 Sep 2014 08:06:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 65C271A046B for ; Mon, 1 Sep 2014 07:39:34 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus003) with ESMTP (Nemesis) id 0MXGkd-1XsYF11gv7-00WCHb; Mon, 01 Sep 2014 16:39:30 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_94914258-3C3E-4B4D-834B-B79C2377CF16" From: Alper Yegin In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D919A33D5@PALLENE.office.hd> Date: Mon, 1 Sep 2014 17:39:32 +0300 Message-Id: References: <69756203DDDDE64E987BC4F70B71A26D919A33D5@PALLENE.office.hd> To: Marco Liebsch X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:6LdHHNNNK8gViKlI3DTlw/42UtfOA52yB6n2T2Mw9x+ SlNQ2REOZjpyAoPCHl63yZraHrM/XoJJqpV5MzVaxgad4VpBHA 0+lsIhQFCCGg+Wx/ATS8/4K5aiFOALc+T16lKBzl7fPEcKCsKN RXEt3FdNCEUFp+RoIm+D4YiYTTcR6hOkUYPKPiMk2ENHdmC/q6 99vBOBRrWCDvTjK/ZL+YmONpBpsvSi3BSXb/COnzpCQVakQBuk 7AYp+xH2BnDp2RVkxv7WspYxS9Ynur/q6JUzQ5IN1ov3GDzMF5 +FW02hqNRGlY1CBrGZkcLlpYiChRFPl/EXkQnw+dP8A9sZX/bG +Tbb/NAh2nI87mqyV2qKPrMao9fwhv6zcQ+MsE6gVh/tDwLW5W r4izoSuLU77CQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/66OZ_v-H5AMVgTSfiJuUCBNP4kw Cc: "dmm@ietf.org" Subject: Re: [DMM] 3GPP CSIPTO 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, 01 Sep 2014 15:06:05 -0000 --Apple-Mail=_94914258-3C3E-4B4D-834B-B79C2377CF16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Marco, > thanks for posting the update. One clarifying question on the = following service requirement: > =20 > =91The 3GPP system shall minimize the number of connections of a UE = without disrupting the > UE=92s services, e.g. to ensure economical use of network resources=92 > =20 > Can this be understood as the number of connections, which is to be = minimized, is equal to the > number of mobility session and associated IP addresses? You can say that. The idea is to make sure the simultaneous PDN connections do not keep = adding up each time the UE encounters a new GW. Alper > =20 > Is this to minimize the states in the network, or is the intention to = limit the control-plane > signaling with the mobile device to setup/teardown the connection? > =20 > Thanks for your feedback in advance, > marco > =20 > =20 > =20 > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin > Sent: Montag, 1. September 2014 09:51 > To: dmm@ietf.org > Subject: [DMM] 3GPP CSIPTO > =20 > Dear DMMers, > =20 > Here's an update on 3GPP SA1 CSIPTO work=85 > =20 > Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting = SA1 has completed the CSIPTO normative work. > As you might remember, SA1 is in charge of defining service = requirements. > =20 > The next step for CSIPTO is to initiate a work item in SA2. > =20 > =20 > And here's a copy-paste of the normative requirements (accepted doc is = S1-143607.zip): > =20 > =20 > Some types of services (e.g. streaming services, VOIP, VPN, = HTTPS-Based Services) cannot tolerate a change of IP address of the UE = without disruption of the service. > SIPTO can be performed with or without coordination between the UE and = the network. The following requirements apply to coordinated SIPTO: >=20 > - The 3GPP system shall be able to support multiple connections = that are associated with the same defined IP network where each = connection may or may not support IP address preservation. >=20 > - The 3GPP system shall be able to determine if an IP flow = requires IP address preservation or not. Based on this determination, = the 3GPP network shall be able to offload selected IP traffic in = coordinated manner between UE and the network, in order to minimize = service disruption. >=20 > - The 3GPP system shall be able to detect when a connection = becomes suboptimal and decide when to establish a new optimal connection = to the same defined IP network or use an existing connection. > Note 1: The definition of optimal and suboptimal can be based on = a number of implementation criteria like geography, topology and load = balancing etc. > - The 3GPP system shall minimize the number of connections of a UE = without disrupting the UE=92s services, e.g. to ensure economical use of = network resources. > - The 3GPP system shall be able to ensure that the actual average = aggregate bit rate for IP flows of packet data network connections = associated with the same packet data network does not significantly = exceed the subscribed aggregate maximum bit rate for this packet data = network when two connections are used with the same defined IP network. > Note 2: Requirements for Coordinated SIPTO do not apply to IMS. >=20 --Apple-Mail=_94914258-3C3E-4B4D-834B-B79C2377CF16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Marco,

Can = this be understood as the number of connections, which is to be = minimized, is equal to the
number of mobility session and associated = IP addresses?
Is = this to minimize the states in the network, or is the intention to limit = the control-plane
signaling with the mobile device to setup/teardown = the connection?
marco
 dmm = [mailto:dmm-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Montag, 1. September 2014 = 09:51
To: dmm@ietf.org
Subject: [DMM] 3GPP = CSIPTO
Dear = DMMers,
Here's an update on 3GPP = SA1 CSIPTO work=85
Two weeks ago there was = an SA1 meeting (SA1#67), and in that meeting SA1 has completed the = CSIPTO normative work.
As you might remember, SA1 is in charge of defining = service requirements.
The next step for CSIPTO = is to initiate a work item in SA2.
 
 

SIPTO = can be performed with or without coordination between the UE and the = network. The following requirements apply to coordinated = SIPTO:

-     The 3GPP system shall be able to support multiple = connections that are associated with the same defined IP network where = each connection may or may not support IP address = preservation.

-     The 3GPP system shall be able to determine if an IP flow = requires IP address preservation or not. Based on this determination, = the 3GPP network shall be able to offload selected IP traffic in = coordinated manner between UE and the network, in order to minimize = service disruption.

Note 2:  = Requirements for Coordinated SIPTO do not apply to = IMS.


= --Apple-Mail=_94914258-3C3E-4B4D-834B-B79C2377CF16-- From nobody Mon Sep 1 08:53:12 2014 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 1B3381A04B9 for ; Mon, 1 Sep 2014 08:53:10 -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 QYLq7ygXJF-5 for ; Mon, 1 Sep 2014 08:53:06 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2301A0670 for ; Mon, 1 Sep 2014 08:43:04 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ty20so6368337lab.11 for ; Mon, 01 Sep 2014 08:43:02 -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=VA7pko59mkjwQCUzMcvC+m155qSVB3CKqsARRUltZdo=; b=lmy8Q6h8VrLwnYSZBbMN8/ugATJAqAdxYocAAb6hfxqPhEtR7F8EKK1JJk6YGL29Jd kitA958qCxm/pUXTClo3N9n0WhD+oCbtH3zl9SrW5YnP7fT9EYeO4Xoj8wAabl/uEMKh 2CPWiS/cEmed6EOJuJEdNiFnEvaVEGFE9nsYKZLbrYfM0D+gOuC1QGXn1wklDhqm59Oi +946tz1OPshif4UCTrzmudTYaHS4qu0aUzzdeb4wmSRkSUPsBYJO3kLTXk5OTQCWbXkc arnrV2a28oCTmsc2gFKgIqEa+2f1RveOB3PC3YDezHX0H2yoSdQD4ImAezF98MypuyPt k1yQ== MIME-Version: 1.0 X-Received: by 10.112.128.228 with SMTP id nr4mr2925142lbb.42.1409586182738; Mon, 01 Sep 2014 08:43:02 -0700 (PDT) Received: by 10.114.244.73 with HTTP; Mon, 1 Sep 2014 08:43:02 -0700 (PDT) In-Reply-To: <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> Date: Mon, 1 Sep 2014 10:43:02 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Jqx2m6akLpdx3NBIP_DI3dCOtkw Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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: Mon, 01 Sep 2014 15:53:10 -0000 On Mon, Sep 1, 2014 at 3:25 AM, Jouni wrote: > > Alper, > > I hear your concern. Anyway, the division here is similar to (3GPP) stage= -2 and stage-3 work. The ""deployment models and scenarios" are the stage-2= descriptions and then we also need the protocol level solutions that are i= n separate documents. > Thanks Alper for raising this issue. 3GPP Stage 2 like in SA2 documents are architecture documents. I don't understand what is going on here. I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses. Yes, this document talks about deployment in just a few places, here is one occurrence: on page 64, PCC deployment options on page 94, PMIP based S5/S8 deployments, etc. So in all cases the protocol, i.e. PCC or PMIP is known. Regards, Behcet > Makes sense? > > - Jouni > > > On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: > >>> Okay, we are not going to define how the existing 3FPP system works - t= hat knowledge is assumed. What I thought goes into the document, for exampl= e, in the case of 3GPP system would be identifying the architecture changes= or modifications needed. If the deployment model assumes all network funct= ions are virtualized, the document states that and lays out the architectur= e based on that. Satoru's & Ryuji's vEPC deployment model (based on their s= olution) is IMHO a good example of what could be documented. The similar ap= plies for other system architectures such as SP Wi-Fi etc. >>> >> >> Jouni, >> >> The "architecture changes" would be based on the a "specific solution". = So, as part of describing a solution one can be talking about what you are = suggesting above. But I don't understand how we can be talking about "deplo= yment models and scenarios" before we agree on the solutions. >> >> Alper >> >> >> >> >>>>>>> o Enhanced mobility anchoring: define protocol solutions for a >>>>>>> gateway and mobility anchor assignment and mid-session mobilit= y >>>>>>> anchor switching that go beyond what has been specified, for >>>>>>> example, in RFC 6097, 6463, and 5142. Traffic steering >>>>>>> associated with the anchor switch is also in-scope if deemed >>>>>>> appropriate. >>>>>>> >>>>>>> o Forwarding path and signaling management: the function >>>>>>> that handles mobility management signaling interacts with the >>>>>>> DMM network elements for managing the forwarding state >>>>>>> associated with a mobile node's IP traffic. These two function= s >>>>>>> may or may not be collocated. Furthermore, the forwarding stat= e >>>>>>> may also be distributed into multiple network elements instead >>>>>>> of a single network element (e.g., anchor). Protocol extension= s >>>>>>> or new protocols will be specified to allow the above mentione= d >>>>>>> forwarding path and signalling management. >>>>>>> >>>>>> >>>>>> I cannot separate "mobility anchoring" from "fwding path and >>>>>> signaling management". >>>>>> Wherever you want to set your anchor or move your anchor to, you'd >>>>>> need signaling >>>>>> and setting up data path. The two are inseparable. >>>>>> Having said that, I'm OK to keep the current work item descriptions >>>>>> and finalize >>>>>> rechartering. Once we have detailed discussions about the breakdown >>>>> of the work, we >>>>>> can come back and refine the goals and milestones (as already stated >>>>> below [*]). >>>>> >>>>> The enhanced mobility anchoring above is/was rather MIP type solution= s >>>>> influenced with "anchors" like we understand today, while the >>>>> "forwarding path and signaling management" was meant for more future >>>>> oriented solutions where the forwarding path does not necessarily hav= e >>>>> anything mobility specific etc. >>>>> >>>> >>>> (Just FYI: It's not possible to gather what you are saying from readin= g >>>> the charter. Different people reading the charter may not have the sam= e >>>> understanding. But like I said, this is just FYI, I can live with this >>>> text until we come back and refine it later). >>> >>> Ok. I'll try to clarify the point the text tries to make. >>> >>> - Jouni >>> >>>> >>>> Thanks. >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>>> Any other opinions on collapsing these two? >>>>> >>>>> - Jouni >>>>> >>>>>>> o Exposing mobility state to mobile nodes and network nodes: >>>>>>> define solutions that allow, for example, mobile nodes to sele= ct >>>>>>> either a care-of address or a home address depending on an >>>>>>> application' mobility needs. In order to enable this >>>>>>> functionality, the network-side control functions and other >>>>>>> networking nodes must also be able to exchange appropriate >>>>>>> control information, as well as to the mobile nodes and their >>>>>>> applications. >>>>>>> >>>>>>> The working group may decide to extend the current milestones based= on >>>>>>> the new information and knowledge gained during working on other >>>>>>> documents listed in the initial milestones. [*] >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Alper >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Possible new documents and >>>>>>> milestones must still fit into the overall DMM charter scope as out= lined >>>>>>> above. >>>>>>> >>>>>>> Goals and Milestones: >>>>>>> >>>>>>> Feb 2015 - Submit 'The deployment models and scenarios' as a workin= g >>>>>>> group document(s). To be Informational RFC. >>>>>>> >>>>>>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group >>>>>>> document. To be Proposed Standard. >>>>>>> >>>>>>> Feb 2015 - Submit 'Forwarding path and signaling management' as a >>>>>>> working group document. To be Proposed Standard. >>>>>>> >>>>>>> May 2015 - Submit 'Exposing mobility state to mobile nodes and netw= ork >>>>>>> nodes' as a working group document(s). To be Proposed >>>>>>> Standard. >>>>>>> >>>>>>> >>>>>>> May 2015 - Submit 'The deployment models and scenarios' submitted t= o >>>>>>> the IESG. To be Informational RFC. >>>>>>> >>>>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to the IE= SG. >>>>>>> To be Proposed Standard. >>>>>>> >>>>>>> Jun 2015 - Submit 'Forwarding path and signaling management' submit= ted >>>>>>> to the IESG. To be Proposed Standard. >>>>>>> >>>>>>> Oct 2015 - Submit 'Exposing mobility state to mobile nodes and netw= ork >>>>>>> nodes' submitted to the IESG. To be Proposed Standard. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti: >>>>>>>> The webex sessions have been cancelled in accordance of better IET= F >>>>>>>> process compliancy. New dates will be announced rougghly two weeks >>>>>>>> ahead >>>>>>>> of tomorrow. >>>>>>>> >>>>>>>> You can (and should) still actively send edits to the list and I'l= l >>>>>>>> update the text accordingly. Maybe we manage to get ready even >>>>>>>> without a >>>>>>>> call! >>>>>>>> >>>>>>>> - Jouni & Dapeng >>>>>>>> >>>>>>>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti: >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> The latest charter draft can be found here: >>>>>>>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_= draft.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> The deadline for the text chnges are 31st July. I'll setup a call= for >>>>>>>>> next week so that those who want to dial in and have verbal comme= nting >>>>>>>>> can do that. In a meanwhile, email works as usual for updates and >>>>>>>>> comments on the text. The actual milestone dates are to be done >>>>>>>>> last but >>>>>>>>> suggestions are more than welcome. >>>>>>>>> >>>>>>>>> - 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 Mon Sep 1 11:34:48 2014 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 8B2581A0682 for ; Mon, 1 Sep 2014 11:34:46 -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 raimneOZzvoP for ; Mon, 1 Sep 2014 11:34:44 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721581A067B for ; Mon, 1 Sep 2014 11:34:43 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id mc6so6513606lab.37 for ; Mon, 01 Sep 2014 11:34:41 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZRjtDqKm+e4zEATYSsZvost6mv9BEu4yW2+k/1D9tBY=; b=dAIlpqUPJwaTpUAsXiqw5gRAg9G97vreLX9qnP5qqkQO86GMzPqlS47Rj7o1cEUotI ZOSmpNN/fdCo/l4vkKjTCCqV+lTqHQutvA1eCpnFk1OQbQ4X6UkCPwl4Fus3o3MJXYB0 J0jhN0R5220PaBUXdDKWDYUfDI8as2WpQuwlb7poInhYSd16VRDzkEBy5SkQp+Nwy7v9 mACV+kipN7itX4oUasBobAsDHrbQ/3KVGZx2tZLEoTt9jG6zhOlIbv0kjJ69ubJHMefj HLXJ+ImP04iLjXXjDEUKGRAdPCKfAN7iOQeVhnnwPHUhdBIxQnKeDceR0QARzPMiULNK CmIQ== X-Received: by 10.112.235.199 with SMTP id uo7mr28904137lbc.50.1409596481723; Mon, 01 Sep 2014 11:34:41 -0700 (PDT) Received: from [10.17.0.23] ([83.150.126.201]) by mx.google.com with ESMTPSA id pc2sm2176778lbb.5.2014.09.01.11.34.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Sep 2014 11:34:40 -0700 (PDT) Message-ID: <5404BC3D.1000406@gmail.com> Date: Mon, 01 Sep 2014 21:34:37 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/8z7HngczSB6fzb0Bm6tPVIFtPL0 Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 01 Sep 2014 18:34:46 -0000 Behcet, Obviously that protocols are known that the intended deployment is going to use. The details what goes inside that protocol are not. This holds for my example case 3GPP as well. We do not need to into same level of detail that e.g. 3GPP stage-2 has detailing all signaling flows and so on. I believe we as a WG are competent enough to make a fine division what level of detail is left for the "deployment models and scenarios" and what goes into protocol solutions. - Jouni 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti: > On Mon, Sep 1, 2014 at 3:25 AM, Jouni wrote: >> >> Alper, >> >> I hear your concern. Anyway, the division here is similar to (3GPP) stage-2 and stage-3 work. The ""deployment models and scenarios" are the stage-2 descriptions and then we also need the protocol level solutions that are in separate documents. >> > > Thanks Alper for raising this issue. > > 3GPP Stage 2 like in SA2 documents are architecture documents. > I don't understand what is going on here. > > I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses. > > Yes, this document talks about deployment in just a few places, here > is one occurrence: on page 64, PCC deployment options > on page 94, PMIP based S5/S8 deployments, etc. > > So in all cases the protocol, i.e. PCC or PMIP is known. > > Regards, > > Behcet >> Makes sense? >> >> - Jouni >> >> >> On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: >> >>>> Okay, we are not going to define how the existing 3FPP system works - that knowledge is assumed. What I thought goes into the document, for example, in the case of 3GPP system would be identifying the architecture changes or modifications needed. If the deployment model assumes all network functions are virtualized, the document states that and lays out the architecture based on that. Satoru's & Ryuji's vEPC deployment model (based on their solution) is IMHO a good example of what could be documented. The similar applies for other system architectures such as SP Wi-Fi etc. >>>> >>> >>> Jouni, >>> >>> The "architecture changes" would be based on the a "specific solution". So, as part of describing a solution one can be talking about what you are suggesting above. But I don't understand how we can be talking about "deployment models and scenarios" before we agree on the solutions. >>> >>> Alper >>> >>> >>> >>> >>>>>>>> o Enhanced mobility anchoring: define protocol solutions for a >>>>>>>> gateway and mobility anchor assignment and mid-session mobility >>>>>>>> anchor switching that go beyond what has been specified, for >>>>>>>> example, in RFC 6097, 6463, and 5142. Traffic steering >>>>>>>> associated with the anchor switch is also in-scope if deemed >>>>>>>> appropriate. >>>>>>>> >>>>>>>> o Forwarding path and signaling management: the function >>>>>>>> that handles mobility management signaling interacts with the >>>>>>>> DMM network elements for managing the forwarding state >>>>>>>> associated with a mobile node's IP traffic. These two functions >>>>>>>> may or may not be collocated. Furthermore, the forwarding state >>>>>>>> may also be distributed into multiple network elements instead >>>>>>>> of a single network element (e.g., anchor). Protocol extensions >>>>>>>> or new protocols will be specified to allow the above mentioned >>>>>>>> forwarding path and signalling management. >>>>>>>> >>>>>>> >>>>>>> I cannot separate "mobility anchoring" from "fwding path and >>>>>>> signaling management". >>>>>>> Wherever you want to set your anchor or move your anchor to, you'd >>>>>>> need signaling >>>>>>> and setting up data path. The two are inseparable. >>>>>>> Having said that, I'm OK to keep the current work item descriptions >>>>>>> and finalize >>>>>>> rechartering. Once we have detailed discussions about the breakdown >>>>>> of the work, we >>>>>>> can come back and refine the goals and milestones (as already stated >>>>>> below [*]). >>>>>> >>>>>> The enhanced mobility anchoring above is/was rather MIP type solutions >>>>>> influenced with "anchors" like we understand today, while the >>>>>> "forwarding path and signaling management" was meant for more future >>>>>> oriented solutions where the forwarding path does not necessarily have >>>>>> anything mobility specific etc. >>>>>> >>>>> >>>>> (Just FYI: It's not possible to gather what you are saying from reading >>>>> the charter. Different people reading the charter may not have the same >>>>> understanding. But like I said, this is just FYI, I can live with this >>>>> text until we come back and refine it later). >>>> >>>> Ok. I'll try to clarify the point the text tries to make. >>>> >>>> - Jouni >>>> >>>>> >>>>> Thanks. >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> >>>>>> Any other opinions on collapsing these two? >>>>>> >>>>>> - Jouni >>>>>> >>>>>>>> o Exposing mobility state to mobile nodes and network nodes: >>>>>>>> define solutions that allow, for example, mobile nodes to select >>>>>>>> either a care-of address or a home address depending on an >>>>>>>> application' mobility needs. In order to enable this >>>>>>>> functionality, the network-side control functions and other >>>>>>>> networking nodes must also be able to exchange appropriate >>>>>>>> control information, as well as to the mobile nodes and their >>>>>>>> applications. >>>>>>>> >>>>>>>> The working group may decide to extend the current milestones based on >>>>>>>> the new information and knowledge gained during working on other >>>>>>>> documents listed in the initial milestones. [*] >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Alper >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Possible new documents and >>>>>>>> milestones must still fit into the overall DMM charter scope as outlined >>>>>>>> above. >>>>>>>> >>>>>>>> Goals and Milestones: >>>>>>>> >>>>>>>> Feb 2015 - Submit 'The deployment models and scenarios' as a working >>>>>>>> group document(s). To be Informational RFC. >>>>>>>> >>>>>>>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group >>>>>>>> document. To be Proposed Standard. >>>>>>>> >>>>>>>> Feb 2015 - Submit 'Forwarding path and signaling management' as a >>>>>>>> working group document. To be Proposed Standard. >>>>>>>> >>>>>>>> May 2015 - Submit 'Exposing mobility state to mobile nodes and network >>>>>>>> nodes' as a working group document(s). To be Proposed >>>>>>>> Standard. >>>>>>>> >>>>>>>> >>>>>>>> May 2015 - Submit 'The deployment models and scenarios' submitted to >>>>>>>> the IESG. To be Informational RFC. >>>>>>>> >>>>>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG. >>>>>>>> To be Proposed Standard. >>>>>>>> >>>>>>>> Jun 2015 - Submit 'Forwarding path and signaling management' submitted >>>>>>>> to the IESG. To be Proposed Standard. >>>>>>>> >>>>>>>> Oct 2015 - Submit 'Exposing mobility state to mobile nodes and network >>>>>>>> nodes' submitted to the IESG. To be Proposed Standard. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti: >>>>>>>>> The webex sessions have been cancelled in accordance of better IETF >>>>>>>>> process compliancy. New dates will be announced rougghly two weeks >>>>>>>>> ahead >>>>>>>>> of tomorrow. >>>>>>>>> >>>>>>>>> You can (and should) still actively send edits to the list and I'll >>>>>>>>> update the text accordingly. Maybe we manage to get ready even >>>>>>>>> without a >>>>>>>>> call! >>>>>>>>> >>>>>>>>> - Jouni & Dapeng >>>>>>>>> >>>>>>>>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti: >>>>>>>>>> Folks, >>>>>>>>>> >>>>>>>>>> The latest charter draft can be found here: >>>>>>>>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The deadline for the text chnges are 31st July. I'll setup a call for >>>>>>>>>> next week so that those who want to dial in and have verbal commenting >>>>>>>>>> can do that. In a meanwhile, email works as usual for updates and >>>>>>>>>> comments on the text. The actual milestone dates are to be done >>>>>>>>>> last but >>>>>>>>>> suggestions are more than welcome. >>>>>>>>>> >>>>>>>>>> - 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 Sep 2 08:32:56 2014 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 49E6D1A005C for ; Tue, 2 Sep 2014 08:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 hq2zf5qJ85n4 for ; Tue, 2 Sep 2014 08:32:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3E71A063C for ; Tue, 2 Sep 2014 08:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22162; q=dns/txt; s=iport; t=1409671972; x=1410881572; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=J6dPuytvnWrW7yV7T5XwBJIjQpWtGBytTEtc+Faku5Y=; b=QfRF+9By32jyZ18lADQasBNiXSs+K11fH3m1sbXhBuUlm4d2WwQ9Ia+0 cjCsJdfN7lAwQi3Sa9tSDfWfPsxTeO7++fPTRTALecSFjU9gd0YyGCAFI WihPp3HBe6nJG4RQgNp5G/DsKlztwCw2Xq/eN5S40vNbN5KgacLIB4tst o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAB3iBVStJA2K/2dsb2JhbABagkdGU1cEyByHSgGBExZ3hAMBAQEDAXkFDQEIEQMBAQEhBzkUCQgCBAENBYg6CA27TAEXjnZGEQYBhEwFjx2CFIZohEOMGYJEhkGBbxaBXGwBgQZBgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,449,1406592000"; d="scan'208,217";a="351765307" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP; 02 Sep 2014 15:32:51 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s82FWpSW014454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Sep 2014 15:32:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 2 Sep 2014 10:32:51 -0500 From: "Sri Gundavelli (sgundave)" To: Alper Yegin , Marco Liebsch Thread-Topic: [DMM] 3GPP CSIPTO Thread-Index: AQHPxsMoh8Y7pbUki0KQ6nS3uRBz5w== Date: Tue, 2 Sep 2014 15:32:51 +0000 Message-ID: In-Reply-To: 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.217] Content-Type: multipart/alternative; boundary="_000_D02B301016072Bsgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/3CPBnUjt_348hEQ9EXJMJ7YeRvY Cc: "dmm@ietf.org" Subject: Re: [DMM] 3GPP CSIPTO 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, 02 Sep 2014 15:32:55 -0000 --_000_D02B301016072Bsgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Alper - > The idea is to make sure the simultaneous PDN connections do not keep add= ing up each time the UE encounters a new GW. Is that not truly a deployment consideration ? If the approach is gateway s= election based on application/CN basis, can the network control this ? Regards Sri From: Alper Yegin > Date: Monday, September 1, 2014 7:39 AM To: Marco Liebsch > Cc: "dmm@ietf.org" > Subject: Re: [DMM] 3GPP CSIPTO Hi Marco, thanks for posting the update. One clarifying question on the following ser= vice requirement: =91The 3GPP system shall minimize the number of connections of a UE without= disrupting the UE=92s services, e.g. to ensure economical use of network resources=92 Can this be understood as the number of connections, which is to be minimiz= ed, is equal to the number of mobility session and associated IP addresses? You can say that. The idea is to make sure the simultaneous PDN connections do not keep addin= g up each time the UE encounters a new GW. Alper Is this to minimize the states in the network, or is the intention to limit= the control-plane signaling with the mobile device to setup/teardown the connection? Thanks for your feedback in advance, marco From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Montag, 1. September 2014 09:51 To: dmm@ietf.org Subject: [DMM] 3GPP CSIPTO Dear DMMers, Here's an update on 3GPP SA1 CSIPTO work=85 Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting SA1 ha= s completed the CSIPTO normative work. As you might remember, SA1 is in charge of defining service requirements. The next step for CSIPTO is to initiate a work item in SA2. And here's a copy-paste of the normative requirements (accepted doc is S1-1= 43607.zip): Some types of services (e.g. streaming services, VOIP, VPN, HTTPS-Based Ser= vices) cannot tolerate a change of IP address of the UE without disruption = of the service. SIPTO can be performed with or without coordination between the UE and the = network. The following requirements apply to coordinated SIPTO: - The 3GPP system shall be able to support multiple connections that ar= e associated with the same defined IP network where each connection may or = may not support IP address preservation. - The 3GPP system shall be able to determine if an IP flow requires IP = address preservation or not. Based on this determination, the 3GPP network = shall be able to offload selected IP traffic in coordinated manner between = UE and the network, in order to minimize service disruption. - The 3GPP system shall be able to detect when a connection becomes su= boptimal and decide when to establish a new optimal connection to the same = defined IP network or use an existing connection. Note 1: The definition of optimal and suboptimal can be based on a num= ber of implementation criteria like geography, topology and load balancing = etc. - The 3GPP system shall minimize the number of connections of a UE with= out disrupting the UE=92s services, e.g. to ensure economical use of networ= k resources. - The 3GPP system shall be able to ensure that the actual average aggre= gate bit rate for IP flows of packet data network connections associated wi= th the same packet data network does not significantly exceed the subscribe= d aggregate maximum bit rate for this packet data network when two connecti= ons are used with the same defined IP network. Note 2: Requirements for Coordinated SIPTO do not apply to IMS. --_000_D02B301016072Bsgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Alper - 

> The idea is to make sure the simultaneous PDN connections do= not keep adding up each time the UE encounters a new GW.

Is that not truly a deployment consideration ? If the approach is gate= way selection based on application/CN basis, can the network control this ?=


Regards
Sri




From: Alper Yegin <alper.yegin@yegin.org>
Date: Monday, September 1, 2014 7:3= 9 AM
To: Marco Liebsch <Marco.Liebsch@neclab.eu>
Cc: "dmm@ietf.org" <dmm@ietf.= org>
Subject: Re: [DMM] 3GPP CSIPTO

Hi Marco,

thanks for posting the update. One clarifying question on= the following service requirement:
 
=91The 3GPP system shall minimize the number of connec= tions of a UE without disrupting the
UE=92s services, e.g. to ensure economical use of network resources=92<= o:p>
 
Can this be understood as the number of connections, whic= h is to be minimized, is equal to the
number of mobility session and associated IP addresses?

You can say that.

The idea is to make sure the simultaneous PDN connections do not keep = adding up each time the UE encounters a new GW.

Alper





 
Is this to minimize the states in the network, or is the = intention to limit the control-plane
signaling with the mobile device to setup/teardown the connection?
 
Thanks for your feedback in advance,
marco
 
 
 
From:=  dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegi= n
Sent: Montag, 1. S= eptember 2014 09:51
To: dmm@ietf.org
Subject: [DMM] 3GP= P CSIPTO
 
Dear DMMers,
 
Here's an update on 3GPP SA1 CSIPTO work=85
 
Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting SA1 ha= s completed the CSIPTO normative work.
As you might remember, SA1 is in charge of defining service requirements.
 
The next step for CSIPTO is to initiate a work item in SA2.
 
 
And here's a copy-paste of the normative requirements (accepted doc is = ;S= 1-143607.zip):
 
 
Some types of services (e.g. streaming services, VOIP,= VPN, HTTPS-Based Services) cannot tolerate a change of IP address of the U= E without disruption of the service.

SIPTO can be performed with or without coordination be= tween the UE and the network. The following requirements apply to coordinat= ed SIPTO:

- The 3GPP system shall be able to support mult= iple connections that are associated with the same defined IP network where each connection may or may not support IP address preservation.

- The 3GPP system shall be able to determine if= an IP flow requires IP address preservation or not. Based on this determination, the 3GPP network shall be able to offload selected IP traff= ic in coordinated manner between UE and the network, in order to minimize s= ervice disruption.

- = ;The 3GPP system shall be able to detect= when a connection becomes suboptimal and decide when to establish a new optimal connection to the same defined IP network or use an existing conne= ction.
Note 1:      The definition of opt= imal and suboptimal can be based on a number of implementation criteria lik= e geography, topology and load balancing etc.
- The 3GPP system shall minimize the number of = connections of a UE without disrupting the UE=92s services, e.g. to ensure economical use of network resources.
- The 3GPP system shall be able to ensure that = the actual average aggregate bit rate for IP flows of packet data network connections associated with the same packet data network does not signific= antly exceed the subscribed aggregate maximum bit rate for this packet data= network when two connections are used with the same defined IP network.

Note 2:  Requirements for Coordinated SIPTO do no= t apply to IMS.


--_000_D02B301016072Bsgundaveciscocom_-- From nobody Tue Sep 2 11:05:25 2014 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 3F4A61A0537 for ; Tue, 2 Sep 2014 11:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 kqGueN70Xko9 for ; Tue, 2 Sep 2014 11:05:19 -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 70F411A0535 for ; Tue, 2 Sep 2014 11:05:19 -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 s82I5Ipq023804; Tue, 2 Sep 2014 11:05:18 -0700 Received: from XCH-PHX-512.sw.nos.boeing.com (xch-phx-512.sw.nos.boeing.com [10.57.37.29]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s82I5E34023759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 2 Sep 2014 11:05:14 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-512.sw.nos.boeing.com ([169.254.12.132]) with mapi id 14.03.0181.006; Tue, 2 Sep 2014 11:05:12 -0700 From: "Templin, Fred L" To: "dmm@ietf.org" Thread-Topic: I-D Action: draft-templin-aeroent-00.txt Thread-Index: AQHPxtaE1zK83Wp2d0Cjz54dorhhWpvuIYdw Date: Tue, 2 Sep 2014 18:05:12 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D031C3@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: http://mailarchive.ietf.org/arch/msg/dmm/dOv-Zg9mrWArWgNtgRI6CEceUn0 Subject: [DMM] FW: I-D Action: draft-templin-aeroent-00.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, 02 Sep 2014 18:05:21 -0000 Hello, During the call today, there was some interest expressed in learning more about the enterprise network mobility use case. I have submitted a new brief document called "AERO Enterprise Network Profile" (below) that provides a discussion of distributed mobility management needs for enterprise networks. Although the document specifically cites AERO, the use case applies to any solution alternative that could meet the requirements. Also, I am not asking this document be considered as a dmm wg item at this time, but rather offering it for informational purposes. Please let me know if there are any questions or comments. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, September 02, 2014 10:51 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-aeroent-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : AERO Enterprise Network Profile Author : Fred L. Templin Filename : draft-templin-aeroent-00.txt Pages : 12 Date : 2014-09-02 Abstract: Enterprise networks provide a secured data communications infrastructure built for the purpose of information sharing and increased productivity for end users within the organization. Enterprise networks are often organized as private Internets unto themselves that connect to the global Internet either not at all or via firewalls, proxies, and/or other network securing devices. This document discusses an AERO enterprise network profile that outlines new and more flexible methods for connecting, tracking and managing mobile organizational assets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-aeroent/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-templin-aeroent-00 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Sep 2 13:39:22 2014 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 806C31A06B2 for ; Tue, 2 Sep 2014 13:39:21 -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 aUWFQ9v-HD1g for ; Tue, 2 Sep 2014 13:39:20 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4011A0494 for ; Tue, 2 Sep 2014 13:39:19 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hz20so8595311lab.31 for ; Tue, 02 Sep 2014 13:39:17 -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=fyhbO7u/PrE6DUr2PTnOP7cNBi1G4qTc4IxaT5nV67w=; b=VNUQ84HBt1ZhL1t+DSuJHShGQcSp7q9/Rl3NqXvg2FbyPgHEKVfL4ZHpdEh9BxugV+ Mft0qkHQy5QNwFdfmiSdPXQ+FWowIBJtTsJinsnUaH9pB3lKUcw0Ya9p1E0VhYE5CV/w Y6SV/fJiy+JlFKoh9eFrNNPTBVvwMYd48mpr0+dcm73JFfX36AA3qJuOjuXb315BrltO AHzLFdamIxgvELPaA9o9CYQ78iWl6UnpinDiQ2m7gaAWppiU55YtuRYjXhRcHMJ/u4jT QCr8fdQYW4xXm81eTmGTCBinQtZHeBXecQF2C383JgNZTfiYzaP6b9NXh5KfglOf3sQq ux1w== MIME-Version: 1.0 X-Received: by 10.112.148.133 with SMTP id ts5mr35447651lbb.45.1409690357761; Tue, 02 Sep 2014 13:39:17 -0700 (PDT) Received: by 10.114.244.73 with HTTP; Tue, 2 Sep 2014 13:39:17 -0700 (PDT) In-Reply-To: <5404BC3D.1000406@gmail.com> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> Date: Tue, 2 Sep 2014 15:39:17 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/S6Xb4F-_LxOALVvocUWqU7VF4fc Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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: Tue, 02 Sep 2014 20:39:21 -0000 On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen wrote: > Behcet, > > Obviously that protocols are known that the intended deployment is going to > use. The details what goes inside that protocol are not. This holds for my > example case 3GPP as well. > > We do not need to into same level of detail that e.g. 3GPP stage-2 has > detailing all signaling flows and so on. I believe we as a WG are competent > enough to make a fine division what level of detail is left for the > "deployment models and scenarios" and what goes into protocol solutions. > I hope you read previous mails on this issue. I think it clear that 3GPP agrees with IETF on the interpretation of deployment. How can we close our eyes on this and try to put the horse before the cart? Why not simply remove it? Regards, Behcet > - Jouni > > 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti: > >> On Mon, Sep 1, 2014 at 3:25 AM, Jouni wrote: >>> >>> >>> Alper, >>> >>> I hear your concern. Anyway, the division here is similar to (3GPP) >>> stage-2 and stage-3 work. The ""deployment models and scenarios" are the >>> stage-2 descriptions and then we also need the protocol level solutions that >>> are in separate documents. >>> >> >> Thanks Alper for raising this issue. >> >> 3GPP Stage 2 like in SA2 documents are architecture documents. >> I don't understand what is going on here. >> >> I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses. >> >> Yes, this document talks about deployment in just a few places, here >> is one occurrence: on page 64, PCC deployment options >> on page 94, PMIP based S5/S8 deployments, etc. >> >> So in all cases the protocol, i.e. PCC or PMIP is known. >> >> Regards, >> >> Behcet >>> >>> Makes sense? >>> >>> - Jouni >>> >>> >>> On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: >>> >>>>> Okay, we are not going to define how the existing 3FPP system works - >>>>> that knowledge is assumed. What I thought goes into the document, for >>>>> example, in the case of 3GPP system would be identifying the architecture >>>>> changes or modifications needed. If the deployment model assumes all network >>>>> functions are virtualized, the document states that and lays out the >>>>> architecture based on that. Satoru's & Ryuji's vEPC deployment model (based >>>>> on their solution) is IMHO a good example of what could be documented. The >>>>> similar applies for other system architectures such as SP Wi-Fi etc. >>>>> >>>> >>>> Jouni, >>>> >>>> The "architecture changes" would be based on the a "specific solution". >>>> So, as part of describing a solution one can be talking about what you are >>>> suggesting above. But I don't understand how we can be talking about >>>> "deployment models and scenarios" before we agree on the solutions. >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>>>>>>> o Enhanced mobility anchoring: define protocol solutions for a >>>>>>>>> gateway and mobility anchor assignment and mid-session >>>>>>>>> mobility >>>>>>>>> anchor switching that go beyond what has been specified, for >>>>>>>>> example, in RFC 6097, 6463, and 5142. Traffic steering >>>>>>>>> associated with the anchor switch is also in-scope if deemed >>>>>>>>> appropriate. >>>>>>>>> >>>>>>>>> o Forwarding path and signaling management: the function >>>>>>>>> that handles mobility management signaling interacts with the >>>>>>>>> DMM network elements for managing the forwarding state >>>>>>>>> associated with a mobile node's IP traffic. These two >>>>>>>>> functions >>>>>>>>> may or may not be collocated. Furthermore, the forwarding >>>>>>>>> state >>>>>>>>> may also be distributed into multiple network elements >>>>>>>>> instead >>>>>>>>> of a single network element (e.g., anchor). Protocol >>>>>>>>> extensions >>>>>>>>> or new protocols will be specified to allow the above >>>>>>>>> mentioned >>>>>>>>> forwarding path and signalling management. >>>>>>>>> >>>>>>>> >>>>>>>> I cannot separate "mobility anchoring" from "fwding path and >>>>>>>> signaling management". >>>>>>>> Wherever you want to set your anchor or move your anchor to, you'd >>>>>>>> need signaling >>>>>>>> and setting up data path. The two are inseparable. >>>>>>>> Having said that, I'm OK to keep the current work item descriptions >>>>>>>> and finalize >>>>>>>> rechartering. Once we have detailed discussions about the breakdown >>>>>>> >>>>>>> of the work, we >>>>>>>> >>>>>>>> can come back and refine the goals and milestones (as already stated >>>>>>> >>>>>>> below [*]). >>>>>>> >>>>>>> The enhanced mobility anchoring above is/was rather MIP type >>>>>>> solutions >>>>>>> influenced with "anchors" like we understand today, while the >>>>>>> "forwarding path and signaling management" was meant for more future >>>>>>> oriented solutions where the forwarding path does not necessarily >>>>>>> have >>>>>>> anything mobility specific etc. >>>>>>> >>>>>> >>>>>> (Just FYI: It's not possible to gather what you are saying from >>>>>> reading >>>>>> the charter. Different people reading the charter may not have the >>>>>> same >>>>>> understanding. But like I said, this is just FYI, I can live with this >>>>>> text until we come back and refine it later). >>>>> >>>>> >>>>> Ok. I'll try to clarify the point the text tries to make. >>>>> >>>>> - Jouni >>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Alper >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Any other opinions on collapsing these two? >>>>>>> >>>>>>> - Jouni >>>>>>> >>>>>>>>> o Exposing mobility state to mobile nodes and network nodes: >>>>>>>>> define solutions that allow, for example, mobile nodes to >>>>>>>>> select >>>>>>>>> either a care-of address or a home address depending on an >>>>>>>>> application' mobility needs. In order to enable this >>>>>>>>> functionality, the network-side control functions and other >>>>>>>>> networking nodes must also be able to exchange appropriate >>>>>>>>> control information, as well as to the mobile nodes and their >>>>>>>>> applications. >>>>>>>>> >>>>>>>>> The working group may decide to extend the current milestones based >>>>>>>>> on >>>>>>>>> the new information and knowledge gained during working on other >>>>>>>>> documents listed in the initial milestones. [*] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Alper >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Possible new documents and >>>>>>>>> milestones must still fit into the overall DMM charter scope as >>>>>>>>> outlined >>>>>>>>> above. >>>>>>>>> >>>>>>>>> Goals and Milestones: >>>>>>>>> >>>>>>>>> Feb 2015 - Submit 'The deployment models and scenarios' as a >>>>>>>>> working >>>>>>>>> group document(s). To be Informational RFC. >>>>>>>>> >>>>>>>>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group >>>>>>>>> document. To be Proposed Standard. >>>>>>>>> >>>>>>>>> Feb 2015 - Submit 'Forwarding path and signaling management' as a >>>>>>>>> working group document. To be Proposed Standard. >>>>>>>>> >>>>>>>>> May 2015 - Submit 'Exposing mobility state to mobile nodes and >>>>>>>>> network >>>>>>>>> nodes' as a working group document(s). To be Proposed >>>>>>>>> Standard. >>>>>>>>> >>>>>>>>> >>>>>>>>> May 2015 - Submit 'The deployment models and scenarios' submitted >>>>>>>>> to >>>>>>>>> the IESG. To be Informational RFC. >>>>>>>>> >>>>>>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to the >>>>>>>>> IESG. >>>>>>>>> To be Proposed Standard. >>>>>>>>> >>>>>>>>> Jun 2015 - Submit 'Forwarding path and signaling management' >>>>>>>>> submitted >>>>>>>>> to the IESG. To be Proposed Standard. >>>>>>>>> >>>>>>>>> Oct 2015 - Submit 'Exposing mobility state to mobile nodes and >>>>>>>>> network >>>>>>>>> nodes' submitted to the IESG. To be Proposed Standard. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti: >>>>>>>>>> >>>>>>>>>> The webex sessions have been cancelled in accordance of better >>>>>>>>>> IETF >>>>>>>>>> process compliancy. New dates will be announced rougghly two weeks >>>>>>>>>> ahead >>>>>>>>>> of tomorrow. >>>>>>>>>> >>>>>>>>>> You can (and should) still actively send edits to the list and >>>>>>>>>> I'll >>>>>>>>>> update the text accordingly. Maybe we manage to get ready even >>>>>>>>>> without a >>>>>>>>>> call! >>>>>>>>>> >>>>>>>>>> - Jouni & Dapeng >>>>>>>>>> >>>>>>>>>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti: >>>>>>>>>>> >>>>>>>>>>> Folks, >>>>>>>>>>> >>>>>>>>>>> The latest charter draft can be found here: >>>>>>>>>>> >>>>>>>>>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The deadline for the text chnges are 31st July. I'll setup a call >>>>>>>>>>> for >>>>>>>>>>> next week so that those who want to dial in and have verbal >>>>>>>>>>> commenting >>>>>>>>>>> can do that. In a meanwhile, email works as usual for updates and >>>>>>>>>>> comments on the text. The actual milestone dates are to be done >>>>>>>>>>> last but >>>>>>>>>>> suggestions are more than welcome. >>>>>>>>>>> >>>>>>>>>>> - 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 Sep 2 14:50:16 2014 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 CE6581A88D8 for ; Tue, 2 Sep 2014 14:50:13 -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 4X4bSU9QVM1Y for ; Tue, 2 Sep 2014 14:50:12 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8071A88D6 for ; Tue, 2 Sep 2014 14:50:12 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ty20so8605327lab.2 for ; Tue, 02 Sep 2014 14:50:10 -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=0C4LecKuW8H2qrGTwYRHtPPq53nl1B+Ogcdu/18Mwe0=; b=H3MYC3Uf/j+wKOroY6DTlfTPEu8jjsUZadA0qOiLQz2RbUVdAoLDzHAWP0jgqJKM7u QZUzaO8Sv/XKfDKCgBDHW+KzoIXk16dpRT+q+TPMtFZy5cuxe0+0fYsNhUf/3jj58rJ8 0Y62UGofhyOMreBok7RX1U+caZh+ZWIoy8ZDl9Wn5jJkci2MYZ+mQJuqCNFahWmJRSHF 7yISzkxfOa6piTvowmqNClTIqvTWsghrISYNU/JQ3eEklDmLEhGQCAAJPSKmq76XoXTr +YS4oUiUypnLn31cYtxzE9TdJgJCS6f5ZYfC9boJijO7+k9jGeDu45Biidy+8t4TDGZH 5Pdg== X-Received: by 10.152.205.5 with SMTP id lc5mr19167211lac.45.1409694610407; Tue, 02 Sep 2014 14:50:10 -0700 (PDT) Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id tc8sm6896982lbb.8.2014.09.02.14.50.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Sep 2014 14:50:09 -0700 (PDT) Message-ID: <54063B90.9020909@gmail.com> Date: Wed, 03 Sep 2014 00:50:08 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/AADdy2hE5IXLHrpsMJHOngttaww Subject: [DMM] interim call #1 and rechater text 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, 02 Sep 2014 21:50:14 -0000 Folks, Check the charter text we came up with during the interim call #1. The diffs are here: https://github.com/jounikor/dmm-re-charter/commit/4475c1c7aeac024171f6b669d330cfae98bdc283 And the "clean" text is here: https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt Have a look at the text. If you agree with the content we'll start moving this forward. The minutes and stuff from the interim call will follow shortly. - Jouni & Dapeng From nobody Tue Sep 2 22:07:40 2014 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 3DD101A8A0C for ; Tue, 2 Sep 2014 22:07:35 -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 HFBkaxdFr4Iy for ; Tue, 2 Sep 2014 22:07:32 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9730D1A8A23 for ; Tue, 2 Sep 2014 22:07:30 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gl10so8961442lab.38 for ; Tue, 02 Sep 2014 22:07: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8r2pjIb7lDdg/9KeMMtPTaC2W3qiEE5FDcPDSmea7vY=; b=1B/oyE77NaMBLuF3KG4FZ03cKd4I90ZFX78zsvBfm37BsDPhbTxR03fdbqUT3vJE0Z bhPfNXFYbc6ip93xw27mYlYNdUZXgPLchFkmkk5r1FUejzSjsJr6GSgbXZ3Gn4LBLwDw a0DlkPSxJXxkGkHmPhAsBwzEN4XS59RUum+3ZLBwor/TkN+JB8PYO2ZFPo3iRKW3UH+5 F3L1sBwqSkomlWIGu5zt5VAMKJneuU8E92hXYTNk4lcqwg8wm1E2jy7puPOhJztW4JLE E/rhn92zrNYBiJefD7d4pueN/dUFDMmyIF6tEiztNJ4KZQ9bp5E571U9VhWu2LL6hC9H vMWQ== X-Received: by 10.112.147.74 with SMTP id ti10mr36911400lbb.29.1409720848844; Tue, 02 Sep 2014 22:07:28 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id xe10sm7783878lbb.37.2014.09.02.22.07.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Sep 2014 22:07:27 -0700 (PDT) Message-ID: <5406A20F.60604@gmail.com> Date: Wed, 03 Sep 2014 08:07:27 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/LoqM0xkd3uwpYAcTv_R0T_YyZH4 Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 03 Sep 2014 05:07:36 -0000 We were on this in yesterday's interim call. We have a proposal text now. You were also on the call but I did not record you commenting anything during the discussion we had on this particular topic. Are you now saying the resolution we have now in the charter text is not adequate? - JOuni 9/2/2014 11:39 PM, Behcet Sarikaya kirjoitti: > On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen wrote: >> Behcet, >> >> Obviously that protocols are known that the intended deployment is going to >> use. The details what goes inside that protocol are not. This holds for my >> example case 3GPP as well. >> >> We do not need to into same level of detail that e.g. 3GPP stage-2 has >> detailing all signaling flows and so on. I believe we as a WG are competent >> enough to make a fine division what level of detail is left for the >> "deployment models and scenarios" and what goes into protocol solutions. >> > > I hope you read previous mails on this issue. > > I think it clear that 3GPP agrees with IETF on the interpretation of > deployment. How can we close our eyes on this and try to put the horse > before the cart? > > Why not simply remove it? > > Regards, > Behcet > > > >> - Jouni >> >> 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti: >> >>> On Mon, Sep 1, 2014 at 3:25 AM, Jouni wrote: >>>> >>>> >>>> Alper, >>>> >>>> I hear your concern. Anyway, the division here is similar to (3GPP) >>>> stage-2 and stage-3 work. The ""deployment models and scenarios" are the >>>> stage-2 descriptions and then we also need the protocol level solutions that >>>> are in separate documents. >>>> >>> >>> Thanks Alper for raising this issue. >>> >>> 3GPP Stage 2 like in SA2 documents are architecture documents. >>> I don't understand what is going on here. >>> >>> I am looking at 23.402 on Architecture Enhancements for non-3GPP accesses. >>> >>> Yes, this document talks about deployment in just a few places, here >>> is one occurrence: on page 64, PCC deployment options >>> on page 94, PMIP based S5/S8 deployments, etc. >>> >>> So in all cases the protocol, i.e. PCC or PMIP is known. >>> >>> Regards, >>> >>> Behcet >>>> >>>> Makes sense? >>>> >>>> - Jouni >>>> >>>> >>>> On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: >>>> >>>>>> Okay, we are not going to define how the existing 3FPP system works - >>>>>> that knowledge is assumed. What I thought goes into the document, for >>>>>> example, in the case of 3GPP system would be identifying the architecture >>>>>> changes or modifications needed. If the deployment model assumes all network >>>>>> functions are virtualized, the document states that and lays out the >>>>>> architecture based on that. Satoru's & Ryuji's vEPC deployment model (based >>>>>> on their solution) is IMHO a good example of what could be documented. The >>>>>> similar applies for other system architectures such as SP Wi-Fi etc. >>>>>> >>>>> >>>>> Jouni, >>>>> >>>>> The "architecture changes" would be based on the a "specific solution". >>>>> So, as part of describing a solution one can be talking about what you are >>>>> suggesting above. But I don't understand how we can be talking about >>>>> "deployment models and scenarios" before we agree on the solutions. >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> >>>>>>>>>> o Enhanced mobility anchoring: define protocol solutions for a >>>>>>>>>> gateway and mobility anchor assignment and mid-session >>>>>>>>>> mobility >>>>>>>>>> anchor switching that go beyond what has been specified, for >>>>>>>>>> example, in RFC 6097, 6463, and 5142. Traffic steering >>>>>>>>>> associated with the anchor switch is also in-scope if deemed >>>>>>>>>> appropriate. >>>>>>>>>> >>>>>>>>>> o Forwarding path and signaling management: the function >>>>>>>>>> that handles mobility management signaling interacts with the >>>>>>>>>> DMM network elements for managing the forwarding state >>>>>>>>>> associated with a mobile node's IP traffic. These two >>>>>>>>>> functions >>>>>>>>>> may or may not be collocated. Furthermore, the forwarding >>>>>>>>>> state >>>>>>>>>> may also be distributed into multiple network elements >>>>>>>>>> instead >>>>>>>>>> of a single network element (e.g., anchor). Protocol >>>>>>>>>> extensions >>>>>>>>>> or new protocols will be specified to allow the above >>>>>>>>>> mentioned >>>>>>>>>> forwarding path and signalling management. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I cannot separate "mobility anchoring" from "fwding path and >>>>>>>>> signaling management". >>>>>>>>> Wherever you want to set your anchor or move your anchor to, you'd >>>>>>>>> need signaling >>>>>>>>> and setting up data path. The two are inseparable. >>>>>>>>> Having said that, I'm OK to keep the current work item descriptions >>>>>>>>> and finalize >>>>>>>>> rechartering. Once we have detailed discussions about the breakdown >>>>>>>> >>>>>>>> of the work, we >>>>>>>>> >>>>>>>>> can come back and refine the goals and milestones (as already stated >>>>>>>> >>>>>>>> below [*]). >>>>>>>> >>>>>>>> The enhanced mobility anchoring above is/was rather MIP type >>>>>>>> solutions >>>>>>>> influenced with "anchors" like we understand today, while the >>>>>>>> "forwarding path and signaling management" was meant for more future >>>>>>>> oriented solutions where the forwarding path does not necessarily >>>>>>>> have >>>>>>>> anything mobility specific etc. >>>>>>>> >>>>>>> >>>>>>> (Just FYI: It's not possible to gather what you are saying from >>>>>>> reading >>>>>>> the charter. Different people reading the charter may not have the >>>>>>> same >>>>>>> understanding. But like I said, this is just FYI, I can live with this >>>>>>> text until we come back and refine it later). >>>>>> >>>>>> >>>>>> Ok. I'll try to clarify the point the text tries to make. >>>>>> >>>>>> - Jouni >>>>>> >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Alper >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Any other opinions on collapsing these two? >>>>>>>> >>>>>>>> - Jouni >>>>>>>> >>>>>>>>>> o Exposing mobility state to mobile nodes and network nodes: >>>>>>>>>> define solutions that allow, for example, mobile nodes to >>>>>>>>>> select >>>>>>>>>> either a care-of address or a home address depending on an >>>>>>>>>> application' mobility needs. In order to enable this >>>>>>>>>> functionality, the network-side control functions and other >>>>>>>>>> networking nodes must also be able to exchange appropriate >>>>>>>>>> control information, as well as to the mobile nodes and their >>>>>>>>>> applications. >>>>>>>>>> >>>>>>>>>> The working group may decide to extend the current milestones based >>>>>>>>>> on >>>>>>>>>> the new information and knowledge gained during working on other >>>>>>>>>> documents listed in the initial milestones. [*] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Alper >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Possible new documents and >>>>>>>>>> milestones must still fit into the overall DMM charter scope as >>>>>>>>>> outlined >>>>>>>>>> above. >>>>>>>>>> >>>>>>>>>> Goals and Milestones: >>>>>>>>>> >>>>>>>>>> Feb 2015 - Submit 'The deployment models and scenarios' as a >>>>>>>>>> working >>>>>>>>>> group document(s). To be Informational RFC. >>>>>>>>>> >>>>>>>>>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group >>>>>>>>>> document. To be Proposed Standard. >>>>>>>>>> >>>>>>>>>> Feb 2015 - Submit 'Forwarding path and signaling management' as a >>>>>>>>>> working group document. To be Proposed Standard. >>>>>>>>>> >>>>>>>>>> May 2015 - Submit 'Exposing mobility state to mobile nodes and >>>>>>>>>> network >>>>>>>>>> nodes' as a working group document(s). To be Proposed >>>>>>>>>> Standard. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> May 2015 - Submit 'The deployment models and scenarios' submitted >>>>>>>>>> to >>>>>>>>>> the IESG. To be Informational RFC. >>>>>>>>>> >>>>>>>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to the >>>>>>>>>> IESG. >>>>>>>>>> To be Proposed Standard. >>>>>>>>>> >>>>>>>>>> Jun 2015 - Submit 'Forwarding path and signaling management' >>>>>>>>>> submitted >>>>>>>>>> to the IESG. To be Proposed Standard. >>>>>>>>>> >>>>>>>>>> Oct 2015 - Submit 'Exposing mobility state to mobile nodes and >>>>>>>>>> network >>>>>>>>>> nodes' submitted to the IESG. To be Proposed Standard. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti: >>>>>>>>>>> >>>>>>>>>>> The webex sessions have been cancelled in accordance of better >>>>>>>>>>> IETF >>>>>>>>>>> process compliancy. New dates will be announced rougghly two weeks >>>>>>>>>>> ahead >>>>>>>>>>> of tomorrow. >>>>>>>>>>> >>>>>>>>>>> You can (and should) still actively send edits to the list and >>>>>>>>>>> I'll >>>>>>>>>>> update the text accordingly. Maybe we manage to get ready even >>>>>>>>>>> without a >>>>>>>>>>> call! >>>>>>>>>>> >>>>>>>>>>> - Jouni & Dapeng >>>>>>>>>>> >>>>>>>>>>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti: >>>>>>>>>>>> >>>>>>>>>>>> Folks, >>>>>>>>>>>> >>>>>>>>>>>> The latest charter draft can be found here: >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The deadline for the text chnges are 31st July. I'll setup a call >>>>>>>>>>>> for >>>>>>>>>>>> next week so that those who want to dial in and have verbal >>>>>>>>>>>> commenting >>>>>>>>>>>> can do that. In a meanwhile, email works as usual for updates and >>>>>>>>>>>> comments on the text. The actual milestone dates are to be done >>>>>>>>>>>> last but >>>>>>>>>>>> suggestions are more than welcome. >>>>>>>>>>>> >>>>>>>>>>>> - 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 Sep 3 00:04:00 2014 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 A06861A86F4 for ; Wed, 3 Sep 2014 00:03:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 k5OMokDWCGeI for ; Wed, 3 Sep 2014 00:03:56 -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 14E781A040A for ; Wed, 3 Sep 2014 00:03:56 -0700 (PDT) Received: from [192.168.43.191] ([46.221.25.61]) by mrelay.perfora.net (node=mreueus003) with ESMTP (Nemesis) id 0M9peg-1Xa1nj0ktU-00B4we; Wed, 03 Sep 2014 09:03:53 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_43FC22C6-DF8D-46B4-8E8E-669FB38717EF" From: Alper Yegin In-Reply-To: Date: Wed, 3 Sep 2014 09:54:55 +0300 Message-Id: References: To: Sri Gundavelli (sgundave) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:vP4CkQrTtN5b35NCBJQtoCdgYIM3hH8MQ2mgJBf92Ac zOzV8Fqqph2/upue3H/PUGuALjap9sc0IoI3unPfGWC9M4fTgp 5oeepQUcxLoAwVWldNwERNSVfMUHaFjBE3CxAq5icV/Tkg7Tsz oCP9+vR4s/c1mzvDAWrhGkk7due+KCUxuoXYf67/Cd0tOp7HOL 6cXdl5z/mWuJVDfmnTxXFVo3x0FInO9lJgAD7BOli2cTtC8OzV o7qqZozrOKhvx6G4A+KfOp5lb6npYr6nj+kQPs1gHETBoBHG9G jNW+GYggZ4VZxIPuFLjIN6m54rhyWrDZGLYiDsXBCDMReAZ5y2 CEHxxSqtYe2xATpY/YkQcQJdana2oy6AnYltqRF/mDhlPf9e9M 9kIuzOZeK9FQw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/a8gPwSnwUzsPtZzH5bEkPO9oczk Cc: "dmm@ietf.org" Subject: Re: [DMM] 3GPP CSIPTO 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, 03 Sep 2014 07:03:58 -0000 --Apple-Mail=_43FC22C6-DF8D-46B4-8E8E-669FB38717EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sri, On Sep 2, 2014, at 6:32 PM, Sri Gundavelli (sgundave) wrote: > Alper -=20 >=20 > > The idea is to make sure the simultaneous PDN connections do not = keep adding up each time the UE encounters a new GW. >=20 > Is that not truly a deployment consideration ? Supporting #N simultaneous PDN connections per UE has implications on = the systems.=20 So, it's not really only about deployment considerations. > If the approach is gateway selection based on application/CN basis, = can the network control this ? >=20 Not sure how to answer that. Probably this can be discussed in the = context of a specific solution=85. Alper >=20 > Regards > Sri >=20 >=20 >=20 >=20 > From: Alper Yegin > Date: Monday, September 1, 2014 7:39 AM > To: Marco Liebsch > Cc: "dmm@ietf.org" > Subject: Re: [DMM] 3GPP CSIPTO >=20 > Hi Marco, >=20 >> thanks for posting the update. One clarifying question on the = following service requirement: >> =20 >> =91The 3GPP system shall minimize the number of connections of a UE = without disrupting the >> UE=92s services, e.g. to ensure economical use of network resources=92 >> =20 >> Can this be understood as the number of connections, which is to be = minimized, is equal to the >> number of mobility session and associated IP addresses? >=20 > You can say that. >=20 > The idea is to make sure the simultaneous PDN connections do not keep = adding up each time the UE encounters a new GW. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >> =20 >> Is this to minimize the states in the network, or is the intention to = limit the control-plane >> signaling with the mobile device to setup/teardown the connection? >> =20 >> Thanks for your feedback in advance, >> marco >> =20 >> =20 >> =20 >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin >> Sent: Montag, 1. September 2014 09:51 >> To: dmm@ietf.org >> Subject: [DMM] 3GPP CSIPTO >> =20 >> Dear DMMers, >> =20 >> Here's an update on 3GPP SA1 CSIPTO work=85 >> =20 >> Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting = SA1 has completed the CSIPTO normative work. >> As you might remember, SA1 is in charge of defining service = requirements. >> =20 >> The next step for CSIPTO is to initiate a work item in SA2. >> =20 >> =20 >> And here's a copy-paste of the normative requirements (accepted doc = is S1-143607.zip): >> =20 >> =20 >> Some types of services (e.g. streaming services, VOIP, VPN, = HTTPS-Based Services) cannot tolerate a change of IP address of the UE = without disruption of the service. >> SIPTO can be performed with or without coordination between the UE = and the network. The following requirements apply to coordinated SIPTO: >>=20 >> - The 3GPP system shall be able to support multiple connections = that are associated with the same defined IP network where each = connection may or may not support IP address preservation. >>=20 >> - The 3GPP system shall be able to determine if an IP flow = requires IP address preservation or not. Based on this determination, = the 3GPP network shall be able to offload selected IP traffic in = coordinated manner between UE and the network, in order to minimize = service disruption. >>=20 >> - The 3GPP system shall be able to detect when a connection = becomes suboptimal and decide when to establish a new optimal connection = to the same defined IP network or use an existing connection. >> Note 1: The definition of optimal and suboptimal can be based on = a number of implementation criteria like geography, topology and load = balancing etc. >> - The 3GPP system shall minimize the number of connections of a = UE without disrupting the UE=92s services, e.g. to ensure economical use = of network resources. >> - The 3GPP system shall be able to ensure that the actual average = aggregate bit rate for IP flows of packet data network connections = associated with the same packet data network does not significantly = exceed the subscribed aggregate maximum bit rate for this packet data = network when two connections are used with the same defined IP network. >> Note 2: Requirements for Coordinated SIPTO do not apply to IMS. >>=20 >=20 --Apple-Mail=_43FC22C6-DF8D-46B4-8E8E-669FB38717EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Alper - 

> The idea is to make sure the simultaneous PDN connections = do not keep adding up each time the UE encounters a new GW.

Is that not truly a deployment consideration ? =

Supporting #N simultaneous = PDN connections per UE has implications on the = systems. 
So, it's not really only about deployment = considerations.


If the approach is = gateway selection based on application/CN basis, can the network control = this ?


Not sure how to = answer that. Probably this can be discussed in the context of a specific = solution=85.

Alper


<= /div>

Regards
Sri




From: Alper Yegin <alper.yegin@yegin.org>
Date: Monday, September 1, 2014 = 7:39 AM
To: Marco Liebsch <Marco.Liebsch@neclab.eu> Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] 3GPP = CSIPTO

Hi Marco,

thanks for posting the update. One clarifying = question on the following service requirement:
 
=91The 3GPP system shall minimize the number = of connections of a UE without disrupting the
UE=92s services, e.g. to ensure economical use of network = resources=92
 
Can this be understood as the number of = connections, which is to be minimized, is equal to the
number of mobility session and associated IP = addresses?

You can say that.

The idea is to make sure the simultaneous PDN connections do not = keep adding up each time the UE encounters a new GW.

Alper





 
Is this to minimize the states in the network, or = is the intention to limit the control-plane
signaling with the mobile device to setup/teardown the = connection?
 
Thanks for your feedback in = advance,
marco
 
 
 
 dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Montag, = 1. September 2014 09:51
To: dmm@ietf.org
Subject: [DMM] = 3GPP CSIPTO
 
Dear DMMers,
 
Here's an update on 3GPP SA1 CSIPTO work=85
 
Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting SA1 = has completed the CSIPTO normative work.
As you might remember, SA1 is in charge of defining service = requirements.
 
The next step for CSIPTO is to initiate a work item in = SA2.
 
 
And here's a copy-paste of the normative requirements (accepted doc = is   
 
Some types of services (e.g. streaming services, = VOIP, VPN, HTTPS-Based Services) cannot tolerate a change of IP address = of the UE without disruption of the service.

SIPTO can be performed with or without coordination = between the UE and the network. The following requirements apply to = coordinated SIPTO:

-     The 3GPP system shall be able to support multiple = connections that are associated with the same defined IP network where each connection may or may not support IP address = preservation.

-     The 3GPP system shall be able to determine if an IP flow = requires IP address preservation or not. Based on this determination, the 3GPP network shall be able to offload selected IP = traffic in coordinated manner between UE and the network, in order to = minimize service disruption.

-      The 3GPP system shall be able to detect when a connection = becomes suboptimal and decide when to establish a new optimal connection to the same defined IP network or use an existing = connection.
Note 1:      The definition of = optimal and suboptimal can be based on a number of implementation = criteria like geography, topology and load balancing = etc.
-     The 3GPP system shall minimize the number of connections = of a UE without disrupting the UE=92s services, e.g. to ensure economical use of network resources.
-     The 3GPP system shall be able to ensure that the actual = average aggregate bit rate for IP flows of packet data network connections associated with the same packet data network does not = significantly exceed the subscribed aggregate maximum bit rate for this = packet data network when two connections are used with the same defined = IP network.

Note 2:  Requirements for Coordinated SIPTO do = not apply to IMS.

= --Apple-Mail=_43FC22C6-DF8D-46B4-8E8E-669FB38717EF-- From nobody Wed Sep 3 00:29:03 2014 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 AEA4E1A0041 for ; Wed, 3 Sep 2014 00:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 2fG0DliSugQm for ; Wed, 3 Sep 2014 00:29:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 375311A0084 for ; Wed, 3 Sep 2014 00:28:41 -0700 (PDT) Received: from [192.168.43.191] ([46.221.25.61]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0LkykV-1XxJoW08xR-00akLL; Wed, 03 Sep 2014 09:28:39 +0200 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Sep 2014 10:28:34 +0300 Message-Id: <57645B37-C2CB-404D-9F38-4F596ADB2488@yegin.org> To: dmm@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:MmQCMmmQI/7svanmz654wP/vQHr2ZX/xW6+VpxooDH5 t7F2p4l/jWGtf//x8uU9tun2NkPQWBCcEyryQVZI8Si5t1eE+Y F2ZNcG1+igNCTi1Ul8Vst99wAYar2dhgjPk/a4HDHJK6jeUdM5 JdeI1hjiX5XrXErjbGjReUq4BojlevKojvlZFA/t8jV5IpC5sj 9595fbZcIgFfolLKHC12MajqqHM4N79BT3pnu8Ydn5jVJDG7TH rsfpdWN3kg7UA21eJYVmz17F6f/niBbUpqszG5AF436m3m3obt w+cd13LDAajqIDMEDkQCzwgnQztdQVxnLzvL+Kes/T17IJM2J5 FFYlltWR6lbppmB/m3Vzqo+iAt67vn09I7dxIA5MyVh9+7j+Cs sAou+VmFNVpvw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/g6Cq0aqukKW8mZfsjuUr3irD9JI Subject: [DMM] APIs 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, 03 Sep 2014 07:29:02 -0000 Folks, There was discussion about necessity of APIs for DMM yesterday. Let's continue that discussion here. It is true that IETF's primary focus is "protocol design". But when it's necessary, IETF also defines APIs. See, IPv6 basic socket API, for example. And, as a very relevant item, see RFC 5014, source address selection = API. In RFC 5014, there's even consideration to "mobility", in terms of apps = selecting home address vs care-of address as their source address. I think by now it's clear to everyone that we can no longer treat all IP = flows equally when it comes to providing IP mobility treatment to them. This is already recognized in the charter. The way to take apps' mobility need into account is to give them an API. = RFC 5014 already made an attempt at that, but fell short. Now that we = have a better understanding of the issues, we should extend that API. Once we define that API, other APIs (OS specific ones that are not under = the control of IETF) can follow the same path. Discussion welcome. Alper From nobody Wed Sep 3 01:19:24 2014 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 A7C141A873D for ; Wed, 3 Sep 2014 01:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_25=0.6, 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 zkCljmopYW4e for ; Wed, 3 Sep 2014 01:19:17 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C231A016C for ; Wed, 3 Sep 2014 01:17:59 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id el20so728859lab.6 for ; Wed, 03 Sep 2014 01:17:57 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ggJLXYrUc0+iDYOR/WoN2WIrvZeti/wSIizzK5nL9oU=; b=kuD/Vb44YNFc0Gba//h+dzPh///6vH6CjWa2ZrUItr+Vj5WCQnFNXERswLRFMEmsI7 IoFWJ0Y5qm1ccIKcpmwtDGhKNPI2aB7vadfrB+Lp9ibNKcwlfIApm04uSFWe52QQBwPS jw+6mZsOXRIc54W8zOpCOoEiJgG4T1m546ckroHcXyVvHjBuh6K1MyvHjSaTO3Y9wj4S SksXMrV7RU3kFRxCckj7DW8oYf/ar2Si4hjQY7lPEmIW2mChKVeSKWZGr63BrJBOnVfU hf3WLlIqntBY91AS0pUY5esrbYf5+QRbJoUxlMxM7nYdjl/gPX+dpbLHndAXry1GcEXp PltA== X-Received: by 10.152.37.199 with SMTP id a7mr30971015lak.68.1409732277825; Wed, 03 Sep 2014 01:17:57 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id d9sm832043lad.11.2014.09.03.01.17.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 01:17:56 -0700 (PDT) Message-ID: <5406CEB2.3040002@gmail.com> Date: Wed, 03 Sep 2014 11:17:54 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alper Yegin , "Sri Gundavelli (sgundave)" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/r0rMYEfAn1vOOZAjZPlXL_v7iNE Cc: "dmm@ietf.org" Subject: Re: [DMM] 3GPP CSIPTO 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, 03 Sep 2014 08:19:18 -0000 9/3/2014 9:54 AM, Alper Yegin kirjoitti: > Sri, > > On Sep 2, 2014, at 6:32 PM, Sri Gundavelli (sgundave) wrote: > >> Alper - >> >> > The idea is to make sure the simultaneous PDN connections do not >> keep adding up each time the UE encounters a new GW. >> >> Is that not truly a deployment consideration ? > > Supporting #N simultaneous PDN connections per UE has implications on > the systems. > So, it's not really only about deployment considerations. The 3GPP system is able to support up to 11 PDN Connections (or any bearers to be precise). This limit is on both UE and network side. What I cannot now remember on top of my head is whether the limitation is just per UE-PGW pair. Need to check that. So, it also means the maximum number of prefixes per UE in 11.. unless prefix delegation is used (but in that case the prefixes are not for the UE but the LAN side nodes). >> If the approach is gateway selection based on application/CN basis, >> can the network control this ? >> > > Not sure how to answer that. Probably this can be discussed in the > context of a specific solution…. Network should be able to control this. If not, it will be added most probably. - JOuni > > Alper > > > >> >> Regards >> Sri >> >> >> >> >> From: Alper Yegin > >> Date: Monday, September 1, 2014 7:39 AM >> To: Marco Liebsch > > >> Cc: "dmm@ietf.org " > > >> Subject: Re: [DMM] 3GPP CSIPTO >> >> Hi Marco, >> >>> thanks for posting the update. One clarifying question on the >>> following service requirement: >>> ‘/The 3GPP system shall minimize the number of connections of a UE >>> without disrupting the >>> UE’s services, e.g. to ensure economical use of network resources/’ >>> Can this be understood as the number of connections, which is to be >>> minimized, is equal to the >>> number of mobility session and associated IP addresses? >> >> You can say that. >> >> The idea is to make sure the simultaneous PDN connections do not keep >> adding up each time the UE encounters a new GW. >> >> Alper >> >> >> >> >> >>> Is this to minimize the states in the network, or is the intention to >>> limit the control-plane >>> signaling with the mobile device to setup/teardown the connection? >>> Thanks for your feedback in advance, >>> marco >>> *From:*dmm [mailto:dmm-bounces@ietf.org]*On Behalf Of*Alper Yegin >>> *Sent:*Montag, 1. September 2014 09:51 >>> *To:*dmm@ietf.org >>> *Subject:*[DMM] 3GPP CSIPTO >>> Dear DMMers, >>> Here's an update on 3GPP SA1 CSIPTO work… >>> Two weeks ago there was an SA1 meeting (SA1#67), and in that meeting >>> SA1 has completed the CSIPTO normative work. >>> As you might remember, SA1 is in charge of defining service requirements. >>> The next step for CSIPTO is to initiate a work item in SA2. >>> And here's a copy-paste of the normative requirements (accepted doc >>> is S1-143607.zip >>> ): >>> Some types of services (e.g. streaming services, VOIP, VPN, >>> HTTPS-Based Services) cannot tolerate a change of IP address of the >>> UE without disruption of the service. >>> >>> SIPTO can be performed with or without coordination between the UE >>> and the network. The following requirements apply to coordinated SIPTO: >>> >>> -The 3GPP system shall be able to support multiple connections that >>> are associated with the same defined IP network where each connection >>> may or may not support IP address preservation. >>> >>> -The 3GPP system shall be able to determine if an IP flow requires IP >>> address preservation or not. Based on this determination, the 3GPP >>> network shall be able to offload selected IP traffic in coordinated >>> manner between UE and the network, in order to minimize service >>> disruption. >>> >>> -The 3GPP system shall be able to detect when a connection becomes >>> suboptimal and decide when to establish a new optimal connection to >>> the same defined IP network or use an existing connection. >>> Note 1: The definition of optimal and suboptimal can be based on >>> a number of implementation criteria like geography, topology and load >>> balancing etc. >>> -The 3GPP system shall minimize the number of connections of a UE >>> without disrupting the UE’s services, e.g. to ensure economical use >>> of network resources. >>> -The 3GPP system shall be able to ensure that the actual average >>> aggregate bit rate for IP flows of packet data network connections >>> associated with the same packet data network does not significantly >>> exceed the subscribed aggregate maximum bit rate for this packet data >>> network when two connections are used with the same defined IP network. >>> >>> Note 2: Requirements for Coordinated SIPTO do not apply to IMS. >>> >> > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Wed Sep 3 09:23:01 2014 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 9AFD91A002D for ; Wed, 3 Sep 2014 09:22:57 -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 5QXEDP0Jq4_b for ; Wed, 3 Sep 2014 09:22:55 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB691A008C for ; Wed, 3 Sep 2014 09:22:47 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id el20so1585069lab.34 for ; Wed, 03 Sep 2014 09:22:46 -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=YR36mMDbNqz8aG2SpYgZcmOEN23ywIgxk9Z/GdKf5IU=; b=qcj/xV/QQjQpM9Bf5+CfxZWHpF/L46EDI6yJhYdGFQ9Fu+55gAdk+UGPVxNGU/UD5L 1U4adloQXs0Vi/XQWXlKOeSjwj2oaxX1VOX9LJ8uyJgZNvPS3HXhriKMHWRyigFHBuRl iVWcGDwHGTA00euIzqAGqPXw1DFZd/KlzVdXd0TZYP+G9VsapcoYmbq+C4xFB1WAXmcS Gp4X5VYloEXnt1BwSMx5ThTR53F72VEVSmGT13nQZ6NKleAJ9h0tpFC4CR6jVWxWzVBw D8X/FfEh6XDqF/dWUHsZBlym69OALDuf5jwi5EEKVOf7ky18nkaqcLcsbnmXo9Xa0PQm MAmQ== MIME-Version: 1.0 X-Received: by 10.112.150.106 with SMTP id uh10mr39966235lbb.11.1409761366118; Wed, 03 Sep 2014 09:22:46 -0700 (PDT) Received: by 10.114.244.73 with HTTP; Wed, 3 Sep 2014 09:22:46 -0700 (PDT) In-Reply-To: <5406A20F.60604@gmail.com> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> Date: Wed, 3 Sep 2014 11:22:46 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/q0boXABt4PJYfwDcIBs1D_YjYsc Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 03 Sep 2014 16:22:58 -0000 On Wed, Sep 3, 2014 at 12:07 AM, Jouni Korhonen wrote: > We were on this in yesterday's interim call. We have a proposal text now. > You were also on the call but I did not record you commenting anything > during the discussion we had on this particular topic. I had leave early due to doctor's appointment. > Are you now saying > the resolution we have now in the charter text is not adequate? > Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions would apply. Behcet: the above text does not reflect my comments. I am against any deployment work before we decide on a solution (and there is currently no draft on this). This is strongly supported by IETF work on deployment as well as 3GPP. I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. He also emphasized importance of running code. It is not that we don't have solutions and it is claimed that two of them have been implemented. Regards, behcet > - JOuni > > 9/2/2014 11:39 PM, Behcet Sarikaya kirjoitti: > >> On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen >> wrote: >>> >>> Behcet, >>> >>> Obviously that protocols are known that the intended deployment is going >>> to >>> use. The details what goes inside that protocol are not. This holds for >>> my >>> example case 3GPP as well. >>> >>> We do not need to into same level of detail that e.g. 3GPP stage-2 has >>> detailing all signaling flows and so on. I believe we as a WG are >>> competent >>> enough to make a fine division what level of detail is left for the >>> "deployment models and scenarios" and what goes into protocol solutions. >>> >> >> I hope you read previous mails on this issue. >> >> I think it clear that 3GPP agrees with IETF on the interpretation of >> deployment. How can we close our eyes on this and try to put the horse >> before the cart? >> >> Why not simply remove it? >> >> Regards, >> Behcet >> >> >> >>> - Jouni >>> >>> 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti: >>> >>>> On Mon, Sep 1, 2014 at 3:25 AM, Jouni wrote: >>>>> >>>>> >>>>> >>>>> Alper, >>>>> >>>>> I hear your concern. Anyway, the division here is similar to (3GPP) >>>>> stage-2 and stage-3 work. The ""deployment models and scenarios" are >>>>> the >>>>> stage-2 descriptions and then we also need the protocol level solutions >>>>> that >>>>> are in separate documents. >>>>> >>>> >>>> Thanks Alper for raising this issue. >>>> >>>> 3GPP Stage 2 like in SA2 documents are architecture documents. >>>> I don't understand what is going on here. >>>> >>>> I am looking at 23.402 on Architecture Enhancements for non-3GPP >>>> accesses. >>>> >>>> Yes, this document talks about deployment in just a few places, here >>>> is one occurrence: on page 64, PCC deployment options >>>> on page 94, PMIP based S5/S8 deployments, etc. >>>> >>>> So in all cases the protocol, i.e. PCC or PMIP is known. >>>> >>>> Regards, >>>> >>>> Behcet >>>>> >>>>> >>>>> Makes sense? >>>>> >>>>> - Jouni >>>>> >>>>> >>>>> On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: >>>>> >>>>>>> Okay, we are not going to define how the existing 3FPP system works - >>>>>>> that knowledge is assumed. What I thought goes into the document, for >>>>>>> example, in the case of 3GPP system would be identifying the >>>>>>> architecture >>>>>>> changes or modifications needed. If the deployment model assumes all >>>>>>> network >>>>>>> functions are virtualized, the document states that and lays out the >>>>>>> architecture based on that. Satoru's & Ryuji's vEPC deployment model >>>>>>> (based >>>>>>> on their solution) is IMHO a good example of what could be >>>>>>> documented. The >>>>>>> similar applies for other system architectures such as SP Wi-Fi etc. >>>>>>> >>>>>> >>>>>> Jouni, >>>>>> >>>>>> The "architecture changes" would be based on the a "specific >>>>>> solution". >>>>>> So, as part of describing a solution one can be talking about what you >>>>>> are >>>>>> suggesting above. But I don't understand how we can be talking about >>>>>> "deployment models and scenarios" before we agree on the solutions. >>>>>> >>>>>> Alper >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>>> o Enhanced mobility anchoring: define protocol solutions for >>>>>>>>>>> a >>>>>>>>>>> gateway and mobility anchor assignment and mid-session >>>>>>>>>>> mobility >>>>>>>>>>> anchor switching that go beyond what has been specified, >>>>>>>>>>> for >>>>>>>>>>> example, in RFC 6097, 6463, and 5142. Traffic steering >>>>>>>>>>> associated with the anchor switch is also in-scope if >>>>>>>>>>> deemed >>>>>>>>>>> appropriate. >>>>>>>>>>> >>>>>>>>>>> o Forwarding path and signaling management: the function >>>>>>>>>>> that handles mobility management signaling interacts with >>>>>>>>>>> the >>>>>>>>>>> DMM network elements for managing the forwarding state >>>>>>>>>>> associated with a mobile node's IP traffic. These two >>>>>>>>>>> functions >>>>>>>>>>> may or may not be collocated. Furthermore, the forwarding >>>>>>>>>>> state >>>>>>>>>>> may also be distributed into multiple network elements >>>>>>>>>>> instead >>>>>>>>>>> of a single network element (e.g., anchor). Protocol >>>>>>>>>>> extensions >>>>>>>>>>> or new protocols will be specified to allow the above >>>>>>>>>>> mentioned >>>>>>>>>>> forwarding path and signalling management. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I cannot separate "mobility anchoring" from "fwding path and >>>>>>>>>> signaling management". >>>>>>>>>> Wherever you want to set your anchor or move your anchor to, you'd >>>>>>>>>> need signaling >>>>>>>>>> and setting up data path. The two are inseparable. >>>>>>>>>> Having said that, I'm OK to keep the current work item >>>>>>>>>> descriptions >>>>>>>>>> and finalize >>>>>>>>>> rechartering. Once we have detailed discussions about the >>>>>>>>>> breakdown >>>>>>>>> >>>>>>>>> >>>>>>>>> of the work, we >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> can come back and refine the goals and milestones (as already >>>>>>>>>> stated >>>>>>>>> >>>>>>>>> >>>>>>>>> below [*]). >>>>>>>>> >>>>>>>>> The enhanced mobility anchoring above is/was rather MIP type >>>>>>>>> solutions >>>>>>>>> influenced with "anchors" like we understand today, while the >>>>>>>>> "forwarding path and signaling management" was meant for more >>>>>>>>> future >>>>>>>>> oriented solutions where the forwarding path does not necessarily >>>>>>>>> have >>>>>>>>> anything mobility specific etc. >>>>>>>>> >>>>>>>> >>>>>>>> (Just FYI: It's not possible to gather what you are saying from >>>>>>>> reading >>>>>>>> the charter. Different people reading the charter may not have the >>>>>>>> same >>>>>>>> understanding. But like I said, this is just FYI, I can live with >>>>>>>> this >>>>>>>> text until we come back and refine it later). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ok. I'll try to clarify the point the text tries to make. >>>>>>> >>>>>>> - Jouni >>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Alper >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Any other opinions on collapsing these two? >>>>>>>>> >>>>>>>>> - Jouni >>>>>>>>> >>>>>>>>>>> o Exposing mobility state to mobile nodes and network nodes: >>>>>>>>>>> define solutions that allow, for example, mobile nodes to >>>>>>>>>>> select >>>>>>>>>>> either a care-of address or a home address depending on an >>>>>>>>>>> application' mobility needs. In order to enable this >>>>>>>>>>> functionality, the network-side control functions and >>>>>>>>>>> other >>>>>>>>>>> networking nodes must also be able to exchange appropriate >>>>>>>>>>> control information, as well as to the mobile nodes and >>>>>>>>>>> their >>>>>>>>>>> applications. >>>>>>>>>>> >>>>>>>>>>> The working group may decide to extend the current milestones >>>>>>>>>>> based >>>>>>>>>>> on >>>>>>>>>>> the new information and knowledge gained during working on other >>>>>>>>>>> documents listed in the initial milestones. [*] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Alper >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Possible new documents and >>>>>>>>>>> milestones must still fit into the overall DMM charter scope as >>>>>>>>>>> outlined >>>>>>>>>>> above. >>>>>>>>>>> >>>>>>>>>>> Goals and Milestones: >>>>>>>>>>> >>>>>>>>>>> Feb 2015 - Submit 'The deployment models and scenarios' as a >>>>>>>>>>> working >>>>>>>>>>> group document(s). To be Informational RFC. >>>>>>>>>>> >>>>>>>>>>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working >>>>>>>>>>> group >>>>>>>>>>> document. To be Proposed Standard. >>>>>>>>>>> >>>>>>>>>>> Feb 2015 - Submit 'Forwarding path and signaling management' as a >>>>>>>>>>> working group document. To be Proposed Standard. >>>>>>>>>>> >>>>>>>>>>> May 2015 - Submit 'Exposing mobility state to mobile nodes and >>>>>>>>>>> network >>>>>>>>>>> nodes' as a working group document(s). To be Proposed >>>>>>>>>>> Standard. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> May 2015 - Submit 'The deployment models and scenarios' submitted >>>>>>>>>>> to >>>>>>>>>>> the IESG. To be Informational RFC. >>>>>>>>>>> >>>>>>>>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to the >>>>>>>>>>> IESG. >>>>>>>>>>> To be Proposed Standard. >>>>>>>>>>> >>>>>>>>>>> Jun 2015 - Submit 'Forwarding path and signaling management' >>>>>>>>>>> submitted >>>>>>>>>>> to the IESG. To be Proposed Standard. >>>>>>>>>>> >>>>>>>>>>> Oct 2015 - Submit 'Exposing mobility state to mobile nodes and >>>>>>>>>>> network >>>>>>>>>>> nodes' submitted to the IESG. To be Proposed >>>>>>>>>>> Standard. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The webex sessions have been cancelled in accordance of better >>>>>>>>>>>> IETF >>>>>>>>>>>> process compliancy. New dates will be announced rougghly two >>>>>>>>>>>> weeks >>>>>>>>>>>> ahead >>>>>>>>>>>> of tomorrow. >>>>>>>>>>>> >>>>>>>>>>>> You can (and should) still actively send edits to the list and >>>>>>>>>>>> I'll >>>>>>>>>>>> update the text accordingly. Maybe we manage to get ready even >>>>>>>>>>>> without a >>>>>>>>>>>> call! >>>>>>>>>>>> >>>>>>>>>>>> - Jouni & Dapeng >>>>>>>>>>>> >>>>>>>>>>>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Folks, >>>>>>>>>>>>> >>>>>>>>>>>>> The latest charter draft can be found here: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The deadline for the text chnges are 31st July. I'll setup a >>>>>>>>>>>>> call >>>>>>>>>>>>> for >>>>>>>>>>>>> next week so that those who want to dial in and have verbal >>>>>>>>>>>>> commenting >>>>>>>>>>>>> can do that. In a meanwhile, email works as usual for updates >>>>>>>>>>>>> and >>>>>>>>>>>>> comments on the text. The actual milestone dates are to be done >>>>>>>>>>>>> last but >>>>>>>>>>>>> suggestions are more than welcome. >>>>>>>>>>>>> >>>>>>>>>>>>> - 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 Sep 3 09:30:50 2014 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 5C9611A000E for ; Wed, 3 Sep 2014 09:30:49 -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 HxJs28f4CMFE for ; Wed, 3 Sep 2014 09:30:47 -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 2A7D01A0062 for ; Wed, 3 Sep 2014 09:30:47 -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 0F4DB88127 for ; Wed, 3 Sep 2014 09:30:47 -0700 (PDT) Received: from clemson.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id BD8AB136811D for ; Wed, 3 Sep 2014 09:30:46 -0700 (PDT) Message-ID: <5407422F.2010700@innovationslab.net> Date: Wed, 03 Sep 2014 12:30:39 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dmm@ietf.org References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3hsFhRJrSaQsiqUhaW9Ukw7vWl0d20qIL" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/h-kNTf0rVjBKSqXcjWe3twdG1ZQ Subject: Re: [DMM] regarding the re-chartering.. 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, 03 Sep 2014 16:30:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3hsFhRJrSaQsiqUhaW9Ukw7vWl0d20qIL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just for clarification... On 9/3/14 12:22 PM, Behcet Sarikaya wrote: >=20 > I am also concerned on the time DMM is taking on dressing up the > charter text. I remind you on what Jari Arkko who is founding AD for > DMM said in Toronto admin plenary: > WGs should have solution work from day 1. Not "should", but rather "could". Not all WGs need to have requirements, frameworks, architecture, etc. That is why this type of discussion during charter development is important. >=20 > He also emphasized importance of running code. Running code is good thing. So is an understanding of customer needs (in this case, other SDOs). Regards, Brian --3hsFhRJrSaQsiqUhaW9Ukw7vWl0d20qIL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUB0I1AAoJEBOZRqCi7goqa3QH+wa/ypuXEGRSKSG5HvdIU3yz iEKYDfPEyX+ucrBAEilkvG2WGQV0B+hQuczdm5e4jWib4murDLwYSHV77+5ObquO SlKUdtgC/Lu+vj0/JuqxS+Z7Xk3jQ5M7oOOQdOgTwcw3v4oAHUl7ksf1eFUNqM2o CKamQkr1oEdpLvTPdVwqqJPhtu1dbPQOQjvuY5zD8Ng1FYEKhCZK0gzNVINOBb4A TOpcCJYwRZwE5lHQuT4dpd38ToMyY2P+75DtNwg0gt65V0egNne32oEguM4kEtzg vxovsOlmRN8Lm/zBi0V7FfUL5kiywtKr1yGJulUM2c0Qj1seLhInbVuT1tLaVXM= =uRMx -----END PGP SIGNATURE----- --3hsFhRJrSaQsiqUhaW9Ukw7vWl0d20qIL-- From nobody Wed Sep 3 09:38:04 2014 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 5E5B61A000F for ; Wed, 3 Sep 2014 09:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.296 X-Spam-Level: X-Spam-Status: No, score=-4.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, URG_BIZ=0.573] 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 2rO5GrOZApCn for ; Wed, 3 Sep 2014 09:37:58 -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 B14191A0062 for ; Wed, 3 Sep 2014 09:37:47 -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 s83Gbk1h007949; Wed, 3 Sep 2014 09:37:46 -0700 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s83Gbi1g007934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 3 Sep 2014 09:37:45 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.233]) with mapi id 14.03.0181.006; Wed, 3 Sep 2014 09:37:44 -0700 From: "Templin, Fred L" To: "dmm@ietf.org" Thread-Topic: "A Day in the Life of an Enterprise Mobile Device User" Thread-Index: AQHPx5ViOP6F+udYnkWXmXXAiU79KQ== Date: Wed, 3 Sep 2014 16:37:43 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D040CD@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D031C3@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D031C3@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: http://mailarchive.ietf.org/arch/msg/dmm/zggldS7p3UguGMRDYcnLukoHm28 Subject: [DMM] "A Day in the Life of an Enterprise Mobile Device User" 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, 03 Sep 2014 16:38:00 -0000 Hi, The specific passage from the new draft that I wanted the wg to see is the following (with references to AERO removed). Please review and send questions or comments. Thanks - Fred fred.l.templin@boeing.com --- 3. A Day in the Life of an Enterprise Mobile Device User An enterprise network mobile device user ("Bill") begins his workday by seating his primary end user device (EUD) (e.g., a laptop computer, a tablet, a smart phone, etc.) in a docking station at his office desk and turning the device on. The docking station connects Bill's EUD to the enterprise wired LAN, and the EUD receives a Topologically-Fixed Address (TFA) from the infrastructure. Bill's EUD further discovers the DMM service within the enterprise network and requests a Topology Independent Prefix (TIP)delegation. Bill's EUD receives the same TIP delegation it gets every time it connects to the enterprise network, because the DMM service has an administratively set mapping between the TIP and Bill's EUD device ID. Bill's EUD can then access topologically-fixed enterprise services using its TFA directly, and can access DMM services by using an address from its TIP as the source address for tunneling over the enterprise network. As Bill's workday unfolds, his EUD uses the DMM service to correspond with other EUDs in peer-to-peer sessions, join lengthy virtual conferencing sessions, access enterprise fileshares, etc. The DMM service ensures that optimal routes are maintained so that tunneled communications flow over direct paths and network infrastructure elements are not unnecessarily over-burdened. While communications sessions such as the video conference are still in progress, Bill leaves the office to attend a meeting in a nearby conference room. He disconnects his EUD from the docking station and in the process drops his connection to the wired LAN. The EUD quickly enables a WiFi interface that searches for a Service Set Identifier (SSID) that can provide wireless access within the enterprise network. The EUD authenticates itself to the network via the SSID using its pre-loaded certificates, and uses a securing mechanism such as IEEE 802.1x to assure Confidentiality, Integrity and Availability (CIA). The EUD receives a new TFA from the network, then communicates its new TIP-to-TFA association to the DMM service and any active peer correspondents. Any ongoing communications sessions will continue to see the same (stable) TIP. Bill then leaves the enterprise campus to attend an off-site customer meeting with his EUD still powered on and actively seeking to maintain network connectivity. As Bill departs from the building, the WiFi signal fades until it can no longer support communications, and the EUD quickly enables a 4G cellular wireless interface that connects Bill's EUD to a cellular service provider. The EUD then locates the Internet address of an enterprise network security gateway and initiates a VPN session with the gateway (which also acts participates in the DMM service). The DMM service updates the routing system, and Bill can continue to use the same TIP that was assigned to his EUD when he started his workday even though the EUD is now communicating over a VPN configured over the public Internet instead of over the secured campus LAN. Bill subsequently arrives at the customer meeting at a public restaurant with a WiFi hotspot. His EUD quickly powers up its WiFi interface and powers down the 4G interface. The EUD uses DMM signaling to communicate the new TFA to the security gateway and the VPN survives the mobility event. Moreover, the EUD can continue to use the same TIP it received at the beginning of the workday, and ongoing communication sessions can continue until Bill explicitly discontinues them. After the customer meeting, Bill leaves the restaurant and subsequently passes through several additional transitions from WiFi hotspots to 4G wireless. Again, the DMM service keeps the VPN session alive, and the TIP assigned to the EUD remains in continuous use in active communication sessions as well as to allow Bill to receive notifications and process urgent requests. When Bill returns to his office, the EUD discontinues use of the VPN while keeping its TIP active after re-attaching to the campus LAN. Bill ends his workday, powers down his EUD and returns home. Bill powers on his EUD to check e-mails, and connects to the enterprise network via a VPN configured over his home ISP service. The EUD again receives the same TIP that it used within the enterprise network domain, and Bill can access DMM services the same as if he was in the office. Bill finally shuts down for the evening, and begins his next workday in the same fashion. Again, the EUD receives the same TIP as always regardless of the access network point of connection over which the EUD enters the enterprise. > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Tuesday, September 02, 2014 11:05 AM > To: dmm@ietf.org > Subject: [DMM] FW: I-D Action: draft-templin-aeroent-00.txt >=20 > Hello, >=20 > During the call today, there was some interest expressed in learning > more about the enterprise network mobility use case. I have submitted > a new brief document called "AERO Enterprise Network Profile" (below) > that provides a discussion of distributed mobility management needs > for enterprise networks. Although the document specifically cites AERO, > the use case applies to any solution alternative that could meet the > requirements. Also, I am not asking this document be considered as a > dmm wg item at this time, but rather offering it for informational > purposes. Please let me know if there are any questions or comments. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: Tuesday, September 02, 2014 10:51 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-templin-aeroent-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : AERO Enterprise Network Profile > Author : Fred L. Templin > Filename : draft-templin-aeroent-00.txt > Pages : 12 > Date : 2014-09-02 >=20 > Abstract: > Enterprise networks provide a secured data communications > infrastructure built for the purpose of information sharing and > increased productivity for end users within the organization. > Enterprise networks are often organized as private Internets unto > themselves that connect to the global Internet either not at all or > via firewalls, proxies, and/or other network securing devices. This > document discusses an AERO enterprise network profile that outlines > new and more flexible methods for connecting, tracking and managing > mobile organizational assets. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-templin-aeroent/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-templin-aeroent-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 3 09:50:56 2014 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 7875E1A020B for ; Wed, 3 Sep 2014 09:50:53 -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 rJaDqMUEAm8g for ; Wed, 3 Sep 2014 09:50:51 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8E31A02DA for ; Wed, 3 Sep 2014 09:50:40 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id l4so9971912lbv.14 for ; Wed, 03 Sep 2014 09:50:38 -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=EmzBfTFimCla8vsyfs/M53YDU3uDP7SLTwYopkK2iU8=; b=C8zahWv4ndUg0Fl53WihoWHPrQPn4IdpCb6BoIGvQKt/jvsRs1AVa2vvyxqIHSbHmU KEQyNMYf9s/vzlp5PgM2Et/qrAl+cITWIXIuFN6aIufzRnG8Xaco+EETxG/kb/1d41bk gAQnb6IDFN6gB8WyVeaWbFACxlKzqUQqRIv71is2IDpvNPwVYPhMo1gpsjWiBoD1BwXd NX7JPdeNqMNzMhefrFM7UpbFYPwufbCmxKl9kaUnhqofki7/7zvKVep7fWhGMKoxiliz gJByJsOEfKyoGnUtQub8td3Vb0qNQayNLSOEABo0IMy6ZmSAeeQuw8YYHDxL7J6/flD7 QEOw== MIME-Version: 1.0 X-Received: by 10.112.150.106 with SMTP id uh10mr40109279lbb.11.1409763038486; Wed, 03 Sep 2014 09:50:38 -0700 (PDT) Received: by 10.114.244.73 with HTTP; Wed, 3 Sep 2014 09:50:38 -0700 (PDT) In-Reply-To: <5407422F.2010700@innovationslab.net> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> Date: Wed, 3 Sep 2014 11:50:38 -0500 Message-ID: From: Behcet Sarikaya To: Brian Haberman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/arEqJ7CJLHq2NuYAhV4DXhlWuPI Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 03 Sep 2014 16:50:53 -0000 Hi Brian, On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman wrote: > Just for clarification... > > On 9/3/14 12:22 PM, Behcet Sarikaya wrote: > >> >> I am also concerned on the time DMM is taking on dressing up the >> charter text. I remind you on what Jari Arkko who is founding AD for >> DMM said in Toronto admin plenary: >> WGs should have solution work from day 1. > > Not "should", but rather "could". Not all WGs need to have > requirements, frameworks, architecture, etc. That is why this type of > discussion during charter development is important. Here is the quote: WGs should have solution work from day 1 from page 22 of Jari's slides at: http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf BTW we already did the requirements and gap analysis, etc. The architecture in our case is defined elsewhere, like 3GPP and everybody in this group is familiar with 3GPP architecture. > >> >> He also emphasized importance of running code. > > Running code is good thing. So is an understanding of customer needs > (in this case, other SDOs). Absolutely. Regards, Behcet > > Regards, > Brian > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Wed Sep 3 10:20:28 2014 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 91E131A0395 for ; Wed, 3 Sep 2014 10:20:15 -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 4aWN4Wm0I1ZK for ; Wed, 3 Sep 2014 10:20:01 -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 299FB1A038F for ; Wed, 3 Sep 2014 10:19:47 -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 F03EF88127; Wed, 3 Sep 2014 10:19:46 -0700 (PDT) Received: from clemson.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 763CF71B0001; Wed, 3 Sep 2014 10:19:46 -0700 (PDT) Message-ID: <54074DAB.9020801@innovationslab.net> Date: Wed, 03 Sep 2014 13:19:39 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LnMBqjNIDW5RoHvMfAf8hAEwX1PEw8wgR" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/6J-0DixdLLfgpze2ZYRG9e6Die0 Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 03 Sep 2014 17:20:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LnMBqjNIDW5RoHvMfAf8hAEwX1PEw8wgR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 9/3/14 12:50 PM, Behcet Sarikaya wrote: > Hi Brian, >=20 > On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman > wrote: >> Just for clarification... >> >> On 9/3/14 12:22 PM, Behcet Sarikaya wrote: >> >>> >>> I am also concerned on the time DMM is taking on dressing up the >>> charter text. I remind you on what Jari Arkko who is founding AD for >>> DMM said in Toronto admin plenary: >>> WGs should have solution work from day 1. >> >> Not "should", but rather "could". Not all WGs need to have >> requirements, frameworks, architecture, etc. That is why this type of >> discussion during charter development is important. >=20 > Here is the quote: > WGs should have solution work from day 1 >=20 > from page 22 of Jari's slides at: >=20 > http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.p= df Yes, that is what the slide says. The IESG discussed the contents of this presentation and the overwhelming consensus (and what was verbalized in the plenary) is that WGs should not be formed where the *only* output is architecture, frameworks, and/or requirements documents. The charter should have protocol/solution work on the charter from day one. It does not mean that non-solution documents should be skipped if they are needed or provide useful background. The charter text that Jouni sent to the mailing has four (4) work items. By my read, three (3) of them are solutions to identified problem areas. So, I believe the charter is following the spirit of Jari's plenary slides. Your only complaint is about the first work item. I have seen people asking about clarifications on that work item, but you are the only one who wants it removed. I believe others are in favor of providing a document of the high-level models being targeted for the solutions work. At this point, the WG chairs need to determine if there is consensus for the latest charter text. Regards, Brian --LnMBqjNIDW5RoHvMfAf8hAEwX1PEw8wgR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUB02xAAoJEBOZRqCi7goqFp0IALhyinAg/d/VSvhZdvOr1g7M HjN/nSd9BfRhsNht3SE5CnxsX0iYnCLBGuSeB4TzR2DCoiEe1lpjwHFyxwSFZ4Cd 9FFlycxCyX11lcy18fkWGBBgGAuCkyVDRTxbLN92SyulCKSe6vm0QvJIIQvE3zzk +RZV/FZR2heBVbGIBXFQkYPLhebXdz3gn0YQSufUNtMzoyfEhdHGJ8zrdNTts3cF Zq+IE6Zneze6+GMeUdZ+Eyu3fJWJqDx96qoVi1oxy9XmfghvnI8yI1Kxp5xd0KU4 Gqs6h69fpdn94+jy3txVPtYpUarN41zGA2oq2QyBbDKOC1IzlyWjssLnEZQqJNc= =4Py9 -----END PGP SIGNATURE----- --LnMBqjNIDW5RoHvMfAf8hAEwX1PEw8wgR-- From nobody Wed Sep 3 11:33:35 2014 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 8AD4D1A03B9 for ; Wed, 3 Sep 2014 11:33:26 -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 V3WK7g7ML8Ao for ; Wed, 3 Sep 2014 11:33:25 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC6C1A06AC for ; Wed, 3 Sep 2014 11:33:23 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id b17so10155549lan.8 for ; Wed, 03 Sep 2014 11:33:22 -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=5paq4Otp6Lano8TCQIF6zP008UK4jSpOQk4um21W5+I=; b=crj7XsXbE6a8Fama0L8aVMc6UGGE8+Wwo2KUUMEsDrmrHuZOcmKI1+/AG65/zGptQn 1oW6mMV0f3VDBvn+nh9kmzc3NMcIlvNnQU6gEH1nUpP/EmVF4o+kL6JD1k+haqCi1QmA ykEVhdtMhYR/fga/0ClE5hLZduAVsmHzZhtQvURbymZJcMQwBmWjh7LvsjTgmL1+PE9B wOPOO0qgj1h6jRiVZzQjy/I32TsBzGybiJlwSzM2dnD2b3s/HMwR9XZFXj5pq/lrCto+ NwroRglL7m21FBIGwLN+1gSeW2k/xGiZmykGTrY36sxNUSEn2PFyJg8U2gVUqEnIUPLF aTVA== MIME-Version: 1.0 X-Received: by 10.152.87.139 with SMTP id ay11mr42679976lab.38.1409769202295; Wed, 03 Sep 2014 11:33:22 -0700 (PDT) Received: by 10.114.244.73 with HTTP; Wed, 3 Sep 2014 11:33:22 -0700 (PDT) In-Reply-To: <54074DAB.9020801@innovationslab.net> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> Date: Wed, 3 Sep 2014 13:33:22 -0500 Message-ID: From: Behcet Sarikaya To: Brian Haberman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/aVAlJ5grprN2hzI_c0ouuf7nueQ Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 03 Sep 2014 18:33:26 -0000 On Wed, Sep 3, 2014 at 12:19 PM, Brian Haberman wrote: > > > On 9/3/14 12:50 PM, Behcet Sarikaya wrote: >> Hi Brian, >> >> On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman >> wrote: >>> Just for clarification... >>> >>> On 9/3/14 12:22 PM, Behcet Sarikaya wrote: >>> >>>> >>>> I am also concerned on the time DMM is taking on dressing up the >>>> charter text. I remind you on what Jari Arkko who is founding AD for >>>> DMM said in Toronto admin plenary: >>>> WGs should have solution work from day 1. >>> >>> Not "should", but rather "could". Not all WGs need to have >>> requirements, frameworks, architecture, etc. That is why this type of >>> discussion during charter development is important. >> >> Here is the quote: >> WGs should have solution work from day 1 >> >> from page 22 of Jari's slides at: >> >> http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf > > Yes, that is what the slide says. The IESG discussed the contents of > this presentation and the overwhelming consensus (and what was > verbalized in the plenary) is that WGs should not be formed where the > *only* output is architecture, frameworks, and/or requirements > documents. The charter should have protocol/solution work on the > charter from day one. It does not mean that non-solution documents > should be skipped if they are needed or provide useful background. > > The charter text that Jouni sent to the mailing has four (4) work items. > By my read, three (3) of them are solutions to identified problem > areas. So, I believe the charter is following the spirit of Jari's > plenary slides. > > Your only complaint is about the first work item. I have seen people > asking about clarifications on that work item, but you are the only one > who wants it removed. I believe others are in favor of providing a > document of the high-level models being targeted for the solutions work. > You don't seem to understand my points. Anyway, it is better for me to stop this discussion. Regards, Behcet > At this point, the WG chairs need to determine if there is consensus for > the latest charter text. > > Regards, > Brian > From nobody Wed Sep 3 11:53:25 2014 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 743461A06AC for ; Wed, 3 Sep 2014 11:53: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 8rkTMFczSZCP for ; Wed, 3 Sep 2014 11:53: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 EF1F21A04C5 for ; Wed, 3 Sep 2014 11:53: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 D54BF88127; Wed, 3 Sep 2014 11:53:21 -0700 (PDT) Received: from clemson.local (c-76-21-129-88.hsd1.md.comcast.net [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7C1B4136811D; Wed, 3 Sep 2014 11:53:21 -0700 (PDT) Message-ID: <540763A0.7080509@innovationslab.net> Date: Wed, 03 Sep 2014 14:53:20 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Behcet Sarikaya References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ltvq9LrcevtEgHpKeJCmgEI0hh9qSTs6W" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/y-W5yC7GZclTsvzmXw_K6iPCk1Y Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 03 Sep 2014 18:53:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ltvq9LrcevtEgHpKeJCmgEI0hh9qSTs6W Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >=20 > You don't seem to understand my points. That is quite possible. Your comment on the list was "I am against any deployment work before we decide on a solution..." I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian --ltvq9LrcevtEgHpKeJCmgEI0hh9qSTs6W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUB2OgAAoJEBOZRqCi7goqqtoIAKDrO1BUhTrRn85DPXL2HP7o QFgT2+cQzE7pTof2YO2R8ek2rgzEX7+GFknOkp0i3okIyT2Tv94OjZAMsWQhv5iv uz16F5IZmQnWamFbLOjRPiakFu+7t7MvOjRCnDXxBBGSgG/d9JeXAXqCRIM/PD9b RDyQixtY5wvNDkwMBbanyPZCk6nP37gLWXs2Nx9HC2fzBCJAMn1lDOE04wYDxfyR MQe7vdCLOloHpDr5DeJHIBTiLHwWOZQRvkwNC7EK7pv5PuZoHRK1BbNBxnzazavE a+T2BlFqT9D/yg2OlwBAR9KhCHiua9hTFlxR7TTJc4NZD53fj9y6TL7WZYJTE+o= =uJGJ -----END PGP SIGNATURE----- --ltvq9LrcevtEgHpKeJCmgEI0hh9qSTs6W-- From nobody Wed Sep 3 12:52:45 2014 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 667411A6F98 for ; Wed, 3 Sep 2014 12:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 J3jqHM2VBOvk for ; Wed, 3 Sep 2014 12:52:33 -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 4E05B1A0AE4 for ; Wed, 3 Sep 2014 12:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12103; q=dns/txt; s=iport; t=1409773953; x=1410983553; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Zo/6hLJbBlRHmE+efg6n3dlMgpjnq7nZyaf+DjxneGo=; b=AsbtApKlyxV0QdnDKT5VZ0scNEyqu3Dg+dUSMLunq06rqQGSIIxRy9n1 UB56yPyOfMxODXSFc54tUCrqk2Z+QOUCe3FBr1U8/LqxZKljET8hHoNNI dI1cIX0qfAvcK1EOV496n9DyQbOdlZUz9i7+Q5D80jLYcfEiz34PZTMo1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAHdwB1StJV2b/2dsb2JhbABZgw1TVwTIQQqHTAGBDRZ3hAQBAQQBAQE3MgIGBRIBCBIGHgkoBgsUAw4CBA4FG4gTAxENuFQNhj4BEwSNIIFLEQFQB4RMBZEyhC6COoIzghCOZ4Y3g2FsgQYEBRcigQcBAQE X-IronPort-AV: E=Sophos;i="5.04,459,1406592000"; d="scan'208";a="74678633" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 03 Sep 2014 19:52:32 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s83JqVnS011871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Sep 2014 19:52:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 3 Sep 2014 14:52:31 -0500 From: "Sri Gundavelli (sgundave)" To: "sarikaya@ieee.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPx7CZKedbm+Rs8UOKnYPVR+kumg== Date: Wed, 3 Sep 2014 19:52:31 +0000 Message-ID: In-Reply-To: <5406A20F.60604@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.217] Content-Type: text/plain; charset="us-ascii" Content-ID: <84600E2931B5D64B9AA1B6361E00C4A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/keuL3MkakCJMjqcuiMkb3Il57j4 Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 03 Sep 2014 19:52:42 -0000 I don't follow this objection either. This discussion just derails established consensus after months of discussions. We design protocols to enable deployment/solutions/architectures. Those solutions/architectures are not unique to a specific SDO or unique to a specific access. Its a broader framework. The agreements here are based on IETF WG consensus and not strictly based on one specific SDO's requirement. This type of out of context references to historical material does not help these discussions. Sri On 9/2/14 10:07 PM, "Jouni Korhonen" wrote: >We were on this in yesterday's interim call. We have a proposal text >now. You were also on the call but I did not record you commenting >anything during the discussion we had on this particular topic. Are you >now saying the resolution we have now in the charter text is not adequate? > >- JOuni > >9/2/2014 11:39 PM, Behcet Sarikaya kirjoitti: >> On Mon, Sep 1, 2014 at 1:34 PM, Jouni Korhonen >>wrote: >>> Behcet, >>> >>> Obviously that protocols are known that the intended deployment is >>>going to >>> use. The details what goes inside that protocol are not. This holds >>>for my >>> example case 3GPP as well. >>> >>> We do not need to into same level of detail that e.g. 3GPP stage-2 has >>> detailing all signaling flows and so on. I believe we as a WG are >>>competent >>> enough to make a fine division what level of detail is left for the >>> "deployment models and scenarios" and what goes into protocol >>>solutions. >>> >> >> I hope you read previous mails on this issue. >> >> I think it clear that 3GPP agrees with IETF on the interpretation of >> deployment. How can we close our eyes on this and try to put the horse >> before the cart? >> >> Why not simply remove it? >> >> Regards, >> Behcet >> >> >> >>> - Jouni >>> >>> 9/1/2014 6:43 PM, Behcet Sarikaya kirjoitti: >>> >>>> On Mon, Sep 1, 2014 at 3:25 AM, Jouni wrote: >>>>> >>>>> >>>>> Alper, >>>>> >>>>> I hear your concern. Anyway, the division here is similar to (3GPP) >>>>> stage-2 and stage-3 work. The ""deployment models and scenarios" are >>>>>the >>>>> stage-2 descriptions and then we also need the protocol level >>>>>solutions that >>>>> are in separate documents. >>>>> >>>> >>>> Thanks Alper for raising this issue. >>>> >>>> 3GPP Stage 2 like in SA2 documents are architecture documents. >>>> I don't understand what is going on here. >>>> >>>> I am looking at 23.402 on Architecture Enhancements for non-3GPP >>>>accesses. >>>> >>>> Yes, this document talks about deployment in just a few places, here >>>> is one occurrence: on page 64, PCC deployment options >>>> on page 94, PMIP based S5/S8 deployments, etc. >>>> >>>> So in all cases the protocol, i.e. PCC or PMIP is known. >>>> >>>> Regards, >>>> >>>> Behcet >>>>> >>>>> Makes sense? >>>>> >>>>> - Jouni >>>>> >>>>> >>>>> On Sep 1, 2014, at 10:13 AM, Alper Yegin wrote: >>>>> >>>>>>> Okay, we are not going to define how the existing 3FPP system >>>>>>>works - >>>>>>> that knowledge is assumed. What I thought goes into the document, >>>>>>>for >>>>>>> example, in the case of 3GPP system would be identifying the >>>>>>>architecture >>>>>>> changes or modifications needed. If the deployment model assumes >>>>>>>all network >>>>>>> functions are virtualized, the document states that and lays out >>>>>>>the >>>>>>> architecture based on that. Satoru's & Ryuji's vEPC deployment >>>>>>>model (based >>>>>>> on their solution) is IMHO a good example of what could be >>>>>>>documented. The >>>>>>> similar applies for other system architectures such as SP Wi-Fi >>>>>>>etc. >>>>>>> >>>>>> >>>>>> Jouni, >>>>>> >>>>>> The "architecture changes" would be based on the a "specific >>>>>>solution". >>>>>> So, as part of describing a solution one can be talking about what >>>>>>you are >>>>>> suggesting above. But I don't understand how we can be talking about >>>>>> "deployment models and scenarios" before we agree on the solutions. >>>>>> >>>>>> Alper >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>>> o Enhanced mobility anchoring: define protocol solutions >>>>>>>>>>>for a >>>>>>>>>>> gateway and mobility anchor assignment and mid-session >>>>>>>>>>> mobility >>>>>>>>>>> anchor switching that go beyond what has been >>>>>>>>>>>specified, for >>>>>>>>>>> example, in RFC 6097, 6463, and 5142. Traffic steering >>>>>>>>>>> associated with the anchor switch is also in-scope if >>>>>>>>>>>deemed >>>>>>>>>>> appropriate. >>>>>>>>>>> >>>>>>>>>>> o Forwarding path and signaling management: the function >>>>>>>>>>> that handles mobility management signaling interacts >>>>>>>>>>>with the >>>>>>>>>>> DMM network elements for managing the forwarding state >>>>>>>>>>> associated with a mobile node's IP traffic. These two >>>>>>>>>>> functions >>>>>>>>>>> may or may not be collocated. Furthermore, the >>>>>>>>>>>forwarding >>>>>>>>>>> state >>>>>>>>>>> may also be distributed into multiple network elements >>>>>>>>>>> instead >>>>>>>>>>> of a single network element (e.g., anchor). Protocol >>>>>>>>>>> extensions >>>>>>>>>>> or new protocols will be specified to allow the above >>>>>>>>>>> mentioned >>>>>>>>>>> forwarding path and signalling management. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I cannot separate "mobility anchoring" from "fwding path and >>>>>>>>>> signaling management". >>>>>>>>>> Wherever you want to set your anchor or move your anchor to, >>>>>>>>>>you'd >>>>>>>>>> need signaling >>>>>>>>>> and setting up data path. The two are inseparable. >>>>>>>>>> Having said that, I'm OK to keep the current work item >>>>>>>>>>descriptions >>>>>>>>>> and finalize >>>>>>>>>> rechartering. Once we have detailed discussions about the >>>>>>>>>>breakdown >>>>>>>>> >>>>>>>>> of the work, we >>>>>>>>>> >>>>>>>>>> can come back and refine the goals and milestones (as already >>>>>>>>>>stated >>>>>>>>> >>>>>>>>> below [*]). >>>>>>>>> >>>>>>>>> The enhanced mobility anchoring above is/was rather MIP type >>>>>>>>> solutions >>>>>>>>> influenced with "anchors" like we understand today, while the >>>>>>>>> "forwarding path and signaling management" was meant for more >>>>>>>>>future >>>>>>>>> oriented solutions where the forwarding path does not necessarily >>>>>>>>> have >>>>>>>>> anything mobility specific etc. >>>>>>>>> >>>>>>>> >>>>>>>> (Just FYI: It's not possible to gather what you are saying from >>>>>>>> reading >>>>>>>> the charter. Different people reading the charter may not have the >>>>>>>> same >>>>>>>> understanding. But like I said, this is just FYI, I can live with >>>>>>>>this >>>>>>>> text until we come back and refine it later). >>>>>>> >>>>>>> >>>>>>> Ok. I'll try to clarify the point the text tries to make. >>>>>>> >>>>>>> - Jouni >>>>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Alper >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Any other opinions on collapsing these two? >>>>>>>>> >>>>>>>>> - Jouni >>>>>>>>> >>>>>>>>>>> o Exposing mobility state to mobile nodes and network >>>>>>>>>>>nodes: >>>>>>>>>>> define solutions that allow, for example, mobile nodes >>>>>>>>>>>to >>>>>>>>>>> select >>>>>>>>>>> either a care-of address or a home address depending on >>>>>>>>>>>an >>>>>>>>>>> application' mobility needs. In order to enable this >>>>>>>>>>> functionality, the network-side control functions and >>>>>>>>>>>other >>>>>>>>>>> networking nodes must also be able to exchange >>>>>>>>>>>appropriate >>>>>>>>>>> control information, as well as to the mobile nodes and >>>>>>>>>>>their >>>>>>>>>>> applications. >>>>>>>>>>> >>>>>>>>>>> The working group may decide to extend the current milestones >>>>>>>>>>>based >>>>>>>>>>> on >>>>>>>>>>> the new information and knowledge gained during working on >>>>>>>>>>>other >>>>>>>>>>> documents listed in the initial milestones. [*] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Alper >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Possible new documents and >>>>>>>>>>> milestones must still fit into the overall DMM charter scope as >>>>>>>>>>> outlined >>>>>>>>>>> above. >>>>>>>>>>> >>>>>>>>>>> Goals and Milestones: >>>>>>>>>>> >>>>>>>>>>> Feb 2015 - Submit 'The deployment models and scenarios' as a >>>>>>>>>>> working >>>>>>>>>>> group document(s). To be Informational RFC. >>>>>>>>>>> >>>>>>>>>>> Feb 2015 - Submit 'Enhanced mobility anchoring' as a working >>>>>>>>>>>group >>>>>>>>>>> document. To be Proposed Standard. >>>>>>>>>>> >>>>>>>>>>> Feb 2015 - Submit 'Forwarding path and signaling management' >>>>>>>>>>>as a >>>>>>>>>>> working group document. To be Proposed Standard. >>>>>>>>>>> >>>>>>>>>>> May 2015 - Submit 'Exposing mobility state to mobile nodes and >>>>>>>>>>> network >>>>>>>>>>> nodes' as a working group document(s). To be >>>>>>>>>>>Proposed >>>>>>>>>>> Standard. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> May 2015 - Submit 'The deployment models and scenarios' >>>>>>>>>>>submitted >>>>>>>>>>> to >>>>>>>>>>> the IESG. To be Informational RFC. >>>>>>>>>>> >>>>>>>>>>> Jun 2015 - Submit 'Enhanced mobility anchoring' submitted to >>>>>>>>>>>the >>>>>>>>>>> IESG. >>>>>>>>>>> To be Proposed Standard. >>>>>>>>>>> >>>>>>>>>>> Jun 2015 - Submit 'Forwarding path and signaling management' >>>>>>>>>>> submitted >>>>>>>>>>> to the IESG. To be Proposed Standard. >>>>>>>>>>> >>>>>>>>>>> Oct 2015 - Submit 'Exposing mobility state to mobile nodes and >>>>>>>>>>> network >>>>>>>>>>> nodes' submitted to the IESG. To be Proposed >>>>>>>>>>>Standard. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7/29/2014 4:22 PM, Jouni Korhonen kirjoitti: >>>>>>>>>>>> >>>>>>>>>>>> The webex sessions have been cancelled in accordance of better >>>>>>>>>>>> IETF >>>>>>>>>>>> process compliancy. New dates will be announced rougghly two >>>>>>>>>>>>weeks >>>>>>>>>>>> ahead >>>>>>>>>>>> of tomorrow. >>>>>>>>>>>> >>>>>>>>>>>> You can (and should) still actively send edits to the list and >>>>>>>>>>>> I'll >>>>>>>>>>>> update the text accordingly. Maybe we manage to get ready even >>>>>>>>>>>> without a >>>>>>>>>>>> call! >>>>>>>>>>>> >>>>>>>>>>>> - Jouni & Dapeng >>>>>>>>>>>> >>>>>>>>>>>> 7/25/2014 12:49 AM, Jouni Korhonen kirjoitti: >>>>>>>>>>>>> >>>>>>>>>>>>> Folks, >>>>>>>>>>>>> >>>>>>>>>>>>> The latest charter draft can be found here: >>>>>>>>>>>>> >>>>>>>>>>>>>=20 >>>>>>>>>>>>>https://github.com/jounikor/dmm-re-charter/blob/master/rechart >>>>>>>>>>>>>er_draft.txt >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The deadline for the text chnges are 31st July. I'll setup a >>>>>>>>>>>>>call >>>>>>>>>>>>> for >>>>>>>>>>>>> next week so that those who want to dial in and have verbal >>>>>>>>>>>>> commenting >>>>>>>>>>>>> can do that. In a meanwhile, email works as usual for >>>>>>>>>>>>>updates and >>>>>>>>>>>>> comments on the text. The actual milestone dates are to be >>>>>>>>>>>>>done >>>>>>>>>>>>> last but >>>>>>>>>>>>> suggestions are more than welcome. >>>>>>>>>>>>> >>>>>>>>>>>>> - 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 > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 3 23:47:52 2014 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 21F8F1A0B15 for ; Wed, 3 Sep 2014 23:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, URG_BIZ=0.573] 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 3yUYxr6-Om7s for ; Wed, 3 Sep 2014 23:47:48 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 3067C1A0B0E for ; Wed, 3 Sep 2014 23:47:47 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0M5wTf-1YIuxx3VQf-00xvh1; Thu, 04 Sep 2014 08:47:45 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <2134F8430051B64F815C691A62D9831832D040CD@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 4 Sep 2014 09:47:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4C4F8606-FBE7-4BAC-8F81-F1B63695357B@yegin.org> References: <2134F8430051B64F815C691A62D9831832D031C3@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D040CD@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:o0BxZsKxsh4YopbDPAymkq8tUb8jjrWWS6+UJHapq4t wql0r8sfxBxWmVO8B0dkhF0utyW8vBsGvhSybf8QqIKwduh7kz TQI1/5NYIKNb3Qo3r/9YcotEkzOXTPm1ueWVk/coWpu1NrHCCy y4S/DinmbpHLxtt/QYmqm4ySq8zBf393nz/7NyX8kcR2rQV48A ge7uD0UEWoY0exTm2Rg8RdKv0SQzJGpxORGP337+fgIPQPnDOg GxFQyfxHbG1DoehqWbJRkTBnmwTAEa/L96dhMnw1K+6i7AXDLG HYPBwj8BMQOY/vQWQVYqNSX8KHfAOfeSs/Z4A0aaG6/pngPYhv +z4MPJNSbRLN7aT8RbjigTS98Suo6Kta2T2xdwPUT9J2H6BS2M QO8D0T1oqi9WA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/iVwA73Su4vR1ZIWMyDbSW2TmSkQ Cc: "dmm@ietf.org" Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" 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, 04 Sep 2014 06:47:50 -0000 Hi Fred, Can this scenario not be realized by simply placing an HA in the = enterprise network and using Mobile IP? Alper On Sep 3, 2014, at 7:37 PM, Templin, Fred L wrote: > Hi, >=20 > The specific passage from the new draft that I wanted the wg to > see is the following (with references to AERO removed). Please > review and send questions or comments. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > --- >=20 > 3. A Day in the Life of an Enterprise Mobile Device User >=20 > An enterprise network mobile device user ("Bill") begins his workday > by seating his primary end user device (EUD) (e.g., a laptop = computer, > a tablet, a smart phone, etc.) in a docking station at his office = desk > and turning the device on. The docking station connects Bill's EUD = to > the enterprise wired LAN, and the EUD receives a Topologically-Fixed > Address (TFA) from the infrastructure. Bill's EUD further discovers > the DMM service within the enterprise network and requests a = Topology > Independent Prefix (TIP)delegation. Bill's EUD receives the same = TIP > delegation it gets every time it connects to the enterprise network, > because the DMM service has an administratively set mapping between > the TIP and Bill's EUD device ID. >=20 > Bill's EUD can then access topologically-fixed enterprise services > using its TFA directly, and can access DMM services by using an > address from its TIP as the source address for tunneling over the > enterprise network. As Bill's workday unfolds, his EUD uses the DMM > service to correspond with other EUDs in peer-to-peer sessions, join > lengthy virtual conferencing sessions, access enterprise fileshares, > etc. The DMM service ensures that optimal routes are maintained so > that tunneled communications flow over direct paths and network > infrastructure elements are not unnecessarily over-burdened. >=20 > While communications sessions such as the video conference are still > in progress, Bill leaves the office to attend a meeting in a nearby > conference room. He disconnects his EUD from the docking station = and > in the process drops his connection to the wired LAN. The EUD > quickly enables a WiFi interface that searches for a Service Set > Identifier (SSID) that can provide wireless access within the > enterprise network. The EUD authenticates itself to the network via > the SSID using its pre-loaded certificates, and uses a securing > mechanism such as IEEE 802.1x to assure Confidentiality, Integrity > and Availability (CIA). The EUD receives a new TFA from the = network, > then communicates its new TIP-to-TFA association to the DMM service > and any active peer correspondents. Any ongoing communications > sessions will continue to see the same (stable) TIP. >=20 > Bill then leaves the enterprise campus to attend an off-site = customer > meeting with his EUD still powered on and actively seeking to > maintain network connectivity. As Bill departs from the building, > the WiFi signal fades until it can no longer support communications, > and the EUD quickly enables a 4G cellular wireless interface that > connects Bill's EUD to a cellular service provider. The EUD then > locates the Internet address of an enterprise network security > gateway and initiates a VPN session with the gateway (which also = acts > participates in the DMM service). The DMM service updates the = routing > system, and Bill can continue to use the same TIP that was assigned > to his EUD when he started his workday even though the EUD is now > communicating over a VPN configured over the public Internet instead > of over the secured campus LAN. >=20 > Bill subsequently arrives at the customer meeting at a public > restaurant with a WiFi hotspot. His EUD quickly powers up its WiFi > interface and powers down the 4G interface. The EUD uses DMM > signaling to communicate the new TFA to the security gateway and the > VPN survives the mobility event. Moreover, the EUD can continue to > use the same TIP it received at the beginning of the workday, and > ongoing communication sessions can continue until Bill explicitly > discontinues them. >=20 > After the customer meeting, Bill leaves the restaurant and > subsequently passes through several additional transitions from WiFi > hotspots to 4G wireless. Again, the DMM service keeps the VPN > session alive, and the TIP assigned to the EUD remains in continuous > use in active communication sessions as well as to allow Bill to > receive notifications and process urgent requests. When Bill = returns > to his office, the EUD discontinues use of the VPN while keeping its > TIP active after re-attaching to the campus LAN. >=20 > Bill ends his workday, powers down his EUD and returns home. Bill > powers on his EUD to check e-mails, and connects to the enterprise > network via a VPN configured over his home ISP service. The EUD > again receives the same TIP that it used within the enterprise > network domain, and Bill can access DMM services the same as if he > was in the office. Bill finally shuts down for the evening, and > begins his next workday in the same fashion. Again, the EUD = receives > the same TIP as always regardless of the access network point of > connection over which the EUD enters the enterprise. >=20 >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L >> Sent: Tuesday, September 02, 2014 11:05 AM >> To: dmm@ietf.org >> Subject: [DMM] FW: I-D Action: draft-templin-aeroent-00.txt >>=20 >> Hello, >>=20 >> During the call today, there was some interest expressed in learning >> more about the enterprise network mobility use case. I have submitted >> a new brief document called "AERO Enterprise Network Profile" (below) >> that provides a discussion of distributed mobility management needs >> for enterprise networks. Although the document specifically cites = AERO, >> the use case applies to any solution alternative that could meet the >> requirements. Also, I am not asking this document be considered as a >> dmm wg item at this time, but rather offering it for informational >> purposes. Please let me know if there are any questions or comments. >>=20 >> Thanks - Fred >> fred.l.templin@boeing.com >>=20 >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org >> Sent: Tuesday, September 02, 2014 10:51 AM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-templin-aeroent-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : AERO Enterprise Network Profile >> Author : Fred L. Templin >> Filename : draft-templin-aeroent-00.txt >> Pages : 12 >> Date : 2014-09-02 >>=20 >> Abstract: >> Enterprise networks provide a secured data communications >> infrastructure built for the purpose of information sharing and >> increased productivity for end users within the organization. >> Enterprise networks are often organized as private Internets unto >> themselves that connect to the global Internet either not at all or >> via firewalls, proxies, and/or other network securing devices. = This >> document discusses an AERO enterprise network profile that outlines >> new and more flexible methods for connecting, tracking and managing >> mobile organizational assets. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-templin-aeroent/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-templin-aeroent-00 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=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 Sep 4 00:38:54 2014 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 61EB21A6EE8 for ; Thu, 4 Sep 2014 00:38:53 -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 JydECul3Rwkb for ; Thu, 4 Sep 2014 00:38:52 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82B71A6EE1 for ; Thu, 4 Sep 2014 00:38:51 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id el20so2672180lab.20 for ; Thu, 04 Sep 2014 00:38: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=2LSHtq4ps6ot54NIEDZj9PQP4+Fx4q7413audk7HyLI=; b=o0YOOYxj7F4AUMYLIbWHqn4wAtJAnne1nBOgSjsTMMjG56sy2QDIOmy+/7eb2yHlQY HIVIL/9TOdj+DYtVnwV20I3PF9j40JP/5GCbbsXHpUonX61lngEwf17RNzQ8B3q5BhW3 sZGt/eRZIeQTcemVcbJtn4R8cmmGxQdbnBYU3w2V+FelwQszEpGCdJHTnS5kRF4qeh2j B6pZGnJGqjrL4aVds0a/1uictpkoRD4bjSN/RJKiTrRuc21zayzN5VCEf9dOQJROLifU I6G1AY4nG4FIujrs99h2k2Rnjl5ge2tyrkmh623O1DgW8HPixw8neJozz1GeDnmPWdC2 la/Q== X-Received: by 10.112.56.206 with SMTP id c14mr2503244lbq.27.1409816329788; Thu, 04 Sep 2014 00:38:49 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id x10sm263215lbj.25.2014.09.04.00.38.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 00:38:48 -0700 (PDT) Message-ID: <54081706.4020101@gmail.com> Date: Thu, 04 Sep 2014 10:38:46 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" , jouni.nospam@gmail.com References: <54063B90.9020909@gmail.com> In-Reply-To: <54063B90.9020909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/X1otMCqYXTaMqNxXk0Qxk-U6kz0 Subject: Re: [DMM] interim call #1 and rechater text 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, 04 Sep 2014 07:38:53 -0000 Folks, Once the interim minutes are out for everyone to read, we'll wait for one week for comments on the charter text. If there are no disagreement (typos and small tweaks do not count as a disagreement) the chairs will put the charter forward. Please pay specific attention to the milestone dates. - Jouni & dapeng 9/3/2014 12:50 AM, Jouni Korhonen kirjoitti: > Folks, > > Check the charter text we came up with during the interim call #1. The > diffs are here: > https://github.com/jounikor/dmm-re-charter/commit/4475c1c7aeac024171f6b669d330cfae98bdc283 > > > And the "clean" text is here: > https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt > > Have a look at the text. If you agree with the content we'll start > moving this forward. > > The minutes and stuff from the interim call will follow shortly. > > > - Jouni & Dapeng From nobody Thu Sep 4 00:57:03 2014 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 893F71A6F30 for ; Thu, 4 Sep 2014 00:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5k3nfKCfDR9a for ; Thu, 4 Sep 2014 00:57:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D271A6F2C for ; Thu, 4 Sep 2014 00:57:01 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id F36EE2AC260; Thu, 4 Sep 2014 09:56:58 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id D8BF5180089; Thu, 4 Sep 2014 09:56:58 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 09:56:58 +0200 From: To: Jouni Korhonen , "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Thread-Topic: [DMM] interim call #1 and rechater text Thread-Index: AQHPxvflKT3b8/RH9EmltigBGo0+c5vwdw0AgAAkMnA= Date: Thu, 4 Sep 2014 07:56:57 +0000 Message-ID: <7231_1409817418_54081B4A_7231_19107_1_81C77F07008CA24F9783A98CFD706F711429A480@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <54063B90.9020909@gmail.com> <54081706.4020101@gmail.com> In-Reply-To: <54081706.4020101@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.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.3.210920 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/d7Rffm7x0vi3zPE5cCIDLfoinq4 Subject: Re: [DMM] interim call #1 and rechater text 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, 04 Sep 2014 07:57:02 -0000 Hi Jouni, I did not attend the interim meeting, so maybe I'm missing something... bu= t this draft charter does not include anymore item related to the maintenan= ce of IP mobility protocols (If I remember well, previous proposal had this= item). Is it an oversight? Pierrick >-----Message d'origine----- >De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Jouni Korhonen >Envoy=E9=A0: jeudi 4 septembre 2014 09:39 >=C0=A0: dmm@ietf.org; dmm-chairs@tools.ietf.org; jouni.nospam@gmail.com >Objet=A0: Re: [DMM] interim call #1 and rechater text > >Folks, > >Once the interim minutes are out for everyone to read, we'll wait for one >week for comments on the charter text. If there are no disagreement (typos >and small tweaks do not count as a disagreement) the chairs will put the >charter forward. Please pay specific attention to the milestone dates. > >- Jouni & dapeng > > > >9/3/2014 12:50 AM, Jouni Korhonen kirjoitti: >> Folks, >> >> Check the charter text we came up with during the interim call #1. The >> diffs are here: >> https://github.com/jounikor/dmm-re- >charter/commit/4475c1c7aeac024171f6 >> b669d330cfae98bdc283 >> >> >> And the "clean" text is here: >> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft >> .txt >> >> Have a look at the text. If you agree with the content we'll start >> moving this forward. >> >> The minutes and stuff from the interim call will follow shortly. >> >> >> - 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 Thu Sep 4 01:04:13 2014 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 0E8931A6F65 for ; Thu, 4 Sep 2014 01:04:13 -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 Fdl05vkYwynv for ; Thu, 4 Sep 2014 01:04:11 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BDC1A6EF7 for ; Thu, 4 Sep 2014 01:04:10 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id w7so11126458lbi.11 for ; Thu, 04 Sep 2014 01:04:09 -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=kDHTf1yOCpSyAu3j06FQeDXPe92hKhTRua7wPBEMSU8=; b=jtfHVQzfcnFt/xo+tbroPr0LPdSFjcAJhPs37+useqqJN6MH6WfPUFJNdNj/g9bgX9 Eb0LvqPJ17nPYLWa/jTKZSJzzL49PE4x9pyiuj8KW6lLHCcvQpkZL6ae1w8k9DsBJy16 xF2SF7z6UvgiKw7PUc05jw989gBJFnSDqyfrnQh4fb0uYQqpJypi2KhUp95bPZ1TZ7g+ TqYFbdzZnKxVAnBpEtO1jWJ0Sq0TpWOz+Y0t2no/KU0YHQAvncALq+E2biPIBQEeLM0U 5Ag5mOohsHZppDtfCHIQ9Uyhxn0l/7SJBP9S4aZBAf2A0bKKGKdc92bE8wyfV8dfc8yc 0FTA== X-Received: by 10.152.29.1 with SMTP id f1mr2672670lah.47.1409817848977; Thu, 04 Sep 2014 01:04:08 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id qr9sm285150lbb.11.2014.09.04.01.04.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 01:04:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <7231_1409817418_54081B4A_7231_19107_1_81C77F07008CA24F9783A98CFD706F711429A480@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 4 Sep 2014 11:04:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6FAC6094-F76A-44FB-812F-DE137E010386@gmail.com> References: <54063B90.9020909@gmail.com> <54081706.4020101@gmail.com> <7231_1409817418_54081B4A_7231_19107_1_81C77F07008CA24F9783A98CFD706F711429A480@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/8_EElEJB_0CmI5gziY1-2ipLSEw Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] interim call #1 and rechater text 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, 04 Sep 2014 08:04:13 -0000 Pierrick,=20 The third paragraphs says: A topic of particular focus will be mobility anchoring in this = new context, and the DMM working group is chartered to work on maintenance-oriented extensions of the Mobile IPv6 protocol = family (RFC ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the = IETF. So I think we still have that there. - Jouni On Sep 4, 2014, at 10:56 AM, wrote: > Hi Jouni, >=20 > I did not attend the interim meeting, so maybe I'm missing = something... but this draft charter does not include anymore item = related to the maintenance of IP mobility protocols (If I remember well, = previous proposal had this item). Is it an oversight? >=20 > Pierrick >=20 >> -----Message d'origine----- >> De : dmm [mailto:dmm-bounces@ietf.org] De la part de Jouni Korhonen >> Envoy=E9 : jeudi 4 septembre 2014 09:39 >> =C0 : dmm@ietf.org; dmm-chairs@tools.ietf.org; jouni.nospam@gmail.com >> Objet : Re: [DMM] interim call #1 and rechater text >>=20 >> Folks, >>=20 >> Once the interim minutes are out for everyone to read, we'll wait for = one >> week for comments on the charter text. If there are no disagreement = (typos >> and small tweaks do not count as a disagreement) the chairs will put = the >> charter forward. Please pay specific attention to the milestone = dates. >>=20 >> - Jouni & dapeng >>=20 >>=20 >>=20 >> 9/3/2014 12:50 AM, Jouni Korhonen kirjoitti: >>> Folks, >>>=20 >>> Check the charter text we came up with during the interim call #1. = The >>> diffs are here: >>> https://github.com/jounikor/dmm-re- >> charter/commit/4475c1c7aeac024171f6 >>> b669d330cfae98bdc283 >>>=20 >>>=20 >>> And the "clean" text is here: >>> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft >>> .txt >>>=20 >>> Have a look at the text. If you agree with the content we'll start >>> moving this forward. >>>=20 >>> The minutes and stuff from the interim call will follow shortly. >>>=20 >>>=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 From nobody Thu Sep 4 01:17:43 2014 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 67F4A1A6F9A for ; Thu, 4 Sep 2014 01:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 fnHbV5jxWhwF for ; Thu, 4 Sep 2014 01:17:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38D11A6FBA for ; Thu, 4 Sep 2014 01:17:20 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id D02721B818E; Thu, 4 Sep 2014 10:17:18 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B31C0384069; Thu, 4 Sep 2014 10:17:18 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Thu, 4 Sep 2014 10:17:18 +0200 From: To: Jouni Thread-Topic: [DMM] interim call #1 and rechater text Thread-Index: AQHPxvflKT3b8/RH9EmltigBGo0+c5vwdw0AgAAkMnD//+LhgIAAJFQA Date: Thu, 4 Sep 2014 08:17:17 +0000 Message-ID: <31534_1409818638_5408200E_31534_12037_1_81C77F07008CA24F9783A98CFD706F711429A4B0@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <54063B90.9020909@gmail.com> <54081706.4020101@gmail.com> <7231_1409817418_54081B4A_7231_19107_1_81C77F07008CA24F9783A98CFD706F711429A480@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6FAC6094-F76A-44FB-812F-DE137E010386@gmail.com> In-Reply-To: <6FAC6094-F76A-44FB-812F-DE137E010386@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.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.3.210920 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/FjJkzAX81E0262Tp_vRvEcFQYKQ Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] interim call #1 and rechater text 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, 04 Sep 2014 08:17:38 -0000 Oops... Sorry... I guess I need more coffee this morning.... or new pair of= glasses.... Thanks for the answer... >-----Message d'origine----- >De=A0: Jouni [mailto:jouni.nospam@gmail.com] >Envoy=E9=A0: jeudi 4 septembre 2014 10:04 >=C0=A0: SEITE Pierrick IMT/OLN >Cc=A0: dmm@ietf.org; dmm-chairs@tools.ietf.org >Objet=A0: Re: [DMM] interim call #1 and rechater text > >Pierrick, > >The third paragraphs says: > > A topic of particular focus will be mobility anchoring in this new > context, and the DMM working group is chartered to work on > maintenance-oriented extensions of the Mobile IPv6 protocol family >(RFC > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new > approaches which capitalize on other protocols specified by the IETF. > >So I think we still have that there. > >- Jouni > > >On Sep 4, 2014, at 10:56 AM, wrote: > >> Hi Jouni, >> >> I did not attend the interim meeting, so maybe I'm missing something...= but >this draft charter does not include anymore item related to the maintenance >of IP mobility protocols (If I remember well, previous proposal had this i= tem). >Is it an oversight? >> >> Pierrick >> >>> -----Message d'origine----- >>> De : dmm [mailto:dmm-bounces@ietf.org] De la part de Jouni Korhonen >>> Envoy=E9 : jeudi 4 septembre 2014 09:39 =C0 : dmm@ietf.org; >>> dmm-chairs@tools.ietf.org; jouni.nospam@gmail.com Objet : Re: [DMM] >>> interim call #1 and rechater text >>> >>> Folks, >>> >>> Once the interim minutes are out for everyone to read, we'll wait for >>> one week for comments on the charter text. If there are no >>> disagreement (typos and small tweaks do not count as a disagreement) >>> the chairs will put the charter forward. Please pay specific attention = to the >milestone dates. >>> >>> - Jouni & dapeng >>> >>> >>> >>> 9/3/2014 12:50 AM, Jouni Korhonen kirjoitti: >>>> Folks, >>>> >>>> Check the charter text we came up with during the interim call #1. >>>> The diffs are here: >>>> https://github.com/jounikor/dmm-re- >>> charter/commit/4475c1c7aeac024171f6 >>>> b669d330cfae98bdc283 >>>> >>>> >>>> And the "clean" text is here: >>>> https://github.com/jounikor/dmm-re- >charter/blob/master/recharter_dra >>>> ft >>>> .txt >>>> >>>> Have a look at the text. If you agree with the content we'll start >>>> moving this forward. >>>> >>>> The minutes and stuff from the interim call will follow shortly. >>>> >>>> >>>> - 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 >> 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. >> >> 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 d= elete >this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en >modified, changed or falsified. >> Thank you. >> ___________________________________________________________________________= ______________________________________________ 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 Thu Sep 4 02:50:19 2014 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 ED2181A01EE for ; Thu, 4 Sep 2014 02:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 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, J_CHICKENPOX_36=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665, URG_BIZ=0.573] 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 oDanoFnOpBsW for ; Thu, 4 Sep 2014 02:50:15 -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 EA1DC1A00AF for ; Thu, 4 Sep 2014 02:50:14 -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 s849oC99027059 for ; Thu, 4 Sep 2014 11:50:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 285D6202644 for ; Thu, 4 Sep 2014 11:50:27 +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 20C79202634 for ; Thu, 4 Sep 2014 11:50:27 +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 s849o9wf022794 for ; Thu, 4 Sep 2014 11:50:12 +0200 Message-ID: <540835D1.5080108@gmail.com> Date: Thu, 04 Sep 2014 11:50:09 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: dmm@ietf.org References: <2134F8430051B64F815C691A62D9831832D031C3@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D040CD@XCH-BLV-504.nw.nos.boeing.com> <4C4F8606-FBE7-4BAC-8F81-F1B63695357B@yegin.org> In-Reply-To: <4C4F8606-FBE7-4BAC-8F81-F1B63695357B@yegin.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/BSyoQcnG6K2iObGL67mXiamrZMI Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" 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, 04 Sep 2014 09:50:18 -0000 Le 04/09/2014 08:47, Alper Yegin a écrit : > Hi Fred, > > Can this scenario not be realized by simply placing an HA in the > enterprise network and using Mobile IP? I guess yes and no. YEs, in that it is a typical Mobile IP scenario with handovers WiFi/4G/Ethernet. No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not working well together. No, in that TIP (DHCPv6 Prefix Delegation?) is not clear how to work with a EUD device ID? Is it Ethernet's, WiFi's or 4G's interface MAC address? No, in that Mobile IP and prefixes are not known to lead to optimal routes, whereas the scenario says "optimal routes". No - but this is a stretch - the scenario does not mention the neceessity of user typing secure information on a screen (authenticate to web page on a public hotspot prior to ability to Mobile IP, or use One-Time Password tokens for VPN connections); any "seamless" mobility mechanism will need to automate this step; this is even more needed when considering devices without user interfaces, such as Mobile Routers using Mobile IP for a vehicle. Alex > > Alper > > > On Sep 3, 2014, at 7:37 PM, Templin, Fred L wrote: > >> Hi, >> >> The specific passage from the new draft that I wanted the wg to >> see is the following (with references to AERO removed). Please >> review and send questions or comments. >> >> Thanks - Fred fred.l.templin@boeing.com >> >> --- >> >> 3. A Day in the Life of an Enterprise Mobile Device User >> >> An enterprise network mobile device user ("Bill") begins his >> workday by seating his primary end user device (EUD) (e.g., a >> laptop computer, a tablet, a smart phone, etc.) in a docking >> station at his office desk and turning the device on. The docking >> station connects Bill's EUD to the enterprise wired LAN, and the >> EUD receives a Topologically-Fixed Address (TFA) from the >> infrastructure. Bill's EUD further discovers the DMM service >> within the enterprise network and requests a Topology Independent >> Prefix (TIP)delegation. Bill's EUD receives the same TIP >> delegation it gets every time it connects to the enterprise >> network, because the DMM service has an administratively set >> mapping between the TIP and Bill's EUD device ID. >> >> Bill's EUD can then access topologically-fixed enterprise services >> using its TFA directly, and can access DMM services by using an >> address from its TIP as the source address for tunneling over the >> enterprise network. As Bill's workday unfolds, his EUD uses the >> DMM service to correspond with other EUDs in peer-to-peer >> sessions, join lengthy virtual conferencing sessions, access >> enterprise fileshares, etc. The DMM service ensures that optimal >> routes are maintained so that tunneled communications flow over >> direct paths and network infrastructure elements are not >> unnecessarily over-burdened. >> >> While communications sessions such as the video conference are >> still in progress, Bill leaves the office to attend a meeting in a >> nearby conference room. He disconnects his EUD from the docking >> station and in the process drops his connection to the wired LAN. >> The EUD quickly enables a WiFi interface that searches for a >> Service Set Identifier (SSID) that can provide wireless access >> within the enterprise network. The EUD authenticates itself to >> the network via the SSID using its pre-loaded certificates, and >> uses a securing mechanism such as IEEE 802.1x to assure >> Confidentiality, Integrity and Availability (CIA). The EUD >> receives a new TFA from the network, then communicates its new >> TIP-to-TFA association to the DMM service and any active peer >> correspondents. Any ongoing communications sessions will continue >> to see the same (stable) TIP. >> >> Bill then leaves the enterprise campus to attend an off-site >> customer meeting with his EUD still powered on and actively >> seeking to maintain network connectivity. As Bill departs from >> the building, the WiFi signal fades until it can no longer support >> communications, and the EUD quickly enables a 4G cellular wireless >> interface that connects Bill's EUD to a cellular service provider. >> The EUD then locates the Internet address of an enterprise network >> security gateway and initiates a VPN session with the gateway >> (which also acts participates in the DMM service). The DMM >> service updates the routing system, and Bill can continue to use >> the same TIP that was assigned to his EUD when he started his >> workday even though the EUD is now communicating over a VPN >> configured over the public Internet instead of over the secured >> campus LAN. >> >> Bill subsequently arrives at the customer meeting at a public >> restaurant with a WiFi hotspot. His EUD quickly powers up its WiFi >> interface and powers down the 4G interface. The EUD uses DMM >> signaling to communicate the new TFA to the security gateway and >> the VPN survives the mobility event. Moreover, the EUD can >> continue to use the same TIP it received at the beginning of the >> workday, and ongoing communication sessions can continue until >> Bill explicitly discontinues them. >> >> After the customer meeting, Bill leaves the restaurant and >> subsequently passes through several additional transitions from >> WiFi hotspots to 4G wireless. Again, the DMM service keeps the VPN >> session alive, and the TIP assigned to the EUD remains in >> continuous use in active communication sessions as well as to >> allow Bill to receive notifications and process urgent requests. >> When Bill returns to his office, the EUD discontinues use of the >> VPN while keeping its TIP active after re-attaching to the campus >> LAN. >> >> Bill ends his workday, powers down his EUD and returns home. Bill >> powers on his EUD to check e-mails, and connects to the enterprise >> network via a VPN configured over his home ISP service. The EUD >> again receives the same TIP that it used within the enterprise >> network domain, and Bill can access DMM services the same as if he >> was in the office. Bill finally shuts down for the evening, and >> begins his next workday in the same fashion. Again, the EUD >> receives the same TIP as always regardless of the access network >> point of connection over which the EUD enters the enterprise. >> >>> -----Original Message----- From: dmm >>> [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: >>> Tuesday, September 02, 2014 11:05 AM To: dmm@ietf.org Subject: >>> [DMM] FW: I-D Action: draft-templin-aeroent-00.txt >>> >>> Hello, >>> >>> During the call today, there was some interest expressed in >>> learning more about the enterprise network mobility use case. I >>> have submitted a new brief document called "AERO Enterprise >>> Network Profile" (below) that provides a discussion of >>> distributed mobility management needs for enterprise networks. >>> Although the document specifically cites AERO, the use case >>> applies to any solution alternative that could meet the >>> requirements. Also, I am not asking this document be considered >>> as a dmm wg item at this time, but rather offering it for >>> informational purposes. Please let me know if there are any >>> questions or comments. >>> >>> Thanks - Fred fred.l.templin@boeing.com >>> >>> -----Original Message----- From: I-D-Announce >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org Sent: Tuesday, September 02, 2014 10:51 >>> AM To: i-d-announce@ietf.org Subject: I-D Action: >>> draft-templin-aeroent-00.txt >>> >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. >>> >>> >>> Title : AERO Enterprise Network Profile Author : Fred >>> L. Templin Filename : draft-templin-aeroent-00.txt Pages >>> : 12 Date : 2014-09-02 >>> >>> Abstract: Enterprise networks provide a secured data >>> communications infrastructure built for the purpose of >>> information sharing and increased productivity for end users >>> within the organization. Enterprise networks are often organized >>> as private Internets unto themselves that connect to the global >>> Internet either not at all or via firewalls, proxies, and/or >>> other network securing devices. This document discusses an AERO >>> enterprise network profile that outlines new and more flexible >>> methods for connecting, tracking and managing mobile >>> organizational assets. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-templin-aeroent/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-templin-aeroent-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/ >>> >>> _______________________________________________ I-D-Announce >>> mailing list I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> _______________________________________________ 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 Thu Sep 4 03:14:10 2014 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 704B21A0794 for ; Thu, 4 Sep 2014 03:14:09 -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 hlizMiNikwzu for ; Thu, 4 Sep 2014 03:14:07 -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 821A21A0680 for ; Thu, 4 Sep 2014 03:14:07 -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 s84AE5cP005680 for ; Thu, 4 Sep 2014 12:14:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E2CEB2026A4 for ; Thu, 4 Sep 2014 12:14: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 DB3DC202655 for ; Thu, 4 Sep 2014 12:14:19 +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 s84AE41e001244 for ; Thu, 4 Sep 2014 12:14:05 +0200 Message-ID: <54083B6C.5010701@gmail.com> Date: Thu, 04 Sep 2014 12:14:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: dmm@ietf.org References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> In-Reply-To: <540763A0.7080509@innovationslab.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/MbeZ3gn2CfsOWE3KBENJNaHkLco Subject: Re: [DMM] regarding the re-chartering.. 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, 04 Sep 2014 10:14:09 -0000 Le 03/09/2014 20:53, Brian Haberman a écrit : > Behcet, > > On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >> >> You don't seem to understand my points. > > That is quite possible. Your comment on the list was "I am against any > deployment work before we decide on a solution..." > > I read that as an objection to having the deployment models work item on > the agenda. Please do tell me what I am missing. > > Regards, > Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex > > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Thu Sep 4 03:31:40 2014 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 277681A6F27 for ; Thu, 4 Sep 2014 03:31:38 -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 lCvZdESoWQS0 for ; Thu, 4 Sep 2014 03:31:34 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED971A6F50 for ; Thu, 4 Sep 2014 03:31:34 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id el20so2912755lab.20 for ; Thu, 04 Sep 2014 03:31:32 -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=CBYXzCrWPWJsCFuiWIilD7NTnqr4WqbYo01QiMSNwgI=; b=HsreVLTgdU9hCvrAoH+1mt8PCHfsnwiAN6X8u1Oqc816VDaLqNsKoLFcFfrKyiOhxW HQOn11m9YIGbh1n6ywPxOhndZDO5f3uPsyaOnTzdsvhZXt6h1sMJjLqGnEJk/l9kOfBU Yqy+wMqQYCUCOpdiwqG3UpNBbsvGwZRledCtfAmd++59eOPPJ7K8zdTBpqxtITDnQM8J 3jpRUh4cA5F1wohqrn04MCW8Aaethu+gouBJdCVCwUp4J2rIpNWlRoOXfWGpoZERZ6qg VoIU3IoGamoi/Zr7jELdyN3icUZvkpvDx/MYMABW0LAhHqzEkYnWzs+hgpYRb3fOU34w 96JQ== X-Received: by 10.152.26.202 with SMTP id n10mr3838180lag.4.1409826692686; Thu, 04 Sep 2014 03:31:32 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id p3sm1956094lap.14.2014.09.04.03.31.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 03:31:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jouni In-Reply-To: <54083B6C.5010701@gmail.com> Date: Thu, 4 Sep 2014 13:31:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9E4649D6-84B1-40C3-B659-15C28B9F01C8@gmail.com> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/V_Jemo36-xO5Q8MUlZHpjBgXWDQ Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 04 Sep 2014 10:31:38 -0000 Alex, On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: > Le 03/09/2014 20:53, Brian Haberman a =E9crit : >> Behcet, >>=20 >> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>=20 >>> You don't seem to understand my points. >>=20 >> That is quite possible. Your comment on the list was "I am against = any >> deployment work before we decide on a solution..." >>=20 >> I read that as an objection to having the deployment models work item = on >> the agenda. Please do tell me what I am missing. >>=20 >> Regards, >> Brian >=20 > Hi, >=20 > I am following the discussion and me too I do not quite understand = what is the complain. >=20 > I am happy to learn that a if a WG is to be formed then it would be = around a solution rather than just requirements or architecture. We have already done the requirements part. One source of the fuzz has = been that we got no definitive "DMM architecture" so far.. but IETF is = not supposed to work on architectures per se but on protocols. > That said, I would like to express a worry along similar lines. >=20 > In DMM, precedents and the keen NETEXT, there seems to be a = hard-rooted disconnect between the product developped - (P)Mobile IP - = and the deployments. We know for a fact that 3GPP deployments = (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do = mention Mobile IP. To such a point that I wonder whether 3GPP has not = the same disconnect as here. There are LTE deployments using PMIP. Nation wide even. While not hugely = popular, there are still serious commercial deployments. > On another hand, we do have indications of where (P)Mobile IP is used = - the trials, the projects, the kernel code, and not least the slideware = attracting real customers. >=20 > The worry: develop DMM protocol while continuing the disconnect. DMM solutions are not predefined to be a (P)MIP extensions. - Jouni >=20 > Alex >=20 >=20 >=20 >=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Sep 4 03:32:08 2014 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 1E1B41A7012 for ; Thu, 4 Sep 2014 03:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 OT4DNcB-GAXw for ; Thu, 4 Sep 2014 03:32:05 -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 0463B1A6F27 for ; Thu, 4 Sep 2014 03:32:05 -0700 (PDT) Received: from [122.55.93.140] (helo=[172.22.35.120]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XPUKh-0005si-Ub; Thu, 04 Sep 2014 06:32:04 -0400 Message-ID: <54083F9A.8030507@computer.org> Date: Thu, 04 Sep 2014 03:31:54 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dmm@ietf.org References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> In-Reply-To: <54083B6C.5010701@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac71475dce8af98524d0ecc5fdae058dd0b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 122.55.93.140 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/3SRL1I_BGhpYHVVfV1w2IpcZQhA Subject: Re: [DMM] regarding the re-chartering.. 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, 04 Sep 2014 10:32:06 -0000 Hello folks, I have asked this same question many times, in different words... Namely, if we design a solution that fits the requirements, and bridges the gaps as analyzed in the gap analysis document, have we succeeded? Or, is there a requirement for the work to be adopted by 3GPP? What if we design for IEEE 802 Wireless, which is currently carrying the preponderance of the world's wireless data, and will almost assuredly continue to carry a greater proportion? Regards Charlie P. On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: > > Hi, > > .... > > In DMM, precedents and the keen NETEXT, there seems to be a > hard-rooted disconnect between the product developped - (P)Mobile IP - > and the deployments. We know for a fact that 3GPP deployments > (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do > mention Mobile IP. To such a point that I wonder whether 3GPP has not > the same disconnect as here. > > On another hand, we do have indications of where (P)Mobile IP is used > - the trials, the projects, the kernel code, and not least the > slideware attracting real customers. > > The worry: develop DMM protocol while continuing the disconnect. > > Alex > > > > >> >> >> >> >> _______________________________________________ >> 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 > -- Regards, Charlie P. From nobody Thu Sep 4 03:35:49 2014 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 5B9F51A1F70 for ; Thu, 4 Sep 2014 03:35:48 -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 IMSRe0nP7p2d for ; Thu, 4 Sep 2014 03:35:47 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A8E1A063F for ; Thu, 4 Sep 2014 03:35:46 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so3014054lbj.3 for ; Thu, 04 Sep 2014 03:35:44 -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=JyCfmPsun+Jk0NCVoluCzFiOcsU1EcQDQk99Jp4yz90=; b=f0C6oxxTUwJ5qx5vYnd+EoRwDA1fbPhpfQs4Rc5Ox93ytQx27PpBolwnbYXTJfVAqh lz1zvPdeIElZU/SvJbYdlx82JK/xXcIXkzDIiVRi4YqlMx7w407sUIclP01C6zv/2Y/m 7ca6ku42rdoPPK9POdTAzey7afsyQRelMO5JGkpWR1iBmqhhrkpoqIpg5xB1wERcsbbX EICFcHn4yJPiydOR7e+kE+ZE9DoQtGCvo0iByVaqF4ybRXKXgvB/+jDWXQziEmMigA8w uLc8eniB5CkGBmcF+voCflbhcamRJYur3VuOppj5MxE8UUJArMu6u4O6880+DXrwHa8P 5Ueg== X-Received: by 10.152.9.42 with SMTP id w10mr3710976laa.9.1409826944748; Thu, 04 Sep 2014 03:35:44 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:b1a7:79f:4e81:61cb? ([2001:1bc8:101:f101:b1a7:79f:4e81:61cb]) by mx.google.com with ESMTPSA id cm9sm380709lbb.39.2014.09.04.03.35.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Sep 2014 03:35:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <54083F9A.8030507@computer.org> Date: Thu, 4 Sep 2014 13:35:41 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <54083F9A.8030507@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/5I2eVoyrJ4rf5rAPrXhRP5kXyCg Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 04 Sep 2014 10:35:48 -0000 On Sep 4, 2014, at 1:31 PM, Charles E. Perkins wrote: > > Hello folks, > > I have asked this same question many times, in different words... > > Namely, if we design a solution that fits the requirements, and bridges > the gaps as analyzed in the gap analysis document, have we succeeded? > > Or, is there a requirement for the work to be adopted by 3GPP? It would be cool but not required. > What if we design for IEEE 802 Wireless, which is currently carrying the > preponderance of the world's wireless data, and will almost assuredly > continue to carry a greater proportion? ..and if the solution were adopted that would count as a major success. - JOuni > > Regards > Charlie P. > > > > On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: >> >> Hi, >> >> .... >> >> In DMM, precedents and the keen NETEXT, there seems to be a >> hard-rooted disconnect between the product developped - (P)Mobile IP - >> and the deployments. We know for a fact that 3GPP deployments >> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do >> mention Mobile IP. To such a point that I wonder whether 3GPP has not >> the same disconnect as here. >> >> On another hand, we do have indications of where (P)Mobile IP is used >> - the trials, the projects, the kernel code, and not least the >> slideware attracting real customers. >> >> The worry: develop DMM protocol while continuing the disconnect. >> >> Alex >> >> >> >> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Sep 4 04:08:07 2014 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 6E5981A6F8A for ; Thu, 4 Sep 2014 04:07:46 -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 bfIcWDLPW2XZ for ; Thu, 4 Sep 2014 04:07: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 C6F1A1A6F29 for ; Thu, 4 Sep 2014 04:07:34 -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 s84B7Wit023531; Thu, 4 Sep 2014 13:07:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AC10B2026E3; Thu, 4 Sep 2014 13:07:46 +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 A0971200F5A; Thu, 4 Sep 2014 13:07:46 +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 s84B7V40019531; Thu, 4 Sep 2014 13:07:31 +0200 Message-ID: <540847F3.2000202@gmail.com> Date: Thu, 04 Sep 2014 13:07:31 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Jouni References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <9E4649D6-84B1-40C3-B659-15C28B9F01C8@gmail.com> In-Reply-To: <9E4649D6-84B1-40C3-B659-15C28B9F01C8@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/OcCd4pUAX9AD0U--GcAuV-AZn28 Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 04 Sep 2014 11:07:46 -0000 Le 04/09/2014 12:31, Jouni a écrit : [...] >> In DMM, precedents and the keen NETEXT, there seems to be a >> hard-rooted disconnect between the product developped - (P)Mobile >> IP - and the deployments. We know for a fact that 3GPP deployments >> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs >> do mention Mobile IP. To such a point that I wonder whether 3GPP >> has not the same disconnect as here. > > There are LTE deployments using PMIP. Nation wide even. While not > hugely popular, there are still serious commercial deployments. Jouni, I would truly appreciate to stand corrected because it would be a good example to tell other customers about the technology. But I am afraid that what you are saying is part of: the trials, the projects, the kernel code and not least the slideware attracting real customers. The nation-wide LTE IPv6 trial I am familiar with does not use PMIPv6. Alex > >> On another hand, we do have indications of where (P)Mobile IP is >> used - the trials, the projects, the kernel code, and not least the >> slideware attracting real customers. >> >> The worry: develop DMM protocol while continuing the disconnect. > > DMM solutions are not predefined to be a (P)MIP extensions. > > - Jouni > >> >> Alex >> >> >> >> >>> >>> >>> >>> >>> _______________________________________________ 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 Sep 4 04:37:03 2014 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 84EE41A86EC for ; Thu, 4 Sep 2014 04:36: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 HscuOdm8iRSA for ; Thu, 4 Sep 2014 04:36:56 -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 CE48E1A8549 for ; Thu, 4 Sep 2014 04:36:55 -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 s84BaroB009633; Thu, 4 Sep 2014 13:36:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AB2CA20260D; Thu, 4 Sep 2014 13:37:07 +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 9F72C20104E; Thu, 4 Sep 2014 13:37:07 +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 s84BaqI2014177; Thu, 4 Sep 2014 13:36:52 +0200 Message-ID: <54084ED4.9080605@gmail.com> Date: Thu, 04 Sep 2014 13:36:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "Charles E. Perkins" , dmm@ietf.org References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <54083F9A.8030507@computer.org> In-Reply-To: <54083F9A.8030507@computer.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/SN2ofabpbLvNO5El6S8GQRl28gc Subject: Re: [DMM] regarding the re-chartering.. 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, 04 Sep 2014 11:36:59 -0000 Le 04/09/2014 12:31, Charles E. Perkins a écrit : > > Hello folks, > > I have asked this same question many times, in different words... > > Namely, if we design a solution that fits the requirements, and bridges > the gaps as analyzed in the gap analysis document, have we succeeded? My answer is no. As of now it may look as a homework - yes it solves the problem statement, yes it gets a high grade, yes it can. But what if no, deployments wouldn't need it. > Or, is there a requirement for the work to be adopted by 3GPP? Even then - even if there were a req from 3GPP (a row in an excel sheet, an "IPv6" mentioned in a 3GPP doc) - one would rather need a commitment of deployment from 3GPP. > What if we design for IEEE 802 Wireless, which is currently carrying the > preponderance of the world's wireless data, and will almost assuredly > continue to carry a greater proportion? Yes, and with the advent of cheap 802.11ac's huge bandwidth (1.2GB/s) one of the strong selling points of Mobile IP is the ability to offer session continuity when handover cellular/802-Wireless - the heterogeneity to some extent. Additionally, there are many possibilities of doing Mobile IP in a 802-Wireless only environment: large indoor hotspot areas, long 11p-covered roads, etc. These are exhibited in trials. But, sorry for saying again, one couldn't stop wondering whether these are to be embraced by deployments. Why is the 'tethering' application on operator's smartphones preferring to use a form of IPv6 prefix sharing rather than Mobile IP/NEMO? Why there is no session continuity app in these smartphones? Why one has to always click on some icon on their smartphones to (1) switch on/off 'mobile data', (2) turn on/off WiFi? Given these behaviours one may wonder how much the session continuity aspect is need by end users. There are some answers I heard about this... for example when one needs a session to be stable one by instinct will try to not move. Hardly can one walk and talk: two things at a time. Alex > > Regards > Charlie P. > > > > On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: >> >> Hi, >> >> .... >> >> In DMM, precedents and the keen NETEXT, there seems to be a >> hard-rooted disconnect between the product developped - (P)Mobile IP - >> and the deployments. We know for a fact that 3GPP deployments >> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do >> mention Mobile IP. To such a point that I wonder whether 3GPP has not >> the same disconnect as here. >> >> On another hand, we do have indications of where (P)Mobile IP is used >> - the trials, the projects, the kernel code, and not least the >> slideware attracting real customers. >> >> The worry: develop DMM protocol while continuing the disconnect. >> >> Alex >> >> >> >> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Sep 4 07:50:53 2014 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 B5AB51A88F1 for ; Thu, 4 Sep 2014 07:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, URG_BIZ=0.573] 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 cR9EFp-6CgeL for ; Thu, 4 Sep 2014 07:50:50 -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 2FA0A1A88F5 for ; Thu, 4 Sep 2014 07:50:49 -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 s84EonUR020381; Thu, 4 Sep 2014 07:50:49 -0700 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s84Eokaj020099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 4 Sep 2014 07:50:47 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-511.sw.nos.boeing.com ([169.254.11.127]) with mapi id 14.03.0181.006; Thu, 4 Sep 2014 07:50:45 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] "A Day in the Life of an Enterprise Mobile Device User" Thread-Index: AQHPx5ViOP6F+udYnkWXmXXAiU79KZvw/mkAgAAy/oD//9kpQA== Date: Thu, 4 Sep 2014 14:50:45 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D060C6@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D031C3@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D040CD@XCH-BLV-504.nw.nos.boeing.com> <4C4F8606-FBE7-4BAC-8F81-F1B63695357B@yegin.org> <540835D1.5080108@gmail.com> In-Reply-To: <540835D1.5080108@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: http://mailarchive.ietf.org/arch/msg/dmm/pbadq9a7rXj4FtK0YTh2ij-OSqE Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" 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, 04 Sep 2014 14:50:52 -0000 Hi Alex and Alper, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Thursday, September 04, 2014 2:50 AM > To: dmm@ietf.org > Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User= " >=20 > Le 04/09/2014 08:47, Alper Yegin a =E9crit : > > Hi Fred, > > > > Can this scenario not be realized by simply placing an HA in the > > enterprise network and using Mobile IP? >=20 > I guess yes and no. >=20 > YEs, in that it is a typical Mobile IP scenario with handovers > WiFi/4G/Ethernet. Handovers between diverse access technologies is one aspect of the proposal, yes. The ability to coordinate multiple access technologies simultaneously is also included as part of the architecture, but some future work needs to be done to put that into practice. =20 > No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not > working well together. Right - switching between VPN and non-VPN will be important for enterprise network mobile device users. > No, in that TIP (DHCPv6 Prefix Delegation?) is not clear how to work > with a EUD device ID? Is it Ethernet's, WiFi's or 4G's interface MAC > address? The mobile device applies the TIP to its downstream-attached interfaces and not to the access technology interfaces over which the prefix delegation was received. So the mobile device is really a mobile router. But, maybe you are asking where does the mobile device get its Device-Unique Identifier (DUID) so it can talk to the DHCPv6 server? The DUID need not be based on a MAC address, but could be some other unique ID assigned to the mobile. So, there is no confusion about which MAC address to choose. =20 > No, in that Mobile IP and prefixes are not known to lead to optimal > routes, whereas the scenario says "optimal routes". Route optimization is indeed a key aspect of the proposal, and in fact hard-coded into the name "AERO". Another key aspect is the in-built distributed mobility management (dmm) architecture. The enterprise can from day one deploy hundreds or even thousands of AERO servers, and the mobile devices simply associate with one or more that are close by. Beyond that, it doesn't matter which server the mobile associates with - it will get the same service as from any other server. =20 > No - but this is a stretch - the scenario does not mention the > neceessity of user typing secure information on a screen (authenticate > to web page on a public hotspot prior to ability to Mobile IP, or use > One-Time Password tokens for VPN connections); any "seamless" mobility > mechanism will need to automate this step; this is even more needed when > considering devices without user interfaces, such as Mobile Routers > using Mobile IP for a vehicle. Aspects of how the VPN link is established (enter password, insert active badge, etc.) are not discussed, but not really relevant to the way in which AERO can provide the mobile with a stable TIP that never changes. Just that the faster the VPN link can be established, the faster the mobile device can resume service as if it were still coming in through an on-campus enterprise network access link. There is still more to this, such as how AERO can provide an assured path MTU over the tunnel, etc. There should also be an expanded use case analysis. I have been coming at this from an enterprise network viewpoint, but as far as I know AERO could also be applied in the traditional use cases envisioned for MIPv6 and its derivatives. So, it would be good to have some of the experts from this community examine the proposal and provide a comparative analysis.=20 Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > Alper > > > > > > On Sep 3, 2014, at 7:37 PM, Templin, Fred L wrote: > > > >> Hi, > >> > >> The specific passage from the new draft that I wanted the wg to > >> see is the following (with references to AERO removed). Please > >> review and send questions or comments. > >> > >> Thanks - Fred fred.l.templin@boeing.com > >> > >> --- > >> > >> 3. A Day in the Life of an Enterprise Mobile Device User > >> > >> An enterprise network mobile device user ("Bill") begins his > >> workday by seating his primary end user device (EUD) (e.g., a > >> laptop computer, a tablet, a smart phone, etc.) in a docking > >> station at his office desk and turning the device on. The docking > >> station connects Bill's EUD to the enterprise wired LAN, and the > >> EUD receives a Topologically-Fixed Address (TFA) from the > >> infrastructure. Bill's EUD further discovers the DMM service > >> within the enterprise network and requests a Topology Independent > >> Prefix (TIP)delegation. Bill's EUD receives the same TIP > >> delegation it gets every time it connects to the enterprise > >> network, because the DMM service has an administratively set > >> mapping between the TIP and Bill's EUD device ID. > >> > >> Bill's EUD can then access topologically-fixed enterprise services > >> using its TFA directly, and can access DMM services by using an > >> address from its TIP as the source address for tunneling over the > >> enterprise network. As Bill's workday unfolds, his EUD uses the > >> DMM service to correspond with other EUDs in peer-to-peer > >> sessions, join lengthy virtual conferencing sessions, access > >> enterprise fileshares, etc. The DMM service ensures that optimal > >> routes are maintained so that tunneled communications flow over > >> direct paths and network infrastructure elements are not > >> unnecessarily over-burdened. > >> > >> While communications sessions such as the video conference are > >> still in progress, Bill leaves the office to attend a meeting in a > >> nearby conference room. He disconnects his EUD from the docking > >> station and in the process drops his connection to the wired LAN. > >> The EUD quickly enables a WiFi interface that searches for a > >> Service Set Identifier (SSID) that can provide wireless access > >> within the enterprise network. The EUD authenticates itself to > >> the network via the SSID using its pre-loaded certificates, and > >> uses a securing mechanism such as IEEE 802.1x to assure > >> Confidentiality, Integrity and Availability (CIA). The EUD > >> receives a new TFA from the network, then communicates its new > >> TIP-to-TFA association to the DMM service and any active peer > >> correspondents. Any ongoing communications sessions will continue > >> to see the same (stable) TIP. > >> > >> Bill then leaves the enterprise campus to attend an off-site > >> customer meeting with his EUD still powered on and actively > >> seeking to maintain network connectivity. As Bill departs from > >> the building, the WiFi signal fades until it can no longer support > >> communications, and the EUD quickly enables a 4G cellular wireless > >> interface that connects Bill's EUD to a cellular service provider. > >> The EUD then locates the Internet address of an enterprise network > >> security gateway and initiates a VPN session with the gateway > >> (which also acts participates in the DMM service). The DMM > >> service updates the routing system, and Bill can continue to use > >> the same TIP that was assigned to his EUD when he started his > >> workday even though the EUD is now communicating over a VPN > >> configured over the public Internet instead of over the secured > >> campus LAN. > >> > >> Bill subsequently arrives at the customer meeting at a public > >> restaurant with a WiFi hotspot. His EUD quickly powers up its WiFi > >> interface and powers down the 4G interface. The EUD uses DMM > >> signaling to communicate the new TFA to the security gateway and > >> the VPN survives the mobility event. Moreover, the EUD can > >> continue to use the same TIP it received at the beginning of the > >> workday, and ongoing communication sessions can continue until > >> Bill explicitly discontinues them. > >> > >> After the customer meeting, Bill leaves the restaurant and > >> subsequently passes through several additional transitions from > >> WiFi hotspots to 4G wireless. Again, the DMM service keeps the VPN > >> session alive, and the TIP assigned to the EUD remains in > >> continuous use in active communication sessions as well as to > >> allow Bill to receive notifications and process urgent requests. > >> When Bill returns to his office, the EUD discontinues use of the > >> VPN while keeping its TIP active after re-attaching to the campus > >> LAN. > >> > >> Bill ends his workday, powers down his EUD and returns home. Bill > >> powers on his EUD to check e-mails, and connects to the enterprise > >> network via a VPN configured over his home ISP service. The EUD > >> again receives the same TIP that it used within the enterprise > >> network domain, and Bill can access DMM services the same as if he > >> was in the office. Bill finally shuts down for the evening, and > >> begins his next workday in the same fashion. Again, the EUD > >> receives the same TIP as always regardless of the access network > >> point of connection over which the EUD enters the enterprise. > >> > >>> -----Original Message----- From: dmm > >>> [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: > >>> Tuesday, September 02, 2014 11:05 AM To: dmm@ietf.org Subject: > >>> [DMM] FW: I-D Action: draft-templin-aeroent-00.txt > >>> > >>> Hello, > >>> > >>> During the call today, there was some interest expressed in > >>> learning more about the enterprise network mobility use case. I > >>> have submitted a new brief document called "AERO Enterprise > >>> Network Profile" (below) that provides a discussion of > >>> distributed mobility management needs for enterprise networks. > >>> Although the document specifically cites AERO, the use case > >>> applies to any solution alternative that could meet the > >>> requirements. Also, I am not asking this document be considered > >>> as a dmm wg item at this time, but rather offering it for > >>> informational purposes. Please let me know if there are any > >>> questions or comments. > >>> > >>> Thanks - Fred fred.l.templin@boeing.com > >>> > >>> -----Original Message----- From: I-D-Announce > >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > >>> internet-drafts@ietf.org Sent: Tuesday, September 02, 2014 10:51 > >>> AM To: i-d-announce@ietf.org Subject: I-D Action: > >>> draft-templin-aeroent-00.txt > >>> > >>> > >>> A New Internet-Draft is available from the on-line > >>> Internet-Drafts directories. > >>> > >>> > >>> Title : AERO Enterprise Network Profile Author : Fred > >>> L. Templin Filename : draft-templin-aeroent-00.txt Pages > >>> : 12 Date : 2014-09-02 > >>> > >>> Abstract: Enterprise networks provide a secured data > >>> communications infrastructure built for the purpose of > >>> information sharing and increased productivity for end users > >>> within the organization. Enterprise networks are often organized > >>> as private Internets unto themselves that connect to the global > >>> Internet either not at all or via firewalls, proxies, and/or > >>> other network securing devices. This document discusses an AERO > >>> enterprise network profile that outlines new and more flexible > >>> methods for connecting, tracking and managing mobile > >>> organizational assets. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-templin-aeroent/ > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-templin-aeroent-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/ > >>> > >>> _______________________________________________ I-D-Announce > >>> mailing list I-D-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>> Internet-Draft directories: http://www.ietf.org/shadow.html or > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>> > >>> _______________________________________________ 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 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Sep 4 10:00:20 2014 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 D322E1A001B for ; Thu, 4 Sep 2014 10:00:18 -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 DSECjh7vNeum for ; Thu, 4 Sep 2014 10:00:17 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B78C1A0009 for ; Thu, 4 Sep 2014 10:00:17 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id p9so1413404lbv.0 for ; Thu, 04 Sep 2014 10:00:14 -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=xYd59+pqRmYrjBEz1MF9VZ+QrXh13E9daFu7PkhDjzk=; b=RbKJCM9zXGpGU1L9Dse02bThWZBhhI2ZUxo9lMXCgVJknHO3ucszjGjAGYHJOwNWL1 EDfmklnSmcIeGKj+9OBDhZhmL6U+m6fpee+tAQihxSGzp9jeijsNYIiuU4jMlLcyCdw7 sTuXNxXVhmxoMQ7JLJEHKiaY8f1o8ofM+zxZTuZ8gNti2XaaiBati3ueOfy5l7uPFq1l 3c1ZrMXH16sZbW1wuaIxuSH+KdSXkRf6wpjkF/bHxhvhC4xc1P+tsmqPxlE027ZYSU9y 8Nht2qDXkLMmYxTxZpajJtaiXc2C1E2stFxz1rmxg/tstTbVhPTYLGysU7H7/0J+6fw5 7T9Q== MIME-Version: 1.0 X-Received: by 10.112.56.206 with SMTP id c14mr5662382lbq.27.1409850014672; Thu, 04 Sep 2014 10:00:14 -0700 (PDT) Received: by 10.114.244.73 with HTTP; Thu, 4 Sep 2014 10:00:14 -0700 (PDT) In-Reply-To: <54083F9A.8030507@computer.org> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <54083F9A.8030507@computer.org> Date: Thu, 4 Sep 2014 12:00:14 -0500 Message-ID: From: Behcet Sarikaya To: "Charles E. Perkins" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/zwhTMFGTs04Ck8otkLJ4j7oqHC8 Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 04 Sep 2014 17:00:19 -0000 Hi Charlie, Check this out: http://tools.ietf.org/id/draft-sarikaya-dmm-for-wifi-00.txt Regards, Behcet On Thu, Sep 4, 2014 at 5:31 AM, Charles E. Perkins wrote: > > Hello folks, > > I have asked this same question many times, in different words... > > Namely, if we design a solution that fits the requirements, and bridges > the gaps as analyzed in the gap analysis document, have we succeeded? > > Or, is there a requirement for the work to be adopted by 3GPP? > > What if we design for IEEE 802 Wireless, which is currently carrying the > preponderance of the world's wireless data, and will almost assuredly > continue to carry a greater proportion? > > Regards > Charlie P. > > > > On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: >> >> >> Hi, >> >> .... >> >> >> In DMM, precedents and the keen NETEXT, there seems to be a >> hard-rooted disconnect between the product developped - (P)Mobile IP - >> and the deployments. We know for a fact that 3GPP deployments >> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do >> mention Mobile IP. To such a point that I wonder whether 3GPP has not >> the same disconnect as here. >> >> On another hand, we do have indications of where (P)Mobile IP is used >> - the trials, the projects, the kernel code, and not least the >> slideware attracting real customers. >> >> The worry: develop DMM protocol while continuing the disconnect. >> >> Alex >> >> >> >> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > -- > Regards, > Charlie P. > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Sep 4 10:10:20 2014 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 29B9C1A0047 for ; Thu, 4 Sep 2014 10:10:19 -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 GGPt4491Ub6q for ; Thu, 4 Sep 2014 10:10:18 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D9D1A0027 for ; Thu, 4 Sep 2014 10:10:15 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so2545467lbi.19 for ; Thu, 04 Sep 2014 10:10:14 -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=EN9DjN+ZFlt6VCJNnN0KW8AGH2EQoZVZBNvXa88wLZk=; b=HK+HC6Y5Jy1fo7be8STDEI+xzftWSR2cRbGLLVJlS7MJCfxrMOfWzLz050l/MZ8seN GL+N2anDNTY0vMaY02s4h343TIrI1wbJOn2yAbiNvbBsAfsZnSjTyBmtgYmBf+VVnU6o E4O5yuYBWBZK48jad8c9vjUrzN6EDfdNar4LgrL6TqEk4H54GiL7ssCGHzhbvUrviQpz NKrRXGNNqMCpZ9lcTzEXKjNofONdV6OeI2W2hT7YSDrNsce43vGPpmaxAYfThTUoggLt jlr99kM2W3bTM+pax1FLV38IT0TSWvi7Zo3ppuC3kabEmMO89izM7DDWDWBtItvO0h7o qm6Q== MIME-Version: 1.0 X-Received: by 10.153.4.39 with SMTP id cb7mr5941086lad.19.1409850614404; Thu, 04 Sep 2014 10:10:14 -0700 (PDT) Received: by 10.114.244.73 with HTTP; Thu, 4 Sep 2014 10:10:14 -0700 (PDT) In-Reply-To: <54084ED4.9080605@gmail.com> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <54083F9A.8030507@computer.org> <54084ED4.9080605@gmail.com> Date: Thu, 4 Sep 2014 12:10:14 -0500 Message-ID: From: Behcet Sarikaya To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/d_7Vx86v1G4CRdKmJ0U-cFJM6sQ Cc: "dmm@ietf.org" Subject: Re: [DMM] regarding the re-chartering.. 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, 04 Sep 2014 17:10:19 -0000 Hi Alex, On Thu, Sep 4, 2014 at 6:36 AM, Alexandru Petrescu wrote: > Le 04/09/2014 12:31, Charles E. Perkins a =C3=A9crit : > >> >> Hello folks, >> >> I have asked this same question many times, in different words... >> >> Namely, if we design a solution that fits the requirements, and bridges >> the gaps as analyzed in the gap analysis document, have we succeeded? > > > My answer is no. As of now it may look as a homework - yes it solves the > problem statement, yes it gets a high grade, yes it can. But what if no, > deployments wouldn't need it. > > >> Or, is there a requirement for the work to be adopted by 3GPP? > > > Even then - even if there were a req from 3GPP (a row in an excel sheet,= an > "IPv6" mentioned in a 3GPP doc) - one would rather need a commitment of > deployment from 3GPP. > > >> What if we design for IEEE 802 Wireless, which is currently carrying the >> preponderance of the world's wireless data, and will almost assuredly >> continue to carry a greater proportion? > > > Yes, and with the advent of cheap 802.11ac's huge bandwidth (1.2GB/s) one= of > the strong selling points of Mobile IP is the ability to offer session > continuity when handover cellular/802-Wireless - the heterogeneity to som= e > extent. > > Additionally, there are many possibilities of doing Mobile IP in a > 802-Wireless only environment: large indoor hotspot areas, long 11p-cover= ed > roads, etc. These are exhibited in trials. > > But, sorry for saying again, one couldn't stop wondering whether these ar= e > to be embraced by deployments. > > Why is the 'tethering' application on operator's smartphones preferring t= o > use a form of IPv6 prefix sharing rather than Mobile IP/NEMO? > > Why there is no session continuity app in these smartphones? > > Why one has to always click on some icon on their smartphones to (1) swit= ch > on/off 'mobile data', (2) turn on/off WiFi? > Good questions. I think that 3GPP SA1 work reported by Alper is addressing this issue in terms of classifying the flows. They identify certain class of flows like interactive calls where you would definitely need session continuity. 3GPP thinks that in most other cases like Web browsing you don't. So in dmm we can say that the protocol dmm is going to develop could be a candidate solution for those flows that you need session continuity. I don't think IETF can do more. Regards, Behcet > Given these behaviours one may wonder how much the session continuity asp= ect > is need by end users. > > There are some answers I heard about this... for example when one needs a > session to be stable one by instinct will try to not move. Hardly can on= e > walk and talk: two things at a time. > > Alex > > >> >> Regards >> Charlie P. >> >> >> >> On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: >>> >>> >>> Hi, >>> >>> .... >>> >>> In DMM, precedents and the keen NETEXT, there seems to be a >>> hard-rooted disconnect between the product developped - (P)Mobile IP - >>> and the deployments. We know for a fact that 3GPP deployments >>> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do >>> mention Mobile IP. To such a point that I wonder whether 3GPP has not >>> the same disconnect as here. >>> >>> On another hand, we do have indications of where (P)Mobile IP is used >>> - the trials, the projects, the kernel code, and not least the >>> slideware attracting real customers. >>> >>> The worry: develop DMM protocol while continuing the disconnect. >>> >>> Alex >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Thu Sep 4 10:42:53 2014 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 D59801A0004 for ; Thu, 4 Sep 2014 10:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 7WFvLlJgJnpE for ; Thu, 4 Sep 2014 10:42:49 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EC01A00C5 for ; Thu, 4 Sep 2014 10:42:49 -0700 (PDT) X-ASG-Debug-ID: 1409852566-06daaa6c1124b40001-HzFf3l Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id AWz8qQO5l8x7acVc for ; Thu, 04 Sep 2014 13:42:47 -0400 (EDT) X-Barracuda-Envelope-From: JuanCarlos.Zuniga@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Sep 2014 13:42:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 X-ASG-Orig-Subj: RE: [DMM] regarding the re-chartering.. Date: Thu, 4 Sep 2014 13:42:45 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: Ac/ILADZ56Wte+dYTtuTU381rnLyCAAOuIZA References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <54083F9A.8030507@computer.org> From: "Zuniga, Juan Carlos" To: "Jouni" , "Charles E. Perkins" X-OriginalArrivalTime: 04 Sep 2014 17:42:46.0515 (UTC) FILETIME=[A35F4430:01CFC867] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1409852566 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.9173 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/4rj5tDbejZ5EC8S-ams6d-3DoPQ Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 04 Sep 2014 17:42:51 -0000 > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni > Sent: Thursday, September 04, 2014 6:36 AM > To: Charles E. Perkins > Cc: dmm@ietf.org > Subject: Re: [DMM] regarding the re-chartering.. >=20 >=20 > On Sep 4, 2014, at 1:31 PM, Charles E. Perkins wrote: >=20 > > > > Hello folks, > > > > I have asked this same question many times, in different words... > > > > Namely, if we design a solution that fits the requirements, and > > bridges the gaps as analyzed in the gap analysis document, have we > succeeded? > > > > Or, is there a requirement for the work to be adopted by 3GPP? >=20 > It would be cool but not required. >=20 > > What if we design for IEEE 802 Wireless, which is currently carrying > > the preponderance of the world's wireless data, and will almost > > assuredly continue to carry a greater proportion? >=20 > ..and if the solution were adopted that would count as a major success. [JCZ] While I don't have a crystal ball to predict success of a technology (to respond to other people's concerns), I would strongly support addressing IEEE 802 Wireless technologies. Chances are that if 3GPP likes the solution, they will add some bits, change the name, and will adopt it as a non-IETF solution. Jc >=20 > - JOuni >=20 >=20 > > > > Regards > > Charlie P. > > > > > > > > On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: > >> > >> Hi, > >> > >> .... > >> > >> In DMM, precedents and the keen NETEXT, there seems to be a > >> hard-rooted disconnect between the product developped - (P)Mobile IP > >> - and the deployments. We know for a fact that 3GPP deployments > >> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do > >> mention Mobile IP. To such a point that I wonder whether 3GPP has not > >> the same disconnect as here. > >> > >> On another hand, we do have indications of where (P)Mobile IP is used > >> - the trials, the projects, the kernel code, and not least the > >> slideware attracting real customers. > >> > >> The worry: develop DMM protocol while continuing the disconnect. > >> > >> Alex > >> > >> > >> > >> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > -- > > Regards, > > Charlie P. > > > > _______________________________________________ > > 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 Sep 4 23:37:33 2014 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 71D3F1A045C for ; Thu, 4 Sep 2014 23:37:30 -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 YriptKZPqtf3 for ; Thu, 4 Sep 2014 23:37:29 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C5E1A045B for ; Thu, 4 Sep 2014 23:37:28 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id v10so2933665pde.31 for ; Thu, 04 Sep 2014 23:37:28 -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=sGOzORdKhuLg16c6S5ZiS+/ygBlVp10EdcQjMraR22w=; b=XMpI2at3cXwwcT4ywYQSETVb+R4amFd+gQrOatSLXtI7smPHgd1QvoWKRZH/kD9z4+ rTVLxt70/vI2gJtXF1O9BUGj3+ySzuk02PL22K6GBMi5tko/HjOy9IDg/qbzZGAa+5CS AEA0udT9tJgDQu2glUdymii7nu9F+vxJNZ3GMATAlx1e6IuVjyzgrGAk5XwJ6buIuObA 06Mgsm5Yb2DJmslLerkwIxR0Q5vso3uN/7EsgrTlElFho5fdqZcQ5O/vcTPwm1DQVJL+ 5qys+7bgQlkc+Xd9hV7DMp3+qgv47SwJE1La1pcYHPuW6oA3/MLDnTthzA89xSkkqQl7 /+bA== X-Received: by 10.67.24.73 with SMTP id ig9mr18069003pad.67.1409899048375; Thu, 04 Sep 2014 23:37:28 -0700 (PDT) Received: from [183.244.156.97] ([183.244.156.97]) by mx.google.com with ESMTPSA id ro7sm969103pab.25.2014.09.04.23.37.24 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 23:37:27 -0700 (PDT) Date: Fri, 5 Sep 2014 14:40:24 +0800 From: Max To: Jouni Korhonen Message-ID: In-Reply-To: <54063B90.9020909@gmail.com> References: <54063B90.9020909@gmail.com> X-Mailer: sparrow 1.6.3 (build 1173) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="54095ad8_74b0dc51_7cf" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/aj4Jd7tQJQEeu4wdG0_Yi-exJ30 Cc: "=?utf-8?Q?dmm=40ietf.org?=" Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?= interim call #1 and rechater text 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, 05 Sep 2014 06:37:30 -0000 --54095ad8_74b0dc51_7cf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46olks, =20 The meeting minutes is uploaded: http://www.ietf.org/proceedings/interim/= 2014/09/02/dmm/minutes/minutes-interim-2014-dmm-1 =20 -- =20 Dapeng Liu =E5=9C=A8 2014=E5=B9=B49=E6=9C=883=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C5:50=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A > =46olks, > =20 > Check the charter text we came up with during the interim call =231. Th= e =20 > diffs are here: > https://github.com/jounikor/dmm-re-charter/commit/4475c1c7aeac024171f6b= 669d330cfae98bdc283 > =20 > And the =22clean=22 text is here: > https://github.com/jounikor/dmm-re-charter/blob/master/recharter=5Fdraf= t.txt > =20 > Have a look at the text. If you agree with the content we'll start =20 > moving this forward. > =20 > The minutes and stuff from the interim call will follow shortly. > =20 > =20 > - Jouni & Dapeng > =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 > =20 --54095ad8_74b0dc51_7cf Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=46olks,


-- 
Dapeng Liu

=20

=E5=9C=A8 2014=E5=B9=B4= 9=E6=9C=883=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF=BC=8C5:50=EF=BC=8CJou= ni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

=46olks,

Check the charter text we came up with during the interim call =231. Th= e
diffs are here:

And the =22clean=22 text i= s here:

Ha= ve a look at the text. If you agree with the content we'll start
moving this forward.

The minutes and stuff fr= om the interim call will follow shortly.


- Jouni & Dapeng

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

--54095ad8_74b0dc51_7cf-- From nobody Fri Sep 5 01:44:40 2014 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 22F7E1A066B for ; Fri, 5 Sep 2014 01:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 c1k1rEtt1I9w for ; Fri, 5 Sep 2014 01:44:37 -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 EFCB81A064F for ; Fri, 5 Sep 2014 01:44:36 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0MQ4iz-1XUThV20sF-005I2h; Fri, 05 Sep 2014 10:44:34 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <54083F9A.8030507@computer.org> Date: Fri, 5 Sep 2014 11:44:28 +0300 Content-Transfer-Encoding: 7bit Message-Id: <585ACD51-4510-47DC-AEB6-9D63C0C2E725@yegin.org> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <54083F9A.8030507@computer.org> To: Charles E. Perkins X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:8O5HWTViflQUmK73hPHPsODHUvh/zVwlOc3oWFw3UUP U+zQDzFtalTiGWpvAatdPsx7E0HWCE/0kHPvolPd1qES7pBIYG mbw8uwkPp1gIZ0gCWDMdxAGsbK67ADNz2RxaiIVJp/d5lnGYN/ GbxFsmV5mi3yhm6IRAV5ygjmvO1iQ74J05GtD1tXQsuSx/3XsF +T0D+ESmCpycfkeCsrOkfbF2cj0hL16lSB8eK98hDrAKUKkA32 oFSfuVb3vcLgfiJKb2+nv9CdAkJHUdUv4YyfbFYqhd9qgrUf5m SCP1Oxjqqln5Z/BfYks/Smy+r+2HD9jadW9gTktrJ69W7acwdG AhYrg3p6pTnCKJXKSH5UJJXmQnaeyodC8o9GzctD9QCZ75kxoV xL/TmungC/m9A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/-GR06cp-suQf205F6d9_oe-_nzc Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 05 Sep 2014 08:44:39 -0000 Hi Charlie, Success is when we see the protocols we design are deployed and used. Whether it's over 3GPP, WiFi, or something else. The more the merrier. I don't think anyone is preventing use of DMM over WiFi. Alper On Sep 4, 2014, at 1:31 PM, Charles E. Perkins wrote: > > Hello folks, > > I have asked this same question many times, in different words... > > Namely, if we design a solution that fits the requirements, and bridges > the gaps as analyzed in the gap analysis document, have we succeeded? > > Or, is there a requirement for the work to be adopted by 3GPP? > > What if we design for IEEE 802 Wireless, which is currently carrying the > preponderance of the world's wireless data, and will almost assuredly > continue to carry a greater proportion? > > Regards > Charlie P. > > > > On 9/4/2014 3:14 AM, Alexandru Petrescu wrote: >> >> Hi, >> >> .... >> >> In DMM, precedents and the keen NETEXT, there seems to be a >> hard-rooted disconnect between the product developped - (P)Mobile IP - >> and the deployments. We know for a fact that 3GPP deployments >> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do >> mention Mobile IP. To such a point that I wonder whether 3GPP has not >> the same disconnect as here. >> >> On another hand, we do have indications of where (P)Mobile IP is used >> - the trials, the projects, the kernel code, and not least the >> slideware attracting real customers. >> >> The worry: develop DMM protocol while continuing the disconnect. >> >> Alex >> >> >> >> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > -- > Regards, > Charlie P. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri Sep 5 01:49:03 2014 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 9A26F1A04A4 for ; Fri, 5 Sep 2014 01:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 ViBPHAfcyWnT for ; Fri, 5 Sep 2014 01:49:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 9B4121A007F for ; Fri, 5 Sep 2014 01:49:00 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus003) with ESMTP (Nemesis) id 0Mbzhw-1Xj0k52HTC-00JI4j; Fri, 05 Sep 2014 10:48:59 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <54083B6C.5010701@gmail.com> Date: Fri, 5 Sep 2014 11:48:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:hUZUiXgRVde6IpS0jImBZVJDAYRNfXTZoaX5gDRQlqb 0/3dXaX0qukNJctpmHykh0hHULe2cLwgaTHsEkP4UjGlVJ8ejD XDiQsgp877aEuGDJhppz3ymg99OUAUQ5WyyA4jPX+BOICD8UYQ gXVY+xFUNYXHLWIvmt5AvmRrA+e87C7fvpwTwGJ8CI2DawunJ7 QRnRy+UrbnOiZRO1AlSkTGLzgm6UuXfdzaxJazDH/2OiD+dPfQ U3Z/Gy1n2v6Z/iHlgdEAIh5m4lxys2Q+R8e46HWjkzW/NGPpCp PpiQ5slqQpkBXBphyoq2VnBurwHm2nUE8L6QpsT072KKOakKS2 bdX21HN1VM7zc2bsQV+Tk0u90ur5jdZFnA0Sll0kAuLCbsvmvt uCqP3fEVcWRXw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/6X6dphxmjcpiQHW7PT-PbDVRpGQ Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 05 Sep 2014 08:49:02 -0000 Alex, DMM is not meant to be only about a bunch of MIP-based solutions. There are various components in DMM solution space that'd also work with = GTP-based architectures. For example, identifying the mobility needs of flows. Or, conveying the mobility characteristic of a prefix to the UE. Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: > Le 03/09/2014 20:53, Brian Haberman a =E9crit : >> Behcet, >>=20 >> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>=20 >>> You don't seem to understand my points. >>=20 >> That is quite possible. Your comment on the list was "I am against = any >> deployment work before we decide on a solution..." >>=20 >> I read that as an objection to having the deployment models work item = on >> the agenda. Please do tell me what I am missing. >>=20 >> Regards, >> Brian >=20 > Hi, >=20 > I am following the discussion and me too I do not quite understand = what is the complain. >=20 > I am happy to learn that a if a WG is to be formed then it would be = around a solution rather than just requirements or architecture. >=20 > That said, I would like to express a worry along similar lines. >=20 > In DMM, precedents and the keen NETEXT, there seems to be a = hard-rooted disconnect between the product developped - (P)Mobile IP - = and the deployments. We know for a fact that 3GPP deployments = (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do = mention Mobile IP. To such a point that I wonder whether 3GPP has not = the same disconnect as here. >=20 > On another hand, we do have indications of where (P)Mobile IP is used = - the trials, the projects, the kernel code, and not least the slideware = attracting real customers. >=20 > The worry: develop DMM protocol while continuing the disconnect. >=20 > Alex >=20 >=20 >=20 >=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri Sep 5 02:00:09 2014 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 6B8481A0487 for ; Fri, 5 Sep 2014 02:00:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 MyIETdVjRuVQ for ; Fri, 5 Sep 2014 02:00:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 876E31A0478 for ; Fri, 5 Sep 2014 02:00:05 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus003) with ESMTP (Nemesis) id 0M3kt5-1YGPtQ1WU5-00rFHD; Fri, 05 Sep 2014 11:00:04 +0200 From: Alper Yegin Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_BFE20D2E-5BE9-4D71-ABA4-58A248EB19AD" Date: Fri, 5 Sep 2014 11:59:58 +0300 In-Reply-To: <540763A0.7080509@innovationslab.net> To: dmm@ietf.org References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> Message-Id: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:RfLHHt4T8REUyrN+4g0OIe4/byAiWK63SSJbyY8AqFG ilvUUpES0KcXeDBBAKFdsNRFZ17g5dwf4MowCjzIA10C9z0kTC kDhbIXrHxTdpW778QUvWTNRqalzmapad9xrk5KM3hdLbwS3NlU tgj7ua8eg2cOM/QBgHUGy2+wcAIeg39qSLTpUMC0pi7NIDkZXC p84HtbDqj6YBsc9iEoTDZAsx9TSZEDFj/ReuljAcdVnxkoC1A6 KksZ5XYzd57rg7ASMBaRiIGNkpPtQIuNmqpbpEV8m4ZGnxe5eT Rqo1TMOfh+Adwll86JuHZiR2fcP9GOQ9zdYN7OFU9ctyepXuRF UI/Pw6OeFLM55M76iyptHR7XbT1qoMsIlGGNWMtZA4Fc3v345s B/9L7vWOX3ZsA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/9yz0GmsaytK6YCgCaKUEP_-nMSA Subject: Re: [DMM] regarding the re-chartering.. 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, 05 Sep 2014 09:00:07 -0000 --Apple-Mail=_BFE20D2E-5BE9-4D71-ABA4-58A248EB19AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 =46rom meeting minutes: (Jouni) "I suggest that we left the bullet as a work item and we do not = have explicit milestone for it. we can add this milestone when we actually see that there is = something meaningful forming for that document. " The decision at the meeting was to leave the work item in the charter, = but not to associate a specific milestone with it until the WG sees what = goes into that document. It was not fully clear what would be in that = document, and it's a concern that the rest of the WG documents would be = gated by such a document.=20 Jouni's above suggestion is a good way forward IMO. Alper On Sep 3, 2014, at 9:53 PM, Brian Haberman wrote: > Behcet, >=20 > On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>=20 >> You don't seem to understand my points. >=20 > That is quite possible. Your comment on the list was "I am against = any > deployment work before we decide on a solution..." >=20 > I read that as an objection to having the deployment models work item = on > the agenda. Please do tell me what I am missing. >=20 > Regards, > Brian >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_BFE20D2E-5BE9-4D71-ABA4-58A248EB19AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

(Jouni) "I suggest that we = left the bullet as a work item and we do not have explicit = milestone
for it. we can add this milestone when we = actually see that there is something meaningful


Jouni's above suggestion is a = good way forward IMO.

Alper



On Sep 3, 2014, at = 9:53 PM, Brian Haberman wrote:

Behcet,

On 9/3/14 2:33 PM, Behcet Sarikaya = wrote:

You don't seem to understand my = points.

That is quite possible.  Your comment = on the list was "I am against any
deployment work before we decide on = a solution..."

I read that as an objection to having the = deployment models work item on
the agenda.  Please do tell me = what I am = missing.

Regards,
Brian


_____________________________= __________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mail= man/listinfo/dmm

= --Apple-Mail=_BFE20D2E-5BE9-4D71-ABA4-58A248EB19AD-- From nobody Fri Sep 5 03:11:27 2014 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 226A71A0647 for ; Fri, 5 Sep 2014 03:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 HSV5kabwGq2g for ; Fri, 5 Sep 2014 03:11:21 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06141A063E for ; Fri, 5 Sep 2014 03:11:20 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so3637060lbi.19 for ; Fri, 05 Sep 2014 03:11:16 -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=hC29L7tK4Pumigzw1Sz7RGvMKuVt93Uyle/hLdKJmXo=; b=gPDlEjPluM+wlr4QQHR5baESu7AIeshhFCJYkG2KFKgroyG4vK1ti8eMVB85bZqxdt MI17eMlSWVJxHHcDAF+6PPWCpeJKA/M/eBZ6C45MxDWfmsqqBR5mPZfGx0Lzbqd01c7s 9mrSq497qs2ZUrI01UGELkA8/PdM1Il1w2xp3aQTrwcoq1bGXjkbcPUwW2liQ0uw6gQp A8l8kswb0DeLJFnPH4ErNozy9xmpz2aLb/UVJ0CMI7CvE1FiM7yFAvLzcFcW+xT21Ezv rZ+WSCKHiP2HVflHD1nzS4uTldvPvlDsjkYXPVJeR0yEt/NounlDl+2a+2Xi0asxMilV q/oQ== X-Received: by 10.153.5.38 with SMTP id cj6mr10667098lad.34.1409911876353; Fri, 05 Sep 2014 03:11:16 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:c96d:426c:6e2c:8bff? ([2001:1bc8:101:f101:c96d:426c:6e2c:8bff]) by mx.google.com with ESMTPSA id a2sm576456lbg.19.2014.09.05.03.11.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Sep 2014 03:11:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=utf-8 From: Jouni In-Reply-To: Date: Fri, 5 Sep 2014 13:11:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54063B90.9020909@gmail.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/MTJ_favyq1JtZr06_Sj743H_tEA Cc: dmm-chairs@tools.ietf.org Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaICBpbnRlcmltIGNhbGwgIzEgYW5kIHJlY2hh?= =?utf-8?q?ter_text?= 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, 05 Sep 2014 10:11:22 -0000 Folks, This mail start a one week period to comment and propose changes to the = re-charter text. The call ends 12th Sep. All the material from the Interim call#1 including the latest re-charter = text is available at: http://www.ietf.org/proceedings/interim/2014/09/02/dmm/proceedings.html If you have comments / corrections to propose, include the concrete = change proposal with a justification, for example in a form: OLD: Feb 2015 - Submit 'Forwarding path and signaling management' as a working group document. To be Proposed Standard. NEW: May 2019 - Submit 'Forwarding path and signaling management' as a working group document. To be Proposed Standard. WHY: I need to concentrate bettering my golf handicap for the next three years, thus I have no time to contribute until early 2019. And of course the rest of the WG needs to agree (even for the simplest change I hope people acking it with 'ok' or alike oneliner). - Jouni & Dapeng On Sep 5, 2014, at 9:40 AM, Max wrote: > Folks, >=20 > The meeting minutes is uploaded: = http://www.ietf.org/proceedings/interim/2014/09/02/dmm/minutes/minutes-int= erim-2014-dmm-1 >=20 > --=20 > Dapeng Liu >=20 > =E5=9C=A8 2014=E5=B9=B49=E6=9C=883=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89=EF= =BC=8C5:50=EF=BC=8CJouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A >=20 >> Folks, >>=20 >> Check the charter text we came up with during the interim call #1. = The >> diffs are here: >> = https://github.com/jounikor/dmm-re-charter/commit/4475c1c7aeac024171f6b669= d330cfae98bdc283 >>=20 >> And the "clean" text is here: >> = https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt= >>=20 >> Have a look at the text. If you agree with the content we'll start >> moving this forward. >>=20 >> The minutes and stuff from the interim call will follow shortly. >>=20 >>=20 >> - Jouni & Dapeng >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Fri Sep 5 05:32:29 2014 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 406291A06E4 for ; Fri, 5 Sep 2014 05:32:28 -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 OanGYXDssClN for ; Fri, 5 Sep 2014 05:32:26 -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 D82DA1A06E5 for ; Fri, 5 Sep 2014 05:32:25 -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 s85CWNS5024890; Fri, 5 Sep 2014 14:32:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07C09200E61; Fri, 5 Sep 2014 14:32:40 +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 F08F7200DA6; Fri, 5 Sep 2014 14:32:39 +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 s85CW4MR003628; Fri, 5 Sep 2014 14:32:23 +0200 Message-ID: <5409AD44.40308@gmail.com> Date: Fri, 05 Sep 2014 14:32:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Alper Yegin References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_kFBvbCaBAvnIj88rJgoYP_L-RY Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 05 Sep 2014 12:32:28 -0000 Le 05/09/2014 10:48, Alper Yegin a écrit : > Alex, > > DMM is not meant to be only about a bunch of MIP-based solutions. > There are various components in DMM solution space that'd also work with GTP-based architectures. > For example, identifying the mobility needs of flows. > Or, conveying the mobility characteristic of a prefix to the UE. Alper - thanks for the reply. Identifying the mobility needs of flows assumes that IP flows _can_ be characterized, and then distinguished as mobile - or non-mobile. I think this is very hard to do, given the difficulty to write good firewall rules, and the difficulty of analyzing traffic dumps. For example, Netalyzr was written to tell whether or not one's computer is connected to the Internet. That report page has so many lines that it is hard to tell which part of it really means 'connected to the Internet'. The same problem may arise when trying to identify a particular 'flow'. Alex > > Alper > > > > > On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: > >> Le 03/09/2014 20:53, Brian Haberman a écrit : >>> Behcet, >>> >>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>> >>>> You don't seem to understand my points. >>> >>> That is quite possible. Your comment on the list was "I am against any >>> deployment work before we decide on a solution..." >>> >>> I read that as an objection to having the deployment models work item on >>> the agenda. Please do tell me what I am missing. >>> >>> Regards, >>> Brian >> >> Hi, >> >> I am following the discussion and me too I do not quite understand what is the complain. >> >> I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. >> >> That said, I would like to express a worry along similar lines. >> >> In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. >> >> On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. >> >> The worry: develop DMM protocol while continuing the disconnect. >> >> Alex >> >> >> >> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Sep 5 05:46:06 2014 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 30E251A06A4 for ; Fri, 5 Sep 2014 05:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 484tH3KPA2aK for ; Fri, 5 Sep 2014 05:46:02 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 966CF1A0696 for ; Fri, 5 Sep 2014 05:46:02 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0LvBum-1YPvhN49ek-010MXI; Fri, 05 Sep 2014 14:45:56 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <5409AD44.40308@gmail.com> Date: Fri, 5 Sep 2014 15:45:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2C4B175F-425C-40A6-8CD1-432C193FC06C@yegin.org> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409AD44.40308@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:YkD88iJtAaVwSENq1x4shXEuJGX0DCw72HnpZ72OS5d h2r3PJrny3epmp4L6No7ll7RITmQ3cnA5kKSnENczr9do8ONYn XX+vtU49aO40rulDrgwFIfV+TgvuGTLhP10RiRuwRL8ajydWa/ hqAJbFzqhgTBfgbU2ww/O9PNmQVHTDuXoIE7DV326F22PEaVY/ Rz1meIznUkg7gVV5I7qzq13C+kGoi4u42W/63CFw8HPvdnGxIv RoaxbUaRmYnlAXIwyycRaiPPXzAj15x8atxiYpf4e3eCK29dzN WNMgmVVaE46f+Sqx4ieSPBIKYQ4H9LxZ9YLNmd//PtTxnglKrR EiNMtfgx/C6lXzWHBuoLbaG0k1woIpWvWykFiRfzH00v1hW23x JZhs95gqx4ekg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/fzb7Uk3x9jH_A_X0_aqeFm2ZgJ0 Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 05 Sep 2014 12:46:05 -0000 Hi Alex, On Sep 5, 2014, at 3:32 PM, Alexandru Petrescu wrote: > Le 05/09/2014 10:48, Alper Yegin a =E9crit : >> Alex, >>=20 >> DMM is not meant to be only about a bunch of MIP-based solutions. >> There are various components in DMM solution space that'd also work = with GTP-based architectures. >> For example, identifying the mobility needs of flows. >> Or, conveying the mobility characteristic of a prefix to the UE. >=20 > Alper - thanks for the reply. >=20 > Identifying the mobility needs of flows assumes that IP flows _can_ be = characterized, and then distinguished as mobile - or non-mobile. I = think this is very hard to do, given the difficulty to write good = firewall rules, and the difficulty of analyzing traffic dumps. >=20 > For example, Netalyzr was written to tell whether or not one's = computer is connected to the Internet. That report page has so many = lines that it is hard to tell which part of it really means 'connected = to the Internet'. >=20 > The same problem may arise when trying to identify a particular = 'flow'. >=20 The most robust way is to let the application tell the IP stack. http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-02.txt Alper > Alex >=20 >=20 >=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: >>=20 >>> Le 03/09/2014 20:53, Brian Haberman a =E9crit : >>>> Behcet, >>>>=20 >>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>>>=20 >>>>> You don't seem to understand my points. >>>>=20 >>>> That is quite possible. Your comment on the list was "I am against = any >>>> deployment work before we decide on a solution..." >>>>=20 >>>> I read that as an objection to having the deployment models work = item on >>>> the agenda. Please do tell me what I am missing. >>>>=20 >>>> Regards, >>>> Brian >>>=20 >>> Hi, >>>=20 >>> I am following the discussion and me too I do not quite understand = what is the complain. >>>=20 >>> I am happy to learn that a if a WG is to be formed then it would be = around a solution rather than just requirements or architecture. >>>=20 >>> That said, I would like to express a worry along similar lines. >>>=20 >>> In DMM, precedents and the keen NETEXT, there seems to be a = hard-rooted disconnect between the product developped - (P)Mobile IP - = and the deployments. We know for a fact that 3GPP deployments = (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do = mention Mobile IP. To such a point that I wonder whether 3GPP has not = the same disconnect as here. >>>=20 >>> On another hand, we do have indications of where (P)Mobile IP is = used - the trials, the projects, the kernel code, and not least the = slideware attracting real customers. >>>=20 >>> The worry: develop DMM protocol while continuing the disconnect. >>>=20 >>> Alex >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >>=20 >>=20 >=20 >=20 From nobody Fri Sep 5 07:24:24 2014 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 CB24C1A0702 for ; Fri, 5 Sep 2014 07:24:23 -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 TRKCJhrF-wA6 for ; Fri, 5 Sep 2014 07:24:21 -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 798E91A06FA for ; Fri, 5 Sep 2014 07:24:21 -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 s85EOJU7023592; Fri, 5 Sep 2014 16:24:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A5706203661; Fri, 5 Sep 2014 16:24:35 +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 99C1A20365D; Fri, 5 Sep 2014 16:24:35 +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 s85EO2lp023613; Fri, 5 Sep 2014 16:24:19 +0200 Message-ID: <5409C782.6070807@gmail.com> Date: Fri, 05 Sep 2014 16:24:02 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Alper Yegin References: <53D17F75.3030207@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409AD44.40308@gmail.com> <2C4B175F-425C-40A6-8CD1-432C193FC06C@yegin.o! rg> In-Reply-To: <2C4B175F-425C-40A6-8CD1-432C193FC06C@yegin.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/KxJcVpv9WHLzDHXgY4QLtkLc_0I Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 05 Sep 2014 14:24:23 -0000 Le 05/09/2014 14:45, Alper Yegin a écrit : > Hi Alex, > > On Sep 5, 2014, at 3:32 PM, Alexandru Petrescu wrote: > >> Le 05/09/2014 10:48, Alper Yegin a écrit : >>> Alex, >>> >>> DMM is not meant to be only about a bunch of MIP-based >>> solutions. There are various components in DMM solution space >>> that'd also work with GTP-based architectures. For example, >>> identifying the mobility needs of flows. Or, conveying the >>> mobility characteristic of a prefix to the UE. >> >> Alper - thanks for the reply. >> >> Identifying the mobility needs of flows assumes that IP flows _can_ >> be characterized, and then distinguished as mobile - or non-mobile. >> I think this is very hard to do, given the difficulty to write good >> firewall rules, and the difficulty of analyzing traffic dumps. >> >> For example, Netalyzr was written to tell whether or not one's >> computer is connected to the Internet. That report page has so >> many lines that it is hard to tell which part of it really means >> 'connected to the Internet'. >> >> The same problem may arise when trying to identify a particular >> 'flow'. >> > > The most robust way is to let the application tell the IP stack. > > http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-02.txt Sounds reasonable. A complimentary means is to look at this as a source address selection problem: given two addresses configured on an interface (an IP address, and an IP address designated as CoA), the application selects the src address as the IP address if its flows are brief query/response (http), or it selects the src address as the CoA if its flows are longer timed (request of UDP stream, or TCP download). This would need a means to designate to the stack an IP address as to be a 'CoA', or otherwise designate a prefix to be the 'home' prefix and, by deduction any address differing be the CoA. Alex > > Alper > > > >> Alex >> >> >> >>> >>> Alper >>> >>> >>> >>> >>> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: >>> >>>> Le 03/09/2014 20:53, Brian Haberman a écrit : >>>>> Behcet, >>>>> >>>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>>>> >>>>>> You don't seem to understand my points. >>>>> >>>>> That is quite possible. Your comment on the list was "I am >>>>> against any deployment work before we decide on a >>>>> solution..." >>>>> >>>>> I read that as an objection to having the deployment models >>>>> work item on the agenda. Please do tell me what I am >>>>> missing. >>>>> >>>>> Regards, Brian >>>> >>>> Hi, >>>> >>>> I am following the discussion and me too I do not quite >>>> understand what is the complain. >>>> >>>> I am happy to learn that a if a WG is to be formed then it >>>> would be around a solution rather than just requirements or >>>> architecture. >>>> >>>> That said, I would like to express a worry along similar >>>> lines. >>>> >>>> In DMM, precedents and the keen NETEXT, there seems to be a >>>> hard-rooted disconnect between the product developped - >>>> (P)Mobile IP - and the deployments. We know for a fact that >>>> 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also >>>> know that 3GPP specs do mention Mobile IP. To such a point that >>>> I wonder whether 3GPP has not the same disconnect as here. >>>> >>>> On another hand, we do have indications of where (P)Mobile IP >>>> is used - the trials, the projects, the kernel code, and not >>>> least the slideware attracting real customers. >>>> >>>> The worry: develop DMM protocol while continuing the >>>> disconnect. >>>> >>>> Alex >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ 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 Sep 5 10:14:50 2014 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 A09B31A0386 for ; Fri, 5 Sep 2014 10:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 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, RP_MATCHES_RCVD=-0.668] 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 6rnPKQ-e3243 for ; Fri, 5 Sep 2014 10:10:52 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 979C01A037B for ; Fri, 5 Sep 2014 10:10:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VfIQwGpesKRFCqAdnzpSSCghE3emrXfc8mrpb2lLcZQYjxnIIGmQHUN2/SCcymWT; 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.255.215]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XPx2B-0000aw-9h; Fri, 05 Sep 2014 13:10:51 -0400 Message-ID: <5409EE9A.1020700@earthlink.net> Date: Fri, 05 Sep 2014 10:10:50 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alper Yegin , Alexandru Petrescu References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac79e93528a90acc1053f045a62dafe3e33350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/9wzZa5BgmCprAJpO8j9FDtQd0iA X-Mailman-Approved-At: Fri, 05 Sep 2014 10:14:49 -0700 Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 05 Sep 2014 17:10:54 -0000 Hello folks, I have made various presentations at IETF, some from many years ago, proposing that Mobile IP enable use of GTP as a tunneling option. I still think that would be a good idea. Should I re-re-revive a draft stating this in more detail? Regards, Charlie P. On 9/5/2014 1:48 AM, Alper Yegin wrote: > Alex, > > DMM is not meant to be only about a bunch of MIP-based solutions. > There are various components in DMM solution space that'd also work with GTP-based architectures. > For example, identifying the mobility needs of flows. > Or, conveying the mobility characteristic of a prefix to the UE. > > Alper > > > > > On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: > >> Le 03/09/2014 20:53, Brian Haberman a écrit : >>> Behcet, >>> >>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>> You don't seem to understand my points. >>> That is quite possible. Your comment on the list was "I am against any >>> deployment work before we decide on a solution..." >>> >>> I read that as an objection to having the deployment models work item on >>> the agenda. Please do tell me what I am missing. >>> >>> Regards, >>> Brian >> Hi, >> >> I am following the discussion and me too I do not quite understand what is the complain. >> >> I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. >> >> That said, I would like to express a worry along similar lines. >> >> In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. >> >> On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. >> >> The worry: develop DMM protocol while continuing the disconnect. >> >> Alex >> >> >> >> >>> >>> >>> >>> _______________________________________________ >>> 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 Sep 5 10:23:17 2014 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 16FD41A0AF7 for ; Fri, 5 Sep 2014 10:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.669 X-Spam-Level: X-Spam-Status: No, score=-11.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 4Wtre5RoSqam for ; Fri, 5 Sep 2014 10:23:10 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643FF1A0ADB for ; Fri, 5 Sep 2014 10:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1660; q=dns/txt; s=iport; t=1409937790; x=1411147390; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WWtrhnpj9WSKahEvCOhPyg/k3jZB7Q/A0NIi3TpL77I=; b=YjX2IiaGvet2VL59TJb2vkzhPcmiO3L5eO91AosSzhtY4rlgmtDBy4KB jkgiQDarzqWvlrIgES8nC3Lobv2TPWlodpJTK9HJzDRisrOriFNJuu+XF PJ7xM1tW7KCh7n7/BjlJxv8j+Yuvwcfw09+v1ODPsIl+djmMHIHLytPlW A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFABbwCVStJV2Q/2dsb2JhbABagw1TVwSBJIFUxhOHSgEZbxZ3hAQCBDRFEgEIHCgEHxEaCwIEAQ0FCYglAxENjR+cMg6OZg2GWgEXgSOLfYFcAQEcMweCcIFcBZE+iR6CEI5thjmDYWwBgQ45gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,474,1406592000"; d="scan'208";a="75342345" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 05 Sep 2014 17:23:09 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s85HN9bs030367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 17:23:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 12:23:09 -0500 From: "Sri Gundavelli (sgundave)" To: Jouni , "dmm@ietf.org" Thread-Topic: =?big5?B?W0RNTV0gpl7OYKFHICBpbnRlcmltIGNhbGwgIzEgYW5kIHJlY2hhdGVyIHRleHQ=?= Thread-Index: AQHPyS4PnPiua4URFUC0XI9KHVaJsw== Date: Fri, 5 Sep 2014 17:23:08 +0000 Message-ID: In-Reply-To: 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.217] Content-Type: text/plain; charset="big5" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ZdnUcxAjwIRjvSDmBd2y_xjpe_I Cc: "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] =?big5?b?pl7OYKFHICBpbnRlcmltIGNhbGwgIzEgYW5kIHJlY2hhdGVy?= =?big5?b?IHRleHQ=?= 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, 05 Sep 2014 17:23:15 -0000 DQoNCk9uIDkvNS8xNCAzOjExIEFNLCAiSm91bmkiIDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPiB3 cm90ZToNCg0KPg0KPkZvbGtzLA0KPg0KPlRoaXMgbWFpbCBzdGFydCBhIG9uZSB3ZWVrIHBlcmlv ZCB0byBjb21tZW50IGFuZCBwcm9wb3NlIGNoYW5nZXMgdG8gdGhlDQo+cmUtY2hhcnRlciB0ZXh0 LiBUaGUgY2FsbCBlbmRzIDEydGggU2VwLg0KPkFsbCB0aGUgbWF0ZXJpYWwgZnJvbSB0aGUgSW50 ZXJpbSBjYWxsIzEgaW5jbHVkaW5nIHRoZSBsYXRlc3QgcmUtY2hhcnRlcg0KPnRleHQgaXMgYXZh aWxhYmxlIGF0Og0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE0 LzA5LzAyL2RtbS9wcm9jZWVkaW5ncy5odG1sDQo+DQo+SWYgeW91IGhhdmUgY29tbWVudHMgLyBj b3JyZWN0aW9ucyB0byBwcm9wb3NlLCBpbmNsdWRlIHRoZSBjb25jcmV0ZQ0KPmNoYW5nZSBwcm9w b3NhbCB3aXRoIGEganVzdGlmaWNhdGlvbiwgZm9yIGV4YW1wbGUgaW4gYSBmb3JtOg0KPg0KPk9M RDoNCj4gIEZlYiAyMDE1IC0gU3VibWl0ICdGb3J3YXJkaW5nIHBhdGggYW5kIHNpZ25hbGluZyBt YW5hZ2VtZW50JyBhcyBhDQo+ICAgICAgICAgICAgIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRv IGJlIFByb3Bvc2VkIFN0YW5kYXJkLg0KPg0KPk5FVzoNCj4gIE1heSAyMDE5IC0gU3VibWl0ICdG b3J3YXJkaW5nIHBhdGggYW5kIHNpZ25hbGluZyBtYW5hZ2VtZW50JyBhcyBhDQo+ICAgICAgICAg ICAgIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFRvIGJlIFByb3Bvc2VkIFN0YW5kYXJkLg0KPg0K PldIWToNCj4gIEkgbmVlZCB0byBjb25jZW50cmF0ZSBiZXR0ZXJpbmcgbXkgZ29sZiBoYW5kaWNh cCBmb3IgdGhlIG5leHQgdGhyZWUNCj4gIHllYXJzLCB0aHVzIEkgaGF2ZSBubyB0aW1lIHRvIGNv bnRyaWJ1dGUgdW50aWwgZWFybHkgMjAxOS4NCg0KDQpTZXJpb3VzbHkgPw0KDQpUaGF0IHdpbGwg bWFrZSB5b3UgYSBwcm9mZXNzaW9uYWwgZ29sZmVyIGFuZCB3aWxsIGxlYXZlIHRoZSB3b3JraW5n IGdyb3VwDQoiYmVsb3cgdGhlIGhvbGUiLiBBbHNvLCBieSB0aGVuIG9uZSBvZiBvdXIgZmF2b3Jp dGUgU0RPIHdvdWxkIGhhdmUNCnB1Ymxpc2hlZCB6aWxsaW9uIHBhZ2VzIG9mIGxlZ2FsbHkgYWdy ZWVkL25lZ290aWF0ZWQgdGV4dC4NCg0KU28sIGxldHMga2VlcCB0aGlzIDIwMTUuDQoNClJlZ2Fy ZHMNCg0KU3JpDQoNCg== From nobody Fri Sep 5 10:56:37 2014 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 DCE071A0AE9 for ; Fri, 5 Sep 2014 10:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.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_FROM=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 R7j-1nR3cHPa for ; Fri, 5 Sep 2014 10:56:31 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB211A0120 for ; Fri, 5 Sep 2014 10:56:31 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id w7so14097209lbi.11 for ; Fri, 05 Sep 2014 10:56:29 -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=s7ANLr9VmAuGnbzesY5m0qUEMPgtL4HmcqEFJV440TY=; b=hB2aKK/IQpWM6AygNgTK+PCH9whB0hcOe37Q+hnzcqmuTjLHd+QdW/hlGK47g8cbWs tXqIeu/fobMzlC+rh2Gj9ZvGoNeYaH1Sp2odpcK1iA85SRyicl/mhKvcnylRRdo/CXyO iX9GaJMM5iHVccmIyH8YNB0O0BPpwOYP6DEd67lX4TQyzqFPr5qx5Maa7se+5zrArAOn F6HP8FvSzb0j3g+tnX7I19NB8wV98sW4rbqCYUjmAZoevMWW3RhI/f+gJyIQtPjxS/b+ jC7SzGVEUqDzpned0lpVCQow0zwjUNU0SR+OIdULtHPT9lmYQnFYSeLbSGy+OYN01Wvt FYlg== X-Received: by 10.112.160.38 with SMTP id xh6mr12816548lbb.21.1409939789567; Fri, 05 Sep 2014 10:56:29 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:c96d:426c:6e2c:8bff? ([2001:1bc8:101:f101:c96d:426c:6e2c:8bff]) by mx.google.com with ESMTPSA id zc10sm944748lbb.40.2014.09.05.10.56.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Sep 2014 10:56:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=big5 From: Jouni In-Reply-To: Date: Fri, 5 Sep 2014 20:56:26 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: Sri Gundavelli (sgundave) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/sldniG2mtHYBddPFpkH7cSgb-F8 Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaICBpbnRlcmltIGNhbGwgIzEgYW5kIHJlY2hh?= =?utf-8?q?ter_text?= 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, 05 Sep 2014 17:56:36 -0000 On Sep 5, 2014, at 8:23 PM, Sri Gundavelli (sgundave) wrote: > > > On 9/5/14 3:11 AM, "Jouni" wrote: > >> >> Folks, >> >> This mail start a one week period to comment and propose changes to the >> re-charter text. The call ends 12th Sep. >> All the material from the Interim call#1 including the latest re-charter >> text is available at: >> http://www.ietf.org/proceedings/interim/2014/09/02/dmm/proceedings.html >> >> If you have comments / corrections to propose, include the concrete >> change proposal with a justification, for example in a form: >> >> OLD: >> Feb 2015 - Submit 'Forwarding path and signaling management' as a >> working group document. To be Proposed Standard. >> >> NEW: >> May 2019 - Submit 'Forwarding path and signaling management' as a >> working group document. To be Proposed Standard. >> >> WHY: >> I need to concentrate bettering my golf handicap for the next three >> years, thus I have no time to contribute until early 2019. > > > Seriously ? The format above is serious, the content is not ;-) - Jouni > > That will make you a professional golfer and will leave the working group > "below the hole". Also, by then one of our favorite SDO would have > published zillion pages of legally agreed/negotiated text. > > So, lets keep this 2015. > > Regards > > Sri > From nobody Sat Sep 6 03:04:18 2014 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 4AB471A0240 for ; Sat, 6 Sep 2014 03:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 qx2EDn1rCGDg for ; Sat, 6 Sep 2014 03:04:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 EA8AF1A003A for ; Sat, 6 Sep 2014 03:04:13 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0MDfbM-1XblJB0ZVm-00H4Lp; Sat, 06 Sep 2014 12:04:11 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <5409C782.6070807@gmail.com> Date: Sat, 6 Sep 2014 13:04:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D17F75.3030207@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409AD44.40308@gmail.com> <2C4B175F-425C-40A6-8CD1-432C193FC06C@yegin.o! rg> <54 09C782.6070807@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:ZOinomC353B/rZjfCcIuuHIMGrBFRzK5SXcQwiHZsSy P3Tu9VlaFEIJEhBubfrFgJY9ArPQo267CijFtB83zyU9Rqfqwy Z6Rf2vzoCfG4vUINIPgMQ+gxa3OGLfaGWaThfUAVSLlDN64CkY GJCMHA5iQeom3a34dGgHJNmgs61MpQz6Hk3aX8QS+T0G6SdkP9 VZ3JzpR7AwRSpVVPR7QfU0rPnTt4gEELXe+ShXg4c0TUqEZ9+o vrTeoXvtlFAoXKkFVeP5i+tHlqRMq+pAbYMwFBCkG1TceA+Cgc AHicQKB4J9toXTWy4iHz3QVkMgjrPLf8/6PwuMCyK5wvpj0AK+ uU76RyJQ771c1YMiYzEQbilANRFgDYa1gSuT2D7L5mBzP4qD4a xksOVuCPw64aw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/MbVDYG7YQaHAqDw9xoILo0av2V8 Cc: dmm@ietf.org Subject: Re: [DMM] regarding the re-chartering.. 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, 06 Sep 2014 10:04:17 -0000 Alex, >>=20 >> The most robust way is to let the application tell the IP stack. >>=20 >> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-02.txt >=20 > Sounds reasonable. >=20 > A complimentary means is to look at this as a source address selection = problem: given two addresses configured on an interface (an IP address, = and an IP address designated as CoA), the application selects the src = address as the IP address if its flows are brief query/response (http), = or it selects the src address as the CoA if its flows are longer timed = (request of UDP stream, or TCP download). >=20 That's exactly the intention and the approach.=20 > This would need a means to designate to the stack an IP address as to = be a 'CoA', or otherwise designate a prefix to be the 'home' prefix and, = by deduction any address differing be the CoA. >=20 At a high-level, yes. If you've read the draft you'll see there are some = details and extensions on top of that (such as it's not a simply matter = of CoA vs HoA, but there are in fact 3 types of IP addresses, and also a = required type IP address can be configured on-demand when needed). Alper > Alex >=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>> Alex >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: >>>>=20 >>>>> Le 03/09/2014 20:53, Brian Haberman a =E9crit : >>>>>> Behcet, >>>>>>=20 >>>>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>>>>>=20 >>>>>>> You don't seem to understand my points. >>>>>>=20 >>>>>> That is quite possible. Your comment on the list was "I am >>>>>> against any deployment work before we decide on a >>>>>> solution..." >>>>>>=20 >>>>>> I read that as an objection to having the deployment models >>>>>> work item on the agenda. Please do tell me what I am >>>>>> missing. >>>>>>=20 >>>>>> Regards, Brian >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I am following the discussion and me too I do not quite >>>>> understand what is the complain. >>>>>=20 >>>>> I am happy to learn that a if a WG is to be formed then it >>>>> would be around a solution rather than just requirements or >>>>> architecture. >>>>>=20 >>>>> That said, I would like to express a worry along similar >>>>> lines. >>>>>=20 >>>>> In DMM, precedents and the keen NETEXT, there seems to be a >>>>> hard-rooted disconnect between the product developped - >>>>> (P)Mobile IP - and the deployments. We know for a fact that >>>>> 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also >>>>> know that 3GPP specs do mention Mobile IP. To such a point that >>>>> I wonder whether 3GPP has not the same disconnect as here. >>>>>=20 >>>>> On another hand, we do have indications of where (P)Mobile IP >>>>> is used - the trials, the projects, the kernel code, and not >>>>> least the slideware attracting real customers. >>>>>=20 >>>>> The worry: develop DMM protocol while continuing the >>>>> disconnect. >>>>>=20 >>>>> Alex >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ dmm mailing >>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ dmm mailing >>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >=20 >=20 From nobody Sat Sep 6 03:06:48 2014 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 98E6E1A003A for ; Sat, 6 Sep 2014 03:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 5wQxLPkbSALM for ; Sat, 6 Sep 2014 03:06:45 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 58D651A023E for ; Sat, 6 Sep 2014 03:06:44 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0LfAOk-1YAH4d31S4-00okgz; Sat, 06 Sep 2014 12:06:41 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <5409EE9A.1020700@earthlink.net> Date: Sat, 6 Sep 2014 13:06:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <25086374-11E8-45F6-B20F-428897C50DA7@yegin.org> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409EE9A.1020700@earthlink.net> To: Charlie Perkins X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:62aIz7Drc9GdhA63+wfNvCIKgbB8+5HmnVjfwojWWpx WGwzlSku7invM8OgaNGCE1Yk561e9mpmqkniXQM6lfR8oUNFqW PPbHapyHGtR3F69kG9EfZcTF/C6i8s6qpG/aXMF3DhI/s7oKHU qiqzoEMPUlCCHbrmO19jEY/d0tbB9HQdqy6cnducaPe9N2TJSm Gi/BVzdzP41uMrlgm8pEczBOXiJ4pNCMggxyNoQ36toSKFDRdD IJQa0xCWfMGE9dOYGoG1AXAnGnwAp9JSDnEOmAGe1AhMO1+t8p wMYXGzn3/WX8w0vxXj5964ylsC1RS4qpRUmAWzJqIcdkD1RWh3 b6wKMIB8zbh3vNtJZV6OFqZivdGsqXiqYE8uPTLtaUuL05Lj1b GJwwCYg12XkSw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/wzRcUff3d-DRO2mETVdkjekGG3Y Cc: dmm@ietf.org Subject: [DMM] MIP and GTP (was Re: regarding the re-chartering..) 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, 06 Sep 2014 10:06:46 -0000 Hi Charlie, GTP has its data-plane (GTP-U) and control-plane (GTP-C). I think you are talking about using Mobile IP signaling in-place of = GTP-C to enable GTP-U. If so, I think it'd technically work. But, for adoption by 3GPP = standards and deployments, we'd need to make a case for using Mobile IP = instead of GTP-C.=20 Alper On Sep 5, 2014, at 8:10 PM, Charlie Perkins wrote: >=20 > Hello folks, >=20 > I have made various presentations at IETF, some from many years > ago, proposing that Mobile IP enable use of GTP as a tunneling > option. I still think that would be a good idea. Should I = re-re-revive > a draft stating this in more detail? >=20 > Regards, > Charlie P. >=20 >=20 > On 9/5/2014 1:48 AM, Alper Yegin wrote: >> Alex, >>=20 >> DMM is not meant to be only about a bunch of MIP-based solutions. >> There are various components in DMM solution space that'd also work = with GTP-based architectures. >> For example, identifying the mobility needs of flows. >> Or, conveying the mobility characteristic of a prefix to the UE. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: >>=20 >>> Le 03/09/2014 20:53, Brian Haberman a =E9crit : >>>> Behcet, >>>>=20 >>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>>> You don't seem to understand my points. >>>> That is quite possible. Your comment on the list was "I am against = any >>>> deployment work before we decide on a solution..." >>>>=20 >>>> I read that as an objection to having the deployment models work = item on >>>> the agenda. Please do tell me what I am missing. >>>>=20 >>>> Regards, >>>> Brian >>> Hi, >>>=20 >>> I am following the discussion and me too I do not quite understand = what is the complain. >>>=20 >>> I am happy to learn that a if a WG is to be formed then it would be = around a solution rather than just requirements or architecture. >>>=20 >>> That said, I would like to express a worry along similar lines. >>>=20 >>> In DMM, precedents and the keen NETEXT, there seems to be a = hard-rooted disconnect between the product developped - (P)Mobile IP - = and the deployments. We know for a fact that 3GPP deployments = (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do = mention Mobile IP. To such a point that I wonder whether 3GPP has not = the same disconnect as here. >>>=20 >>> On another hand, we do have indications of where (P)Mobile IP is = used - the trials, the projects, the kernel code, and not least the = slideware attracting real customers. >>>=20 >>> The worry: develop DMM protocol while continuing the disconnect. >>>=20 >>> Alex >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>>=20 >>>=20 >>> _______________________________________________ >>> 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 >=20 From nobody Sat Sep 6 03:16:00 2014 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 C5E741A0205 for ; Sat, 6 Sep 2014 03:15:58 -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 fnuVEA3P7kf4 for ; Sat, 6 Sep 2014 03:15:57 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40721A004E for ; Sat, 6 Sep 2014 03:15:56 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id s7so394862lbd.25 for ; Sat, 06 Sep 2014 03:15:54 -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=6WYQujFvEzEm8tAMlTaFOtEtJV42wa+ulKShC2X2Fu0=; b=mm4KJK5dzVsqyI6XG6yfhbbzbmcUqoIbl7vedzHFfR3dfBSH7ve64GBGVAtouC/VeE Vl7FngUPoT0t9ud5IIMrPTnFh4pWH0ECDTmZY2gucXsmOqtDSHrjmKTQrGwzrH5J827c vy+TOag3mx6odaq6uNDqkx1tWtCbHKuTg42j4W16NhrBrkfdVtUHKEyPKEL0t+tV7fSm ZRP/W/2w0mI2wU3WJQHl1lPsevCNsIFbRiOqwzbM3qkwP/l4vD3ELtQ+5r3qNkPzZPd5 9N6+G/dd3FMQE7kn5NwFZhfhJxUVj+Zo5SBsKL+0WWwgEXMvqgj829VowqsPsTrL1wCH Vdcg== X-Received: by 10.112.210.138 with SMTP id mu10mr1655480lbc.81.1409998554882; Sat, 06 Sep 2014 03:15:54 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id y9sm1491118lad.32.2014.09.06.03.15.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Sep 2014 03:15:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jouni In-Reply-To: <25086374-11E8-45F6-B20F-428897C50DA7@yegin.org> Date: Sat, 6 Sep 2014 13:15:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3DCB6C08-05A8-452A-BC24-597011099AA3@gmail.com> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409EE9A.1020700@earthlink.net> <25086374-11E8-45F6-B20F-428897C50DA7@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/pDBouLtF3FGbsoIb1fFa0ld0B2U Cc: Charlie Perkins , dmm@ietf.org Subject: Re: [DMM] MIP and GTP (was Re: regarding the re-chartering..) 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, 06 Sep 2014 10:15:59 -0000 Just to point out that GTP-U also carries control information, which = none of the existing *MIP user plane tunnels do not do today. Regarding GTP-C part, 3GPP TS29.275 has done pretty thorough job already = mapping GTPv2-C to PMIP signaling, so using GTP-U instead of GRE or IPIP = should be rather straightforward if someone were to do it. - Jouni On Sep 6, 2014, at 1:06 PM, Alper Yegin wrote: > Hi Charlie, >=20 > GTP has its data-plane (GTP-U) and control-plane (GTP-C). > I think you are talking about using Mobile IP signaling in-place of = GTP-C to enable GTP-U. > If so, I think it'd technically work. But, for adoption by 3GPP = standards and deployments, we'd need to make a case for using Mobile IP = instead of GTP-C.=20 >=20 > Alper >=20 >=20 > On Sep 5, 2014, at 8:10 PM, Charlie Perkins wrote: >=20 >>=20 >> Hello folks, >>=20 >> I have made various presentations at IETF, some from many years >> ago, proposing that Mobile IP enable use of GTP as a tunneling >> option. I still think that would be a good idea. Should I = re-re-revive >> a draft stating this in more detail? >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >> On 9/5/2014 1:48 AM, Alper Yegin wrote: >>> Alex, >>>=20 >>> DMM is not meant to be only about a bunch of MIP-based solutions. >>> There are various components in DMM solution space that'd also work = with GTP-based architectures. >>> For example, identifying the mobility needs of flows. >>> Or, conveying the mobility characteristic of a prefix to the UE. >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: >>>=20 >>>> Le 03/09/2014 20:53, Brian Haberman a =E9crit : >>>>> Behcet, >>>>>=20 >>>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>>>> You don't seem to understand my points. >>>>> That is quite possible. Your comment on the list was "I am = against any >>>>> deployment work before we decide on a solution..." >>>>>=20 >>>>> I read that as an objection to having the deployment models work = item on >>>>> the agenda. Please do tell me what I am missing. >>>>>=20 >>>>> Regards, >>>>> Brian >>>> Hi, >>>>=20 >>>> I am following the discussion and me too I do not quite understand = what is the complain. >>>>=20 >>>> I am happy to learn that a if a WG is to be formed then it would be = around a solution rather than just requirements or architecture. >>>>=20 >>>> That said, I would like to express a worry along similar lines. >>>>=20 >>>> In DMM, precedents and the keen NETEXT, there seems to be a = hard-rooted disconnect between the product developped - (P)Mobile IP - = and the deployments. We know for a fact that 3GPP deployments = (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do = mention Mobile IP. To such a point that I wonder whether 3GPP has not = the same disconnect as here. >>>>=20 >>>> On another hand, we do have indications of where (P)Mobile IP is = used - the trials, the projects, the kernel code, and not least the = slideware attracting real customers. >>>>=20 >>>> The worry: develop DMM protocol while continuing the disconnect. >>>>=20 >>>> Alex >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> dmm mailing list >>>>> dmm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 >>=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Sun Sep 7 23:57:50 2014 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 5E79D1A6F2B for ; Sun, 7 Sep 2014 23:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-1.652] 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 LdJ9cnilhfTd for ; Sun, 7 Sep 2014 23:57:47 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29681A6F2A for ; Sun, 7 Sep 2014 23:57:47 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9568B89B231BD for ; Mon, 8 Sep 2014 06:57:43 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s886viWo019922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Sep 2014 08:57:45 +0200 Received: from [172.27.204.72] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 8 Sep 2014 08:57:44 +0200 Message-ID: <540D5367.2000403@alcatel-lucent.com> Date: Mon, 8 Sep 2014 08:57:43 +0200 From: "MONGAZON-CAZAVET, BRUNO (BRUNO)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409EE9A.1020700@earthlink.net> In-Reply-To: <5409EE9A.1020700@earthlink.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/0iX0OWq57wLRd4B6gobN_pAJNFc Subject: Re: [DMM] regarding the re-chartering.. 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, 08 Sep 2014 06:57:49 -0000 On 05/09/2014 19:10, Charlie Perkins wrote: > > Hello folks, > > I have made various presentations at IETF, some from many years > ago, proposing that Mobile IP enable use of GTP as a tunneling > option. I still think that would be a good idea. Should I re-re-revive > a draft stating this in more detail? I would be interested to look at this draft. Thanks. Bruno > > > Regards, > Charlie P. > > > On 9/5/2014 1:48 AM, Alper Yegin wrote: >> Alex, >> >> DMM is not meant to be only about a bunch of MIP-based solutions. >> There are various components in DMM solution space that'd also work >> with GTP-based architectures. >> For example, identifying the mobility needs of flows. >> Or, conveying the mobility characteristic of a prefix to the UE. >> >> Alper >> >> >> >> >> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: >> >>> Le 03/09/2014 20:53, Brian Haberman a écrit : >>>> Behcet, >>>> >>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>>> You don't seem to understand my points. >>>> That is quite possible. Your comment on the list was "I am against >>>> any >>>> deployment work before we decide on a solution..." >>>> >>>> I read that as an objection to having the deployment models work >>>> item on >>>> the agenda. Please do tell me what I am missing. >>>> >>>> Regards, >>>> Brian >>> Hi, >>> >>> I am following the discussion and me too I do not quite understand >>> what is the complain. >>> >>> I am happy to learn that a if a WG is to be formed then it would be >>> around a solution rather than just requirements or architecture. >>> >>> That said, I would like to express a worry along similar lines. >>> >>> In DMM, precedents and the keen NETEXT, there seems to be a >>> hard-rooted disconnect between the product developped - (P)Mobile IP >>> - and the deployments. We know for a fact that 3GPP deployments >>> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do >>> mention Mobile IP. To such a point that I wonder whether 3GPP has >>> not the same disconnect as here. >>> >>> On another hand, we do have indications of where (P)Mobile IP is >>> used - the trials, the projects, the kernel code, and not least the >>> slideware attracting real customers. >>> >>> The worry: develop DMM protocol while continuing the disconnect. >>> >>> Alex >>> >>> >>> >>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Sep 8 07:28:59 2014 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 BEF551A883F for ; Mon, 8 Sep 2014 07:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 k9QnMtDoazhe for ; Mon, 8 Sep 2014 07:28:57 -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 2D3C11A8837 for ; Mon, 8 Sep 2014 07:28:57 -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 s88ESu5s032315; Mon, 8 Sep 2014 09:28:56 -0500 Received: from XCH-BLV-306.nw.nos.boeing.com (xch-blv-306.nw.nos.boeing.com [130.247.25.218]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s88ESkSw032199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 8 Sep 2014 09:28:47 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-306.nw.nos.boeing.com ([169.254.6.59]) with mapi id 14.03.0181.006; Mon, 8 Sep 2014 07:28:45 -0700 From: "Templin, Fred L" To: Alper Yegin , Charlie Perkins Thread-Topic: [DMM] MIP and GTP (was Re: regarding the re-chartering..) Thread-Index: AQHPybpWBou3up9he0+Sft4fJwV685v3TmPg Date: Mon, 8 Sep 2014 14:28:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D11CEC@XCH-BLV-504.nw.nos.boeing.com> References: <53D17F75.3030207@gmail.com> <53D7A012.2050700@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409EE9A.1020700@earthlink.net> <25086374-11E8-45F6-B20F-428897C50DA7@yegin.org> In-Reply-To: <25086374-11E8-45F6-B20F-428897C50DA7@yegin.org> 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: http://mailarchive.ietf.org/arch/msg/dmm/Hoi6wBGROruXU6O54QBKMMdZCm0 Cc: "dmm@ietf.org" Subject: Re: [DMM] MIP and GTP (was Re: regarding the re-chartering..) 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, 08 Sep 2014 14:28:58 -0000 Hi Alper, Charlie, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin > Sent: Saturday, September 06, 2014 3:06 AM > To: Charlie Perkins > Cc: dmm@ietf.org > Subject: [DMM] MIP and GTP (was Re: regarding the re-chartering..) >=20 > Hi Charlie, >=20 > GTP has its data-plane (GTP-U) and control-plane (GTP-C). > I think you are talking about using Mobile IP signaling in-place of GTP-C= to enable GTP-U. > If so, I think it'd technically work. But, for adoption by 3GPP standards= and deployments, we'd need > to make a case for using Mobile IP instead of GTP-C. At the risk of saying "me too", AERO would work fine with GTP as well, using AERO control plane signaling. AERO works over any tunnel type that supports IP-in-*-in-IP encapsulation. Thanks - Fred fred.l.templin@boeing.com =20 > Alper >=20 >=20 > On Sep 5, 2014, at 8:10 PM, Charlie Perkins wrote: >=20 > > > > Hello folks, > > > > I have made various presentations at IETF, some from many years > > ago, proposing that Mobile IP enable use of GTP as a tunneling > > option. I still think that would be a good idea. Should I re-re-reviv= e > > a draft stating this in more detail? > > > > Regards, > > Charlie P. > > > > > > On 9/5/2014 1:48 AM, Alper Yegin wrote: > >> Alex, > >> > >> DMM is not meant to be only about a bunch of MIP-based solutions. > >> There are various components in DMM solution space that'd also work wi= th GTP-based architectures. > >> For example, identifying the mobility needs of flows. > >> Or, conveying the mobility characteristic of a prefix to the UE. > >> > >> Alper > >> > >> > >> > >> > >> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: > >> > >>> Le 03/09/2014 20:53, Brian Haberman a =E9crit : > >>>> Behcet, > >>>> > >>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: > >>>>> You don't seem to understand my points. > >>>> That is quite possible. Your comment on the list was "I am against = any > >>>> deployment work before we decide on a solution..." > >>>> > >>>> I read that as an objection to having the deployment models work ite= m on > >>>> the agenda. Please do tell me what I am missing. > >>>> > >>>> Regards, > >>>> Brian > >>> Hi, > >>> > >>> I am following the discussion and me too I do not quite understand wh= at is the complain. > >>> > >>> I am happy to learn that a if a WG is to be formed then it would be a= round a solution rather than > just requirements or architecture. > >>> > >>> That said, I would like to express a worry along similar lines. > >>> > >>> In DMM, precedents and the keen NETEXT, there seems to be a hard-root= ed disconnect between the > product developped - (P)Mobile IP - and the deployments. We know for a f= act that 3GPP deployments > (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do ment= ion Mobile IP. To such a > point that I wonder whether 3GPP has not the same disconnect as here. > >>> > >>> On another hand, we do have indications of where (P)Mobile IP is used= - the trials, the projects, > the kernel code, and not least the slideware attracting real customers. > >>> > >>> The worry: develop DMM protocol while continuing the disconnect. > >>> > >>> Alex > >>> > >>> > >>> > >>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Mon Sep 8 10:50:16 2014 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 D2EAD1A0109 for ; Mon, 8 Sep 2014 10:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 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, RP_MATCHES_RCVD=-1.652] 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 NWjTihlbJsmb for ; Mon, 8 Sep 2014 10:50:13 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id AA3B11A010A for ; Mon, 8 Sep 2014 10:50:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Vuc6rc+ZhSVsY4gUR0pAXT8jE9NNYqvBoL5u233629Fmkwt2H1oJFFRB99H6R8EO; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To: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.255.215]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XR34n-0000ZJ-MO; Mon, 08 Sep 2014 13:50:05 -0400 Message-ID: <540DEC4C.5030409@earthlink.net> Date: Mon, 08 Sep 2014 10:50:04 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "MONGAZON-CAZAVET, BRUNO \(BRUNO\)" , dmm@ietf.org References: <53D17F75.3030207@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409EE9A.1020700@earthlink.net> <540D5367.2000403@alcatel-lucent.com> In-Reply-To: <540D5367.2000403@alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7430a9c3aa26cafb85d1ef03201fe60b5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/hahHe4OCzQBR-DXim8I3ArUsuUM Subject: Re: [DMM] regarding the re-chartering.. 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, 08 Sep 2014 17:50:15 -0000 Hello folks, I'll go look for the link(s). But in the meantime, as part of the ongoing maintenance work, I'd be happy to see the following: - Additional tunnel types (including GTP) - Additional mobile node identifier types (including IMSI, MAC, ...) - Additional security mechanisms If there is a sliver of a chance that we could go down any one or more of these paths, I will resurrect the old Internet drafts as well. If people are interested, I will re-submit them for the November meeting. There are two or three other things that Mobile IP needs also, that take more words to express, but not necessarily directly related to distributed mobility management. Much of my development had to do with trying to provide an easier / incremental path for the deployment of Mobile IP by SDO partners in 3GPP, which would necessitate inclusion in their standards, which (for instance) seems to necessitate GTP as a tunneling protocol, etc. Regards, Charlie P. On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote: > On 05/09/2014 19:10, Charlie Perkins wrote: >> >> Hello folks, >> >> I have made various presentations at IETF, some from many years >> ago, proposing that Mobile IP enable use of GTP as a tunneling >> option. I still think that would be a good idea. Should I re-re-revive >> a draft stating this in more detail? > > I would be interested to look at this draft. > Thanks. > Bruno > >> >> >> Regards, >> Charlie P. >> >> >> On 9/5/2014 1:48 AM, Alper Yegin wrote: >>> Alex, >>> >>> DMM is not meant to be only about a bunch of MIP-based solutions. >>> There are various components in DMM solution space that'd also work >>> with GTP-based architectures. >>> For example, identifying the mobility needs of flows. >>> Or, conveying the mobility characteristic of a prefix to the UE. >>> >>> Alper >>> >>> >>> >>> >>> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: >>> >>>> Le 03/09/2014 20:53, Brian Haberman a écrit : >>>>> Behcet, >>>>> >>>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>>>> You don't seem to understand my points. >>>>> That is quite possible. Your comment on the list was "I am >>>>> against any >>>>> deployment work before we decide on a solution..." >>>>> >>>>> I read that as an objection to having the deployment models work >>>>> item on >>>>> the agenda. Please do tell me what I am missing. >>>>> >>>>> Regards, >>>>> Brian >>>> Hi, >>>> >>>> I am following the discussion and me too I do not quite understand >>>> what is the complain. >>>> >>>> I am happy to learn that a if a WG is to be formed then it would be >>>> around a solution rather than just requirements or architecture. >>>> >>>> That said, I would like to express a worry along similar lines. >>>> >>>> In DMM, precedents and the keen NETEXT, there seems to be a >>>> hard-rooted disconnect between the product developped - (P)Mobile >>>> IP - and the deployments. We know for a fact that 3GPP deployments >>>> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs >>>> do mention Mobile IP. To such a point that I wonder whether 3GPP >>>> has not the same disconnect as here. >>>> >>>> On another hand, we do have indications of where (P)Mobile IP is >>>> used - the trials, the projects, the kernel code, and not least the >>>> slideware attracting real customers. >>>> >>>> The worry: develop DMM protocol while continuing the disconnect. >>>> >>>> Alex >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Mon Sep 8 13:46:10 2014 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 09FEE1A0394 for ; Mon, 8 Sep 2014 13:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 EfpxSe1Xh5an for ; Mon, 8 Sep 2014 13:46:07 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157251A0389 for ; Mon, 8 Sep 2014 13:46:07 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id z107so15961514qgd.21 for ; Mon, 08 Sep 2014 13:46:06 -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=NLRpHOLjnCSSEdH/i4NEX5SBMg/qY/LA6sBqHyCAQJ0=; b=YtpFPwinM0S6YYI1nSp2wx91uDXgQq3+xlNHm1mfsUtvNQIw+nrASl66OJsTdPVzn2 H3iGcrsgeqTQIXf5zyl8ZzAL7kWqnGw+ZuOzQJv4Bvk4IFs1Pa146m6N6NCdMsfa9US0 eDHm4SDQZl+VaO9ydju/afQuolaPIVQ7OmKiF9KjRZFRC10l9UseteOmMs/hgqIDOcMq yqoDtwsJcdclUvPwyt1QUqb8i1PBPdkSMy5165CfwJTqwl51ih8h/J3v+im04cNWo9W2 YcUBJqckYP1wU4b1aqKL1NPtA++B0mCvY0lapaLiUl1c0W8QRaVurGZmI12wd13jz2eu kcog== X-Received: by 10.229.191.2 with SMTP id dk2mr44731482qcb.8.1410209166208; Mon, 08 Sep 2014 13:46:06 -0700 (PDT) Received: from [10.201.0.64] ([209.29.74.150]) by mx.google.com with ESMTPSA id r7sm1244815qai.15.2014.09.08.13.46.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 13:46:05 -0700 (PDT) Message-ID: <540E158D.70904@gmail.com> Date: Mon, 08 Sep 2014 23:46:05 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Ofbizcf3N40RsRxr9pXrTTcUATQ Subject: [DMM] A need for further interim calls? 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, 08 Sep 2014 20:46:08 -0000 Folks, Just asking whether you are willing to have additional interim calls in addition to the two that have already been allocated? Eventually we would reach the point when we can have a discussion on specific solutions.. - Jouni & Dapeng From nobody Mon Sep 8 13:49:57 2014 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 5DD901A03A0 for ; Mon, 8 Sep 2014 13:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 xqhkNjnEhQtT for ; Mon, 8 Sep 2014 13:49:54 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7DF1A0398 for ; Mon, 8 Sep 2014 13:49:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s88Knr7N020215; Mon, 8 Sep 2014 15:49:53 -0500 Received: from XCH-BLV-408.nw.nos.boeing.com (xch-blv-408.nw.nos.boeing.com [130.247.25.166]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s88KnpLP020190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 8 Sep 2014 15:49:52 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-408.nw.nos.boeing.com ([169.254.8.96]) with mapi id 14.03.0181.006; Mon, 8 Sep 2014 13:49:51 -0700 From: "Templin, Fred L" To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] A need for further interim calls? Thread-Index: AQHPy6X9kTGs7DK78UqrVe4pQZNw5pv3tRzA Date: Mon, 8 Sep 2014 20:49:50 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D12464@XCH-BLV-504.nw.nos.boeing.com> References: <540E158D.70904@gmail.com> In-Reply-To: <540E158D.70904@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: http://mailarchive.ietf.org/arch/msg/dmm/pg3iBCCiJhhhwnah4PcChauZ54g Subject: Re: [DMM] A need for further interim calls? 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, 08 Sep 2014 20:49:56 -0000 > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Monday, September 08, 2014 1:46 PM > To: dmm@ietf.org > Subject: [DMM] A need for further interim calls? >=20 > Folks, >=20 > Just asking whether you are willing to have additional interim calls in > addition to the two that have already been allocated? OK for me. > Eventually we would reach the point when we can have a discussion on > specific solutions.. Thanks - Fred fred.l.templin@boeing.com =20 > - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue Sep 9 02:04:59 2014 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 A4DEB1A8947 for ; Tue, 9 Sep 2014 02:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6hbLfy18_7Kz for ; Tue, 9 Sep 2014 02:04:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9336A1A8997 for ; Tue, 9 Sep 2014 02:04:53 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 145072DC1A2; Tue, 9 Sep 2014 11:04:49 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D94EF35C045; Tue, 9 Sep 2014 11:04:45 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 11:04:45 +0200 From: To: Charlie Perkins , "MONGAZON-CAZAVET, BRUNO (BRUNO)" , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPyCj0MdIqtvBNWkSYPugqaAf9A5vyGpeAgACMPgCABAuxgIAAtkQAgAEfhKA= Date: Tue, 9 Sep 2014 09:04:45 +0000 Message-ID: <16516_1410253485_540EC2AD_16516_3647_1_81C77F07008CA24F9783A98CFD706F711429C413@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <53D17F75.3030207@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409EE9A.1020700@earthlink.net> <540D5367.2000403@alcatel-lucent.com> <540DEC4C.5030409@earthlink.net> In-Reply-To: <540DEC4C.5030409@earthlink.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.9.70020 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/jhHrC5Gjl5BSEdUq_n9AX46ILY0 Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 09:04:58 -0000 Hi, I second Charlie on this proposal, especially on the need for additional MN= ID and tunnel types. Another example for the latter is: using GRE with MIP/= NEMO. BR, Pierrick >-----Message d'origine----- >De=A0: dmm [mailto:dmm-bounces@ietf.org] De la part de Charlie Perkins >Envoy=E9=A0: lundi 8 septembre 2014 19:50 >=C0=A0: MONGAZON-CAZAVET, BRUNO (BRUNO); dmm@ietf.org >Objet=A0: Re: [DMM] regarding the re-chartering.. > > >Hello folks, > >I'll go look for the link(s). But in the meantime, as part of the ongoing >maintenance work, I'd be happy to see the following: > >- Additional tunnel types (including GTP) >- Additional mobile node identifier types (including IMSI, MAC, ...) >- Additional security mechanisms > >If there is a sliver of a chance that we could go down any one or more of = these >paths, I will resurrect the old Internet drafts as well. If people are int= erested, I >will re-submit them for the November meeting. > >There are two or three other things that Mobile IP needs also, that take m= ore >words to express, but not necessarily directly related to distributed mobi= lity >management. Much of my development had to do with trying to provide an >easier / incremental path for the deployment of Mobile IP by SDO partners = in >3GPP, which would necessitate inclusion in their standards, which (for >instance) seems to necessitate GTP as a tunneling protocol, etc. > >Regards, >Charlie P. > > > >On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote: >> On 05/09/2014 19:10, Charlie Perkins wrote: >>> >>> Hello folks, >>> >>> I have made various presentations at IETF, some from many years ago, >>> proposing that Mobile IP enable use of GTP as a tunneling option. I >>> still think that would be a good idea. Should I re-re-revive a draft >>> stating this in more detail? >> >> I would be interested to look at this draft. >> Thanks. >> Bruno >> >>> >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 9/5/2014 1:48 AM, Alper Yegin wrote: >>>> Alex, >>>> >>>> DMM is not meant to be only about a bunch of MIP-based solutions. >>>> There are various components in DMM solution space that'd also work >>>> with GTP-based architectures. >>>> For example, identifying the mobility needs of flows. >>>> Or, conveying the mobility characteristic of a prefix to the UE. >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: >>>> >>>>> Le 03/09/2014 20:53, Brian Haberman a =E9crit : >>>>>> Behcet, >>>>>> >>>>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>>>>> You don't seem to understand my points. >>>>>> That is quite possible. Your comment on the list was "I am >>>>>> against any deployment work before we decide on a solution..." >>>>>> >>>>>> I read that as an objection to having the deployment models work >>>>>> item on the agenda. Please do tell me what I am missing. >>>>>> >>>>>> Regards, >>>>>> Brian >>>>> Hi, >>>>> >>>>> I am following the discussion and me too I do not quite understand >>>>> what is the complain. >>>>> >>>>> I am happy to learn that a if a WG is to be formed then it would be >>>>> around a solution rather than just requirements or architecture. >>>>> >>>>> That said, I would like to express a worry along similar lines. >>>>> >>>>> In DMM, precedents and the keen NETEXT, there seems to be a >>>>> hard-rooted disconnect between the product developped - (P)Mobile >>>>> IP - and the deployments. We know for a fact that 3GPP deployments >>>>> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs >>>>> do mention Mobile IP. To such a point that I wonder whether 3GPP >>>>> has not the same disconnect as here. >>>>> >>>>> On another hand, we do have indications of where (P)Mobile IP is >>>>> used - the trials, the projects, the kernel code, and not least the >>>>> slideware attracting real customers. >>>>> >>>>> The worry: develop DMM protocol while continuing the disconnect. >>>>> >>>>> Alex >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Sep 9 07:08:18 2014 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 0F6DA1A02EC for ; Tue, 9 Sep 2014 07:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 FXsxKmMo0KuW for ; Tue, 9 Sep 2014 07:07:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465F81A6F9D for ; Tue, 9 Sep 2014 07:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55808; q=dns/txt; s=iport; t=1410271566; x=1411481166; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=jpEYTX4/a20cesJyjdXh48kOKz5VrPMfUzLIVJxuclc=; b=ecQ0UKaY6TMnu4w5In4VNMNMrUuY5DlZiirYQeuk5ymYVM/hNXRzupD1 zKQpYO0iuxwuHjdyAacIKKrFmXE94/qTFPv+iHnsN6WdxMzLr0zir8MU0 AUneaNX5iE3cTZUOwgkGGfdjDzd/+ailelIkw/Da8ymj6NQuvI33ANBlL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8KAJ4ID1StJA2L/2dsb2JhbABZgkdGU1cEhBSBRL0GgjaFCAEJh0wBgQ0WeIQDAQEBBAEBAWQHAxoBCBEBAgECDhMBBi4LFAMGCAIEARIJEognDbxCAReBQ40oEQE/DAELBoMFgUEFinqEMoIVizKVLoFIghlsAQEBgQw5gQcBAQE X-IronPort-AV: E=Sophos; i="5.04,491,1406592000"; d="scan'208,217"; a="76292863" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP; 09 Sep 2014 14:06:03 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s89E63Cu011586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 14:06:03 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 09:06:03 -0500 From: "Sri Gundavelli (sgundave)" To: "pierrick.seite@orange.com" , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzDcwFTJi/s504kOP81QcxzozOA== Date: Tue, 9 Sep 2014 14:06:02 +0000 Message-ID: In-Reply-To: <16516_1410253485_540EC2AD_16516_3647_1_81C77F07008CA24F9783A98CFD706F711429C413@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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.217] Content-Type: multipart/alternative; boundary="_000_D03453581625DCsgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/o-FLED15soqceu7OmiPkcQTve8c Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 14:07:56 -0000 --_000_D03453581625DCsgundaveciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support the extension to MN Id type. I talked to few people (Yokota-san, = Jouni ..) on this in the past and below is the explanation. Currently, the= NAI that is carried in the PBU does not distinguish a IMSI based NAI, gene= ric-NAI and a MAc-based NAI. Email below. Regarding supporting GTP-U as a tunnel type, I'm not to keen on that. If th= e tunnel type is GTP-U, there is no reason for the SDO to use a different s= ignaling protocol, it can be GTP-C. That battle is over, I'd rather focus o= n pushing SDN approaches than trying to supporting GTP-U types in IETF mobi= lity protocols. But, if some one wants to do this, I'll not argue against t= his. Sri From: Sri Gundavelli > Date: Thursday, February 28, 2013 11:57 AM To: Hidetoshi Yokota > Subject: NAI Support over Gx Hi Yokota-san: We need a new sub-type to differentiate between NAI (user@realm) vs., IMSI-= NAI. Can we define new sub-types to Mobile Node Identifier option ? Value [http://www.iana.org/assignments/_support/sort_none.gif] Description= [http://www.iana.org/assignments/_support/sort_none.gif] Reference [htt= p://www.iana.org/assignments/_support/sort_none.gif] 1 NAI [RFC4283] 2 USER-NAI (user@realm, should not be used for IM= SI-NAI) 3 MAC-48 Goal is to address the issue below. Any comments ? --- 1. If MAG sends a PBU which includes IMSI: MN NAI Mobility Option Follows: Type: 0x08 Length: 0x36 Sub Type: 0x01 NAI: 1724052800014033@nai.epc.mnc05.mccxxx.3gppnetwork.org= The LMA will trigger the PCRF using the following AVP in the Gx CCR-I: [M] Subscription-Id: [M] Subscription-Id-Type: END_USER_IMSI (1) [M] Subscription-Id-Data: 724052800014033 2. If MAG sends a PBU which includes MSISDN: Vendor Specific Mobility Option Follows: Type: 0x13 Length: 0x0C Vendor ID: 0x000028AF Sub Type: 0x0C (MSISDN) Fragment (M) Flag: 0x00 MSISDN: <552176297602> Then, the LMA will trigger the PCRF using the following AVP in the Gx CCR-I= : [M] Subscription-Id: [M] Subscription-Id-Type: END_USER_E164 (0) [M] Subscription-Id-Data: 552176297602 3. If the MAG sends a PBU with Username: MN NAI Mobility Option Follows: Type: 0x08 Length: 0x2C Sub Type: 0x01 NAI: xxx1@nai.epc.mnc05.mccxxx.3gppnetwork.org Then, How can LMA trigger the PCRF with this following AVP ?: [M] Subscription-Id: [M] Subscription-Id-Type: END_USER_NAI (3) [M] Subscription-Id-Data: xxx1@nai.epc.mnc05.mccxxx.3gppnetwork.o= rg On 9/9/14 2:04 AM, "pierrick.seite@orange.com" > wrote: Hi, I second Charlie on this proposal, especially on the need for additional MN= ID and tunnel types. Another example for the latter is: using GRE with MIP/= NEMO. BR, Pierrick -----Message d'origine----- De : dmm [mailto:dmm-bounces@ietf.org] De la part de Charlie Perkins Envoy=E9 : lundi 8 septembre 2014 19:50 =C0 : MONGAZON-CAZAVET, BRUNO (BRUNO); dmm@ietf.org Objet : Re: [DMM] regarding the re-chartering.. Hello folks, I'll go look for the link(s). But in the meantime, as part of the ongoing maintenance work, I'd be happy to see the following: - Additional tunnel types (including GTP) - Additional mobile node identifier types (including IMSI, MAC, ...) - Additional security mechanisms If there is a sliver of a chance that we could go down any one or more of t= hese paths, I will resurrect the old Internet drafts as well. If people are inte= rested, I will re-submit them for the November meeting. There are two or three other things that Mobile IP needs also, that take mo= re words to express, but not necessarily directly related to distributed mobil= ity management. Much of my development had to do with trying to provide an easier / incremental path for the deployment of Mobile IP by SDO partners i= n 3GPP, which would necessitate inclusion in their standards, which (for instance) seems to necessitate GTP as a tunneling protocol, etc. Regards, Charlie P. On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote: On 05/09/2014 19:10, Charlie Perkins wrote: Hello folks, I have made various presentations at IETF, some from many years ago, proposing that Mobile IP enable use of GTP as a tunneling option. I still think that would be a good idea. Should I re-re-revive a draft stating this in more detail? I would be interested to look at this draft. Thanks. Bruno Regards, Charlie P. On 9/5/2014 1:48 AM, Alper Yegin wrote: Alex, DMM is not meant to be only about a bunch of MIP-based solutions. There are various components in DMM solution space that'd also work with GTP-based architectures. For example, identifying the mobility needs of flows. Or, conveying the mobility characteristic of a prefix to the UE. Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: Le 03/09/2014 20:53, Brian Haberman a =E9crit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was "I am against any deployment work before we decide on a solution..." I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex _______________________________________________ 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 _______________________________________________ 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. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_D03453581625DCsgundaveciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5F24B43E7E95D74298299C553ED5C359@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I support the extension to MN Id type. I talked to few people (Yokota-= san, Jouni ..)  on this in the past and below is the explanation. Curr= ently, the NAI that is carried in the PBU does not distinguish a IMSI based= NAI, generic-NAI and a MAc-based NAI. Email below.

Regarding supporting GTP-U as a tunnel type, I'm not to keen on that. = If the tunnel type is GTP-U, there is no reason for the SDO to use a differ= ent signaling protocol, it can be GTP-C. That battle is over, I'd rath= er focus on pushing SDN approaches than trying to supporting GTP-U types in IETF mobility protocols. But, if some = one wants to do this, I'll not argue against this.
 

Sri



From: Sri Gundavelli <sgundave@cisco.com>
Date: Thursday, February 28= , 2013 11:57 AM
To: Hidetoshi Yokota <yokota@kddilabs.jp>
Subject: NAI Support over G= x

Hi Yokota-san:


We need a new sub-type to differentiate between NAI (user@realm) vs., IMSI-= NAI. Can we define new sub-types to Mobile Node Identifier option ?


Value  Description  Reference 
1 NAI [RFC4283]
               2     &nbs= p;      USER-NAI (user@realm, should not be used for IMSI-NA= I)
               3     &nbs= p;      MAC-48


Goal is to address the issue below. 

Any comments ?



---

1. If MAG sends a PBU which includes IMSI:

 

MN NAI Mobility Option Follows:

            &n= bsp;   Type: 0x08

            &n= bsp; Length: 0x36

            Sub Typ= e: 0x01

          = ;       NAI: 1724052800014033@nai.epc.mnc05.mccxxx.3gppnetwork.or= g

 

The LMA will trigger the PCRF using the following AVP in = the Gx CCR-I:

 

        [M] Subsc= ription-Id:

          [M] Subscripti= on-Id-Type: END_USER_IMSI (1)

          [M] Subscription-Id= -Data: 724052800014033

 





2. If MAG sends a PBU which includes MSISDN:

 

Vendor Specific Mobility Option Follows:

            &n= bsp;   Type: 0x13

            &n= bsp; Length: 0x0C

           Vendor ID: 0x= 000028AF

            Sub Typ= e: 0x0C (MSISDN)

   Fragment (M) Flag: 0x00

            &n= bsp; MSISDN: <552176297602>

 

Then, the LMA will trigger the PCRF using the following A= VP in the Gx CCR-I:

 

        [M] Subsc= ription-Id:

          [M] Subscripti= on-Id-Type: END_USER_E164 (0)

          [M] Subscription-Id= -Data: 552176297602

 




3. If the MAG sends a PBU with Username:

 

MN NAI Mobility Option Follows:

            &n= bsp;   Type: 0x08

            &n= bsp; Length: 0x2C

&n= bsp;           Sub Type: = 0x01

          = ;       NAI: xxx1@nai.epc.mnc05.mccxxx.3gppnetwork.org

 

Then, How can LMA trigger the PCRF with this following AV= P ?:

 

        [M] Subsc= ription-Id:

          [M] Subscripti= on-Id-Type: END_USER_NAI (3)

          [M] Subscription-Id= -Data: xxx1@nai.epc.mnc05.mccx= xx.3gppnetwork.org

 




Hi,

I second Charlie on this proposal, especially on the need for addition= al MNID and tunnel types. Another example for the latter is: using GRE with= MIP/NEMO.

BR,
Pierrick

-----Message d'origine-----
De : dmm [mailto:dmm-boun= ces@ietf.org] De la part de Charlie Perkins
Envoy=E9 : lundi 8 septembre 2014 19:50
=C0 : MONGAZON-CAZAVET, BRUNO (BRUNO); dmm@ietf.org
Objet : Re: [DMM] regarding the re-chartering..


Hello folks,

I'll go look for the link(s).  But in the meantime, as part = of the ongoing
maintenance work, I'd be happy to see the following:

- Additional tunnel types (including GTP)
- Additional mobile node identifier types (including IMSI, MAC, ...)
- Additional security mechanisms

If there is a sliver of a chance that we could go down any one or more= of these
paths, I will resurrect the old Internet drafts as well. If people are= interested, I
will re-submit them for the November meeting.

There are two or three other things that Mobile IP needs also, that ta= ke more
words to express, but not necessarily directly related to distributed = mobility
management.  Much of my development had to do with trying to= provide an
easier / incremental path for the deployment of Mobile IP by SDO partn= ers in
3GPP, which would necessitate inclusion in their standards, which (for=
instance) seems to necessitate GTP as a tunneling protocol, etc.

Regards,
Charlie P.



On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote:
On 05/09/2014 19:10, Charlie Perkins wrote:

Hello folks,

I have made various presentations at IETF, some from many years ago,
proposing that Mobile IP enable use of GTP as a tunneling option. = ; I
still think that would be a good idea.  Should I re-re-reviv= e a draft
stating this in more detail?

I would be interested to look at this draft.
Thanks.
Bruno



Regards,
Charlie P.


On 9/5/2014 1:48 AM, Alper Yegin wrote:
Alex,

DMM is not meant to be only about a bunch of MIP-based solutions.
There are various components in DMM solution space that'd also work
with GTP-based architectures.
For example, identifying the mobility needs of flows.
Or, conveying the mobility characteristic of a prefix to the UE.

Alper




On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote:

Le 03/09/2014 20:53, Brian Haberman a =E9crit :
Behcet,

On 9/3/14 2:33 PM, Behcet Sarikaya wrote:
You don't seem to understand my points.
That is quite possible.  Your comment on the list was "= I am
against any deployment work before we decide on a solution..."

I read that as an objection to having the deployment models work
item on the agenda.  Please do tell me what I am missing.

Regards,
Brian
Hi,

I am following the discussion and me too I do not quite understand
what is the complain.

I am happy to learn that a if a WG is to be formed then it would be
around a solution rather than just requirements or architecture.

That said, I would like to express a worry along similar lines.

In DMM, precedents and the keen NETEXT, there seems to be a
hard-rooted disconnect between the product developped - (P)Mobile
IP - and the deployments.  We know for a fact that 3GPP depl= oyments
(2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP = specs
do mention Mobile IP. To such a point that I wonder whether 3GPP
has not the same disconnect as here.

On another hand, we do have indications of where (P)Mobile IP is
used - the trials, the projects, the kernel code, and not least the
slideware attracting real customers.

The worry: develop DMM protocol while continuing the disconnect.

Alex







_______________________________________________
dmm mailing list


_______________________________________________
dmm mailing list
_______________________________________________
dmm mailing list


_______________________________________________
dmm mailing list



_______________________________________________
dmm mailing list


_______________________________________________
dmm mailing list

______________________________________________________________________= ___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci.

This message and its attachments may contain confidential or privilege= d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<= /div>
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.

_______________________________________________
dmm mailing list

--_000_D03453581625DCsgundaveciscocom_-- From nobody Tue Sep 9 07:13:05 2014 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 B1BC01A6F9F for ; Tue, 9 Sep 2014 07:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.142 X-Spam-Level: X-Spam-Status: No, score=-16.142 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 YkMRZcG9LkXP for ; Tue, 9 Sep 2014 07:12:39 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8CC1A6FA1 for ; Tue, 9 Sep 2014 07:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66747; q=dns/txt; s=iport; t=1410271898; x=1411481498; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=S3+ZIw7hnzVt30OefM/AXcd7N3ffYWRI//44AAYqh8Y=; b=inZ/lEj4LhsPonEF+8X37xYoDnUt8Ja5mT4NicnjLFjTePiweLwwh5PF KBvJpjrHrgXmxiC/CXpAwzPdafeV6Gfe0kvnbPB5SBDIbswEorV2yzuiS ssGPc68UrAmQXuEniMSCIUn9oWfhrULMzbAQyNmjyHKahgIsEnxtlFCGJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkKAAcKD1StJV2Y/2dsb2JhbABZgkdGU1cEhBSBRK5LjjuCNoMqgV4BC4dKAYENFniEAwEBAQQBAQFkBwMaAQgRAQIBAg4TAQYuCxQDBggCBAESCRKIEwMRDbxAAReBQ4tdgUsQAgEtEQwBCwaDBYFBBYZLiGGCFYQwhwKBX5NPgUiCGWwBAQGBRYEHAQEB X-IronPort-AV: E=Sophos; i="5.04,491,1406592000"; d="scan'208,217"; a="76289045" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 09 Sep 2014 14:11:37 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s89EBb5x026511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 14:11:37 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 09:11:37 -0500 From: "Sri Gundavelli (sgundave)" To: "pierrick.seite@orange.com" , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzDf3FTJi/s504kOP81QcxzozOA== Date: Tue, 9 Sep 2014 14:11:36 +0000 Message-ID: In-Reply-To: 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.217] Content-Type: multipart/alternative; boundary="_000_D0345767162607sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/6KXdMWX64O-LD9Nxn6e0Iz6MtUU Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 14:12:52 -0000 --_000_D0345767162607sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is bit strange. Some thing changed in the IANA Mobile Node Identifier = pages. I assumed the MN Id was defined in RFC4283. How come I see a defini= tion in 5271 as well. Confused. Jouni / Brian =96 Any ideas ? Unless, I've been smoking =85 http://tools.ietf.org/html/rfc4283#page-3 http://tools.ietf.org/html/rfc5271#page-16 I remember this in the IANA pages. Unless, I edited this when I copied this= into a mail in Feb 2013. Value [http://www.iana.org/assignments/_support/sort_none.gif] Description= [http://www.iana.org/assignments/_support/sort_none.gif] Reference [htt= p://www.iana.org/assignments/_support/sort_none.gif] 1 NAI [RFC4283] 2 USER-NAI (user@realm, should not be used for IM= SI-NAI) 3 MAC-48 Now I see the following: Option-Code for Mobile Node Identifier Option (Type 30) Registration Procedure(s) Standards Action or IESG Approval Reference [RFC5271] Available Formats [http://www.iana.org/_img/icons/text-csv.png] CSV Value [http://www.iana.org/assignments/_support/sort_none.gif] Description= [http://www.iana.org/assignments/_support/sort_none.gif] Reference [htt= p://www.iana.org/assignments/_support/sort_none.gif] 0 Reserved [RFC5271] 1 NAI [RFC5271] 2 IMSI [RFC5271] 3-255 Unassigned From: Sri Gundavelli > Date: Tuesday, September 9, 2014 7:06 AM To: "pierrick.seite@orange.com" >, Charlie Perkins >, "dmm@ietf= .org" > Subject: Re: [DMM] regarding the re-chartering.. I support the extension to MN Id type. I talked to few people (Yokota-san, = Jouni ..) on this in the past and below is the explanation. Currently, the= NAI that is carried in the PBU does not distinguish a IMSI based NAI, gene= ric-NAI and a MAc-based NAI. Email below. Regarding supporting GTP-U as a tunnel type, I'm not to keen on that. If th= e tunnel type is GTP-U, there is no reason for the SDO to use a different s= ignaling protocol, it can be GTP-C. That battle is over, I'd rather focus o= n pushing SDN approaches than trying to supporting GTP-U types in IETF mobi= lity protocols. But, if some one wants to do this, I'll not argue against t= his. Sri From: Sri Gundavelli > Date: Thursday, February 28, 2013 11:57 AM To: Hidetoshi Yokota > Subject: NAI Support over Gx Hi Yokota-san: We need a new sub-type to differentiate between NAI (user@realm) vs., IMSI-= NAI. Can we define new sub-types to Mobile Node Identifier option ? Value [http://www.iana.org/assignments/_support/sort_none.gif] Description= [http://www.iana.org/assignments/_support/sort_none.gif] Reference [htt= p://www.iana.org/assignments/_support/sort_none.gif] 1 NAI [RFC4283] 2 USER-NAI (user@realm, should not be used for IM= SI-NAI) 3 MAC-48 Goal is to address the issue below. Any comments ? --- 1. If MAG sends a PBU which includes IMSI: MN NAI Mobility Option Follows: Type: 0x08 Length: 0x36 Sub Type: 0x01 NAI: 1724052800014033@nai.epc.mnc05.mccxxx.3gppnetwork.org= The LMA will trigger the PCRF using the following AVP in the Gx CCR-I: [M] Subscription-Id: [M] Subscription-Id-Type: END_USER_IMSI (1) [M] Subscription-Id-Data: 724052800014033 2. If MAG sends a PBU which includes MSISDN: Vendor Specific Mobility Option Follows: Type: 0x13 Length: 0x0C Vendor ID: 0x000028AF Sub Type: 0x0C (MSISDN) Fragment (M) Flag: 0x00 MSISDN: <552176297602> Then, the LMA will trigger the PCRF using the following AVP in the Gx CCR-I= : [M] Subscription-Id: [M] Subscription-Id-Type: END_USER_E164 (0) [M] Subscription-Id-Data: 552176297602 3. If the MAG sends a PBU with Username: MN NAI Mobility Option Follows: Type: 0x08 Length: 0x2C Sub Type: 0x01 NAI: xxx1@nai.epc.mnc05.mccxxx.3gppnetwork.org Then, How can LMA trigger the PCRF with this following AVP ?: [M] Subscription-Id: [M] Subscription-Id-Type: END_USER_NAI (3) [M] Subscription-Id-Data: xxx1@nai.epc.mnc05.mccxxx.3gppnetwork.o= rg On 9/9/14 2:04 AM, "pierrick.seite@orange.com" > wrote: Hi, I second Charlie on this proposal, especially on the need for additional MN= ID and tunnel types. Another example for the latter is: using GRE with MIP/= NEMO. BR, Pierrick -----Message d'origine----- De : dmm [mailto:dmm-bounces@ietf.org] De la part de Charlie Perkins Envoy=E9 : lundi 8 septembre 2014 19:50 =C0 : MONGAZON-CAZAVET, BRUNO (BRUNO); dmm@ietf.org Objet : Re: [DMM] regarding the re-chartering.. Hello folks, I'll go look for the link(s). But in the meantime, as part of the ongoing maintenance work, I'd be happy to see the following: - Additional tunnel types (including GTP) - Additional mobile node identifier types (including IMSI, MAC, ...) - Additional security mechanisms If there is a sliver of a chance that we could go down any one or more of t= hese paths, I will resurrect the old Internet drafts as well. If people are inte= rested, I will re-submit them for the November meeting. There are two or three other things that Mobile IP needs also, that take mo= re words to express, but not necessarily directly related to distributed mobil= ity management. Much of my development had to do with trying to provide an easier / incremental path for the deployment of Mobile IP by SDO partners i= n 3GPP, which would necessitate inclusion in their standards, which (for instance) seems to necessitate GTP as a tunneling protocol, etc. Regards, Charlie P. On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote: On 05/09/2014 19:10, Charlie Perkins wrote: Hello folks, I have made various presentations at IETF, some from many years ago, proposing that Mobile IP enable use of GTP as a tunneling option. I still think that would be a good idea. Should I re-re-revive a draft stating this in more detail? I would be interested to look at this draft. Thanks. Bruno Regards, Charlie P. On 9/5/2014 1:48 AM, Alper Yegin wrote: Alex, DMM is not meant to be only about a bunch of MIP-based solutions. There are various components in DMM solution space that'd also work with GTP-based architectures. For example, identifying the mobility needs of flows. Or, conveying the mobility characteristic of a prefix to the UE. Alper On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: Le 03/09/2014 20:53, Brian Haberman a =E9crit : Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was "I am against any deployment work before we decide on a solution..." I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian Hi, I am following the discussion and me too I do not quite understand what is the complain. I am happy to learn that a if a WG is to be formed then it would be around a solution rather than just requirements or architecture. That said, I would like to express a worry along similar lines. In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted disconnect between the product developped - (P)Mobile IP - and the deployments. We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs do mention Mobile IP. To such a point that I wonder whether 3GPP has not the same disconnect as here. On another hand, we do have indications of where (P)Mobile IP is used - the trials, the projects, the kernel code, and not least the slideware attracting real customers. The worry: develop DMM protocol while continuing the disconnect. Alex _______________________________________________ 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 _______________________________________________ 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. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_D0345767162607sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
This is bit strange. Some thing changed in the IANA Mobile Node Identi= fier pages.  I assumed the MN Id was defined in RFC4283. How come I se= e a definition in 5271 as well.


Confused. Jouni / Brian =96 Any ideas ? Unless, I've been smoking =85<= /div>






I remember this in the IANA pages. Unless, I edited this when I copied= this into a mail in Feb 2013.

Value  Description  Reference 
1 NAI [RFC4283]
               2     &nbs= p;      USER-NAI (user@realm, should not be used for IMSI-NA= I)
               3     &nbs= p;      MAC-48




Now I see the following:

Option-Code for Mobile Node Identifier Option (Type 30)

Registration Procedure(s) 
Standards Action or IESG Approval
Reference
[RFC= 5271]
Available Formats

CSV
Value Description Reference
0 Reserved [RFC5271]
1 NAI [RFC5271]
2 IMSI [RFC5271]
3-255 Unassigned




From: Sri Gundavelli <sgundave@cisco.com>
Date: Tuesday, September 9, 2014 7:= 06 AM
To: "pierrick.seite@orange.com" <pierrick.seite@orange.com>, Charlie Pe= rkins <charles.perkins@= earthlink.net>, "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] regarding the re= -chartering..

I support the extension to MN Id type. I talked to few people (Yokota-= san, Jouni ..)  on this in the past and below is the explanation. Curr= ently, the NAI that is carried in the PBU does not distinguish a IMSI based= NAI, generic-NAI and a MAc-based NAI. Email below.

Regarding supporting GTP-U as a tunnel type, I'm not to keen on that. = If the tunnel type is GTP-U, there is no reason for the SDO to use a differ= ent signaling protocol, it can be GTP-C. That battle is over, I'd rath= er focus on pushing SDN approaches than trying to supporting GTP-U types in IETF mobility protocols. But, if some = one wants to do this, I'll not argue against this.
 

Sri



From: Sri Gundavelli <sgundave@cisco.com>
Date: Thursday, February 28= , 2013 11:57 AM
To: Hidetoshi Yokota <yokota@kddilabs.jp>
Subject: NAI Support over G= x

Hi Yokota-san:


We need a new sub-type to differentiate between NAI (user@realm) vs., IMSI-= NAI. Can we define new sub-types to Mobile Node Identifier option ?


Value  Description  Reference 
1 NAI [RFC4283]
               2     &nbs= p;      USER-NAI (user@realm, should not be used for IMSI-NA= I)
               3     &nbs= p;      MAC-48


Goal is to address the issue below. 

Any comments ?



---

1. If MAG sends a PBU which includes IMSI:

 

MN NAI Mobility Option Follows:

            &n= bsp;   Type: 0x08

            &n= bsp; Length: 0x36

            Sub Typ= e: 0x01

          = ;       NAI: 1724052800014033@nai.epc.mnc05.mccxxx.3gppnetwork.or= g

 

The LMA will trigger the PCRF using the following AVP in = the Gx CCR-I:

 

        [M] Subsc= ription-Id:

          [M] Subscripti= on-Id-Type: END_USER_IMSI (1)

          [M] Subscription-Id= -Data: 724052800014033

 





2. If MAG sends a PBU which includes MSISDN:

 

Vendor Specific Mobility Option Follows:

            &n= bsp;   Type: 0x13

            &n= bsp; Length: 0x0C

           Vendor ID: 0x= 000028AF

            Sub Typ= e: 0x0C (MSISDN)

   Fragment (M) Flag: 0x00

            &n= bsp; MSISDN: <552176297602>

 

Then, the LMA will trigger the PCRF using the following A= VP in the Gx CCR-I:

 

        [M] Subsc= ription-Id:

          [M] Subscripti= on-Id-Type: END_USER_E164 (0)

          [M] Subscription-Id= -Data: 552176297602

 




3. If the MAG sends a PBU with Username:

 

MN NAI Mobility Option Follows:

            &n= bsp;   Type: 0x08

            &n= bsp; Length: 0x2C

&n= bsp;           Sub Type: = 0x01

          = ;       NAI: xxx1@nai.epc.mnc05.mccxxx.3gppnetwork.org

 

Then, How can LMA trigger the PCRF with this following AV= P ?:

 

        [M] Subsc= ription-Id:

          [M] Subscripti= on-Id-Type: END_USER_NAI (3)

          [M] Subscription-Id= -Data: xxx1@nai.epc.mnc05.mccx= xx.3gppnetwork.org

 




Hi,

I second Charlie on this proposal, especially on the need for addition= al MNID and tunnel types. Another example for the latter is: using GRE with= MIP/NEMO.

BR,
Pierrick

-----Message d'origine-----
De : dmm [mailto:dmm-boun= ces@ietf.org] De la part de Charlie Perkins
Envoy=E9 : lundi 8 septembre 2014 19:50
=C0 : MONGAZON-CAZAVET, BRUNO (BRUNO); dmm@ietf.org
Objet : Re: [DMM] regarding the re-chartering..


Hello folks,

I'll go look for the link(s).  But in the meantime, as part = of the ongoing
maintenance work, I'd be happy to see the following:

- Additional tunnel types (including GTP)
- Additional mobile node identifier types (including IMSI, MAC, ...)
- Additional security mechanisms

If there is a sliver of a chance that we could go down any one or more= of these
paths, I will resurrect the old Internet drafts as well. If people are= interested, I
will re-submit them for the November meeting.

There are two or three other things that Mobile IP needs also, that ta= ke more
words to express, but not necessarily directly related to distributed = mobility
management.  Much of my development had to do with trying to= provide an
easier / incremental path for the deployment of Mobile IP by SDO partn= ers in
3GPP, which would necessitate inclusion in their standards, which (for=
instance) seems to necessitate GTP as a tunneling protocol, etc.

Regards,
Charlie P.



On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote:
On 05/09/2014 19:10, Charlie Perkins wrote:

Hello folks,

I have made various presentations at IETF, some from many years ago,
proposing that Mobile IP enable use of GTP as a tunneling option. = ; I
still think that would be a good idea.  Should I re-re-reviv= e a draft
stating this in more detail?

I would be interested to look at this draft.
Thanks.
Bruno



Regards,
Charlie P.


On 9/5/2014 1:48 AM, Alper Yegin wrote:
Alex,

DMM is not meant to be only about a bunch of MIP-based solutions.
There are various components in DMM solution space that'd also work
with GTP-based architectures.
For example, identifying the mobility needs of flows.
Or, conveying the mobility characteristic of a prefix to the UE.

Alper




On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote:

Le 03/09/2014 20:53, Brian Haberman a =E9crit :
Behcet,

On 9/3/14 2:33 PM, Behcet Sarikaya wrote:
You don't seem to understand my points.
That is quite possible.  Your comment on the list was "= I am
against any deployment work before we decide on a solution..."

I read that as an objection to having the deployment models work
item on the agenda.  Please do tell me what I am missing.

Regards,
Brian
Hi,

I am following the discussion and me too I do not quite understand
what is the complain.

I am happy to learn that a if a WG is to be formed then it would be
around a solution rather than just requirements or architecture.

That said, I would like to express a worry along similar lines.

In DMM, precedents and the keen NETEXT, there seems to be a
hard-rooted disconnect between the product developped - (P)Mobile
IP - and the deployments.  We know for a fact that 3GPP depl= oyments
(2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP = specs
do mention Mobile IP. To such a point that I wonder whether 3GPP
has not the same disconnect as here.

On another hand, we do have indications of where (P)Mobile IP is
used - the trials, the projects, the kernel code, and not least the
slideware attracting real customers.

The worry: develop DMM protocol while continuing the disconnect.

Alex







_______________________________________________
dmm mailing list


_______________________________________________
dmm mailing list
_______________________________________________
dmm mailing list


_______________________________________________
dmm mailing list



_______________________________________________
dmm mailing list


_______________________________________________
dmm mailing list

______________________________________________________________________= ___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci.

This message and its attachments may contain confidential or privilege= d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<= /div>
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.

_______________________________________________
dmm mailing list

 --_000_D0345767162607sgundaveciscocom_-- From nobody Tue Sep 9 10:40:12 2014 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 98A031A02F1 for ; Tue, 9 Sep 2014 10:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Bo9TB6CCp6EQ for ; Tue, 9 Sep 2014 10:40:10 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04641A7004 for ; Tue, 9 Sep 2014 10:40:09 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-0a-540ee600d74d Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 08.39.05330.006EE045; Tue, 9 Sep 2014 13:35:29 +0200 (CEST) Received: from [142.133.113.41] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 9 Sep 2014 13:40:01 -0400 Message-ID: <540F3B69.7030109@ericsson.com> Date: Tue, 9 Sep 2014 13:39:53 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , "pierrick.seite@orange.com" , Charlie Perkins , "dmm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyuXRPuC7jM74Qg8kvWC3u37nGZnH/UY3F t2eOFgf/bGNzYPGY8nsjq8eqLxOYPZYs+cnk0fLsJFsASxSXTUpqTmZZapG+XQJXxszrsxkL zrBVnHuR3MC4kbWLkZNDQsBE4tOR6WwQtpjEhXvrgWwuDiGBo4wS566vBisSEtjKKDH/QhmI zSugLfFkdRsTiM0ioCKxdOUURhCbDWjQhp2fweKiAiESTa09bBD1ghInZz5hARkqInCQUeJI xzGwocICBhLTL59jgVhgILFn/QWwZk4BQ4nO9hnMXYwcHMwC9hIPtoLtZRaQl2jeOpsZolxT Yuua71APKEq8OP6TaQKj4Cwk62YhdM9C0r2AkXkVI0dpcWpZbrqRwSZGYNAek2DT3cG456Xl IUYBDkYlHt4HanwhQqyJZcWVuYcYpTlYlMR5Z9XOCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTB KdXAWPCRcaXIhZILb+NuRX0w2PP1Pvd2r9n9lU92PZauOGHcsL3NXGbnoYIDD/KeOV3ynmjT a51j+t3/aerkdb2xudWHp+R2b/u/1Jb714Wrl5/rb3PefEJPd9mi/+5pu2Q7pVPZxDedFjBt /KjwXCzGV6VNm/XDt/rJijynVq8ydGY3S3u4TmX5ZyWW4oxEQy3mouJEAKyL6Rs7AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_XtoRlCf9NhLSUN0NJq8iWL0kZM Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 17:40:11 -0000 Hi Sri, On 09/09/2014 10:11 AM, Sri Gundavelli (sgundave) wrote: > This is bit strange. Some thing changed in the IANA Mobile Node > Identifier pages. I assumed the MN Id was defined in RFC4283. How come > I see a definition in 5271 as well. > > > Confused. Jouni / Brian – Any ideas ? Unless, I've been smoking … No comments on that one :-). There are indeed two definitions of the MNID types. The one you originally saw is for the mobility option and is available in the mobility parameters registry http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml#mobility-parameters-5 The second one you saw is for the *ND option* to carry MNID from the ICMPv6 parameters registry http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5 Thanks Suresh From nobody Tue Sep 9 10:41:21 2014 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 EF5621A7003 for ; Tue, 9 Sep 2014 10:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 RYYPbtH35gQV for ; Tue, 9 Sep 2014 10:41:20 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50521A7004 for ; Tue, 9 Sep 2014 10:41:19 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-b6-540ee3e31677 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F5.3C.25146.3E3EE045; Tue, 9 Sep 2014 13:26:27 +0200 (CEST) Received: from [142.133.113.41] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 9 Sep 2014 13:41:18 -0400 Message-ID: <540F3BB9.1060503@ericsson.com> Date: Tue, 9 Sep 2014 13:41:13 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , "pierrick.seite@orange.com" , Charlie Perkins , "dmm@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyuXRPuO7jx3whBpdXa1rcv3ONzeL+oxqL b88cLQ7+2cbmwOIx5fdGVo9VXyYweyxZ8pPJo+XZSbYAligum5TUnMyy1CJ9uwSujEOzN7IX fGWq+Hl1A2MD4xKmLkZODgkBE4kVsz9A2WISF+6tZ+ti5OIQEjjKKPHm1B1mCGcro8TLn0cZ Qap4BbQldvXvA+tgEVCR2NRwiRXEZgOatGHnZ7C4qECIRFNrDxtEvaDEyZlPWEAGiQgcZJQ4 0nEMrEFYwEBi+uVzLCC2EJD9ZkE/M4jNKWAosWjFVqBBHBzMAvYSD7aWgYSZBeQltr+dwwxR rimxdc13VoirFSVeHP/JNIFRcBaSdbMQumch6V7AyLyKkaO0OLUsN93IcBMjMHCPSbA57mBc 8MnyEKMAB6MSD+8DNb4QIdbEsuLK3EOM0hwsSuK8mtXzgoUE0hNLUrNTUwtSi+KLSnNSiw8x MnFwSjUwet61K3V4UrMlPVl5lfHj07kZso7vc/Nuvz7lzPJoe6KN7tWQHY2nXe/7GSUd/r5x rurn63XdZwurxO8ZNmZb7dkSKC5q8sfA9I/UhoumS0Vsbpz/uzrxxcdj2SvvH9oWdPjqe4WN 5ou/2D0U/CV6vf2UuHluyP3Dx1JZvq5w6u9PlZry2/a2nhJLcUaioRZzUXEiAAUFrcE9AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/cTCJmcakQQfaQ54jaY25Ul6i0Ro Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 17:41:21 -0000 On 09/09/2014 10:06 AM, Sri Gundavelli (sgundave) wrote: > I support the extension to MN Id type. I talked to few people > (Yokota-san, Jouni ..) on this in the past and below is the > explanation. Currently, the NAI that is carried in the PBU does not > distinguish a IMSI based NAI, generic-NAI and a MAc-based NAI. Email below. +1 for this. Thanks Suresh From nobody Tue Sep 9 11:09:52 2014 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 E01A61A0659 for ; Tue, 9 Sep 2014 11:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 elL8FUBhPGlw for ; Tue, 9 Sep 2014 11:09:48 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE7F1A0489 for ; Tue, 9 Sep 2014 11:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1193; q=dns/txt; s=iport; t=1410286188; x=1411495788; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=MGyta18CckrjpBUB8YVB4zscWh5W5kVuwNb3VKyaE6E=; b=L7XFS4KWjhfl0EhyyDWQmY2aq2yM2ZfMRKT51o/fg5beZ6GJUeFnPEB+ inh4TGsn+Nby1Z9ve7WNarPq4xPwdpqQq93XbjgEsTMB3+CQCJT4WhHSd P7s8gCGw7UhKXEo4KjHik6D2++u1O+zA8xRLYEkJw/NRF4FqUxflZYIan I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAJVBD1StJA2B/2dsb2JhbABZgw1TVwTKKIdKAYENFniEAwEBAQMBfg0BCBhgJQIEARIJiDEIDb0eARePVIRMBZFBizKVLoNhbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,492,1406592000"; d="scan'208";a="353852403" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 09 Sep 2014 18:09:47 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s89I9lMp025215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 18:09:47 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 13:09:47 -0500 From: "Sri Gundavelli (sgundave)" To: Suresh Krishnan , "pierrick.seite@orange.com" , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzFk9FTJi/s504kOP81QcxzozOA== Date: Tue, 9 Sep 2014 18:09:46 +0000 Message-ID: In-Reply-To: <540F3B69.7030109@ericsson.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.217] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/aUSMff_o0MFVsMIDqZwdHhBr0Co Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 18:09:50 -0000 Hi Suresh, Thanks. That makes sense. Now, I remember that spec/update. The option name conflict and my search not finding 4283 references threw me off. Thanks. > No comments on that one :-) :) Regards Sri On 9/9/14 10:39 AM, "Suresh Krishnan" wrote: >Hi Sri, > >On 09/09/2014 10:11 AM, Sri Gundavelli (sgundave) wrote: >> This is bit strange. Some thing changed in the IANA Mobile Node >> Identifier pages. I assumed the MN Id was defined in RFC4283. How come >> I see a definition in 5271 as well. >> >> >> Confused. Jouni / Brian =AD Any ideas ? Unless, I've been smoking =8A > >No comments on that one :-). There are indeed two definitions of the >MNID types. > >The one you originally saw is for the mobility option and is available >in the mobility parameters registry > >http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xh >tml#mobility-parameters-5 > >The second one you saw is for the *ND option* to carry MNID from the >ICMPv6 parameters registry > >http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml# >icmpv6-parameters-5 > >Thanks >Suresh > From nobody Tue Sep 9 11:48:40 2014 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 8706D1A00FF for ; Tue, 9 Sep 2014 11:48:18 -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 nkgBf-9w44GU for ; Tue, 9 Sep 2014 11:48:17 -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 011A71A00FD for ; Tue, 9 Sep 2014 11:48:16 -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 AEEF5880D1 for ; Tue, 9 Sep 2014 11:48:16 -0700 (PDT) Received: from 1025210049.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7650671B0001 for ; Tue, 9 Sep 2014 11:48:16 -0700 (PDT) Message-ID: <540F4B81.4040408@innovationslab.net> Date: Tue, 09 Sep 2014 14:48:33 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dmm@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H5GifqKC5U2fWpX7cs9mBaqqaP1hDDSU1" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/xlHqie8EkOsuezCAG5JSKk6_tB8 Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 18:48:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H5GifqKC5U2fWpX7cs9mBaqqaP1hDDSU1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sri, On 9/9/14 2:09 PM, Sri Gundavelli (sgundave) wrote: > Hi Suresh, >=20 > Thanks. That makes sense. Now, I remember that spec/update. >=20 > The option name conflict and my search not finding 4283 references thre= w > me off. Thanks. >=20 If this is *really* confusing, it may be worth updating the name of one of them. Not sure if it is or not... Brian >=20 >> No comments on that one :-) >=20 >=20 > :) >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > On 9/9/14 10:39 AM, "Suresh Krishnan" wr= ote: >=20 >> Hi Sri, >> >> On 09/09/2014 10:11 AM, Sri Gundavelli (sgundave) wrote: >>> This is bit strange. Some thing changed in the IANA Mobile Node >>> Identifier pages. I assumed the MN Id was defined in RFC4283. How co= me >>> I see a definition in 5271 as well. >>> >>> >>> Confused. Jouni / Brian =AD Any ideas ? Unless, I've been smoking =8A= >> >> No comments on that one :-). There are indeed two definitions of the >> MNID types. >> >> The one you originally saw is for the mobility option and is available= >> in the mobility parameters registry >> >> http://www.iana.org/assignments/mobility-parameters/mobility-parameter= s.xh >> tml#mobility-parameters-5 >> >> The second one you saw is for the *ND option* to carry MNID from the >> ICMPv6 parameters registry >> >> http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xh= tml# >> icmpv6-parameters-5 >> >> Thanks >> Suresh >> >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 --H5GifqKC5U2fWpX7cs9mBaqqaP1hDDSU1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUD0uBAAoJEBOZRqCi7goqwqwH/2iWWlkNgBDF0KXo9SG9wlJm EEHEzEdmJkoDkVPY9Bxt/lm0+V3wUn5pm6vdpqSXQiKsLhgXiZhQVG1hlIaBH+4b 0eyeF+dXQM6jxUgRKzljf1ITPqmruvK6TowyDwFJwxhRXAIEicDodUOk7TiF5Cvc HpUmnxeH3kYCx6qN3SMYTOADmnbrVp0mpksKFOtMoHA05pAKBXyLfYACeisGU9vQ 52IoBUQ/qnlwxDcsCApO0GLYhFi4hqRgBVXWiFDPKVQKcpuV8Hb1ILyE+LiYDSve 64jZK2sUCF32CZxzYGK/ZdgySMqiJMxTX9n5teamGx7lNDj6ufQji4JyWdE5E6k= =5OwV -----END PGP SIGNATURE----- --H5GifqKC5U2fWpX7cs9mBaqqaP1hDDSU1-- From nobody Tue Sep 9 11:57:18 2014 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 E48B11A0013 for ; Tue, 9 Sep 2014 11:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 16FjeyL0S4d4 for ; Tue, 9 Sep 2014 11:56:59 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411D11A00C2 for ; Tue, 9 Sep 2014 11:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=776; q=dns/txt; s=iport; t=1410289019; x=1411498619; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=q+EaOe03YmfWmbNypB0GeaVDLCTEguCuNjPuApOd9Zo=; b=KvsKWqrMQOO2YWMWnMU8OhwHBSKyFK8FtfSwUVXtee1Cb5abMbXCzofo FJATYxjSWygaGY1Lhyw/oWz0PwiP+R4y1rIJuxRTn4rCs8mCqeHjYJn7S 8F+r5v+5bdTQAw9nDYfdTfjoYEeuAs5nhsKSEiQoZmsM8Xax/qPGP/OhG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAFhMD1StJV2T/2dsb2JhbABZgw2BKgTRcgGBDRZ4hAQBAQQ6UQEIGB5CJQIEARKIQr0xARePVIRMAQSRQYsylS6DYWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,492,1406592000"; d="scan'208";a="76384690" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP; 09 Sep 2014 18:56:58 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s89IuwCh006606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 18:56:58 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 13:56:58 -0500 From: "Sri Gundavelli (sgundave)" To: Brian Haberman , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzF/UFTJi/s504kOP81QcxzozOA== Date: Tue, 9 Sep 2014 18:56:58 +0000 Message-ID: In-Reply-To: <540F4B81.4040408@innovationslab.net> 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.217] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_i5TF6QhPh96HY78sOCaC9xDR1o Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 18:57:01 -0000 Hi Brian, It might worth adding a note in the IANA page. I will send a request to IANA. We refer to the "Mobile Node Identifier option" in all MIP/PMIP specs and the search from IANA page ends in the Mobile Node Identifier option defined for ICMP.=20 Regards Sri =20 On 9/9/14 11:48 AM, "Brian Haberman" wrote: >Sri, > >On 9/9/14 2:09 PM, Sri Gundavelli (sgundave) wrote: >> Hi Suresh, >>=20 >> Thanks. That makes sense. Now, I remember that spec/update. >>=20 >> The option name conflict and my search not finding 4283 references threw >> me off. Thanks. >>=20 > >If this is *really* confusing, it may be worth updating the name of one >of them. > >Not sure if it is or not... > >Brian > >>=20 >>> From nobody Tue Sep 9 13:28:23 2014 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 8F7B31A0174 for ; Tue, 9 Sep 2014 13:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 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, RP_MATCHES_RCVD=-1.652] 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 06Z_0WshQxT1 for ; Tue, 9 Sep 2014 13:28:17 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2541A0149 for ; Tue, 9 Sep 2014 13:28:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=DnA264t9dpi2ZHc/kXBVS3lfkMx6b7uXViYTmVRMH5dQxosoQcY7fpeQuMLN7etG; 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.255.215]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XRS1M-0003gO-4r; Tue, 09 Sep 2014 16:28:12 -0400 Message-ID: <540F62DA.906@earthlink.net> Date: Tue, 09 Sep 2014 13:28:10 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: pierrick.seite@orange.com, "MONGAZON-CAZAVET, BRUNO \(BRUNO\)" , dmm@ietf.org References: <53D17F75.3030207@gmail.com> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <5404BC3D.1000406@gmail.com> <5406A20F.60604@gmail.com> <5407422F.2010700@innovationslab.net> <54074DAB.9020801@innovationslab.net> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <5409EE9A.1020700@earthlink.net> <540D5367.2000403@alcatel-lucent.com> <540DEC4C.5030409@earthl ink.net> <16516_1410253485_540EC2AD_16516_3647_1_81C77F07008CA24F9783A98CFD706F711429C413@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <16516_1410253485_540EC2AD_16516_3647_1_81C77F07008CA24F9783A98CFD706F711429C413@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac77887a94d1543a591a4dd5f197ea6099c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/jg85kEraycTgwyj8RsAF2YXEMG8 Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 20:28:20 -0000 Hello folks, Here's the last Internet Draft that we did, long ago expired: http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt I'll resubmit it with a few updates as a personal draft to dmm. Regards, Charlie P. On 9/9/2014 2:04 AM, pierrick.seite@orange.com wrote: > Hi, > > I second Charlie on this proposal, especially on the need for additional MNID and tunnel types. Another example for the latter is: using GRE with MIP/NEMO. > > BR, > Pierrick > >> -----Message d'origine----- >> De : dmm [mailto:dmm-bounces@ietf.org] De la part de Charlie Perkins >> Envoyé : lundi 8 septembre 2014 19:50 >> À : MONGAZON-CAZAVET, BRUNO (BRUNO); dmm@ietf.org >> Objet : Re: [DMM] regarding the re-chartering.. >> >> >> Hello folks, >> >> I'll go look for the link(s). But in the meantime, as part of the ongoing >> maintenance work, I'd be happy to see the following: >> >> - Additional tunnel types (including GTP) >> - Additional mobile node identifier types (including IMSI, MAC, ...) >> - Additional security mechanisms >> >> If there is a sliver of a chance that we could go down any one or more of these >> paths, I will resurrect the old Internet drafts as well. If people are interested, I >> will re-submit them for the November meeting. >> >> There are two or three other things that Mobile IP needs also, that take more >> words to express, but not necessarily directly related to distributed mobility >> management. Much of my development had to do with trying to provide an >> easier / incremental path for the deployment of Mobile IP by SDO partners in >> 3GPP, which would necessitate inclusion in their standards, which (for >> instance) seems to necessitate GTP as a tunneling protocol, etc. >> >> Regards, >> Charlie P. >> >> >> >> On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote: >>> On 05/09/2014 19:10, Charlie Perkins wrote: >>>> Hello folks, >>>> >>>> I have made various presentations at IETF, some from many years ago, >>>> proposing that Mobile IP enable use of GTP as a tunneling option. I >>>> still think that would be a good idea. Should I re-re-revive a draft >>>> stating this in more detail? >>> I would be interested to look at this draft. >>> Thanks. >>> Bruno >>> >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> On 9/5/2014 1:48 AM, Alper Yegin wrote: >>>>> Alex, >>>>> >>>>> DMM is not meant to be only about a bunch of MIP-based solutions. >>>>> There are various components in DMM solution space that'd also work >>>>> with GTP-based architectures. >>>>> For example, identifying the mobility needs of flows. >>>>> Or, conveying the mobility characteristic of a prefix to the UE. >>>>> >>>>> Alper >>>>> >>>>> >>>>> >>>>> >>>>> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote: >>>>> >>>>>> Le 03/09/2014 20:53, Brian Haberman a écrit : >>>>>>> Behcet, >>>>>>> >>>>>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote: >>>>>>>> You don't seem to understand my points. >>>>>>> That is quite possible. Your comment on the list was "I am >>>>>>> against any deployment work before we decide on a solution..." >>>>>>> >>>>>>> I read that as an objection to having the deployment models work >>>>>>> item on the agenda. Please do tell me what I am missing. >>>>>>> >>>>>>> Regards, >>>>>>> Brian >>>>>> Hi, >>>>>> >>>>>> I am following the discussion and me too I do not quite understand >>>>>> what is the complain. >>>>>> >>>>>> I am happy to learn that a if a WG is to be formed then it would be >>>>>> around a solution rather than just requirements or architecture. >>>>>> >>>>>> That said, I would like to express a worry along similar lines. >>>>>> >>>>>> In DMM, precedents and the keen NETEXT, there seems to be a >>>>>> hard-rooted disconnect between the product developped - (P)Mobile >>>>>> IP - and the deployments. We know for a fact that 3GPP deployments >>>>>> (2G/3G/4G) do not use (P)Mobile IP. We also know that 3GPP specs >>>>>> do mention Mobile IP. To such a point that I wonder whether 3GPP >>>>>> has not the same disconnect as here. >>>>>> >>>>>> On another hand, we do have indications of where (P)Mobile IP is >>>>>> used - the trials, the projects, the kernel code, and not least the >>>>>> slideware attracting real customers. >>>>>> >>>>>> The worry: develop DMM protocol while continuing the disconnect. >>>>>> >>>>>> Alex >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > _________________________________________________________________________________________________________________________ > > 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. > > 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. > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Tue Sep 9 14:20:54 2014 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 CADED1A8549 for ; Tue, 9 Sep 2014 14:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 w_zTbgOSVdE1 for ; Tue, 9 Sep 2014 14:20:41 -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 D3FE91A0380 for ; Tue, 9 Sep 2014 14:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1919; q=dns/txt; s=iport; t=1410297639; x=1411507239; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XyMVBudL04nktoVRqBzYuJsxH6gy3WwKCSZaAreNiK0=; b=GN5IvLcHfc1/KN7YjV4sQA4oBwUnqVL2c82caf+8vzycFLQHlP1k8pnL EPqMbgkjZUzA7tw7KSF2VFJ/IAcHeCNdGVfbq7Kn8gzqRVOWu5nKO3T0N LlUV9faa1tKDgQ/LyNSae1r3/feTLfuAPz/PhBy+WAzcXZC8R7L0oy9Jo 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAFduD1StJV2Y/2dsb2JhbABZgw1TVwTKJodMAYENFniEBAIEOj8SAQgOKEIlAgQBDQUJiCUDEQ29LQEXjSCCLQeETAWGGosnizKVLoNhbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,493,1406592000"; d="scan'208";a="353966701" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 09 Sep 2014 21:20:39 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s89LKcem018054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 21:20:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 16:20:37 -0500 From: "Sri Gundavelli (sgundave)" To: Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzHPmFTJi/s504kOP81QcxzozOA== Date: Tue, 9 Sep 2014 21:20:37 +0000 Message-ID: In-Reply-To: <540F62DA.906@earthlink.net> 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.217] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/7KPQoQ_9IsWZ_ePivuoh6OIRUCQ Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 21:20:47 -0000 Hi Charlie, This is good. Thanks. 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 address, why do we need to two sub-types ? Why not have just one sub-type for mac based identifiers ? 2.) Sub type value (1) is currently used. Its currently overloaded for IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the definition of new sub-types, we need some text explaining the motivation 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is this ? Are these CGA-based IPv6 addresses ? New Mobile Node Identifier Types +-----------------+------------------------+ | Identifier Type | Identifier Type Number | +-----------------+------------------------+ | IPv6 Address | 2 | | | | | IMSI | 3 | | | | | P-TMSI | 4 | | | | | EUI-48 address | 5 | | | | | EUI-64 address | 6 | | | | | GUTI | 7 | +-----------------+------------------------+ Regards Sri PS: Good to see Vijay back On 9/9/14 1:28 PM, "Charlie Perkins" wrote: > >Hello folks, > >Here's the last Internet Draft that we did, long ago expired: >http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt > >I'll resubmit it with a few updates as a personal draft to dmm. > >Regards, >Charlie P. From nobody Tue Sep 9 14:30:40 2014 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 18AD41A0316 for ; Tue, 9 Sep 2014 14:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 OmSx4KtcgsSG for ; Tue, 9 Sep 2014 14:30:35 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BB11A88CD for ; Tue, 9 Sep 2014 14:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2565; q=dns/txt; s=iport; t=1410298230; x=1411507830; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=fnGHnOTTcxafk9qlyZahvXD6atQzZF3a2EIkkpjNyuk=; b=QzQM+YXIvGrMzpNgEUw2/SnwxuQyNej+x/3zqBKB9bi3xUMXZ6WK2ja8 nRcgBi4gZVjd7DeI0lq73HxODTTpM+SLJCKd5vC0guccEyQNu7V6Emd2H 8sQP8f1LdPj5P2dmt3CWWWlaJZAD71Ld23bcWaXqLqPOiHYDPSADsem6+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAABwD1StJA2K/2dsb2JhbABZgw1TTgkEyhwKh0wBgQ0WeIQEAQEEAQEBNzQLEgEINjcLJQIEAQ0FCYglAxENvTABF40ggi0HhEwFhhqJEoIVizKVLoNhbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,493,1406592000"; d="scan'208";a="76422221" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 09 Sep 2014 21:30:29 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s89LUTiP023029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Sep 2014 21:30:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 9 Sep 2014 16:30:29 -0500 From: "Sri Gundavelli (sgundave)" To: "Sri Gundavelli (sgundave)" , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzHVGFTJi/s504kOP81QcxzozOA== Date: Tue, 9 Sep 2014 21:30:28 +0000 Message-ID: In-Reply-To: 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.217] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/F0n6lIr3LIaYYbE5nMHX2ixQSDM Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 09 Sep 2014 21:30:39 -0000 Two more comments. 4.) I'd also use sub-type value of (2) for IMSI. Just to align with the sub-types defined for MN Id defined for ICMP. I suspect there are some implementations already using sub-type (2). Please see the other thread. 5.) For each of the sub-types, we need text including examples and some explanation on how they are used. Sri=20 On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" wrote: >Hi Charlie, > >This is good. Thanks. > > >1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 >address, why do we need to two sub-types ? Why not have just one sub-type >for mac based identifiers ? > >2.) Sub type value (1) is currently used. Its currently overloaded for >IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the >definition of new sub-types, we need some text explaining the motivation > >3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is this >? Are these CGA-based IPv6 addresses ? > > > > > New Mobile Node Identifier Types > > +-----------------+------------------------+ > | Identifier Type | Identifier Type Number | > +-----------------+------------------------+ > | IPv6 Address | 2 | > | | | > | IMSI | 3 | > | | | > | P-TMSI | 4 | > | | | > | EUI-48 address | 5 | > | | | > | EUI-64 address | 6 | > | | | > | GUTI | 7 | > +-----------------+------------------------+ > > > > > > > >Regards >Sri >PS: Good to see Vijay back > > >On 9/9/14 1:28 PM, "Charlie Perkins" >wrote: > >> >>Hello folks, >> >>Here's the last Internet Draft that we did, long ago expired: >>http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt >> >>I'll resubmit it with a few updates as a personal draft to dmm. >> >>Regards, >>Charlie P. > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 10 06:29:48 2014 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 782151A6FDD for ; Wed, 10 Sep 2014 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.254 X-Spam-Level: X-Spam-Status: No, score=-4.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-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 bFQaT_aE3657 for ; Wed, 10 Sep 2014 06:29:44 -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 18F341A00D7 for ; Wed, 10 Sep 2014 06:29:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 961D3107EA4; Wed, 10 Sep 2014 15:29:42 +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 UFIhIOqnfT3j; Wed, 10 Sep 2014 15:29:42 +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 7B28B107E9E; Wed, 10 Sep 2014 15:29:34 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.88]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 10 Sep 2014 15:29:33 +0200 From: Marco Liebsch To: "Sri Gundavelli (sgundave)" , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPp4lB4DM2zhzjQk2BPAsjwbgBU5u2760AgAE+DgCACXRoAIAMxHwAgAAPCACACYjsAIAT+UaAgAAUBoCAAHpbAIAAL/CAgAG1KoCAAI37gIAAvK4AgAACNICAAAWVAIAACByAgAAUmACAAAWVAIABAUAAgAF6iICAAIw+AIAEC7GAgAC2QwCAAP+QgIAAvvIAgAAOp4CAAALBAIABLIIQ Date: Wed, 10 Sep 2014 13:29:34 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D91A58AC3@DAPHNIS.office.hd> References: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 10 Sep 2014 13:29:46 -0000 It seems the MNID is somehow overloaded to carry both, node-specific IDs, e= .g. MAC, as well as subscriber IDs, which is the IMSI. There may be value in adding the IMEI to the list of possible types of node= -specific IDs.=20 marco >-----Original Message----- >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >(sgundave) >Sent: Dienstag, 9. September 2014 23:30 >To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org >Cc: Vijay Devarapalli >Subject: Re: [DMM] regarding the re-chartering.. > >Two more comments. > > > >4.) I'd also use sub-type value of (2) for IMSI. Just to align with the su= b-types >defined for MN Id defined for ICMP. I suspect there are some implementatio= ns >already using sub-type (2). Please see the other thread. > > >5.) For each of the sub-types, we need text including examples and some >explanation on how they are used. > > >Sri > > > >On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" wrote: > >>Hi Charlie, >> >>This is good. Thanks. >> >> >>1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 >>address, why do we need to two sub-types ? Why not have just one >>sub-type for mac based identifiers ? >> >>2.) Sub type value (1) is currently used. Its currently overloaded for >>IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the >>definition of new sub-types, we need some text explaining the >>motivation >> >>3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is >>this ? Are these CGA-based IPv6 addresses ? >> >> >> >> >> New Mobile Node Identifier Types >> >> +-----------------+------------------------+ >> | Identifier Type | Identifier Type Number | >> +-----------------+------------------------+ >> | IPv6 Address | 2 | >> | | | >> | IMSI | 3 | >> | | | >> | P-TMSI | 4 | >> | | | >> | EUI-48 address | 5 | >> | | | >> | EUI-64 address | 6 | >> | | | >> | GUTI | 7 | >> +-----------------+------------------------+ >> >> >> >> >> >> >> >>Regards >>Sri >>PS: Good to see Vijay back >> >> >>On 9/9/14 1:28 PM, "Charlie Perkins" >>wrote: >> >>> >>>Hello folks, >>> >>>Here's the last Internet Draft that we did, long ago expired: >>>http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt >>> >>>I'll resubmit it with a few updates as a personal draft to dmm. >>> >>>Regards, >>>Charlie P. >> >>_______________________________________________ >>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 Sep 10 07:51:52 2014 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 63D461A8766 for ; Wed, 10 Sep 2014 07:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 EimcOXz6OH9y for ; Wed, 10 Sep 2014 07:51:50 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F151A015D for ; Wed, 10 Sep 2014 07:51:50 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q108so1996302qgd.40 for ; Wed, 10 Sep 2014 07:51: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:cc:subject :content-type:content-transfer-encoding; bh=Rl+nlxC51PZxn3W/8pk85dlEmBgF4e+Wk4IjrFLTqKs=; b=YlxKYRYyXEL5t/ylsYpo3b94sfeAURy00qp81OaAqQxnmKqwPQLiMGWHVeXtgAXNkm VOVqdLhD75FmGPi9LYO7ivPsBhrTCE6NEquv7Qk1UedtW8jNtUiEYtIEPdywOKiadRHN 2tCX1ZjnkxPqE4RMtqsEmfoSp7YLIgnq/WZMsU6wSGkJf4s985mTYYjkzSOFRIjzj0oX jjmCeW/t5g9KP0nZoP8/drbAPi7LJGs1+bI+jNp9RnDujLZ36UQMokzlGB9bMt9b6p/a fPnndwGVYmCQGChtqGxdjCN3lmBcBYFUB+vkDU68xwOfD7gzSe+4/KKrfnpX2vsBfGRc hWjw== X-Received: by 10.140.104.213 with SMTP id a79mr60233800qgf.46.1410360709626; Wed, 10 Sep 2014 07:51:49 -0700 (PDT) Received: from [10.201.5.177] ([209.29.74.150]) by mx.google.com with ESMTPSA id d8sm12951561qam.46.2014.09.10.07.51.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 07:51:49 -0700 (PDT) Message-ID: <54106584.2030203@gmail.com> Date: Wed, 10 Sep 2014 17:51:48 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/WGeD3TP51cs2HzHAT2HnsiC-mk8 Cc: Dapeng Liu Subject: [DMM] qyery DMM interim call #3 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, 10 Sep 2014 14:51:51 -0000 Folks, Potential place for the interim call #3 would be: #3 30-Sep-2014 5PM EEST Unless there is heavy opposition, we'll go for this. - Jouni & Dapeng From nobody Wed Sep 10 08:11:56 2014 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 75C131A03F5 for ; Wed, 10 Sep 2014 08:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 wFQ6q3DkMfK3 for ; Wed, 10 Sep 2014 08:11:52 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A366D1A8725 for ; Wed, 10 Sep 2014 08:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4011; q=dns/txt; s=iport; t=1410361912; x=1411571512; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Y2jN6Y2XLJFhLRLHtLyImmDgYPPYmFIhrxbvrhc9rjo=; b=Zbpa85C+My+Whp61rDwS6qQn3EUy3abO6AH+evZhtwnb9zCJCnCuxvUT f/zbISCFt2lMgmf1SMt2Yjwpx1aJXEjePm9+n/EjO4c9+YUKtSnJX9jdX r+/nOYezCQnm9rUm/kbFQwSv2uqyurqbPGJVz7vZYpWex6IwMVlq7IVJJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAJZpEFStJA2D/2dsb2JhbABZgw1TVwTKNAqHTAGBEBZ4hAMBAQEEAQEBawsMBgEIEQQBASguCxQJCAIEAQ0FCYglAxENvioBF40gggIrBwaERgWGGoRghkeLMpUug2FsAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,499,1406592000"; d="scan'208";a="354111209" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP; 10 Sep 2014 15:11:52 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8AFBp7N014000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 15:11:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 10:11:51 -0500 From: "Sri Gundavelli (sgundave)" To: Marco Liebsch , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzQmMFTJi/s504kOP81QcxzozOA== Date: Wed, 10 Sep 2014 15:11:50 +0000 Message-ID: In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D91A58AC3@DAPHNIS.office.hd> 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.210] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <323F35006034C84DB6FE99D14D76D906@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/35nGFVzbCaLbH4jv4LNNT7FfBys Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 10 Sep 2014 15:11:54 -0000 Yes. Currently, the MNID is if the nai format and is overloaded. The MNID in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the IMSI. Ex: "@epc.mnc.mcc.3gppnetwork.org=B2 We also have MAC48@REALM; We also have approaches to transform MAC to Pseudo IMSI, and then carry IMSI-NAI as the MN-ID. So, we need unique sub-types for each of the types/sources. MN-Id based on IMSI, MSISDN, IMEI, MAC .. Also, do we need to distinguish between IMSI and IMSI-NAI ? Sri On 9/10/14 6:29 AM, "Marco Liebsch" wrote: >It seems the MNID is somehow overloaded to carry both, node-specific IDs, >e.g. MAC, as well as subscriber IDs, which is the IMSI. >There may be value in adding the IMEI to the list of possible types of >node-specific IDs. > >marco > >>-----Original Message----- >>From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >>(sgundave) >>Sent: Dienstag, 9. September 2014 23:30 >>To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org >>Cc: Vijay Devarapalli >>Subject: Re: [DMM] regarding the re-chartering.. >> >>Two more comments. >> >> >> >>4.) I'd also use sub-type value of (2) for IMSI. Just to align with the >>sub-types >>defined for MN Id defined for ICMP. I suspect there are some >>implementations >>already using sub-type (2). Please see the other thread. >> >> >>5.) For each of the sub-types, we need text including examples and some >>explanation on how they are used. >> >> >>Sri >> >> >> >>On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" >>wrote: >> >>>Hi Charlie, >>> >>>This is good. Thanks. >>> >>> >>>1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 >>>address, why do we need to two sub-types ? Why not have just one >>>sub-type for mac based identifiers ? >>> >>>2.) Sub type value (1) is currently used. Its currently overloaded for >>>IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the >>>definition of new sub-types, we need some text explaining the >>>motivation >>> >>>3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is >>>this ? Are these CGA-based IPv6 addresses ? >>> >>> >>> >>> >>> New Mobile Node Identifier Types >>> >>> +-----------------+------------------------+ >>> | Identifier Type | Identifier Type Number | >>> +-----------------+------------------------+ >>> | IPv6 Address | 2 | >>> | | | >>> | IMSI | 3 | >>> | | | >>> | P-TMSI | 4 | >>> | | | >>> | EUI-48 address | 5 | >>> | | | >>> | EUI-64 address | 6 | >>> | | | >>> | GUTI | 7 | >>> +-----------------+------------------------+ >>> >>> >>> >>> >>> >>> >>> >>>Regards >>>Sri >>>PS: Good to see Vijay back >>> >>> >>>On 9/9/14 1:28 PM, "Charlie Perkins" >>>wrote: >>> >>>> >>>>Hello folks, >>>> >>>>Here's the last Internet Draft that we did, long ago expired: >>>>http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt >>>> >>>>I'll resubmit it with a few updates as a personal draft to dmm. >>>> >>>>Regards, >>>>Charlie P. >>> >>>_______________________________________________ >>>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 Sep 10 10:41:29 2014 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 C55231A702F for ; Wed, 10 Sep 2014 10:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 jnO1uIfZd3NW for ; Wed, 10 Sep 2014 10:41:26 -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 82AE01A7028 for ; Wed, 10 Sep 2014 10:41:26 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0MSbFy-1XtMsd0OX6-00RZPM; Wed, 10 Sep 2014 19:39:00 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <54106584.2030203@gmail.com> Date: Wed, 10 Sep 2014 20:38:52 +0300 Content-Transfer-Encoding: 7bit Message-Id: <3AE602C1-2927-4999-8552-6BA5F03C2C35@yegin.org> References: <54106584.2030203@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:MZpJ5O4KrKEkUP3t9syF87WuZYyFXs2qNDjncRGBXfC FUKwIoXz9jeh8COruSq6uJbztsdODE+q/zRyJ2WlO4xulDZvzE r6+ZYfSYIFz1ObXn1zkM6y3HjSzFcUy2aQQWzJ7S2ipMNzlnB+ N18kNc9dtQQA9YrrE/Uu32t4hs3GLXGGQyXL0qZwY2u4Ls77Wg DxvU69qAIb+xbCkedEku7PPqjE/JYYNqrfZsJXqX5pFkhSzGqu liGpPOB3CrUUnhTn5pjShWI/4A/2PnYoY3keg9VlnN/aJ+9wNV snvNMIme/17s0AYa1lIdKQkYTVh7srs/EGokF8zHeCVDCzPoyf ss2aKcjUoUbIAnLwS7xSsIiTMxQfxYc3pwju3/n5ikILODXtbi g7BgmihJXYCpA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/I2NrSgmjYONEy8bH8j1bz0Pt1TI Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] qyery DMM interim call #3 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, 10 Sep 2014 17:41:27 -0000 Jouni, That date does not work for me. Alper On Sep 10, 2014, at 5:51 PM, Jouni Korhonen wrote: > Folks, > > Potential place for the interim call #3 would be: > #3 30-Sep-2014 5PM EEST > > Unless there is heavy opposition, we'll go for this. > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 10 10:42:30 2014 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 E160C1A7029 for ; Wed, 10 Sep 2014 10:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 kAk572C1rIft for ; Wed, 10 Sep 2014 10:42:27 -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 46E131A7025 for ; Wed, 10 Sep 2014 10:42:24 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus003) with ESMTP (Nemesis) id 0Lwp0Y-1YP8sM3gE4-016MKX; Wed, 10 Sep 2014 19:42:22 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <540E158D.70904@gmail.com> Date: Wed, 10 Sep 2014 20:42:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <540E158D.70904@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:/Mh3uwzwv30Du+MEGDOIenBIsr117mob7lEQGlyUkKZ 49e7Xm1kpzLGr6rDlllV5WjJ03DSDUkTrxYzjPD9VTbt7NXBAF ltIxaBcmnG47W2Ep+F15ZswboJFnVvwL29NlvvkM0HTffzptT+ uAvQ5jp4fdVXV8V/JsvbL9p9Pc6pBpRm5Y8QVR/yU6FsrCFuuH 99Ltg5EgbwGQNezlTHHdN2Bzt+uj1hJgm9Tt075oE3t9pKxmOK tXDLoxvRs/ELhhXV3v4+/I52svwSwH5mp5QqzOPJoqUvqLdalT 8IBS2MHC4rXGJEXf3pjOXz5GMh7BKyu/SLB4TL6yL7orC1oTXg /3hc5zeRRmzkauOAy34IVlBMK3lDrziycrMpwcXQ4LSYT03qZF mMrBDt82lpWeQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/4npbkWgynO13laWNSvJPOTXHSww Cc: "dmm@ietf.org" Subject: Re: [DMM] A need for further interim calls? 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, 10 Sep 2014 17:42:29 -0000 On Sep 8, 2014, at 11:46 PM, Jouni Korhonen wrote: > Folks, >=20 > Just asking whether you are willing to have additional interim calls = in addition to the two that have already been allocated? >=20 Yes, indeed! (I was even suggesting to have such calls even after IETF = 89. Better late than never.) > Eventually we would reach the point when we can have a discussion on = specific solutions.. >=20 Btw, what is the agenda for the upcoming call (Sep 16)? Alper > - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 10 11:02:57 2014 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 219001A701E for ; Wed, 10 Sep 2014 11:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 wq9oicLs5oJG for ; Wed, 10 Sep 2014 11:02:51 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E311A7026 for ; Wed, 10 Sep 2014 11:02:50 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id x13so6747771qcv.27 for ; Wed, 10 Sep 2014 11:02: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=d9pr8NjU/Xte60xBwIj8YjJMwrdMRTxOGFX1pkOMoOA=; b=XXH/R4O82m3r/nySwnl9tLO1T4jEIcjLKwBanYjgJ6z6RO/MH1CHWeJLs3FlZSVsUM mcP8s5mUuO65ZxFcABC6nuz7vN5+ooxJiNoUPLUGrFj58Ag4tViMBTj/tt/SCEETVQG7 A7/REbY11mEx2Wje6LAM7WVn5Pclch5FEY59Qd3/8yfJFzyyFA8HNDthZDLAbEW37dA5 uVfS3XlihF9vdQ7v7PVNYVVbf2qkGcjDFIhsVBE8bQ73RdmEV7lt8ljqQvJoHeLBeUsa IPUDS4vLZNSMza6HmmMbGTfsNIxjGZhmGT6YG53r1wAOukkxnkzhuYkNmz+oA8Sw5lYO Uv1Q== X-Received: by 10.224.161.140 with SMTP id r12mr63036969qax.74.1410372169660; Wed, 10 Sep 2014 11:02:49 -0700 (PDT) Received: from [10.201.5.177] ([209.29.74.150]) by mx.google.com with ESMTPSA id s102sm12837672qgd.44.2014.09.10.11.02.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 11:02:49 -0700 (PDT) Message-ID: <54109247.4090500@gmail.com> Date: Wed, 10 Sep 2014 21:02:47 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" References: <540E14EC.8070404@gmail.com> In-Reply-To: <540E14EC.8070404@gmail.com> X-Forwarded-Message-Id: <540E14EC.8070404@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/wQa78jbXVd-dRJoVew8xcBz1teQ Cc: Dapeng Liu Subject: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 18:02:56 -0000 It seems I sent this to a wrong receiver.. that explains why it did not appear on the list. - Jouni -------- Alkuperäinen viesti / Orig.Msg. -------- Aihe: DMM Interim call #2 - agenda forming Päiväys: Mon, 08 Sep 2014 23:43:24 +0300 Lähettäjä: Jouni Korhonen Vastaanottaja: dmm-ads@tools.ietf.org CC: jouni.nospam@gmail.com, Dapeng Liu Folks, The next interim is close. Assuming there are no overwhelming amount of comments to the re-charter text, we are ready to start setting up the work split on the solution space! Remember the discussion and the minutes from the IETF#90 Friday session. No other agenda items are planned for the next interim. - Jouni & Dapeng From nobody Wed Sep 10 11:04:21 2014 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 A05D51A7026 for ; Wed, 10 Sep 2014 11:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 iqHDPjPkLGGk for ; Wed, 10 Sep 2014 11:04:19 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A68C1A701E for ; Wed, 10 Sep 2014 11:04:19 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so1567058qcy.15 for ; Wed, 10 Sep 2014 11:04: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tF9T4YyLxyZx7iOPq1ajvhHAgPSen4aK+g/xj2KAcxI=; b=Fvls3bWUUIiuMlXyN0RhV42VHGnYNmSx5l6ram+PE886J3SSKE5PYvCGakMtXO88tV BqTn82ae55DUHDHFr1t/UcaNaRUsxtxJkiwdC6TpLpYt8NFf4bLz6kdxuOwnLOCfKrh0 ZHnZxmG3BL/LpSZEZk7BIcaIZcEfJUgSEeZXY1n3uWUpWIXYGw2E4CqLYOZ3HFNlYo6i yKOoTSv0Jd//9+B/r4fyb/ZepNIdH8O6APaG8OIKKokBwPa7m3ZXRwKBDSMGWZd+K6T1 f2Q5UZjSnQjteWxgJIhJUI5LEBiBntErcLTJGaDcKHbgnQk+z8UTpa3bbugE0Al1/Wbr OFGg== X-Received: by 10.140.82.213 with SMTP id h79mr18059491qgd.51.1410372258516; Wed, 10 Sep 2014 11:04:18 -0700 (PDT) Received: from [10.201.5.177] ([209.29.74.150]) by mx.google.com with ESMTPSA id i93sm12841735qgd.43.2014.09.10.11.04.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 11:04:18 -0700 (PDT) Message-ID: <5410929F.5040200@gmail.com> Date: Wed, 10 Sep 2014 21:04:15 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alper Yegin References: <540E158D.70904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/g-P0Ly_8H4ewU4ptVEYHuV937eQ Cc: "dmm@ietf.org" Subject: Re: [DMM] A need for further interim calls? 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, 10 Sep 2014 18:04:20 -0000 9/10/2014 8:42 PM, Alper Yegin kirjoitti: > > On Sep 8, 2014, at 11:46 PM, Jouni Korhonen wrote: > >> Folks, >> >> Just asking whether you are willing to have additional interim calls in addition to the two that have already been allocated? >> > > Yes, indeed! (I was even suggesting to have such calls even after IETF 89. Better late than never.) > >> Eventually we would reach the point when we can have a discussion on specific solutions.. >> > > Btw, what is the agenda for the upcoming call (Sep 16)? Hmm.. I sent the agenda out on 8th.. Need to check why it did not show up here. - Jouni > > Alper > > > > > > >> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > From nobody Wed Sep 10 11:06:59 2014 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 8F7A91A7D83 for ; Wed, 10 Sep 2014 11:06:50 -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 YVcEt04CIn7Y for ; Wed, 10 Sep 2014 11:06:44 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B108E1A7034 for ; Wed, 10 Sep 2014 11:06:41 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id z11so7731613lbi.40 for ; Wed, 10 Sep 2014 11:06:40 -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=pOnjt3yMFcRn+RDDI9nYjzYN8WuQZ264M0gtQ0R/bRI=; b=EA3WwlQ2fy5Uw99DK0tuF1H77spjJ4Xw2hH5qRBDHfe1HerGe4TNm3bAJFCOtut10L Uszcti4TZn4UgKowwlAZrR3Ck0oskCwAQ9QHKoZz5n0qK+8kHGlQ02wHuC2wd+TWBCx2 NC+fLvx7iEFXQJTCrlnFM11qA6l4msJ8dRdHTRxrkrOy7/FlgYGxMVyS1WwO43tSa6zV nIK/FI0KWYdWmptBxA+XVFe/2snzM9M3wo9hArh8iZUP36Vgo4m83K5oumpWPK68Nryg 8hE/G85U9RLsqpnL6urEqd/BFQG+XzJQBytgKDYUwm+72OwgD845LlA1WTY4xEnFsoSy 2HHw== MIME-Version: 1.0 X-Received: by 10.112.33.74 with SMTP id p10mr41086536lbi.0.1410372400010; Wed, 10 Sep 2014 11:06:40 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Wed, 10 Sep 2014 11:06:39 -0700 (PDT) In-Reply-To: <54109247.4090500@gmail.com> References: <540E14EC.8070404@gmail.com> <54109247.4090500@gmail.com> Date: Wed, 10 Sep 2014 13:06:39 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/F6lD35nZSLOhxK9vOQTRFc4_z5g Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 18:06:50 -0000 Jouni, why don't we cancel this one (#2) and do the next one (#3) with an agenda? I hope Alper can attend :-) Regards, Behcet On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen wr= ote: > > It seems I sent this to a wrong receiver.. that explains why it did not > appear on the list. > > - Jouni > > -------- Alkuper=C3=A4inen viesti / Orig.Msg. -------- > Aihe: DMM Interim call #2 - agenda forming > P=C3=A4iv=C3=A4ys: Mon, 08 Sep 2014 23:43:24 +0300 > L=C3=A4hett=C3=A4j=C3=A4: Jouni Korhonen > Vastaanottaja: dmm-ads@tools.ietf.org > CC: jouni.nospam@gmail.com, Dapeng Liu > > Folks, > > The next interim is close. Assuming there are no overwhelming amount of > comments to the re-charter text, we are ready to start setting up the > work split on the solution space! Remember the discussion and the > minutes from the IETF#90 Friday session. No other agenda items are > planned for the next interim. > > - Jouni & Dapeng > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 10 11:37:04 2014 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 324A91A7033 for ; Wed, 10 Sep 2014 11:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 fNAI91S7oMq1 for ; Wed, 10 Sep 2014 11:36:49 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5ED61A0066 for ; Wed, 10 Sep 2014 11:36:49 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x3so19942662qcv.16 for ; Wed, 10 Sep 2014 11:36:48 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IMqi9aK2usNkf3H/O0ImfCPMCgH0KofoUnk3bXfDiMs=; b=jy9JD+7NFxWvcseAkDhK3qrSOViKnP2W34IrxjSAi531iISC3ToTc+PHqI0t7LTpeE 039L/JF3WhS/zKD4145FrI4rb/eoRZoUCdUnYUobMjVVBIqyNyAFnDba7+oDn3MWdhbz lFqyxBiWAcGMCYUpTRHVYKUwlhRzGaPyXYUglh3e5ExDQt48379JtjEXmJeLCaveWfsV 3IoYtYqu8hLdQ9Y2VSk88/7p80TosBDbL1h6rHxqxpUp4j7VyOqCFkic9ffltsQkeEnJ tA7yzjJxsXlwZGeGkkt02fyzpBKVcQnxCRuKKkb9FG1ewn4IKyztfRQuH8sWyHdDy8Wr ggcg== X-Received: by 10.224.122.137 with SMTP id l9mr64277301qar.76.1410374208628; Wed, 10 Sep 2014 11:36:48 -0700 (PDT) Received: from [10.201.5.177] ([209.29.74.150]) by mx.google.com with ESMTPSA id l46sm12917950qgd.27.2014.09.10.11.36.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 11:36:47 -0700 (PDT) Message-ID: <54109A3E.7040007@gmail.com> Date: Wed, 10 Sep 2014 21:36:46 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <540E14EC.8070404@gmail.com> <54109247.4090500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/kvDQbcrAjEhkq1uz1ArzwiyvCq4 Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 18:36:53 -0000 What do you mean by no agenda? To me it clearly says we use the call #2 for setting up the work split. - Jouni 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: > Jouni, why don't we cancel this one (#2) and do the next one (#3) with > an agenda? > I hope Alper can attend :-) > > Regards, > > Behcet > > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen wrote: >> >> It seems I sent this to a wrong receiver.. that explains why it did not >> appear on the list. >> >> - Jouni >> >> -------- Alkuperäinen viesti / Orig.Msg. -------- >> Aihe: DMM Interim call #2 - agenda forming >> Päiväys: Mon, 08 Sep 2014 23:43:24 +0300 >> Lähettäjä: Jouni Korhonen >> Vastaanottaja: dmm-ads@tools.ietf.org >> CC: jouni.nospam@gmail.com, Dapeng Liu >> >> Folks, >> >> The next interim is close. Assuming there are no overwhelming amount of >> comments to the re-charter text, we are ready to start setting up the >> work split on the solution space! Remember the discussion and the >> minutes from the IETF#90 Friday session. No other agenda items are >> planned for the next interim. >> >> - Jouni & Dapeng >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 10 11:44:16 2014 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 D25111A86F0 for ; Wed, 10 Sep 2014 11:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 41oGO8mszUcw for ; Wed, 10 Sep 2014 11:44:12 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C238B1A86EB for ; Wed, 10 Sep 2014 11:44:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s8AIiCWG001215; Wed, 10 Sep 2014 13:44:12 -0500 Received: from XCH-BLV-403.nw.nos.boeing.com (xch-blv-403.nw.nos.boeing.com [130.247.25.62]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8AIi0YF000421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Sep 2014 13:44:01 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-403.nw.nos.boeing.com ([169.254.3.144]) with mapi id 14.03.0181.006; Wed, 10 Sep 2014 11:43:59 -0700 From: "Templin, Fred L" To: Jouni Korhonen , "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzSY685cNtlvM5kaPQ9fwALiOyZv6soAw Date: Wed, 10 Sep 2014 18:43:59 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D1590D@XCH-BLV-504.nw.nos.boeing.com> References: <540E14EC.8070404@gmail.com> <54109247.4090500@gmail.com> <54109A3E.7040007@gmail.com> In-Reply-To: <54109A3E.7040007@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: http://mailarchive.ietf.org/arch/msg/dmm/ECJ0lJ7DfMaWHzNfQQYuH1Rhi1Q Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 18:44:16 -0000 SGkgSm91bmksDQoNCkknZCBsaWtlIHRvIHByb3Bvc2UgYSBzbGlnaHRseSBkaWZmZXJlbnQgY2hh cnRlcjoNCg0KICAiQUVSTyBhbHJlYWR5IHNvbHZlcyBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5h Z2VtZW50IGFuZCBwcm92aWRlcyBhDQogICBhIGNvbXByZWhlbnNpdmUgbW9iaWxpdHkgc29sdXRp b24gZm9yIGFueSBtb2JpbGUgZGV2aWNlLiBBRVJPIHNob3VsZA0KICAgdGhlcmVmb3JlIGJlIGFw cHJvdmVkIGFzIHRoZSBtb2JpbGl0eSBtYW5hZ2VtZW50IHNvbHV0aW9uIGZvciBETU0uDQogICBQ dWJsaWNhdGlvbiBvZiBBRVJPIHdpbGwgdGhlcmVmb3JlIGNvbmNsdWRlIHRoZSB3b3JraW5nIGdy b3VwJ3MNCiAgIGFjdGl2aXR5LiINCg0KQ2FuIHdlIGhhdmUgdGhpcyBvbiB0aGUgYWdlbmRhPw0K DQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKb3VuaSBLb3Job25lbg0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRl bWJlciAxMCwgMjAxNCAxMTozNyBBTQ0KPiBUbzogc2FyaWtheWFAaWVlZS5vcmcNCj4gQ2M6IERh cGVuZyBMaXU7IGRtbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0RNTV0gRE1NIEludGVyaW0g Y2FsbCAjMiAtIGFnZW5kYSBmb3JtaW5nDQo+IA0KPiANCj4gV2hhdCBkbyB5b3UgbWVhbiBieSBu byBhZ2VuZGE/IFRvIG1lIGl0IGNsZWFybHkgc2F5cyB3ZSB1c2UgdGhlIGNhbGwgIzINCj4gZm9y IHNldHRpbmcgdXAgdGhlIHdvcmsgc3BsaXQuDQo+IA0KPiAtIEpvdW5pDQo+IA0KPiA5LzEwLzIw MTQgOTowNiBQTSwgQmVoY2V0IFNhcmlrYXlhIGtpcmpvaXR0aToNCj4gPiBKb3VuaSwgd2h5IGRv bid0IHdlIGNhbmNlbCB0aGlzIG9uZSAoIzIpIGFuZCBkbyB0aGUgbmV4dCBvbmUgKCMzKSB3aXRo DQo+ID4gYW4gYWdlbmRhPw0KPiA+IEkgaG9wZSBBbHBlciBjYW4gYXR0ZW5kIDotKQ0KPiA+DQo+ ID4gUmVnYXJkcywNCj4gPg0KPiA+IEJlaGNldA0KPiA+DQo+ID4gT24gV2VkLCBTZXAgMTAsIDIw MTQgYXQgMTowMiBQTSwgSm91bmkgS29yaG9uZW4gPGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+IHdy b3RlOg0KPiA+Pg0KPiA+PiBJdCBzZWVtcyBJIHNlbnQgdGhpcyB0byBhIHdyb25nIHJlY2VpdmVy Li4gdGhhdCBleHBsYWlucyB3aHkgaXQgZGlkIG5vdA0KPiA+PiBhcHBlYXIgb24gdGhlIGxpc3Qu DQo+ID4+DQo+ID4+IC0gSm91bmkNCj4gPj4NCj4gPj4gLS0tLS0tLS0gQWxrdXBlcsOkaW5lbiB2 aWVzdGkgLyBPcmlnLk1zZy4gLS0tLS0tLS0NCj4gPj4gQWloZTogRE1NIEludGVyaW0gY2FsbCAj MiAtIGFnZW5kYSBmb3JtaW5nDQo+ID4+IFDDpGl2w6R5czogTW9uLCAwOCBTZXAgMjAxNCAyMzo0 MzoyNCArMDMwMA0KPiA+PiBMw6RoZXR0w6Rqw6Q6IEpvdW5pIEtvcmhvbmVuIDxqb3VuaS5ub3Nw YW1AZ21haWwuY29tPg0KPiA+PiBWYXN0YWFub3R0YWphOiBkbW0tYWRzQHRvb2xzLmlldGYub3Jn DQo+ID4+IENDOiBqb3VuaS5ub3NwYW1AZ21haWwuY29tLCBEYXBlbmcgTGl1IDxsaXVkYXBlbmdA Y2hpbmFtb2JpbGUuY29tPg0KPiA+Pg0KPiA+PiBGb2xrcywNCj4gPj4NCj4gPj4gVGhlIG5leHQg aW50ZXJpbSBpcyBjbG9zZS4gQXNzdW1pbmcgdGhlcmUgYXJlIG5vIG92ZXJ3aGVsbWluZyBhbW91 bnQgb2YNCj4gPj4gY29tbWVudHMgdG8gdGhlIHJlLWNoYXJ0ZXIgdGV4dCwgd2UgYXJlIHJlYWR5 IHRvIHN0YXJ0IHNldHRpbmcgdXAgdGhlDQo+ID4+IHdvcmsgc3BsaXQgb24gdGhlIHNvbHV0aW9u IHNwYWNlISBSZW1lbWJlciB0aGUgZGlzY3Vzc2lvbiBhbmQgdGhlDQo+ID4+IG1pbnV0ZXMgZnJv bSB0aGUgSUVURiM5MCBGcmlkYXkgc2Vzc2lvbi4gTm8gb3RoZXIgYWdlbmRhIGl0ZW1zIGFyZQ0K PiA+PiBwbGFubmVkIGZvciB0aGUgbmV4dCBpbnRlcmltLg0KPiA+Pg0KPiA+PiAtIEpvdW5pICYg RGFwZW5nDQo+ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+IGRtbSBtYWlsaW5nIGxpc3QNCj4gPj4gZG1tQGlldGYub3Jn DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkbW0gbWFp bGluZyBsaXN0DQo+IGRtbUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RtbQ0K From nobody Wed Sep 10 12:04:37 2014 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 619821A0028 for ; Wed, 10 Sep 2014 12:04:36 -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 noXxeFazrv4l for ; Wed, 10 Sep 2014 12:04:35 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BF51A001E for ; Wed, 10 Sep 2014 12:04:34 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id u10so4910482lbd.29 for ; Wed, 10 Sep 2014 12:04: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:content-transfer-encoding; bh=kyZq4nA9gKAQVCvJhqp1Sh9CABgyBxTG9jP2kfkTKn8=; b=MTLPVMD9iyQVrBQQaofUeg/3prfbny2aRxwFl/42egU7Dar3zIjyA80E1VNOC6mZgV iiclgCZbgdgOBIc/PdO4ukFWVgcKe/8wWVx/OJvWBfzksXCGWfGYRwnhG7NCeRzELcHP TKTbt3rHZWG0s8yqFkKCLWzYlrmdKsjr+pm5TG5Zoc0lgUTkZ0/kakaUgA9e18/gSrNg 5tgYrXHftXiH6tqwMIUt6xomGitLMi6DwVdAcoG4j/Ahqc89KtSdr+7Oka9SJJJiP42E rcA3RZupSfdIpyYGrU7tccTDtfVJE2vcG//4EMCJFLogqszohe5Bujzk89FE9+Cqubqy rBTw== MIME-Version: 1.0 X-Received: by 10.152.37.72 with SMTP id w8mr17769603laj.48.1410375873080; Wed, 10 Sep 2014 12:04:33 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Wed, 10 Sep 2014 12:04:33 -0700 (PDT) In-Reply-To: <54109A3E.7040007@gmail.com> References: <540E14EC.8070404@gmail.com> <54109247.4090500@gmail.com> <54109A3E.7040007@gmail.com> Date: Wed, 10 Sep 2014 14:04:33 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Dcx8dR2VABgEMQLs_pI8xvXb8zc Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 19:04:36 -0000 This is what I saw in your mail: No other agenda items are planned for the next interim. On Wed, Sep 10, 2014 at 1:36 PM, Jouni Korhonen wr= ote: > > What do you mean by no agenda? To me it clearly says we use the call #2 f= or > setting up the work split. > > - Jouni > > 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: > >> Jouni, why don't we cancel this one (#2) and do the next one (#3) with >> an agenda? >> I hope Alper can attend :-) >> >> Regards, >> >> Behcet >> >> On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen >> wrote: >>> >>> >>> It seems I sent this to a wrong receiver.. that explains why it did not >>> appear on the list. >>> >>> - Jouni >>> >>> -------- Alkuper=C3=A4inen viesti / Orig.Msg. -------- >>> Aihe: DMM Interim call #2 - agenda forming >>> P=C3=A4iv=C3=A4ys: Mon, 08 Sep 2014 23:43:24 +0300 >>> L=C3=A4hett=C3=A4j=C3=A4: Jouni Korhonen >>> Vastaanottaja: dmm-ads@tools.ietf.org >>> CC: jouni.nospam@gmail.com, Dapeng Liu >>> >>> Folks, >>> >>> The next interim is close. Assuming there are no overwhelming amount of >>> comments to the re-charter text, we are ready to start setting up the >>> work split on the solution space! Remember the discussion and the >>> minutes from the IETF#90 Friday session. No other agenda items are >>> planned for the next interim. >>> >>> - Jouni & Dapeng >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 10 12:12:53 2014 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 3F7C91A014E for ; Wed, 10 Sep 2014 12:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 J92Jfx-HxHuN for ; Wed, 10 Sep 2014 12:12:49 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B721A001E for ; Wed, 10 Sep 2014 12:12:48 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id w7so19774804qcr.18 for ; Wed, 10 Sep 2014 12:12:48 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OOCf+5LMOHCnOSvnnJR0jnGSWhCHXkBCEcbvbT0RbEU=; b=fRtKOCJGMD4THtYQeAwvUvdsi5tcef6UuhIToQ3ZnZX46GkfiqKnc+ge4p8INnq2vP DKF23DMRrAaTNxXSxeNNqTCNVz+UmDM18Jfw2ks72yCNVkH/raJBCVXHXqhlDNulkIwA Bjoxx3cnzs8A2j1L/keQktUNBRvKML52UNXDvU+cIBr/75GpvLUBy+Jn26VRevMI8RBj g1dao6+CUrh/S5+90Sz6y4GeXmKZuBnOCmeglp6bofybWfq/REKj0WZahMaROn4PQj1x FLvPvXruK8JVHpNF0SFZSZTGTg3KjPR/Urw7h260aPCWwGLbBkxIHi2vvRRaJ9rVWVy6 LLKw== X-Received: by 10.224.120.138 with SMTP id d10mr57813232qar.8.1410376368151; Wed, 10 Sep 2014 12:12:48 -0700 (PDT) Received: from [10.201.5.177] ([209.29.74.150]) by mx.google.com with ESMTPSA id 75sm12991205qgg.25.2014.09.10.12.12.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 12:12:47 -0700 (PDT) Message-ID: <5410A2AE.7060602@gmail.com> Date: Wed, 10 Sep 2014 22:12:46 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , "sarikaya@ieee.org" References: <540E14EC.8070404@gmail.com> <54109247.4090500@gmail.com> <54109A3E.7040007@gmail.com> <2134F8430051B64F815C691A62D9831832D1590D@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D1590D@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/edwyk0CUIAgWmpzTASa_74g6nNo Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 19:12:51 -0000 Fred, We'll prioritize the work split we discussed in IETF90. If we have time left, we can look into other topics. - Jouni 9/10/2014 9:43 PM, Templin, Fred L kirjoitti: > Hi Jouni, > > I'd like to propose a slightly different charter: > > "AERO already solves distributed mobility management and provides a > a comprehensive mobility solution for any mobile device. AERO should > therefore be approved as the mobility management solution for DMM. > Publication of AERO will therefore conclude the working group's > activity." > > Can we have this on the agenda? > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Wednesday, September 10, 2014 11:37 AM >> To: sarikaya@ieee.org >> Cc: Dapeng Liu; dmm@ietf.org >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming >> >> >> What do you mean by no agenda? To me it clearly says we use the call #2 >> for setting up the work split. >> >> - Jouni >> >> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: >>> Jouni, why don't we cancel this one (#2) and do the next one (#3) with >>> an agenda? >>> I hope Alper can attend :-) >>> >>> Regards, >>> >>> Behcet >>> >>> On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen wrote: >>>> >>>> It seems I sent this to a wrong receiver.. that explains why it did not >>>> appear on the list. >>>> >>>> - Jouni >>>> >>>> -------- Alkuperäinen viesti / Orig.Msg. -------- >>>> Aihe: DMM Interim call #2 - agenda forming >>>> Päiväys: Mon, 08 Sep 2014 23:43:24 +0300 >>>> Lähettäjä: Jouni Korhonen >>>> Vastaanottaja: dmm-ads@tools.ietf.org >>>> CC: jouni.nospam@gmail.com, Dapeng Liu >>>> >>>> Folks, >>>> >>>> The next interim is close. Assuming there are no overwhelming amount of >>>> comments to the re-charter text, we are ready to start setting up the >>>> work split on the solution space! Remember the discussion and the >>>> minutes from the IETF#90 Friday session. No other agenda items are >>>> planned for the next interim. >>>> >>>> - 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 Sep 10 13:07:33 2014 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 1D64D1A87D6 for ; Wed, 10 Sep 2014 13:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 9txmz-mgsFLB for ; Wed, 10 Sep 2014 13:07:28 -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 B7C101A8762 for ; Wed, 10 Sep 2014 13:07:28 -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 s8AK7SBd031535; Wed, 10 Sep 2014 13:07:28 -0700 Received: from XCH-PHX-112.sw.nos.boeing.com (xch-phx-112.sw.nos.boeing.com [130.247.25.134]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8AK7Q2T031514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Sep 2014 13:07:26 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-PHX-112.sw.nos.boeing.com ([169.254.12.71]) with mapi id 14.03.0181.006; Wed, 10 Sep 2014 13:07:25 -0700 From: "Templin, Fred L" To: Jouni Korhonen , "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzSY685cNtlvM5kaPQ9fwALiOyZv6soAwgAB+9AD//5HpgA== Date: Wed, 10 Sep 2014 20:07:25 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D15B10@XCH-BLV-504.nw.nos.boeing.com> References: <540E14EC.8070404@gmail.com> <54109247.4090500@gmail.com> <54109A3E.7040007@gmail.com> <2134F8430051B64F815C691A62D9831832D1590D@XCH-BLV-504.nw.nos.boeing.com> <5410A2AE.7060602@gmail.com> In-Reply-To: <5410A2AE.7060602@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: http://mailarchive.ietf.org/arch/msg/dmm/IAMvV1BnC1V7_oOwLZxii5rLHPo Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 20:07:32 -0000 SGkgSm91bmksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm91bmkg S29yaG9uZW4gW21haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tXQ0KPiBTZW50OiBXZWRuZXNk YXksIFNlcHRlbWJlciAxMCwgMjAxNCAxMjoxMyBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMOyBz YXJpa2F5YUBpZWVlLm9yZw0KPiBDYzogRGFwZW5nIExpdTsgZG1tQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbRE1NXSBETU0gSW50ZXJpbSBjYWxsICMyIC0gYWdlbmRhIGZvcm1pbmcNCj4gDQo+ IEZyZWQsDQo+IA0KPiBXZSdsbCBwcmlvcml0aXplIHRoZSB3b3JrIHNwbGl0IHdlIGRpc2N1c3Nl ZCBpbiBJRVRGOTAuIElmIHdlIGhhdmUgdGltZQ0KPiBsZWZ0LCB3ZSBjYW4gbG9vayBpbnRvIG90 aGVyIHRvcGljcy4NCg0KV2VsbCwgbGV0J3MgZGlzY3VzcyB0aGlzIGZvciBhIG1vbWVudCB0aG91 Z2guIFdlIGhhdmUgYWxyZWFkeSBzZWVuDQpvbmUgY2FzZSBpbiB3aGljaCBBRVJPIGNhbiBiZSB1 c2VkIHdoZXJlIE1JUC1iYXNlZCBzb2x1dGlvbnMgYXJlDQpkZWZpY2llbnQsIGkuZS4sIGluIGVu dGVycHJpc2UgbmV0d29ya3MuIEJ1dCAiZW50ZXJwcmlzZSBuZXR3b3JrcyINCmNvdWxkIGVuY29t cGFzcyBhIHZlcnkgYnJvYWQgcmFuZ2Ugb2YgYXBwbGljYXRpb25zLCBpbmNsdWRpbmcgbm90DQpv bmx5IGNvcnBvcmF0ZSBlbnRlcnByaXNlcywgYnV0IGFsc28gYWNhZGVtaWMgY2FtcHVzZXMsIGFp ciB0cmFmZmljDQptYW5hZ2VtZW50IG5ldHdvcmtzLCBvcGVyYXRvciBuZXR3b3JrcywgSVNQIG5l dHdvcmtzLCBldGMuDQoNCkxpa2UgTUlQLCB0aGUgZGVmYXVsdCBtb2RlIG9mIG9wZXJhdGlvbiBm b3IgQUVSTyByZXF1aXJlcyBhIHBpZWNlDQpvZiBjcml0aWNhbCBpbmZyYXN0cnVjdHVyZS4gRm9y IE1JUCwgaXQgaXMgdGhlIEhvbWUgQWdlbnQuIEZvcg0KQUVSTywgaXQgaXMgdGhlIEFFUk8gU2Vy dmVyLg0KDQpBRkFJQ1QsIHRoZXJlZm9yZSwgYW4gQUVSTyBTZXJ2ZXIgY2FuIGJlIHBsYWNlZCBh bnl3aGVyZSBhIE1JUCBIb21lDQpBZ2VudCBjb3VsZCBiZSBwbGFjZWQuIEhlbmNlLCB0aGUgQUVS TyBzZXJ2aWNlIGNhbiBiZSBvZmZlcmVkIGluDQphbnkgZW52aXJvbm1lbnQgaW4gd2hpY2ggYSBN SVAgc2VydmljZSBjb3VsZCBiZSBvZmZlcmVkLg0KDQpTbyBsb29raW5nIGF0IHRoZSBzZXJ2aWNl cyB0aGF0IGFscmVhZHkgY29tZSBpbi1idWlsdCBpbiB0aGUgQUVSTyANCmFyY2hpdGVjdHVyZSAo ZGlzdHJpYnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVudCwgbW9iaWxlIG5ldHdvcmtzLA0Kcm91dGUg b3B0aW1pemF0aW9uLCBtb2JpbGUgVlBOLCBhY2NvbW1vZGF0aW9uIG9mIGFueSBJUCB2ZXJzaW9u LA0Kbm8ga2VybmVsIGNoYW5nZXMgbmVlZGVkLCBldGMuKSB0aGVyZSB3b3VsZCBzZWVtIHRvIGJl IHNvbWUNCnBvaW50cyBmb3IgY29tcGFyaXNvbiB0byBkaXNjdXNzIGJlZm9yZSBhIHNvbHV0aW9u IGlzIGNob3Nlbi4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0K DQoNCj4gLSBKb3VuaQ0KPiANCj4gOS8xMC8yMDE0IDk6NDMgUE0sIFRlbXBsaW4sIEZyZWQgTCBr aXJqb2l0dGk6DQo+ID4gSGkgSm91bmksDQo+ID4NCj4gPiBJJ2QgbGlrZSB0byBwcm9wb3NlIGEg c2xpZ2h0bHkgZGlmZmVyZW50IGNoYXJ0ZXI6DQo+ID4NCj4gPiAgICAiQUVSTyBhbHJlYWR5IHNv bHZlcyBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IGFuZCBwcm92aWRlcyBhDQo+ID4g ICAgIGEgY29tcHJlaGVuc2l2ZSBtb2JpbGl0eSBzb2x1dGlvbiBmb3IgYW55IG1vYmlsZSBkZXZp Y2UuIEFFUk8gc2hvdWxkDQo+ID4gICAgIHRoZXJlZm9yZSBiZSBhcHByb3ZlZCBhcyB0aGUgbW9i aWxpdHkgbWFuYWdlbWVudCBzb2x1dGlvbiBmb3IgRE1NLg0KPiA+ICAgICBQdWJsaWNhdGlvbiBv ZiBBRVJPIHdpbGwgdGhlcmVmb3JlIGNvbmNsdWRlIHRoZSB3b3JraW5nIGdyb3VwJ3MNCj4gPiAg ICAgYWN0aXZpdHkuIg0KPiA+DQo+ID4gQ2FuIHdlIGhhdmUgdGhpcyBvbiB0aGUgYWdlbmRhPw0K PiA+DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4g Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBkbW0gW21haWx0 bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvdW5pIEtvcmhvbmVuDQo+ID4+ IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE0IDExOjM3IEFNDQo+ID4+IFRvOiBz YXJpa2F5YUBpZWVlLm9yZw0KPiA+PiBDYzogRGFwZW5nIExpdTsgZG1tQGlldGYub3JnDQo+ID4+ IFN1YmplY3Q6IFJlOiBbRE1NXSBETU0gSW50ZXJpbSBjYWxsICMyIC0gYWdlbmRhIGZvcm1pbmcN Cj4gPj4NCj4gPj4NCj4gPj4gV2hhdCBkbyB5b3UgbWVhbiBieSBubyBhZ2VuZGE/IFRvIG1lIGl0 IGNsZWFybHkgc2F5cyB3ZSB1c2UgdGhlIGNhbGwgIzINCj4gPj4gZm9yIHNldHRpbmcgdXAgdGhl IHdvcmsgc3BsaXQuDQo+ID4+DQo+ID4+IC0gSm91bmkNCj4gPj4NCj4gPj4gOS8xMC8yMDE0IDk6 MDYgUE0sIEJlaGNldCBTYXJpa2F5YSBraXJqb2l0dGk6DQo+ID4+PiBKb3VuaSwgd2h5IGRvbid0 IHdlIGNhbmNlbCB0aGlzIG9uZSAoIzIpIGFuZCBkbyB0aGUgbmV4dCBvbmUgKCMzKSB3aXRoDQo+ ID4+PiBhbiBhZ2VuZGE/DQo+ID4+PiBJIGhvcGUgQWxwZXIgY2FuIGF0dGVuZCA6LSkNCj4gPj4+ DQo+ID4+PiBSZWdhcmRzLA0KPiA+Pj4NCj4gPj4+IEJlaGNldA0KPiA+Pj4NCj4gPj4+IE9uIFdl ZCwgU2VwIDEwLCAyMDE0IGF0IDE6MDIgUE0sIEpvdW5pIEtvcmhvbmVuIDxqb3VuaS5ub3NwYW1A Z21haWwuY29tPiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+IEl0IHNlZW1zIEkgc2VudCB0aGlzIHRv IGEgd3JvbmcgcmVjZWl2ZXIuLiB0aGF0IGV4cGxhaW5zIHdoeSBpdCBkaWQgbm90DQo+ID4+Pj4g YXBwZWFyIG9uIHRoZSBsaXN0Lg0KPiA+Pj4+DQo+ID4+Pj4gLSBKb3VuaQ0KPiA+Pj4+DQo+ID4+ Pj4gLS0tLS0tLS0gQWxrdXBlcsOkaW5lbiB2aWVzdGkgLyBPcmlnLk1zZy4gLS0tLS0tLS0NCj4g Pj4+PiBBaWhlOiBETU0gSW50ZXJpbSBjYWxsICMyIC0gYWdlbmRhIGZvcm1pbmcNCj4gPj4+PiBQ w6RpdsOkeXM6IE1vbiwgMDggU2VwIDIwMTQgMjM6NDM6MjQgKzAzMDANCj4gPj4+PiBMw6RoZXR0 w6Rqw6Q6IEpvdW5pIEtvcmhvbmVuIDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPg0KPiA+Pj4+IFZh c3RhYW5vdHRhamE6IGRtbS1hZHNAdG9vbHMuaWV0Zi5vcmcNCj4gPj4+PiBDQzogam91bmkubm9z cGFtQGdtYWlsLmNvbSwgRGFwZW5nIExpdSA8bGl1ZGFwZW5nQGNoaW5hbW9iaWxlLmNvbT4NCj4g Pj4+Pg0KPiA+Pj4+IEZvbGtzLA0KPiA+Pj4+DQo+ID4+Pj4gVGhlIG5leHQgaW50ZXJpbSBpcyBj bG9zZS4gQXNzdW1pbmcgdGhlcmUgYXJlIG5vIG92ZXJ3aGVsbWluZyBhbW91bnQgb2YNCj4gPj4+ PiBjb21tZW50cyB0byB0aGUgcmUtY2hhcnRlciB0ZXh0LCB3ZSBhcmUgcmVhZHkgdG8gc3RhcnQg c2V0dGluZyB1cCB0aGUNCj4gPj4+PiB3b3JrIHNwbGl0IG9uIHRoZSBzb2x1dGlvbiBzcGFjZSEg UmVtZW1iZXIgdGhlIGRpc2N1c3Npb24gYW5kIHRoZQ0KPiA+Pj4+IG1pbnV0ZXMgZnJvbSB0aGUg SUVURiM5MCBGcmlkYXkgc2Vzc2lvbi4gTm8gb3RoZXIgYWdlbmRhIGl0ZW1zIGFyZQ0KPiA+Pj4+ IHBsYW5uZWQgZm9yIHRoZSBuZXh0IGludGVyaW0uDQo+ID4+Pj4NCj4gPj4+PiAtIEpvdW5pICYg RGFwZW5nDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4gZG1tIG1haWxpbmcgbGlzdA0KPiA+Pj4+IGRt bUBpZXRmLm9yZw0KPiA+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG1tDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+IGRtbSBtYWlsaW5nIGxpc3QNCj4gPj4gZG1tQGlldGYub3JnDQo+ID4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo= From nobody Wed Sep 10 13:21:53 2014 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 77BD01A9143 for ; Wed, 10 Sep 2014 13:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.68 X-Spam-Level: X-Spam-Status: No, score=-4.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, URG_BIZ=0.573] 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 yIEXCUt7HOwL for ; Wed, 10 Sep 2014 13:21: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 0462A1A9138 for ; Wed, 10 Sep 2014 13:21: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 s8AKLmuh023413; Wed, 10 Sep 2014 15:21:48 -0500 Received: from XCH-BLV-303.nw.nos.boeing.com (xch-blv-303.nw.nos.boeing.com [130.247.25.215]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8AKLhXO023363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Sep 2014 15:21:44 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.55]) with mapi id 14.03.0181.006; Wed, 10 Sep 2014 13:21:41 -0700 From: "Templin, Fred L" To: Alper Yegin , Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] "A Day in the Life of an Enterprise Mobile Device User" Thread-Index: AQHPx5ViOP6F+udYnkWXmXXAiU79KZvw/mkAgAAy/oD//9kpQIAJzrUw Date: Wed, 10 Sep 2014 20:21:41 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D15B64@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D031C3@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D040CD@XCH-BLV-504.nw.nos.boeing.com> <4C4F8606-FBE7-4BAC-8F81-F1B63695357B@yegin.org> <540835D1.5080108@gmail.com> <2134F8430051B64F815C691A62D9831832D060C6@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D060C6@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/c3ppq3l-2_EZi4LiVDW5krDWWXo Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" 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, 10 Sep 2014 20:21:52 -0000 Hi Alper, > > > Can this scenario not be realized by simply placing an HA in the > > > enterprise network and using Mobile IP? You did not respond to say whether your question was answered. I think it is also fair to ask the opposite question: "Are there scenarios for MIP-based solutions that cannot be realized by simply placing an AERO Server in the network and using AERO?" Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Thursday, September 04, 2014 7:51 AM > To: Alexandru Petrescu; dmm@ietf.org > Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User= " >=20 > Hi Alex and Alper, >=20 > > -----Original Message----- > > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu > > Sent: Thursday, September 04, 2014 2:50 AM > > To: dmm@ietf.org > > Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device Us= er" > > > > Le 04/09/2014 08:47, Alper Yegin a =E9crit : > > > Hi Fred, > > > > > > Can this scenario not be realized by simply placing an HA in the > > > enterprise network and using Mobile IP? > > > > I guess yes and no. > > > > YEs, in that it is a typical Mobile IP scenario with handovers > > WiFi/4G/Ethernet. >=20 > Handovers between diverse access technologies is one aspect of the > proposal, yes. The ability to coordinate multiple access technologies > simultaneously is also included as part of the architecture, but some > future work needs to be done to put that into practice. >=20 > > No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not > > working well together. >=20 > Right - switching between VPN and non-VPN will be important for > enterprise network mobile device users. >=20 > > No, in that TIP (DHCPv6 Prefix Delegation?) is not clear how to work > > with a EUD device ID? Is it Ethernet's, WiFi's or 4G's interface MAC > > address? >=20 > The mobile device applies the TIP to its downstream-attached > interfaces and not to the access technology interfaces over > which the prefix delegation was received. So the mobile device > is really a mobile router. >=20 > But, maybe you are asking where does the mobile device get its > Device-Unique Identifier (DUID) so it can talk to the DHCPv6 > server? The DUID need not be based on a MAC address, but could > be some other unique ID assigned to the mobile. So, there is > no confusion about which MAC address to choose. >=20 > > No, in that Mobile IP and prefixes are not known to lead to optimal > > routes, whereas the scenario says "optimal routes". >=20 > Route optimization is indeed a key aspect of the proposal, and > in fact hard-coded into the name "AERO". Another key aspect is > the in-built distributed mobility management (dmm) architecture. > The enterprise can from day one deploy hundreds or even > thousands of AERO servers, and the mobile devices simply > associate with one or more that are close by. Beyond that, it > doesn't matter which server the mobile associates with - it > will get the same service as from any other server. >=20 > > No - but this is a stretch - the scenario does not mention the > > neceessity of user typing secure information on a screen (authenticate > > to web page on a public hotspot prior to ability to Mobile IP, or use > > One-Time Password tokens for VPN connections); any "seamless" mobility > > mechanism will need to automate this step; this is even more needed whe= n > > considering devices without user interfaces, such as Mobile Routers > > using Mobile IP for a vehicle. >=20 > Aspects of how the VPN link is established (enter password, > insert active badge, etc.) are not discussed, but not really > relevant to the way in which AERO can provide the mobile with > a stable TIP that never changes. Just that the faster the VPN > link can be established, the faster the mobile device can resume > service as if it were still coming in through an on-campus > enterprise network access link. >=20 > There is still more to this, such as how AERO can provide an > assured path MTU over the tunnel, etc. There should also be > an expanded use case analysis. I have been coming at this from > an enterprise network viewpoint, but as far as I know AERO > could also be applied in the traditional use cases envisioned > for MIPv6 and its derivatives. So, it would be good to have > some of the experts from this community examine the proposal > and provide a comparative analysis. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > Alex > > > > > > > > Alper > > > > > > > > > On Sep 3, 2014, at 7:37 PM, Templin, Fred L wrote: > > > > > >> Hi, > > >> > > >> The specific passage from the new draft that I wanted the wg to > > >> see is the following (with references to AERO removed). Please > > >> review and send questions or comments. > > >> > > >> Thanks - Fred fred.l.templin@boeing.com > > >> > > >> --- > > >> > > >> 3. A Day in the Life of an Enterprise Mobile Device User > > >> > > >> An enterprise network mobile device user ("Bill") begins his > > >> workday by seating his primary end user device (EUD) (e.g., a > > >> laptop computer, a tablet, a smart phone, etc.) in a docking > > >> station at his office desk and turning the device on. The docking > > >> station connects Bill's EUD to the enterprise wired LAN, and the > > >> EUD receives a Topologically-Fixed Address (TFA) from the > > >> infrastructure. Bill's EUD further discovers the DMM service > > >> within the enterprise network and requests a Topology Independent > > >> Prefix (TIP)delegation. Bill's EUD receives the same TIP > > >> delegation it gets every time it connects to the enterprise > > >> network, because the DMM service has an administratively set > > >> mapping between the TIP and Bill's EUD device ID. > > >> > > >> Bill's EUD can then access topologically-fixed enterprise services > > >> using its TFA directly, and can access DMM services by using an > > >> address from its TIP as the source address for tunneling over the > > >> enterprise network. As Bill's workday unfolds, his EUD uses the > > >> DMM service to correspond with other EUDs in peer-to-peer > > >> sessions, join lengthy virtual conferencing sessions, access > > >> enterprise fileshares, etc. The DMM service ensures that optimal > > >> routes are maintained so that tunneled communications flow over > > >> direct paths and network infrastructure elements are not > > >> unnecessarily over-burdened. > > >> > > >> While communications sessions such as the video conference are > > >> still in progress, Bill leaves the office to attend a meeting in a > > >> nearby conference room. He disconnects his EUD from the docking > > >> station and in the process drops his connection to the wired LAN. > > >> The EUD quickly enables a WiFi interface that searches for a > > >> Service Set Identifier (SSID) that can provide wireless access > > >> within the enterprise network. The EUD authenticates itself to > > >> the network via the SSID using its pre-loaded certificates, and > > >> uses a securing mechanism such as IEEE 802.1x to assure > > >> Confidentiality, Integrity and Availability (CIA). The EUD > > >> receives a new TFA from the network, then communicates its new > > >> TIP-to-TFA association to the DMM service and any active peer > > >> correspondents. Any ongoing communications sessions will continue > > >> to see the same (stable) TIP. > > >> > > >> Bill then leaves the enterprise campus to attend an off-site > > >> customer meeting with his EUD still powered on and actively > > >> seeking to maintain network connectivity. As Bill departs from > > >> the building, the WiFi signal fades until it can no longer support > > >> communications, and the EUD quickly enables a 4G cellular wireless > > >> interface that connects Bill's EUD to a cellular service provider. > > >> The EUD then locates the Internet address of an enterprise network > > >> security gateway and initiates a VPN session with the gateway > > >> (which also acts participates in the DMM service). The DMM > > >> service updates the routing system, and Bill can continue to use > > >> the same TIP that was assigned to his EUD when he started his > > >> workday even though the EUD is now communicating over a VPN > > >> configured over the public Internet instead of over the secured > > >> campus LAN. > > >> > > >> Bill subsequently arrives at the customer meeting at a public > > >> restaurant with a WiFi hotspot. His EUD quickly powers up its WiFi > > >> interface and powers down the 4G interface. The EUD uses DMM > > >> signaling to communicate the new TFA to the security gateway and > > >> the VPN survives the mobility event. Moreover, the EUD can > > >> continue to use the same TIP it received at the beginning of the > > >> workday, and ongoing communication sessions can continue until > > >> Bill explicitly discontinues them. > > >> > > >> After the customer meeting, Bill leaves the restaurant and > > >> subsequently passes through several additional transitions from > > >> WiFi hotspots to 4G wireless. Again, the DMM service keeps the VPN > > >> session alive, and the TIP assigned to the EUD remains in > > >> continuous use in active communication sessions as well as to > > >> allow Bill to receive notifications and process urgent requests. > > >> When Bill returns to his office, the EUD discontinues use of the > > >> VPN while keeping its TIP active after re-attaching to the campus > > >> LAN. > > >> > > >> Bill ends his workday, powers down his EUD and returns home. Bill > > >> powers on his EUD to check e-mails, and connects to the enterprise > > >> network via a VPN configured over his home ISP service. The EUD > > >> again receives the same TIP that it used within the enterprise > > >> network domain, and Bill can access DMM services the same as if he > > >> was in the office. Bill finally shuts down for the evening, and > > >> begins his next workday in the same fashion. Again, the EUD > > >> receives the same TIP as always regardless of the access network > > >> point of connection over which the EUD enters the enterprise. > > >> > > >>> -----Original Message----- From: dmm > > >>> [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: > > >>> Tuesday, September 02, 2014 11:05 AM To: dmm@ietf.org Subject: > > >>> [DMM] FW: I-D Action: draft-templin-aeroent-00.txt > > >>> > > >>> Hello, > > >>> > > >>> During the call today, there was some interest expressed in > > >>> learning more about the enterprise network mobility use case. I > > >>> have submitted a new brief document called "AERO Enterprise > > >>> Network Profile" (below) that provides a discussion of > > >>> distributed mobility management needs for enterprise networks. > > >>> Although the document specifically cites AERO, the use case > > >>> applies to any solution alternative that could meet the > > >>> requirements. Also, I am not asking this document be considered > > >>> as a dmm wg item at this time, but rather offering it for > > >>> informational purposes. Please let me know if there are any > > >>> questions or comments. > > >>> > > >>> Thanks - Fred fred.l.templin@boeing.com > > >>> > > >>> -----Original Message----- From: I-D-Announce > > >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > >>> internet-drafts@ietf.org Sent: Tuesday, September 02, 2014 10:51 > > >>> AM To: i-d-announce@ietf.org Subject: I-D Action: > > >>> draft-templin-aeroent-00.txt > > >>> > > >>> > > >>> A New Internet-Draft is available from the on-line > > >>> Internet-Drafts directories. > > >>> > > >>> > > >>> Title : AERO Enterprise Network Profile Author : Fred > > >>> L. Templin Filename : draft-templin-aeroent-00.txt Pages > > >>> : 12 Date : 2014-09-02 > > >>> > > >>> Abstract: Enterprise networks provide a secured data > > >>> communications infrastructure built for the purpose of > > >>> information sharing and increased productivity for end users > > >>> within the organization. Enterprise networks are often organized > > >>> as private Internets unto themselves that connect to the global > > >>> Internet either not at all or via firewalls, proxies, and/or > > >>> other network securing devices. This document discusses an AERO > > >>> enterprise network profile that outlines new and more flexible > > >>> methods for connecting, tracking and managing mobile > > >>> organizational assets. > > >>> > > >>> > > >>> The IETF datatracker status page for this draft is: > > >>> https://datatracker.ietf.org/doc/draft-templin-aeroent/ > > >>> > > >>> There's also a htmlized version available at: > > >>> http://tools.ietf.org/html/draft-templin-aeroent-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/ > > >>> > > >>> _______________________________________________ I-D-Announce > > >>> mailing list I-D-Announce@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/i-d-announce > > >>> Internet-Draft directories: http://www.ietf.org/shadow.html or > > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >>> > > >>> _______________________________________________ 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 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 10 14:51:54 2014 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 DB8221A0233; Wed, 10 Sep 2014 14:51:52 -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 gFP9Zc41tEUC; Wed, 10 Sep 2014 14:51:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E7E1A0205; Wed, 10 Sep 2014 14:51:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140910215151.10736.76308.idtracker@ietfa.amsl.com> Date: Wed, 10 Sep 2014 14:51:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/t2cZIA4d2gIVoaNSl67_sC6hK5E Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-best-practices-gap-analysis-07.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, 10 Sep 2014 21:51:53 -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 : Distributed Mobility Management: Current practices and gap analysis Authors : Dapeng Liu Juan Carlos Zuniga Pierrick Seite H Anthony Chan Carlos J. Bernardos Filename : draft-ietf-dmm-best-practices-gap-analysis-07.txt Pages : 30 Date : 2014-09-10 Abstract: This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-best-practices-gap-analysis-07 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 Sep 10 15:01:03 2014 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 956041A8896 for ; Wed, 10 Sep 2014 15:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.553 X-Spam-Level: X-Spam-Status: No, score=-15.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 kmVmhTJzyz7j for ; Wed, 10 Sep 2014 15:00:57 -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 759E21A029F for ; Wed, 10 Sep 2014 15:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=725; q=dns/txt; s=iport; t=1410386443; x=1411596043; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=q6jOi2lj5reHlFPqf3UYrTzDzbDMt3DOIvuMHkKLtcA=; b=l5Y0Hre0fW005Lfh3Yzj6YDBnokoL+MEXjk369HM8cblUDox0/MKEQ97 Qpdo1i0ZNQQVrNH8OeO7qVfIpY665K/w6B2zaaxg12mMkTCJQkovZIgWs J6b3+xY/YrHXP7OrrVk1BEc56gtwxXaOvdtrfny7WUobIXOxnpsN8pgSF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFANvIEFStJA2B/2dsb2JhbABggw2BLtBpgSMBgRIWeIQEAgQ6UQEINkIlAgQBEhkCiCe/TgEXj1SETAEEkUmLM5U5gW8WgVxsAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,501,1406592000"; d="scan'208";a="76803302" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 10 Sep 2014 22:00:43 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8AM0gIX003999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 22:00:42 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 17:00:42 -0500 From: "Sri Gundavelli (sgundave)" To: "Templin, Fred L" , Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] "A Day in the Life of an Enterprise Mobile Device User" Thread-Index: AQHPzUKqmhbfq3sPD02yUlQIPUOdKg== Date: Wed, 10 Sep 2014 22:00:42 +0000 Message-ID: In-Reply-To: <2134F8430051B64F815C691A62D9831832D060C6@XCH-BLV-504.nw.nos.boeing.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.210] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E23E41F3F4EE540B310BF92DC38DC16@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/dz7aQ4MgyQZcGYwRVhhmN6e-ebk Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" 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, 10 Sep 2014 22:01:00 -0000 Hi Fred, On 9/4/14 7:50 AM, "Templin, Fred L" wrote: >>No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not >>working well together. > >Right - switching between VPN and non-VPN will be important for >enterprise network mobile device users. I think Alex is referring to the DSMIP and IKEv2 interactions and I don't believe his point is about switching across VPN and non-VPN modes. FWIW, the 3GPP S2b interface allows a mobile node to perform handovers from 3GPP access (S5/S8) to non-3GPP access (S2b). There are other examples of Mobile VPN solutions that are deployed and are based on Mobile IP protocols. RFC5265 is only one example. Regards Sri From nobody Wed Sep 10 15:01:57 2014 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 D23B61A88A8 for ; Wed, 10 Sep 2014 15:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 tITUl6W_RL-k for ; Wed, 10 Sep 2014 15:01:52 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00B11A88A7 for ; Wed, 10 Sep 2014 15:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3136; q=dns/txt; s=iport; t=1410386512; x=1411596112; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LTWbmP7ZGRTn1QfrQMzaWbpCjDrhNj32qYOxanErYcE=; b=TU6Db9W34cYNYyCx7jcg81m5+5Dn3aaaHE+J60SBnZPnEP2Uas4G7jLc Z4ngkvooN8VcdVgOGYGT/EkCCk7wlmjaHRK8AD2ANNJvDdeKyuj15ucz+ twx0hKF8geVfchw+EXttPAh/0yNhSIFvLx+DhhSJSzhBgdwvM+9Nelc2d w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAPjIEFStJV2a/2dsb2JhbABWCoMNU1vKNQqHTQGBEhZ4hAMBAQEEAQEBCWILDAYBCBEEAQEBJygGCxQJCAIEAQ0FG4gTAxENuFINhmIBEwSNIIFRMSsHBoRGBYsAhkmJI4IQjnyGPYNhbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,501,1406592000"; d="scan'208";a="76803345" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 10 Sep 2014 22:01:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8AM1pVR010203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 22:01:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 17:01:51 -0500 From: "Sri Gundavelli (sgundave)" To: "Templin, Fred L" , Jouni Korhonen , "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzULS29YFnE+CEEGRXci0ZwBJmA== Date: Wed, 10 Sep 2014 22:01:50 +0000 Message-ID: In-Reply-To: <2134F8430051B64F815C691A62D9831832D1590D@XCH-BLV-504.nw.nos.boeing.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.210] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2F143561A8460143B3198B848D4CF2DF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/uOygbLRdyY6ny9jByP2_soeE2jU Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 22:01:55 -0000 Hi Fred, IMHO, DMM solution need to be tied to one specific protocol. We don't have to battle this out and come up with one answer. Once we have high-level view of the solution and the interfaces, its possible to realize those interfaces using any protocols. You call it MIP, GTP, Aero ..does not matter. The core specs can identify the interface requirements and the specific protocol documents can publish extensions to the protocols. We let the deployments make the call on the protocol choice. Regards Sri On 9/10/14 11:43 AM, "Templin, Fred L" wrote: >Hi Jouni, > >I'd like to propose a slightly different charter: > > "AERO already solves distributed mobility management and provides a > a comprehensive mobility solution for any mobile device. AERO should > therefore be approved as the mobility management solution for DMM. > Publication of AERO will therefore conclude the working group's > activity." > >Can we have this on the agenda? > >Thanks - Fred >fred.l.templin@boeing.com > >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Wednesday, September 10, 2014 11:37 AM >> To: sarikaya@ieee.org >> Cc: Dapeng Liu; dmm@ietf.org >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming >>=20 >>=20 >> What do you mean by no agenda? To me it clearly says we use the call #2 >> for setting up the work split. >>=20 >> - Jouni >>=20 >> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: >> > Jouni, why don't we cancel this one (#2) and do the next one (#3) with >> > an agenda? >> > I hope Alper can attend :-) >> > >> > Regards, >> > >> > Behcet >> > >> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen >> wrote: >> >> >> >> It seems I sent this to a wrong receiver.. that explains why it did >>not >> >> appear on the list. >> >> >> >> - Jouni >> >> >> >> -------- Alkuper=E4inen viesti / Orig.Msg. -------- >> >> Aihe: DMM Interim call #2 - agenda forming >> >> P=E4iv=E4ys: Mon, 08 Sep 2014 23:43:24 +0300 >> >> L=E4hett=E4j=E4: Jouni Korhonen >> >> Vastaanottaja: dmm-ads@tools.ietf.org >> >> CC: jouni.nospam@gmail.com, Dapeng Liu >> >> >> >> Folks, >> >> >> >> The next interim is close. Assuming there are no overwhelming amount >>of >> >> comments to the re-charter text, we are ready to start setting up the >> >> work split on the solution space! Remember the discussion and the >> >> minutes from the IETF#90 Friday session. No other agenda items are >> >> planned for the next interim. >> >> >> >> - Jouni & Dapeng >> >> >> >> >> >> _______________________________________________ >> >> 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 >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Sep 10 15:15:26 2014 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 33BE61A8896 for ; Wed, 10 Sep 2014 15:15:23 -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 uqryTlDc3qvc for ; Wed, 10 Sep 2014 15:15:21 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876CD1A6FB9 for ; Wed, 10 Sep 2014 15:15:21 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so11700978lbi.5 for ; Wed, 10 Sep 2014 15:15: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=IbNmnep/fvxPk8x2h1a3k0R7Xt/5/Xyb99HEhzhq+4Q=; b=r016thu0q9s9kJ4Xb3bP4C72K+J0KGxbOLFMxvSlO8GqTj8OJfr0I/inwG/odksX9s HeQSehCKV7aMewTdGVlV+Up6Zx2kREL2ju3pCORsAy/k//KkdQkYYp6KQHGjE/pd7yKc CHzv+i1pYUYIPKAwwAeRJ4xTc/SMN5jY0puqQk+4e5scMrV9ryVfscjcEIwXw6BkoAVK 8c92Nyl/JzKy6ugNVx5XtNJVcFD+WWAEcQRWWSF7tWYSEdG/FIS0KzNJTC91emzbw6dt QlRns9Vf/if4bGNPNr1vOVsSSkqDZgE37YmhZnkBQzWC7yh9MLAV/wFjVbymoqbTO2UJ TmFA== MIME-Version: 1.0 X-Received: by 10.112.14.199 with SMTP id r7mr42652973lbc.58.1410387319822; Wed, 10 Sep 2014 15:15:19 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Wed, 10 Sep 2014 15:15:19 -0700 (PDT) In-Reply-To: References: <2134F8430051B64F815C691A62D9831832D1590D@XCH-BLV-504.nw.nos.boeing.com> Date: Wed, 10 Sep 2014 17:15:19 -0500 Message-ID: From: Behcet Sarikaya To: "Sri Gundavelli (sgundave)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/oakZCVgLDGHebuVpOTSGJeN9tyU Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 22:15:23 -0000 Hi Sri, On Wed, Sep 10, 2014 at 5:01 PM, Sri Gundavelli (sgundave) wrote: > Hi Fred, > > > IMHO, DMM solution need to be tied to one specific protocol. We don't hav= e > to battle this out and come up with one answer. Once we have high-level > view of the solution and the interfaces, its possible to realize those > interfaces using any protocols. You call it MIP, GTP, Aero ..does not > matter. The core specs can identify the interface requirements and the > specific protocol documents can publish extensions to the protocols. We > let the deployments make the call on the protocol choice. > These are your views. Not mine for sure. Regards, Behcet > > > Regards > Sri > > > > > > On 9/10/14 11:43 AM, "Templin, Fred L" wrote: > >>Hi Jouni, >> >>I'd like to propose a slightly different charter: >> >> "AERO already solves distributed mobility management and provides a >> a comprehensive mobility solution for any mobile device. AERO should >> therefore be approved as the mobility management solution for DMM. >> Publication of AERO will therefore conclude the working group's >> activity." >> >>Can we have this on the agenda? >> >>Thanks - Fred >>fred.l.templin@boeing.com >> >>> -----Original Message----- >>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >>> Sent: Wednesday, September 10, 2014 11:37 AM >>> To: sarikaya@ieee.org >>> Cc: Dapeng Liu; dmm@ietf.org >>> Subject: Re: [DMM] DMM Interim call #2 - agenda forming >>> >>> >>> What do you mean by no agenda? To me it clearly says we use the call #2 >>> for setting up the work split. >>> >>> - Jouni >>> >>> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: >>> > Jouni, why don't we cancel this one (#2) and do the next one (#3) wit= h >>> > an agenda? >>> > I hope Alper can attend :-) >>> > >>> > Regards, >>> > >>> > Behcet >>> > >>> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen >>> wrote: >>> >> >>> >> It seems I sent this to a wrong receiver.. that explains why it did >>>not >>> >> appear on the list. >>> >> >>> >> - Jouni >>> >> >>> >> -------- Alkuper=C3=A4inen viesti / Orig.Msg. -------- >>> >> Aihe: DMM Interim call #2 - agenda forming >>> >> P=C3=A4iv=C3=A4ys: Mon, 08 Sep 2014 23:43:24 +0300 >>> >> L=C3=A4hett=C3=A4j=C3=A4: Jouni Korhonen >>> >> Vastaanottaja: dmm-ads@tools.ietf.org >>> >> CC: jouni.nospam@gmail.com, Dapeng Liu >>> >> >>> >> Folks, >>> >> >>> >> The next interim is close. Assuming there are no overwhelming amount >>>of >>> >> comments to the re-charter text, we are ready to start setting up th= e >>> >> work split on the solution space! Remember the discussion and the >>> >> minutes from the IETF#90 Friday session. No other agenda items are >>> >> planned for the next interim. >>> >> >>> >> - 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 >>_______________________________________________ >>dmm mailing list >>dmm@ietf.org >>https://www.ietf.org/mailman/listinfo/dmm > From nobody Wed Sep 10 15:21:49 2014 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 A8D5C1A6FFC for ; Wed, 10 Sep 2014 15:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 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, RP_MATCHES_RCVD=-1.652] 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 kqkMoPf1eCqJ for ; Wed, 10 Sep 2014 15:21:42 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 680EB1A88A7 for ; Wed, 10 Sep 2014 15:21:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=nToTNdLlDiF4/UcqBv/6qzqXZqGtw72Dv7KKbbgfjXBTU+kbxlxad0mU7M5pV2TO; 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.255.215]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XRqGi-0004bM-MK; Wed, 10 Sep 2014 18:21:40 -0400 Message-ID: <5410CEF2.2010809@earthlink.net> Date: Wed, 10 Sep 2014 15:21:38 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , Marco Liebsch , dmm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7d31508a4f4ee34e0b602030d7dc11a8c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/m8PKz1RAocXMAd7CPaVv73ZA4fs Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 10 Sep 2014 22:21:46 -0000 Hello folks, I think it's best to consider the MNID as simply living in a space of identifiers, and not worry too much about whether it's a logical identifier or a physical identifier. If the former, then somewhere (perhaps below the network layer) the logical identifier has been bound to something in the physical interface, but that's not our problem. The number space for types of MNIDs is likely to stay pretty empty, so I'd say we could add as many types as would be convenient for the software designers. So, we could conceivably have several MNIDs defined that all "looked like" NAIs (which, themselves, "look like" FQDNs). Regards, Charlie P. On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote: > Yes. Currently, the MNID is if the nai format and is overloaded. The MNID > in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the IMSI. Ex: > "@epc.mnc.mcc.3gppnetwork.org² > > We also have MAC48@REALM; > > We also have approaches to transform MAC to Pseudo IMSI, and then carry > IMSI-NAI as the MN-ID. > > > So, we need unique sub-types for each of the types/sources. > > MN-Id based on IMSI, MSISDN, IMEI, MAC .. > > Also, do we need to distinguish between IMSI and IMSI-NAI ? > > Sri > > > > On 9/10/14 6:29 AM, "Marco Liebsch" wrote: > >> It seems the MNID is somehow overloaded to carry both, node-specific IDs, >> e.g. MAC, as well as subscriber IDs, which is the IMSI. >> There may be value in adding the IMEI to the list of possible types of >> node-specific IDs. >> >> marco >> >>> -----Original Message----- >>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >>> (sgundave) >>> Sent: Dienstag, 9. September 2014 23:30 >>> To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org >>> Cc: Vijay Devarapalli >>> Subject: Re: [DMM] regarding the re-chartering.. >>> >>> Two more comments. >>> >>> >>> >>> 4.) I'd also use sub-type value of (2) for IMSI. Just to align with the >>> sub-types >>> defined for MN Id defined for ICMP. I suspect there are some >>> implementations >>> already using sub-type (2). Please see the other thread. >>> >>> >>> 5.) For each of the sub-types, we need text including examples and some >>> explanation on how they are used. >>> >>> >>> Sri >>> >>> >>> >>> On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" >>> wrote: >>> >>>> Hi Charlie, >>>> >>>> This is good. Thanks. >>>> >>>> >>>> 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 >>>> address, why do we need to two sub-types ? Why not have just one >>>> sub-type for mac based identifiers ? >>>> >>>> 2.) Sub type value (1) is currently used. Its currently overloaded for >>>> IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the >>>> definition of new sub-types, we need some text explaining the >>>> motivation >>>> >>>> 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is >>>> this ? Are these CGA-based IPv6 addresses ? >>>> >>>> >>>> >>>> >>>> New Mobile Node Identifier Types >>>> >>>> +-----------------+------------------------+ >>>> | Identifier Type | Identifier Type Number | >>>> +-----------------+------------------------+ >>>> | IPv6 Address | 2 | >>>> | | | >>>> | IMSI | 3 | >>>> | | | >>>> | P-TMSI | 4 | >>>> | | | >>>> | EUI-48 address | 5 | >>>> | | | >>>> | EUI-64 address | 6 | >>>> | | | >>>> | GUTI | 7 | >>>> +-----------------+------------------------+ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards >>>> Sri >>>> PS: Good to see Vijay back >>>> >>>> >>>> On 9/9/14 1:28 PM, "Charlie Perkins" >>>> wrote: >>>> >>>>> Hello folks, >>>>> >>>>> Here's the last Internet Draft that we did, long ago expired: >>>>> http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt >>>>> >>>>> I'll resubmit it with a few updates as a personal draft to dmm. >>>>> >>>>> Regards, >>>>> Charlie P. >>>> _______________________________________________ >>>> 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 Sep 10 15:38:23 2014 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 06D021A890E for ; Wed, 10 Sep 2014 15:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 QyOpQhWw3AE2 for ; Wed, 10 Sep 2014 15:38:19 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146741A020B for ; Wed, 10 Sep 2014 15:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3842; q=dns/txt; s=iport; t=1410388699; x=1411598299; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bKDljl1xxHvGUS8ZkAZcqYopKT6HLfPKTH41QU3BVFQ=; b=S3s17lD2G0D4s4GGGCJ9JYm/cWbw195T/NhdH9muYSK6r8afyaFIkPNR 4zXuXwt0fhimBuZJwgzs3yRRFoUQtX3fNIacxHcXDqRchy1H5Gfq9yQEV forkKTLCuWMYt2eN6ahzPJAjJ2wdsCnWAhwls+iSApF5sw2255WQpfFIN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFABzSEFStJV2U/2dsb2JhbABWCoMNU1vKNQqHTQGBEhZ4hAMBAQEEAQEBCWILDAYBCBEEAQEBJygGCxQJCAIEDgUbiBMDEQ24Ug2GYgETBI0ggVExKwcGhEYFiwCGSYkjghCOfIY9g2FsAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,501,1406592000"; d="scan'208";a="76813516" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 10 Sep 2014 22:38:18 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8AMcIQ5005982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 22:38:18 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 17:38:17 -0500 From: "Sri Gundavelli (sgundave)" To: "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzUfqRW2G6z0A4UuMx5G1/Sur8w== Date: Wed, 10 Sep 2014 22:38:17 +0000 Message-ID: In-Reply-To: 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.210] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <940436CFC4720443B1A7871BD56BCA9C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/TWuRRfsiu76UEfoIfY_J5aRvd9Q Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 22:38:21 -0000 Hi Behcet, Look for the qualifiers which states its an opinion. Don't just poke. Goal is to converge - Read that. If you disagree with this, I assume you want a debate on the protocol choice. Go for it. Sri On 9/10/14 3:15 PM, "Behcet Sarikaya" wrote: >Hi Sri, > >On Wed, Sep 10, 2014 at 5:01 PM, Sri Gundavelli (sgundave) > wrote: >> Hi Fred, >> >> >> IMHO, DMM solution need to be tied to one specific protocol. We don't >>have >> to battle this out and come up with one answer. Once we have high-level >> view of the solution and the interfaces, its possible to realize those >> interfaces using any protocols. You call it MIP, GTP, Aero ..does not >> matter. The core specs can identify the interface requirements and the >> specific protocol documents can publish extensions to the protocols. We >> let the deployments make the call on the protocol choice. >> > >These are your views. >Not mine for sure. > >Regards, > >Behcet >> >> >> Regards >> Sri >> >> >> >> >> >> On 9/10/14 11:43 AM, "Templin, Fred L" >>wrote: >> >>>Hi Jouni, >>> >>>I'd like to propose a slightly different charter: >>> >>> "AERO already solves distributed mobility management and provides a >>> a comprehensive mobility solution for any mobile device. AERO should >>> therefore be approved as the mobility management solution for DMM. >>> Publication of AERO will therefore conclude the working group's >>> activity." >>> >>>Can we have this on the agenda? >>> >>>Thanks - Fred >>>fred.l.templin@boeing.com >>> >>>> -----Original Message----- >>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>> Sent: Wednesday, September 10, 2014 11:37 AM >>>> To: sarikaya@ieee.org >>>> Cc: Dapeng Liu; dmm@ietf.org >>>> Subject: Re: [DMM] DMM Interim call #2 - agenda forming >>>> >>>> >>>> What do you mean by no agenda? To me it clearly says we use the call >>>>#2 >>>> for setting up the work split. >>>> >>>> - Jouni >>>> >>>> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: >>>> > Jouni, why don't we cancel this one (#2) and do the next one (#3) >>>>with >>>> > an agenda? >>>> > I hope Alper can attend :-) >>>> > >>>> > Regards, >>>> > >>>> > Behcet >>>> > >>>> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen >>>> wrote: >>>> >> >>>> >> It seems I sent this to a wrong receiver.. that explains why it did >>>>not >>>> >> appear on the list. >>>> >> >>>> >> - Jouni >>>> >> >>>> >> -------- Alkuper=E4inen viesti / Orig.Msg. -------- >>>> >> Aihe: DMM Interim call #2 - agenda forming >>>> >> P=E4iv=E4ys: Mon, 08 Sep 2014 23:43:24 +0300 >>>> >> L=E4hett=E4j=E4: Jouni Korhonen >>>> >> Vastaanottaja: dmm-ads@tools.ietf.org >>>> >> CC: jouni.nospam@gmail.com, Dapeng Liu >>>> >> >>>> >> Folks, >>>> >> >>>> >> The next interim is close. Assuming there are no overwhelming >>>>amount >>>>of >>>> >> comments to the re-charter text, we are ready to start setting up >>>>the >>>> >> work split on the solution space! Remember the discussion and the >>>> >> minutes from the IETF#90 Friday session. No other agenda items are >>>> >> planned for the next interim. >>>> >> >>>> >> - 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 >>>_______________________________________________ >>>dmm mailing list >>>dmm@ietf.org >>>https://www.ietf.org/mailman/listinfo/dmm >> From nobody Wed Sep 10 15:41:48 2014 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 E16061A8917 for ; Wed, 10 Sep 2014 15:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 GgiPZbYvt2Ja for ; Wed, 10 Sep 2014 15:41:46 -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 BAEBC1A8914 for ; Wed, 10 Sep 2014 15:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8080; q=dns/txt; s=iport; t=1410388906; x=1411598506; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NUocZ3OBAr1SRzwo2vSx0ckhdvAtnvJ7b549Hnjpd3c=; b=ZEo++Fh1XQoq+6u4V10ONGvJBZRERn5hkS32ciqCzuC72xSMG4+PXXfM kEb5AumRt8yV8SdYZUVM4JoP/XGpoLroMGjfBKdQ2o1QI2UU5rnNWt5Cl Rg5ilGOTn9BuG2olrOw6ekv35mwBXssF+HaV8Cev3oboM0v+AEfNb5QQL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAAzTEFStJA2K/2dsb2JhbABXCYMNU1uCeMc9CodNARl5FniEAwEBAQQBAQExOgsMBgEIDgMEAQEBBCMFBCULFAkIAgQBDQUJiCUDEQ2NRZw9BpU+AReBJot6gVIoCBAbBwQCgm2BWQWGHYssizOVOYNhbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,501,1406592000"; d="scan'208";a="354317547" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 10 Sep 2014 22:41:45 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8AMfiAw003733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 22:41:44 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 17:41:44 -0500 From: "Sri Gundavelli (sgundave)" To: Charlie Perkins , Marco Liebsch , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzUhlFTJi/s504kOP81QcxzozOA== Date: Wed, 10 Sep 2014 22:41:44 +0000 Message-ID: In-Reply-To: <5410CEF2.2010809@earthlink.net> 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.210] Content-Type: text/plain; charset="euc-kr" Content-ID: <9BB1B1914524E94DB19553CE6AF5D673@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/8iGgnjQ6ZAKPwmL1o2RvMlwVtQg Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 10 Sep 2014 22:41:48 -0000 SGVsbG8gQ2hhcmxpZSwNCg0KQWdyZWUgd2l0aCB0aGF0LiBNTi1JZCBhcyBpdHMgZGVmaW5lZCB0 b2RheSBpcyBhIGxvZ2ljYWwgaWRlbnRpZmllci4gSXQNCmRvZXMgbm90IHJlcXVpcmUgdGhlIGlk ZW50aWZpZXIgdG8gYmUgYm91bmQgdG8gYSBwaHlzaWNhbCBkZXZpY2Ugb3IgYQ0KaW50ZXJmYWNl IGlkZW50aXR5LiBCdXQsIHdlIGhhdmUgY2xlYXJseSBzZWVuIHJlcXVpcmVtZW50cyB3aGVyZSB0 aGUgbmVlZA0KaXMgZm9yIGdlbmVyYXRpbmcgaWRlbnRpZmllcnMgYmFzZWQgb24gc29tZSBwaHlz aWNhbCBpZGVudGlmaWVycy4gVGhvc2UNCnBoeXNpY2FsIGlkZW50aWZpZXJzIGluY2x1ZGUgSU1T SSwgTVNJU0ROLCBJTUVJLCBNQUMgLi5ldGMuIElmIHdlIGNhbg0KZGVmaW5lIGEgdHlwZSBmb3Ig ZWFjaCBvZiB0aGUgc291cmNlIGFuZCB0aGUgcnVsZXMgZm9yIGdlbmVyYXRpbmcgTU4tSUQNCmJh c2VkIHVzaW5nIHRob3NlIHNvdXJjZXMsIHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyIHdpbGwgaGF2 ZSBjbGVhcg0KZ3VpZGFuY2Ugb24gaG93IHRvIHVzZSB0aGUgc3BlYy4gU29tZSBwb2ludGVycywg ZXhwbGFuYXRpb24gYW5kIGV4YW1wbGVzDQpmb3IgZWFjaCBvZiB0aG9zZSBpZGVudGlmaWVycyB3 aWxsIGdyZWF0bHkgaGVscCBhdm9pZCBpbnRlci1vcCBpc3N1ZXMuDQoNCg0KUmVnYXJkcw0KU3Jp DQoNCg0KDQoNCg0KDQoNCk9uIDkvMTAvMTQgMzoyMSBQTSwgIkNoYXJsaWUgUGVya2lucyIgPGNo YXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pg0Kd3JvdGU6DQoNCj4NCj5IZWxsbyBmb2xrcywN Cj4NCj5JIHRoaW5rIGl0J3MgYmVzdCB0byBjb25zaWRlciB0aGUgTU5JRCBhcyBzaW1wbHkgbGl2 aW5nIGluIGEgc3BhY2Ugb2YNCj5pZGVudGlmaWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVjaCBh Ym91dCB3aGV0aGVyIGl0J3MgYSBsb2dpY2FsDQo+aWRlbnRpZmllcg0KPm9yIGEgcGh5c2ljYWwg aWRlbnRpZmllci4gIElmIHRoZSBmb3JtZXIsIHRoZW4gc29tZXdoZXJlIChwZXJoYXBzIGJlbG93 DQo+dGhlIG5ldHdvcmsgbGF5ZXIpIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIgaGFzIGJlZW4gYm91 bmQgdG8gc29tZXRoaW5nDQo+aW4gdGhlIHBoeXNpY2FsIGludGVyZmFjZSwgYnV0IHRoYXQncyBu b3Qgb3VyIHByb2JsZW0uDQo+DQo+VGhlIG51bWJlciBzcGFjZSBmb3IgdHlwZXMgb2YgTU5JRHMg aXMgbGlrZWx5IHRvIHN0YXkgcHJldHR5IGVtcHR5LA0KPnNvIEknZCBzYXkgd2UgY291bGQgYWRk IGFzIG1hbnkgdHlwZXMgYXMgd291bGQgYmUgY29udmVuaWVudCBmb3IgdGhlDQo+c29mdHdhcmUg ZGVzaWduZXJzLiAgU28sIHdlIGNvdWxkIGNvbmNlaXZhYmx5IGhhdmUgc2V2ZXJhbCBNTklEcw0K PmRlZmluZWQgdGhhdCBhbGwgImxvb2tlZCBsaWtlIiBOQUlzICh3aGljaCwgdGhlbXNlbHZlcywg Imxvb2sgbGlrZSINCj5GUUROcykuDQo+DQo+UmVnYXJkcywNCj5DaGFybGllIFAuDQo+DQo+DQo+ DQo+T24gOS8xMC8yMDE0IDg6MTEgQU0sIFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6 DQo+PiBZZXMuIEN1cnJlbnRseSwgdGhlIE1OSUQgaXMgaWYgdGhlIG5haSBmb3JtYXQgYW5kIGlz IG92ZXJsb2FkZWQuIFRoZQ0KPj5NTklEDQo+PiBpbiAzR1BQIHNwZWNzIGlzIHRoZSBJTVNJLU5B SSAoSU1TSUBSRUFMTSksIGl0cyBiYXNlZCBvbiB0aGUgSU1TSS4gRXg6DQo+PiAiPElNU0k+QGVw Yy5tbmM8TU5DPi5tY2M8TUNDPi4zZ3BwbmV0d29yay5vcmep9w0KPj4NCj4+IFdlIGFsc28gaGF2 ZSBNQUM0OEBSRUFMTTsNCj4+DQo+PiBXZSBhbHNvIGhhdmUgYXBwcm9hY2hlcyB0byB0cmFuc2Zv cm0gTUFDIHRvIFBzZXVkbyBJTVNJLCBhbmQgdGhlbiBjYXJyeQ0KPj4gSU1TSS1OQUkgYXMgdGhl IE1OLUlELg0KPj4NCj4+DQo+PiBTbywgd2UgbmVlZCB1bmlxdWUgc3ViLXR5cGVzIGZvciBlYWNo IG9mIHRoZSB0eXBlcy9zb3VyY2VzLg0KPj4NCj4+IE1OLUlkIGJhc2VkIG9uIElNU0ksIE1TSVNE TiwgSU1FSSwgTUFDIC4uDQo+Pg0KPj4gQWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBi ZXR3ZWVuIElNU0kgYW5kIElNU0ktTkFJID8NCj4+DQo+PiBTcmkNCj4+DQo+Pg0KPj4NCj4+IE9u IDkvMTAvMTQgNjoyOSBBTSwgIk1hcmNvIExpZWJzY2giIDxNYXJjby5MaWVic2NoQG5lY2xhYi5l dT4gd3JvdGU6DQo+Pg0KPj4+IEl0IHNlZW1zIHRoZSBNTklEIGlzIHNvbWVob3cgb3ZlcmxvYWRl ZCB0byBjYXJyeSBib3RoLCBub2RlLXNwZWNpZmljDQo+Pj5JRHMsDQo+Pj4gZS5nLiBNQUMsIGFz IHdlbGwgYXMgc3Vic2NyaWJlciBJRHMsIHdoaWNoIGlzIHRoZSBJTVNJLg0KPj4+IFRoZXJlIG1h eSBiZSB2YWx1ZSBpbiBhZGRpbmcgdGhlIElNRUkgdG8gdGhlIGxpc3Qgb2YgcG9zc2libGUgdHlw ZXMgb2YNCj4+PiBub2RlLXNwZWNpZmljIElEcy4NCj4+Pg0KPj4+IG1hcmNvDQo+Pj4NCj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogZG1tIFttYWlsdG86ZG1tLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmkgR3VuZGF2ZWxsaQ0KPj4+PiAoc2d1bmRh dmUpDQo+Pj4+IFNlbnQ6IERpZW5zdGFnLCA5LiBTZXB0ZW1iZXIgMjAxNCAyMzozMA0KPj4+PiBU bzogU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKTsgQ2hhcmxpZSBQZXJraW5zOyBkbW1AaWV0Zi5v cmcNCj4+Pj4gQ2M6IFZpamF5IERldmFyYXBhbGxpDQo+Pj4+IFN1YmplY3Q6IFJlOiBbRE1NXSBy ZWdhcmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLg0KPj4+Pg0KPj4+PiBUd28gbW9yZSBjb21tZW50 cy4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gNC4pIEknZCBhbHNvIHVzZSBzdWItdHlwZSB2YWx1 ZSBvZiAoMikgZm9yIElNU0kuIEp1c3QgdG8gYWxpZ24gd2l0aA0KPj4+PnRoZQ0KPj4+PiBzdWIt dHlwZXMNCj4+Pj4gZGVmaW5lZCBmb3IgTU4gSWQgZGVmaW5lZCBmb3IgSUNNUC4gSSBzdXNwZWN0 IHRoZXJlIGFyZSBzb21lDQo+Pj4+IGltcGxlbWVudGF0aW9ucw0KPj4+PiBhbHJlYWR5IHVzaW5n IHN1Yi10eXBlICgyKS4gUGxlYXNlIHNlZSB0aGUgb3RoZXIgdGhyZWFkLg0KPj4+Pg0KPj4+Pg0K Pj4+PiA1LikgRm9yIGVhY2ggb2YgdGhlIHN1Yi10eXBlcywgd2UgbmVlZCB0ZXh0IGluY2x1ZGlu ZyBleGFtcGxlcyBhbmQNCj4+Pj5zb21lDQo+Pj4+IGV4cGxhbmF0aW9uIG9uIGhvdyB0aGV5IGFy ZSB1c2VkLg0KPj4+Pg0KPj4+Pg0KPj4+PiBTcmkNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gT24g OS85LzE0IDI6MjAgUE0sICJTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIiA8c2d1bmRhdmVAY2lz Y28uY29tPg0KPj4+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhpIENoYXJsaWUsDQo+Pj4+Pg0KPj4+ Pj4gVGhpcyBpcyBnb29kLiBUaGFua3MuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IDEuKSBJZiBFVUkt NDggYW5kIEVVSS02NCBhZGRyZXNzZXMgYXJlIGRlcml2ZWQgb2YgYSA0OC1iaXQgSUVFRSA4MDIu Mg0KPj4+Pj4gYWRkcmVzcywgd2h5IGRvIHdlIG5lZWQgdG8gdHdvIHN1Yi10eXBlcyA/IFdoeSBu b3QgaGF2ZSBqdXN0IG9uZQ0KPj4+Pj4gc3ViLXR5cGUgZm9yIG1hYyBiYXNlZCBpZGVudGlmaWVy cyA/DQo+Pj4+Pg0KPj4+Pj4gMi4pIFN1YiB0eXBlIHZhbHVlICgxKSBpcyBjdXJyZW50bHkgdXNl ZC4gSXRzIGN1cnJlbnRseSBvdmVybG9hZGVkDQo+Pj4+PmZvcg0KPj4+Pj4gSU1TSS1OQUkgKDNH UFAgc3BlY3MpIGFuZCBnZW5lcmljIE5BSSBiYXNlZCBpZGVudGlmaWVycy4gR2l2ZW4gdGhlDQo+ Pj4+PiBkZWZpbml0aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxh aW5pbmcgdGhlDQo+Pj4+PiBtb3RpdmF0aW9uDQo+Pj4+Pg0KPj4+Pj4gMy4pIFByb3Bvc2VkIFN1 Yi10eXBlIHZhbHVlIG9mICgyKSBmb3IgSVB2NiBhZGRyZXNzLiBXaGF0IGV4YWN0bHkgaXMNCj4+ Pj4+IHRoaXMgPyBBcmUgdGhlc2UgQ0dBLWJhc2VkIElQdjYgYWRkcmVzc2VzID8NCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICBOZXcgTW9iaWxl IE5vZGUgSWRlbnRpZmllciBUeXBlcw0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+PiAgICAgICAgICAg ICAgICB8IElkZW50aWZpZXIgVHlwZSB8IElkZW50aWZpZXIgVHlwZSBOdW1iZXIgfA0KPj4+Pj4g ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCj4+Pj4+ICAgICAgICAgICAgICAgIHwgSVB2NiBBZGRyZXNzICAgIHwgMiAgICAgICAgICAg ICAgICAgICAgICB8DQo+Pj4+PiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgfA0KPj4+Pj4gICAgICAgICAgICAgICAgfCBJTVNJICAgICAg ICAgICAgfCAzICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4+ICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+PiAgICAgICAg ICAgICAgICB8IFAtVE1TSSAgICAgICAgICB8IDQgICAgICAgICAgICAgICAgICAgICAgfA0KPj4+ Pj4gICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgIHwNCj4+Pj4+ICAgICAgICAgICAgICAgIHwgRVVJLTQ4IGFkZHJlc3MgIHwgNSAgICAgICAg ICAgICAgICAgICAgICB8DQo+Pj4+PiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4+Pj4gICAgICAgICAgICAgICAgfCBFVUktNjQg YWRkcmVzcyAgfCA2ICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4+ICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+PiAgICAg ICAgICAgICAgICB8IEdVVEkgICAgICAgICAgICB8IDcgICAgICAgICAgICAgICAgICAgICAgfA0K Pj4+Pj4gICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+PiBSZWdhcmRzDQo+Pj4+PiBTcmkNCj4+Pj4+IFBTOiBHb29kIHRvIHNlZSBWaWpheSBi YWNrDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IE9uIDkvOS8xNCAxOjI4IFBNLCAiQ2hhcmxpZSBQZXJr aW5zIiA8Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+ DQo+Pj4+Pj4gSGVsbG8gZm9sa3MsDQo+Pj4+Pj4NCj4+Pj4+PiBIZXJlJ3MgdGhlIGxhc3QgSW50 ZXJuZXQgRHJhZnQgdGhhdCB3ZSBkaWQsIGxvbmcgYWdvIGV4cGlyZWQ6DQo+Pj4+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXBlcmtpbnMtbWV4dC00MjgzbW5pZHMtMDEu dHh0DQo+Pj4+Pj4NCj4+Pj4+PiBJJ2xsIHJlc3VibWl0IGl0IHdpdGggYSBmZXcgdXBkYXRlcyBh cyBhIHBlcnNvbmFsIGRyYWZ0IHRvIGRtbS4NCj4+Pj4+Pg0KPj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+ Pj4gQ2hhcmxpZSBQLg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4+IGRtbSBtYWlsaW5nIGxpc3QNCj4+Pj4+IGRtbUBpZXRmLm9yZw0K Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gZG1tIG1h aWxpbmcgbGlzdA0KPj4+PiBkbW1AaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kbW0NCj4+DQo+DQoNCg== From nobody Wed Sep 10 15:47:23 2014 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 482A81A8918 for ; Wed, 10 Sep 2014 15:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 LwMGzwuKLVSa for ; Wed, 10 Sep 2014 15:47:18 -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 BDBC41A8914 for ; Wed, 10 Sep 2014 15:47:18 -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 s8AMlIMP008026; Wed, 10 Sep 2014 15:47:18 -0700 Received: from XCH-PHX-309.sw.nos.boeing.com (xch-phx-309.sw.nos.boeing.com [130.247.25.163]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8AMlBua007978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 10 Sep 2014 15:47:12 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-PHX-309.sw.nos.boeing.com ([169.254.9.233]) with mapi id 14.03.0181.006; Wed, 10 Sep 2014 15:47:09 -0700 From: "Templin, Fred L" To: "sarikaya@ieee.org" , "Sri Gundavelli (sgundave)" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzUS085cNtlvM5kaPQ9fwALiOyZv68k2A Date: Wed, 10 Sep 2014 22:47:08 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D15E20@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D1590D@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/-WyINcay8QqbKCKIHoYmQ5hUN04 Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 22:47:21 -0000 SGkgQmVoY2V0IGFuZCBTcmksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQmVoY2V0IFNhcmlrYXlhIFttYWlsdG86c2FyaWtheWEyMDEyQGdtYWlsLmNvbV0NCj4gU2Vu dDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTQgMzoxNSBQTQ0KPiBUbzogU3JpIEd1bmRh dmVsbGkgKHNndW5kYXZlKQ0KPiBDYzogVGVtcGxpbiwgRnJlZCBMOyBKb3VuaSBLb3Job25lbjsg RGFwZW5nIExpdTsgZG1tQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbRE1NXSBETU0gSW50ZXJp bSBjYWxsICMyIC0gYWdlbmRhIGZvcm1pbmcNCj4gDQo+IEhpIFNyaSwNCj4gDQo+IE9uIFdlZCwg U2VwIDEwLCAyMDE0IGF0IDU6MDEgUE0sIFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkNCj4gPHNn dW5kYXZlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gSGkgRnJlZCwNCj4gPg0KPiA+DQo+ID4gSU1I TywgRE1NIHNvbHV0aW9uIG5lZWQgdG8gYmUgdGllZCB0byBvbmUgc3BlY2lmaWMgcHJvdG9jb2wu IFdlIGRvbid0IGhhdmUNCj4gPiB0byBiYXR0bGUgdGhpcyBvdXQgYW5kIGNvbWUgdXAgd2l0aCBv bmUgYW5zd2VyLiBPbmNlIHdlIGhhdmUgaGlnaC1sZXZlbA0KPiA+IHZpZXcgb2YgdGhlIHNvbHV0 aW9uIGFuZCB0aGUgaW50ZXJmYWNlcywgaXRzIHBvc3NpYmxlIHRvIHJlYWxpemUgdGhvc2UNCj4g PiBpbnRlcmZhY2VzIHVzaW5nIGFueSBwcm90b2NvbHMuIFlvdSBjYWxsIGl0IE1JUCwgR1RQLCBB ZXJvIC4uZG9lcyBub3QNCj4gPiBtYXR0ZXIuIFRoZSBjb3JlIHNwZWNzIGNhbiBpZGVudGlmeSB0 aGUgaW50ZXJmYWNlIHJlcXVpcmVtZW50cyBhbmQgdGhlDQo+ID4gc3BlY2lmaWMgcHJvdG9jb2wg ZG9jdW1lbnRzIGNhbiBwdWJsaXNoIGV4dGVuc2lvbnMgdG8gdGhlIHByb3RvY29scy4gV2UNCj4g PiBsZXQgdGhlIGRlcGxveW1lbnRzIG1ha2UgdGhlIGNhbGwgb24gdGhlIHByb3RvY29sIGNob2lj ZS4NCj4gPg0KDQpUaGVyZSBhcmUgcG9pbnRzIG9mIGNvbXBhcmlzb24gYmV0d2VlbiBNSVAgYW5k IEFFUk8gdGhhdCBJTUhPDQpzaG91bGQgYmUgdGFrZW4gdW5kZXIgY29uc2lkZXJhdGlvbi4gTUlQ IGhhcyBiZWVuIGFyb3VuZCBmb3IgYQ0KbG9uZyB0aW1lLCBidXQgQUVSTyBpcyBub3QgZXhhY3Rs eSBuZXcgZWl0aGVyLiBJdCBoYXMgaXRzIGdlbmVzaXMNCmZyb20gYSBsb25nIGxpc3Qgb2YgZWFy bGllciBSRkNzIGluY2x1ZGluZyAoaW4gY2hyb25vbG9naWMgb3JkZXIpOg0KDQpodHRwOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyNTI5LnR4dA0KaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9y Zy9yZmMvcmZjNDIxNC50eHQNCmh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzUyMTQu dHh0DQpodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MzIwLnR4dA0KaHR0cDovL3d3 dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNTcyMC50eHQNCmh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvcmZjL3JmYzYxMzkudHh0DQpodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM2MTc5 LnR4dA0KaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNjcwNi50eHQNCg0KSSBrbm93 IGEgbG90IG9mIHBlb3BsZSB0aHJvdWdob3V0IHRoZSBJRVRGIGFuZCBvdGhlciBmb3J1bXMgaGF2 ZQ0KcHV0IGEgdHJlbWVuZG91cyBhbW91bnQgb2YgZW5lcmd5IGludG8gTUlQLWJhc2VkIHNvbHV0 aW9ucywgYnV0DQp0byBteSB1bmRlcnN0YW5kaW5nIHRoZSBhcmNoZXR5cGUgZm9yIHRob3NlIHNv bHV0aW9ucyBpcyBzdGlsbA0KYmFzZWQgb24gYSBob3N0IHRoYXQgZ29lcyB3YW5kZXJpbmcgZnJv bSBpdHMgaG9tZSBwaHlzaWNhbCBsaW5rDQphbmQgcmVxdWlyZXMgdGhlIGFzc2lzdCBvZiBhIGhv bWUgYWdlbnQgb24gdGhhdCBwaHlzaWNhbCBsaW5rDQp0byBrZWVwIHRyYWNrIG9mIGl0cyBjdXJy ZW50IGxvY2F0aW9uLg0KDQpDb252ZXJzZWx5LCB0aGUgYXJjaGV0eXBlIGZvciBBRVJPIGlzIGEg cm91dGVyIHRoYXQgcmVtYWlucw0KY29ubmVjdGVkIHRvIGEgdmlydHVhbCBsaW5rIGNvbmZpZ3Vy ZWQgb3ZlciBpdHMgaG9tZSBuZXR3b3JrIG5vDQptYXR0ZXIgd2hlcmUgdGhlIHJvdXRlciBtb3Zl cyB0by4gVGhhdCBtZWFucyB0aGF0IGl0IGRvZXMgbm90DQptYXR0ZXIgd2hpY2ggImFnZW50IiBv biB0aGUgdmlydHVhbCBsaW5rIHRoZSByb3V0ZXIgYXNzb2NpYXRlcw0Kd2l0aCwgYW5kIHRoYXQg aXMgd2h5IEFFUk8gaGFzIGFscmVhZHkgc29sdmVkIHRoZSBETU0gcHJvYmxlbS4gIA0KIA0KPiBU aGVzZSBhcmUgeW91ciB2aWV3cy4NCj4gTm90IG1pbmUgZm9yIHN1cmUuDQoNCkkgaGF2ZSBoZWFy ZCB5b3Ugc2F5IHRoaXMgb24gbXVsdGlwbGUgb2NjYXNpb25zLCBCZWhjZXQsIGFuZCBJDQphbSBi ZWdpbm5pbmcgdG8gd29uZGVyIGlmIHlvdSBoYXZlIGEgYmV0dGVyIHVuZGVyc3RhbmRpbmcgb2Yg dGhlDQpzaXR1YXRpb24gdGhhbiBJIGRvLiBCdXQsIEkgZG8gYmVsaWV2ZSBzb2x1dGlvbiBhbHRl cm5hdGl2ZXMNCnNob3VsZCBiZSBkaXNjdXNzZWQgcmF0aGVyIHRoYW4ganVzdCBtYXJjaGluZyBm b3J3YXJkIHdpdGhvdXQNCmNvbnNpZGVyaW5nIG5ldyBhcHByb2FjaGVzLg0KDQpUaGFua3MgLSBG cmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCj4gUmVnYXJkcywNCj4gDQo+IEJlaGNl dA0KPiA+DQo+ID4NCj4gPiBSZWdhcmRzDQo+ID4gU3JpDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+IE9uIDkvMTAvMTQgMTE6NDMgQU0sICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPg0KPiA+PkhpIEpvdW5pLA0KPiA+Pg0KPiA+Pkkn ZCBsaWtlIHRvIHByb3Bvc2UgYSBzbGlnaHRseSBkaWZmZXJlbnQgY2hhcnRlcjoNCj4gPj4NCj4g Pj4gICJBRVJPIGFscmVhZHkgc29sdmVzIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQg YW5kIHByb3ZpZGVzIGENCj4gPj4gICBhIGNvbXByZWhlbnNpdmUgbW9iaWxpdHkgc29sdXRpb24g Zm9yIGFueSBtb2JpbGUgZGV2aWNlLiBBRVJPIHNob3VsZA0KPiA+PiAgIHRoZXJlZm9yZSBiZSBh cHByb3ZlZCBhcyB0aGUgbW9iaWxpdHkgbWFuYWdlbWVudCBzb2x1dGlvbiBmb3IgRE1NLg0KPiA+ PiAgIFB1YmxpY2F0aW9uIG9mIEFFUk8gd2lsbCB0aGVyZWZvcmUgY29uY2x1ZGUgdGhlIHdvcmtp bmcgZ3JvdXAncw0KPiA+PiAgIGFjdGl2aXR5LiINCj4gPj4NCj4gPj5DYW4gd2UgaGF2ZSB0aGlz IG9uIHRoZSBhZ2VuZGE/DQo+ID4+DQo+ID4+VGhhbmtzIC0gRnJlZA0KPiA+PmZyZWQubC50ZW1w bGluQGJvZWluZy5jb20NCj4gPj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+PiBGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEpvdW5pIEtvcmhvbmVuDQo+ID4+PiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMCwgMjAx NCAxMTozNyBBTQ0KPiA+Pj4gVG86IHNhcmlrYXlhQGllZWUub3JnDQo+ID4+PiBDYzogRGFwZW5n IExpdTsgZG1tQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSZTogW0RNTV0gRE1NIEludGVyaW0g Y2FsbCAjMiAtIGFnZW5kYSBmb3JtaW5nDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFdoYXQgZG8geW91 IG1lYW4gYnkgbm8gYWdlbmRhPyBUbyBtZSBpdCBjbGVhcmx5IHNheXMgd2UgdXNlIHRoZSBjYWxs ICMyDQo+ID4+PiBmb3Igc2V0dGluZyB1cCB0aGUgd29yayBzcGxpdC4NCj4gPj4+DQo+ID4+PiAt IEpvdW5pDQo+ID4+Pg0KPiA+Pj4gOS8xMC8yMDE0IDk6MDYgUE0sIEJlaGNldCBTYXJpa2F5YSBr aXJqb2l0dGk6DQo+ID4+PiA+IEpvdW5pLCB3aHkgZG9uJ3Qgd2UgY2FuY2VsIHRoaXMgb25lICgj MikgYW5kIGRvIHRoZSBuZXh0IG9uZSAoIzMpIHdpdGgNCj4gPj4+ID4gYW4gYWdlbmRhPw0KPiA+ Pj4gPiBJIGhvcGUgQWxwZXIgY2FuIGF0dGVuZCA6LSkNCj4gPj4+ID4NCj4gPj4+ID4gUmVnYXJk cywNCj4gPj4+ID4NCj4gPj4+ID4gQmVoY2V0DQo+ID4+PiA+DQo+ID4+PiA+IE9uIFdlZCwgU2Vw IDEwLCAyMDE0IGF0IDE6MDIgUE0sIEpvdW5pIEtvcmhvbmVuDQo+ID4+Pjxqb3VuaS5ub3NwYW1A Z21haWwuY29tPiB3cm90ZToNCj4gPj4+ID4+DQo+ID4+PiA+PiBJdCBzZWVtcyBJIHNlbnQgdGhp cyB0byBhIHdyb25nIHJlY2VpdmVyLi4gdGhhdCBleHBsYWlucyB3aHkgaXQgZGlkDQo+ID4+Pm5v dA0KPiA+Pj4gPj4gYXBwZWFyIG9uIHRoZSBsaXN0Lg0KPiA+Pj4gPj4NCj4gPj4+ID4+IC0gSm91 bmkNCj4gPj4+ID4+DQo+ID4+PiA+PiAtLS0tLS0tLSBBbGt1cGVyw6RpbmVuIHZpZXN0aSAvIE9y aWcuTXNnLiAtLS0tLS0tLQ0KPiA+Pj4gPj4gQWloZTogRE1NIEludGVyaW0gY2FsbCAjMiAtIGFn ZW5kYSBmb3JtaW5nDQo+ID4+PiA+PiBQw6RpdsOkeXM6IE1vbiwgMDggU2VwIDIwMTQgMjM6NDM6 MjQgKzAzMDANCj4gPj4+ID4+IEzDpGhldHTDpGrDpDogSm91bmkgS29yaG9uZW4gPGpvdW5pLm5v c3BhbUBnbWFpbC5jb20+DQo+ID4+PiA+PiBWYXN0YWFub3R0YWphOiBkbW0tYWRzQHRvb2xzLmll dGYub3JnDQo+ID4+PiA+PiBDQzogam91bmkubm9zcGFtQGdtYWlsLmNvbSwgRGFwZW5nIExpdSA8 bGl1ZGFwZW5nQGNoaW5hbW9iaWxlLmNvbT4NCj4gPj4+ID4+DQo+ID4+PiA+PiBGb2xrcywNCj4g Pj4+ID4+DQo+ID4+PiA+PiBUaGUgbmV4dCBpbnRlcmltIGlzIGNsb3NlLiBBc3N1bWluZyB0aGVy ZSBhcmUgbm8gb3ZlcndoZWxtaW5nIGFtb3VudA0KPiA+Pj5vZg0KPiA+Pj4gPj4gY29tbWVudHMg dG8gdGhlIHJlLWNoYXJ0ZXIgdGV4dCwgd2UgYXJlIHJlYWR5IHRvIHN0YXJ0IHNldHRpbmcgdXAg dGhlDQo+ID4+PiA+PiB3b3JrIHNwbGl0IG9uIHRoZSBzb2x1dGlvbiBzcGFjZSEgUmVtZW1iZXIg dGhlIGRpc2N1c3Npb24gYW5kIHRoZQ0KPiA+Pj4gPj4gbWludXRlcyBmcm9tIHRoZSBJRVRGIzkw IEZyaWRheSBzZXNzaW9uLiBObyBvdGhlciBhZ2VuZGEgaXRlbXMgYXJlDQo+ID4+PiA+PiBwbGFu bmVkIGZvciB0aGUgbmV4dCBpbnRlcmltLg0KPiA+Pj4gPj4NCj4gPj4+ID4+IC0gSm91bmkgJiBE YXBlbmcNCj4gPj4+ID4+DQo+ID4+PiA+Pg0KPiA+Pj4gPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ID4+IGRtbSBtYWlsaW5nIGxpc3QNCj4g Pj4+ID4+IGRtbUBpZXRmLm9yZw0KPiA+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kbW0NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gZG1tIG1haWxpbmcgbGlzdA0KPiA+Pj4gZG1tQGll dGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0K PiA+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ ZG1tIG1haWxpbmcgbGlzdA0KPiA+PmRtbUBpZXRmLm9yZw0KPiA+Pmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo+ID4NCg== From nobody Wed Sep 10 16:25:56 2014 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 C06841A03A8 for ; Wed, 10 Sep 2014 16:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 xYt8P6Lipis6 for ; Wed, 10 Sep 2014 16:25:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9781A03B7 for ; Wed, 10 Sep 2014 16:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7497; q=dns/txt; s=iport; t=1410391552; x=1411601152; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PG/KZ60+QgaQ/pCzTMmD2E1zEsQLMFgZRKHwH0a+c1M=; b=kDJOK2YUH8AlZyF6C1RisntrCWlg3sptYR8Asxq90rQ32/YYhw5ZdU44 iQXDDWMxKiz/MoAl5qiBG5HwVfXg6N5pzwp6oRDha69V1bUAdWDkQTAue Qm1zR3a2B8r3Q0zmVwPWasytOC6e7ZA/kbkCS85XwCYPTNhwjmkQRzFje E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAFzdEFStJV2d/2dsb2JhbABWCoMNU1vKOwqHTQGBExZ4hAMBAQEEAQEBCRFRCwwGAQgRBAEBAScoBgsUCQgCBAENBRuIEwMRDbhODYZiAReKAIMggVExKwcGhEYFiwCGSYZtgjaCEI58hj2DYWwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,502,1406592000"; d="scan'208";a="351148963" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 10 Sep 2014 23:25:50 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8ANPojL002255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Sep 2014 23:25:50 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 18:25:50 -0500 From: "Sri Gundavelli (sgundave)" To: "Templin, Fred L" , "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzU6OsnfxVAHi6EWibOxFONG0kw== Date: Wed, 10 Sep 2014 23:25:50 +0000 Message-ID: In-Reply-To: <2134F8430051B64F815C691A62D9831832D15E20@XCH-BLV-504.nw.nos.boeing.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.21.64.105] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/oAXyJLCgIIYQCVDsB4tMdsqoSl0 Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 10 Sep 2014 23:25:54 -0000 Fred, I'm not suggesting Aero vs MIP debate. IMO, its simply not worth it. Each of the protocols have certain properties, which helps in some use-cases and may be inefficient for some other use-cases. But, you can make all of them work, MIP, GTP, MOBIKE, AERO ... There is no silver bullet in any one of them, unless some one can prove it. Some architectures are based on fixed anchors and some such as LISP-based are based on floating anchors. Solutions based on fixed anchors have properties that suits a SP deployment; a single point of charging, policy enforcement, LI support, subscriber control but looses the aspect of optimized routing path. As an example, "I've the best optimized path for my traffic, but my operator has no clue where my traffic gets routed out". That works very well for some cases and does not work for some other deployments. These are all points of debate and each have to be measures on its own merit. =20 The choice of the protocol is also tied to the legacy and deployed infrastructure. Many times its about an evolution. I do not know how many people in this WG have been involved in the AERO protocol development, or familiar with it, at least I'm not involved in its development. But, I'm not against AERO or some thing else. If the discussion has to be about a protocol selection and the approach of multiple options does not work, then we should just only do that and call for a vote and settle that matter. I'm suggesting an approach, where we avoid this protocol debate and allow multiple options. I'm sure, that battle will be bitter and not worth it. Regards Sri On 9/10/14 3:47 PM, "Templin, Fred L" wrote: >Hi Behcet and Sri, > >> -----Original Message----- >> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> Sent: Wednesday, September 10, 2014 3:15 PM >> To: Sri Gundavelli (sgundave) >> Cc: Templin, Fred L; Jouni Korhonen; Dapeng Liu; dmm@ietf.org >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming >>=20 >> Hi Sri, >>=20 >> On Wed, Sep 10, 2014 at 5:01 PM, Sri Gundavelli (sgundave) >> wrote: >> > Hi Fred, >> > >> > >> > IMHO, DMM solution need to be tied to one specific protocol. We don't >>have >> > to battle this out and come up with one answer. Once we have >>high-level >> > view of the solution and the interfaces, its possible to realize those >> > interfaces using any protocols. You call it MIP, GTP, Aero ..does not >> > matter. The core specs can identify the interface requirements and the >> > specific protocol documents can publish extensions to the protocols. >>We >> > let the deployments make the call on the protocol choice. >> > > >There are points of comparison between MIP and AERO that IMHO >should be taken under consideration. MIP has been around for a >long time, but AERO is not exactly new either. It has its genesis >from a long list of earlier RFCs including (in chronologic order): > >http://www.rfc-editor.org/rfc/rfc2529.txt >http://www.rfc-editor.org/rfc/rfc4214.txt >http://www.rfc-editor.org/rfc/rfc5214.txt >http://www.rfc-editor.org/rfc/rfc5320.txt >http://www.rfc-editor.org/rfc/rfc5720.txt >http://www.rfc-editor.org/rfc/rfc6139.txt >http://www.rfc-editor.org/rfc/rfc6179.txt >http://www.rfc-editor.org/rfc/rfc6706.txt > >I know a lot of people throughout the IETF and other forums have >put a tremendous amount of energy into MIP-based solutions, but >to my understanding the archetype for those solutions is still >based on a host that goes wandering from its home physical link >and requires the assist of a home agent on that physical link >to keep track of its current location. > >Conversely, the archetype for AERO is a router that remains >connected to a virtual link configured over its home network no >matter where the router moves to. That means that it does not >matter which "agent" on the virtual link the router associates >with, and that is why AERO has already solved the DMM problem. >=20 >> These are your views. >> Not mine for sure. > >I have heard you say this on multiple occasions, Behcet, and I >am beginning to wonder if you have a better understanding of the >situation than I do. But, I do believe solution alternatives >should be discussed rather than just marching forward without >considering new approaches. > >Thanks - Fred >fred.l.templin@boeing.com > >> Regards, >>=20 >> Behcet >> > >> > >> > Regards >> > Sri >> > >> > >> > >> > >> > >> > On 9/10/14 11:43 AM, "Templin, Fred L" >>wrote: >> > >> >>Hi Jouni, >> >> >> >>I'd like to propose a slightly different charter: >> >> >> >> "AERO already solves distributed mobility management and provides a >> >> a comprehensive mobility solution for any mobile device. AERO >>should >> >> therefore be approved as the mobility management solution for DMM. >> >> Publication of AERO will therefore conclude the working group's >> >> activity." >> >> >> >>Can we have this on the agenda? >> >> >> >>Thanks - Fred >> >>fred.l.templin@boeing.com >> >> >> >>> -----Original Message----- >> >>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >> >>> Sent: Wednesday, September 10, 2014 11:37 AM >> >>> To: sarikaya@ieee.org >> >>> Cc: Dapeng Liu; dmm@ietf.org >> >>> Subject: Re: [DMM] DMM Interim call #2 - agenda forming >> >>> >> >>> >> >>> What do you mean by no agenda? To me it clearly says we use the >>call #2 >> >>> for setting up the work split. >> >>> >> >>> - Jouni >> >>> >> >>> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: >> >>> > Jouni, why don't we cancel this one (#2) and do the next one (#3) >>with >> >>> > an agenda? >> >>> > I hope Alper can attend :-) >> >>> > >> >>> > Regards, >> >>> > >> >>> > Behcet >> >>> > >> >>> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen >> >>> wrote: >> >>> >> >> >>> >> It seems I sent this to a wrong receiver.. that explains why it >>did >> >>>not >> >>> >> appear on the list. >> >>> >> >> >>> >> - Jouni >> >>> >> >> >>> >> -------- Alkuper=E4inen viesti / Orig.Msg. -------- >> >>> >> Aihe: DMM Interim call #2 - agenda forming >> >>> >> P=E4iv=E4ys: Mon, 08 Sep 2014 23:43:24 +0300 >> >>> >> L=E4hett=E4j=E4: Jouni Korhonen >> >>> >> Vastaanottaja: dmm-ads@tools.ietf.org >> >>> >> CC: jouni.nospam@gmail.com, Dapeng Liu >> >> >>> >> >> >>> >> Folks, >> >>> >> >> >>> >> The next interim is close. Assuming there are no overwhelming >>amount >> >>>of >> >>> >> comments to the re-charter text, we are ready to start setting >>up the >> >>> >> work split on the solution space! Remember the discussion and the >> >>> >> minutes from the IETF#90 Friday session. No other agenda items >>are >> >>> >> planned for the next interim. >> >>> >> >> >>> >> - 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 >> >>_______________________________________________ >> >>dmm mailing list >> >>dmm@ietf.org >> >>https://www.ietf.org/mailman/listinfo/dmm >> > From nobody Wed Sep 10 17:13:59 2014 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 C8A411A0450 for ; Wed, 10 Sep 2014 17:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 fBthGaCpckc1 for ; Wed, 10 Sep 2014 17:13:56 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5147E1A0444 for ; Wed, 10 Sep 2014 17:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2040; q=dns/txt; s=iport; t=1410394436; x=1411604036; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Lsdbrie6shMUI2HNpxQ6mQ68hsdjmNVzkOYhsPNZjrY=; b=eLfMppIpWsWDCJyB5AuXlUycOYEHmuf1e/XwglY0/VSaz6QUR3LS+8/q kf36EB1QmTIv55tE9xcAy1pyXMvPEfPWq/rp40LrWN9GsUhqIbMQ6cjcK 3SPnGtNR8E/u2lLP5I2cxRch97heq1ewMHXzLVwNX+bXiGNGod0iRjJ3t E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAJ/oEFStJV2a/2dsb2JhbABggw1TTg3KRodNAYERFniEBAIEHR0/EgEINkIlAgQBDQUJEognDb9GARePTQeETAWRSYszlTmDYWwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,502,1406592000"; d="scan'208";a="354231990" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 11 Sep 2014 00:13:55 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8B0DtJ4018326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 00:13:55 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 10 Sep 2014 19:13:55 -0500 From: "Sri Gundavelli (sgundave)" To: "Sri Gundavelli (sgundave)" , "Templin, Fred L" , "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzVVFEQQwJSH/Bk6ksq8z1ww1uQ== Date: Thu, 11 Sep 2014 00:13:54 +0000 Message-ID: In-Reply-To: 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.21.64.105] Content-Type: text/plain; charset="us-ascii" Content-ID: <6219D51CECA8EF478901CB1757C1A7CD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ZCBdF2smfX4320mIU4tvqhMtOWc Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 11 Sep 2014 00:13:57 -0000 Hi Fred, Looking at other solution alternative, there is this proposal from Satoru-san.=20 http://www.ietf.org/id/draft-matsushima-stateless-uplane-vepc-03.txt Will be good to know your views on how you see this approach compare with Aero.=20 Regards Sri On 9/10/14 4:25 PM, "Sri Gundavelli (sgundave)" wrote: >Fred, > >I'm not suggesting Aero vs MIP debate. IMO, its simply not worth it. Each >of the protocols have certain properties, which helps in some use-cases >and may be inefficient for some other use-cases. But, you can make all of >them work, MIP, GTP, MOBIKE, AERO ... There is no silver bullet in any one >of them, unless some one can prove it. Some architectures are based on >fixed anchors and some such as LISP-based are based on floating anchors. >Solutions based on fixed anchors have properties that suits a SP >deployment; a single point of charging, policy enforcement, LI support, >subscriber control but looses the aspect of optimized routing path. As an >example, "I've the best optimized path for my traffic, but my operator has >no clue where my traffic gets routed out". That works very well for some >cases and does not work for some other deployments. These are all points >of debate and each have to be measures on its own merit. >=20 >The choice of the protocol is also tied to the legacy and deployed >infrastructure. Many times its about an evolution. I do not know how many >people in this WG have been involved in the AERO protocol development, or >familiar with it, at least I'm not involved in its development. But, I'm >not against AERO or some thing else. If the discussion has to be about a >protocol selection and the approach of multiple options does not work, >then we should just only do that and call for a vote and settle that >matter. I'm suggesting an approach, where we avoid this protocol debate >and allow multiple options. I'm sure, that battle will be bitter and not >worth it. > > >Regards >Sri > > > > From nobody Wed Sep 10 23:37:25 2014 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 A48C91A04D2 for ; Wed, 10 Sep 2014 23:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.728 X-Spam-Level: X-Spam-Status: No, score=-0.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, URG_BIZ=0.573] 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 mF0lmqcqKVWn for ; Wed, 10 Sep 2014 23:37:20 -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 A943E1A04B4 for ; Wed, 10 Sep 2014 23:37:20 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus003) with ESMTP (Nemesis) id 0MD7RC-1XZjND2rQi-00GaxG; Thu, 11 Sep 2014 08:37:17 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <2134F8430051B64F815C691A62D9831832D15B64@XCH-BLV-504.nw.nos.boeing.com> Date: Thu, 11 Sep 2014 09:37:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9170362B-1EC8-4729-AA67-1D05D5A37745@yegin.org> References: <2134F8430051B64F815C691A62D9831832D031C3@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D040CD@XCH-BLV-504.nw.nos.boeing.com> <4C4F8606-FBE7-4BAC-8F81-F1B63695357B@yegin.org> <540835D1.5080108@gmail.com> <2134F8430051B64F815C691A62D9831832D060C6@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D15B64@XCH-BLV-504.nw.nos.boeing.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:2RWes/l7HI4tJzX6n3EMzB5ZeaPnt/arz0BDOdrDgxZ arzQEIn+g0ctMt++UCMEFPMeR0BKQ4DYHCo+qWsX0w2BuSMpkU 0Ij1H0Rsqp45SgtmE5sPQqueqeXtMWCho60yKrovL9eeTfgUja S4jmu3gWpIJbR76rWweBYPZ93vFGZaDcKKVp8Jh/vGcdSwDLiT GxG1yGKz54UyyUg4RW7ztzLYkyuNLNudpkNF7rKBhwW+DhKuUH xjiwWFnh28P4NegmRtMWf062gJ1i5Ozk+LTnBSiLPmG5VqWzRS VZ+bxy6L14fi5yELASgoOY/rEcVS2K2W7ZqMlGjVgd0sejd4QN wNcOvuaG+2cBOpnJQEntm3MR60+8s6FHfiwAHdqxn6KGRxAVgi 7Xp0t9pdhFLWg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/S73kpD8lEYdWFHonIke7nLYzWk8 Cc: "dmm@ietf.org" Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" 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, 11 Sep 2014 06:37:23 -0000 Hi Fred, Actually, you had provided the description of the scenario w/o any = references to the solutions (AERO, MIP, etc.). So, I asked if that scenario could already be handled using existing MIP = protocol. I didn't imply it couldn't be done using AERO. Alper On Sep 10, 2014, at 11:21 PM, Templin, Fred L wrote: > Hi Alper, >=20 >>>> Can this scenario not be realized by simply placing an HA in the >>>> enterprise network and using Mobile IP? >=20 > You did not respond to say whether your question was answered. > I think it is also fair to ask the opposite question: >=20 > "Are there scenarios for MIP-based solutions that cannot be realized > by simply placing an AERO Server in the network and using AERO?" >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L >> Sent: Thursday, September 04, 2014 7:51 AM >> To: Alexandru Petrescu; dmm@ietf.org >> Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device = User" >>=20 >> Hi Alex and Alper, >>=20 >>> -----Original Message----- >>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru = Petrescu >>> Sent: Thursday, September 04, 2014 2:50 AM >>> To: dmm@ietf.org >>> Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device = User" >>>=20 >>> Le 04/09/2014 08:47, Alper Yegin a =E9crit : >>>> Hi Fred, >>>>=20 >>>> Can this scenario not be realized by simply placing an HA in the >>>> enterprise network and using Mobile IP? >>>=20 >>> I guess yes and no. >>>=20 >>> YEs, in that it is a typical Mobile IP scenario with handovers >>> WiFi/4G/Ethernet. >>=20 >> Handovers between diverse access technologies is one aspect of the >> proposal, yes. The ability to coordinate multiple access technologies >> simultaneously is also included as part of the architecture, but some >> future work needs to be done to put that into practice. >>=20 >>> No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not >>> working well together. >>=20 >> Right - switching between VPN and non-VPN will be important for >> enterprise network mobile device users. >>=20 >>> No, in that TIP (DHCPv6 Prefix Delegation?) is not clear how to work >>> with a EUD device ID? Is it Ethernet's, WiFi's or 4G's interface = MAC >>> address? >>=20 >> The mobile device applies the TIP to its downstream-attached >> interfaces and not to the access technology interfaces over >> which the prefix delegation was received. So the mobile device >> is really a mobile router. >>=20 >> But, maybe you are asking where does the mobile device get its >> Device-Unique Identifier (DUID) so it can talk to the DHCPv6 >> server? The DUID need not be based on a MAC address, but could >> be some other unique ID assigned to the mobile. So, there is >> no confusion about which MAC address to choose. >>=20 >>> No, in that Mobile IP and prefixes are not known to lead to optimal >>> routes, whereas the scenario says "optimal routes". >>=20 >> Route optimization is indeed a key aspect of the proposal, and >> in fact hard-coded into the name "AERO". Another key aspect is >> the in-built distributed mobility management (dmm) architecture. >> The enterprise can from day one deploy hundreds or even >> thousands of AERO servers, and the mobile devices simply >> associate with one or more that are close by. Beyond that, it >> doesn't matter which server the mobile associates with - it >> will get the same service as from any other server. >>=20 >>> No - but this is a stretch - the scenario does not mention the >>> neceessity of user typing secure information on a screen = (authenticate >>> to web page on a public hotspot prior to ability to Mobile IP, or = use >>> One-Time Password tokens for VPN connections); any "seamless" = mobility >>> mechanism will need to automate this step; this is even more needed = when >>> considering devices without user interfaces, such as Mobile Routers >>> using Mobile IP for a vehicle. >>=20 >> Aspects of how the VPN link is established (enter password, >> insert active badge, etc.) are not discussed, but not really >> relevant to the way in which AERO can provide the mobile with >> a stable TIP that never changes. Just that the faster the VPN >> link can be established, the faster the mobile device can resume >> service as if it were still coming in through an on-campus >> enterprise network access link. >>=20 >> There is still more to this, such as how AERO can provide an >> assured path MTU over the tunnel, etc. There should also be >> an expanded use case analysis. I have been coming at this from >> an enterprise network viewpoint, but as far as I know AERO >> could also be applied in the traditional use cases envisioned >> for MIPv6 and its derivatives. So, it would be good to have >> some of the experts from this community examine the proposal >> and provide a comparative analysis. >>=20 >> Thanks - Fred >> fred.l.templin@boeing.com >>=20 >>> Alex >>>=20 >>>>=20 >>>> Alper >>>>=20 >>>>=20 >>>> On Sep 3, 2014, at 7:37 PM, Templin, Fred L wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> The specific passage from the new draft that I wanted the wg to >>>>> see is the following (with references to AERO removed). Please >>>>> review and send questions or comments. >>>>>=20 >>>>> Thanks - Fred fred.l.templin@boeing.com >>>>>=20 >>>>> --- >>>>>=20 >>>>> 3. A Day in the Life of an Enterprise Mobile Device User >>>>>=20 >>>>> An enterprise network mobile device user ("Bill") begins his >>>>> workday by seating his primary end user device (EUD) (e.g., a >>>>> laptop computer, a tablet, a smart phone, etc.) in a docking >>>>> station at his office desk and turning the device on. The docking >>>>> station connects Bill's EUD to the enterprise wired LAN, and the >>>>> EUD receives a Topologically-Fixed Address (TFA) from the >>>>> infrastructure. Bill's EUD further discovers the DMM service >>>>> within the enterprise network and requests a Topology Independent >>>>> Prefix (TIP)delegation. Bill's EUD receives the same TIP >>>>> delegation it gets every time it connects to the enterprise >>>>> network, because the DMM service has an administratively set >>>>> mapping between the TIP and Bill's EUD device ID. >>>>>=20 >>>>> Bill's EUD can then access topologically-fixed enterprise services >>>>> using its TFA directly, and can access DMM services by using an >>>>> address from its TIP as the source address for tunneling over the >>>>> enterprise network. As Bill's workday unfolds, his EUD uses the >>>>> DMM service to correspond with other EUDs in peer-to-peer >>>>> sessions, join lengthy virtual conferencing sessions, access >>>>> enterprise fileshares, etc. The DMM service ensures that optimal >>>>> routes are maintained so that tunneled communications flow over >>>>> direct paths and network infrastructure elements are not >>>>> unnecessarily over-burdened. >>>>>=20 >>>>> While communications sessions such as the video conference are >>>>> still in progress, Bill leaves the office to attend a meeting in a >>>>> nearby conference room. He disconnects his EUD from the docking >>>>> station and in the process drops his connection to the wired LAN. >>>>> The EUD quickly enables a WiFi interface that searches for a >>>>> Service Set Identifier (SSID) that can provide wireless access >>>>> within the enterprise network. The EUD authenticates itself to >>>>> the network via the SSID using its pre-loaded certificates, and >>>>> uses a securing mechanism such as IEEE 802.1x to assure >>>>> Confidentiality, Integrity and Availability (CIA). The EUD >>>>> receives a new TFA from the network, then communicates its new >>>>> TIP-to-TFA association to the DMM service and any active peer >>>>> correspondents. Any ongoing communications sessions will continue >>>>> to see the same (stable) TIP. >>>>>=20 >>>>> Bill then leaves the enterprise campus to attend an off-site >>>>> customer meeting with his EUD still powered on and actively >>>>> seeking to maintain network connectivity. As Bill departs from >>>>> the building, the WiFi signal fades until it can no longer support >>>>> communications, and the EUD quickly enables a 4G cellular wireless >>>>> interface that connects Bill's EUD to a cellular service provider. >>>>> The EUD then locates the Internet address of an enterprise network >>>>> security gateway and initiates a VPN session with the gateway >>>>> (which also acts participates in the DMM service). The DMM >>>>> service updates the routing system, and Bill can continue to use >>>>> the same TIP that was assigned to his EUD when he started his >>>>> workday even though the EUD is now communicating over a VPN >>>>> configured over the public Internet instead of over the secured >>>>> campus LAN. >>>>>=20 >>>>> Bill subsequently arrives at the customer meeting at a public >>>>> restaurant with a WiFi hotspot. His EUD quickly powers up its = WiFi >>>>> interface and powers down the 4G interface. The EUD uses DMM >>>>> signaling to communicate the new TFA to the security gateway and >>>>> the VPN survives the mobility event. Moreover, the EUD can >>>>> continue to use the same TIP it received at the beginning of the >>>>> workday, and ongoing communication sessions can continue until >>>>> Bill explicitly discontinues them. >>>>>=20 >>>>> After the customer meeting, Bill leaves the restaurant and >>>>> subsequently passes through several additional transitions from >>>>> WiFi hotspots to 4G wireless. Again, the DMM service keeps the = VPN >>>>> session alive, and the TIP assigned to the EUD remains in >>>>> continuous use in active communication sessions as well as to >>>>> allow Bill to receive notifications and process urgent requests. >>>>> When Bill returns to his office, the EUD discontinues use of the >>>>> VPN while keeping its TIP active after re-attaching to the campus >>>>> LAN. >>>>>=20 >>>>> Bill ends his workday, powers down his EUD and returns home. Bill >>>>> powers on his EUD to check e-mails, and connects to the enterprise >>>>> network via a VPN configured over his home ISP service. The EUD >>>>> again receives the same TIP that it used within the enterprise >>>>> network domain, and Bill can access DMM services the same as if he >>>>> was in the office. Bill finally shuts down for the evening, and >>>>> begins his next workday in the same fashion. Again, the EUD >>>>> receives the same TIP as always regardless of the access network >>>>> point of connection over which the EUD enters the enterprise. >>>>>=20 >>>>>> -----Original Message----- From: dmm >>>>>> [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: >>>>>> Tuesday, September 02, 2014 11:05 AM To: dmm@ietf.org Subject: >>>>>> [DMM] FW: I-D Action: draft-templin-aeroent-00.txt >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> During the call today, there was some interest expressed in >>>>>> learning more about the enterprise network mobility use case. I >>>>>> have submitted a new brief document called "AERO Enterprise >>>>>> Network Profile" (below) that provides a discussion of >>>>>> distributed mobility management needs for enterprise networks. >>>>>> Although the document specifically cites AERO, the use case >>>>>> applies to any solution alternative that could meet the >>>>>> requirements. Also, I am not asking this document be considered >>>>>> as a dmm wg item at this time, but rather offering it for >>>>>> informational purposes. Please let me know if there are any >>>>>> questions or comments. >>>>>>=20 >>>>>> Thanks - Fred fred.l.templin@boeing.com >>>>>>=20 >>>>>> -----Original Message----- From: I-D-Announce >>>>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>>>>> internet-drafts@ietf.org Sent: Tuesday, September 02, 2014 10:51 >>>>>> AM To: i-d-announce@ietf.org Subject: I-D Action: >>>>>> draft-templin-aeroent-00.txt >>>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line >>>>>> Internet-Drafts directories. >>>>>>=20 >>>>>>=20 >>>>>> Title : AERO Enterprise Network Profile Author : Fred >>>>>> L. Templin Filename : draft-templin-aeroent-00.txt Pages >>>>>> : 12 Date : 2014-09-02 >>>>>>=20 >>>>>> Abstract: Enterprise networks provide a secured data >>>>>> communications infrastructure built for the purpose of >>>>>> information sharing and increased productivity for end users >>>>>> within the organization. Enterprise networks are often organized >>>>>> as private Internets unto themselves that connect to the global >>>>>> Internet either not at all or via firewalls, proxies, and/or >>>>>> other network securing devices. This document discusses an AERO >>>>>> enterprise network profile that outlines new and more flexible >>>>>> methods for connecting, tracking and managing mobile >>>>>> organizational assets. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-templin-aeroent/ >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-templin-aeroent-00 >>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ I-D-Announce >>>>>> mailing list I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>>=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 >>>>=20 >>>> _______________________________________________ dmm mailing list >>>> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm >>>>=20 >>>>=20 >>>=20 >>>=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 Wed Sep 10 23:39:17 2014 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 B42F11A04D2 for ; Wed, 10 Sep 2014 23:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 v58sgAcW8t4X for ; Wed, 10 Sep 2014 23:39:14 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 779B21A04B4 for ; Wed, 10 Sep 2014 23:39:14 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0Mhk8L-1XfO3P1q2F-00MxPz; Thu, 11 Sep 2014 08:39:09 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <3AE602C1-2927-4999-8552-6BA5F03C2C35@yegin.org> Date: Thu, 11 Sep 2014 09:39:02 +0300 Content-Transfer-Encoding: 7bit Message-Id: <686AD61A-799B-479A-915D-F8E49C00AA6C@yegin.org> References: <54106584.2030203@gmail.com> <3AE602C1-2927-4999-8552-6BA5F03C2C35@yegin.org> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:ST+d4rX4gQpxMiqHhBEGhxX8pYd3xOnBIGpTOg5q3rt c3eYypKN1Ul0thdO3iMPDg6LU+VNvNCpL4yiKinn1vcCNn7nVS cM55e0F1NohOQou/sXyOLcWA5r9rPYHXmuq3ye2+G2gTKBGcgC GWBOOtPz4kTugp/he0a70iyLzCGcYI7EVZ8cBGRnVoBhmMgyEK ZjeGELWThVpd9GWxQiaDs8KRnbeTh6O33FsldV3VTpn1RQjy0B 5l41Sls7QA3LWbKRQO88usgq6BtJoXiQqTpz3vkBaYXiA+NXDh p5izpU0784waYHAGAt+6NnnbYEe9kLIgr/CdwBJ2kBWkHULyFe /PXsEuiEz+c4pCrDP7INTJJlT08GKsDxNki8gyCe61Ho3RVyN1 vaKVLSZJAPIaA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/AgIjXAnANA1H5OyKrw6pTIQZCCo Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] qyery DMM interim call #3 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, 11 Sep 2014 06:39:15 -0000 Let's doodle. On Sep 10, 2014, at 8:38 PM, Alper Yegin wrote: > Jouni, > > That date does not work for me. > > > Alper > > On Sep 10, 2014, at 5:51 PM, Jouni Korhonen wrote: > >> Folks, >> >> Potential place for the interim call #3 would be: >> #3 30-Sep-2014 5PM EEST >> >> Unless there is heavy opposition, we'll go for this. >> >> - 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 Sep 11 00:28:21 2014 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 AE76D1A6F4C for ; Thu, 11 Sep 2014 00:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 YQz0E87y3gFr for ; Thu, 11 Sep 2014 00:28:16 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA4D1A0601 for ; Thu, 11 Sep 2014 00:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4036; q=dns/txt; s=iport; t=1410420495; x=1411630095; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=rB8+5V1dZRuDD+XTDcH+ZJHagg5YafqN4gSNcUJ+aVw=; b=MOmD8W76DrQv7ZYc+oqSmSmRB9jdOaXDFG2V2DblbSPZrlEeVTaeQ3xa oGy0YOnX3jSedLc3YXxz5dKslihyJTwpURCN5w3B4aK+EeedF1yu+Rw+V ZjyvfB50IROmZDsBTjM6YnIU9pzvFnIQLBKYy6RtfveaWPo73dcp3rVHA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAJVOEVStJA2B/2dsb2JhbABggw1TVwTILAqHTQGBChZ4hAMBAQEEAQEBCWILDAYBCBEEAQEBJygGCxQJCAIEAQ0FG4gTAxENuGUNhmIBEwSNIIICKwcGhEYFiwCGSYkjghCOfIY9g2FsAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,504,1406592000"; d="scan'208";a="76915399" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 11 Sep 2014 07:28:14 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8B7SEvK030542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 07:28:14 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 02:28:14 -0500 From: "Sri Gundavelli (sgundave)" To: "Templin, Fred L" , Jouni Korhonen , "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzZHygEHdrpfrGEu7bKsCg1HKXg== Date: Thu, 11 Sep 2014 07:28:14 +0000 Message-ID: In-Reply-To: <2134F8430051B64F815C691A62D9831832D1590D@XCH-BLV-504.nw.nos.boeing.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.21.64.105] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6AE8FCACB79AAD44BBC9AB853D9C268E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Ss7JM3E5___7Pj7JhJUqmDyvclU Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 11 Sep 2014 07:28:17 -0000 Hi Fred, The below comment from you made me thinking. I must admit I'm not much familiar with Aero, have not seen its references in CDMA, WiMAX, CableLabs, WLAN or LTE architectures. But, if it has all the mobility features and you believe this can conclude the WG, I thought I will explore this a bit. I started reviewing the charts that you sent and started browsing some of the specs. Few high-level questions, if you can answer or point me to some documents, it will be great. 1.) What is the interface between the Aero Server and the client ? Is it just DHCPv6 ? There is no other signaling interface ? 2.) What is the service authorization model for a Aero client ? How is the client identified by the server ? What is the security model ? 3.) Can the Aero solution support IP nodes that do not have Aero client stack ? 4.) If a mobile or a cable SP deploys Aero, where is their point of control ? Where can they do Accounting, Lawful interception ? 5.) I assume Aero client can be IPv4 or an IPv6 device ? For an IPv4-only legacy device, is the interface DHCPv4 ? 6.) Can an operator enable location-based services for a Aero client ? 7.) How can an operator enable IP Flow Mobility type features in an Aero system ? 8.) Taking a mobile router scenario, how does Aero client support multi-tenancy ? Is there a single tunnel between the client and the server ? Regards Sri On 9/10/14 11:43 AM, "Templin, Fred L" wrote: >Hi Jouni, > >I'd like to propose a slightly different charter: > > "AERO already solves distributed mobility management and provides a > a comprehensive mobility solution for any mobile device. AERO should > therefore be approved as the mobility management solution for DMM. > Publication of AERO will therefore conclude the working group's > activity." > >Can we have this on the agenda? > >Thanks - Fred >fred.l.templin@boeing.com > >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Wednesday, September 10, 2014 11:37 AM >> To: sarikaya@ieee.org >> Cc: Dapeng Liu; dmm@ietf.org >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming >>=20 >>=20 >> What do you mean by no agenda? To me it clearly says we use the call #2 >> for setting up the work split. >>=20 >> - Jouni >>=20 >> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: >> > Jouni, why don't we cancel this one (#2) and do the next one (#3) with >> > an agenda? >> > I hope Alper can attend :-) >> > >> > Regards, >> > >> > Behcet >> > >> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen >> wrote: >> >> >> >> It seems I sent this to a wrong receiver.. that explains why it did >>not >> >> appear on the list. >> >> >> >> - Jouni >> >> >> >> -------- Alkuper=E4inen viesti / Orig.Msg. -------- >> >> Aihe: DMM Interim call #2 - agenda forming >> >> P=E4iv=E4ys: Mon, 08 Sep 2014 23:43:24 +0300 >> >> L=E4hett=E4j=E4: Jouni Korhonen >> >> Vastaanottaja: dmm-ads@tools.ietf.org >> >> CC: jouni.nospam@gmail.com, Dapeng Liu >> >> >> >> Folks, >> >> >> >> The next interim is close. Assuming there are no overwhelming amount >>of >> >> comments to the re-charter text, we are ready to start setting up the >> >> work split on the solution space! Remember the discussion and the >> >> minutes from the IETF#90 Friday session. No other agenda items are >> >> planned for the next interim. >> >> >> >> - Jouni & Dapeng >> >> >> >> >> >> _______________________________________________ >> >> 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 >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Sep 11 01:42:05 2014 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 691001A0687 for ; Thu, 11 Sep 2014 01:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 2ahQHeK6VlJh for ; Thu, 11 Sep 2014 01:42:02 -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 D602F1A0108 for ; Thu, 11 Sep 2014 01:42:02 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus003) with ESMTP (Nemesis) id 0Mabjb-1XlSkH0t1l-00K7cB; Thu, 11 Sep 2014 10:42:01 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <54109247.4090500@gmail.com> Date: Thu, 11 Sep 2014 11:41:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <540E14EC.8070404@gmail.com> <54109247.4090500@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:n089SeZZ42jobVDuIlHfvOlUJZ8/ghkj5BODO6/QEtv 0HQlynvTN62HOzaLExQ1I/w6eW7hqv7mnzkrwpsGGO9KR9RCSq z/mHaRTUoQnLQkLzLjqooXKE3OWPSRA1wwwCfE9yvgdg1G3DY6 a2BgbZ+s2YJizYURY/SYZEXBZ8YZVaUe3027VbTQk1tGntmnHj TdnFlLiIQNTU6IP+vdmmlJrzCku1qpIGX7wZajl7v4en1GB1Xf YvryVTSkS1NXT6BLlpDOAWH2EmYFL7BpjehH+3Mg4+qalNMM43 pqRwX9kmStrSGEYko96jXgwZnDyFXOMzWSl7ZEe8qHUBwED6ds KEc/8rS17XgofGIM3VklnH8vxbDdjQ3tO+xd5LSoZEioHN7BCd nP+B/v63C6ATA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/sr9Wb6Sbeo0zMB6jn0LHSBhwnro Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 11 Sep 2014 08:42:04 -0000 Folks, Here's a proposal for scoping out the DMM work and identifying areas to = tackle. http://yegin.org/NGmobility/IETF_DMM_WG_work_scoping.pptx I can present this at the upcoming DMM call. It'd be very good if people = can read and send comments/questions on the list in advance. Cheers, Alper On Sep 10, 2014, at 9:02 PM, Jouni Korhonen wrote: >=20 > It seems I sent this to a wrong receiver.. that explains why it did = not appear on the list. >=20 > - Jouni >=20 > -------- Alkuper=E4inen viesti / Orig.Msg. -------- > Aihe: DMM Interim call #2 - agenda forming > P=E4iv=E4ys: Mon, 08 Sep 2014 23:43:24 +0300 > L=E4hett=E4j=E4: Jouni Korhonen > Vastaanottaja: dmm-ads@tools.ietf.org > CC: jouni.nospam@gmail.com, Dapeng Liu >=20 > Folks, >=20 > The next interim is close. Assuming there are no overwhelming amount = of > comments to the re-charter text, we are ready to start setting up the > work split on the solution space! Remember the discussion and the > minutes from the IETF#90 Friday session. No other agenda items are > planned for the next interim. >=20 > - Jouni & Dapeng >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Sep 11 02:04:12 2014 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 11C001A0697 for ; Thu, 11 Sep 2014 02:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.254 X-Spam-Level: X-Spam-Status: No, score=-4.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-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 KvJXuA76rF2q for ; Thu, 11 Sep 2014 02:04: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 154B41A068A for ; Thu, 11 Sep 2014 02:04:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D0DC2107EDA; Thu, 11 Sep 2014 11:04:06 +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 hbj_7vhI-cvR; Thu, 11 Sep 2014 11:04:06 +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 AE785107ED8; Thu, 11 Sep 2014 11:03:58 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.88]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 11 Sep 2014 11:03:58 +0200 From: Marco Liebsch To: "Sri Gundavelli (sgundave)" , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPp4lB4DM2zhzjQk2BPAsjwbgBU5u2760AgAE+DgCACXRoAIAMxHwAgAAPCACACYjsAIAT+UaAgAAUBoCAAHpbAIAAL/CAgAG1KoCAAI37gIAAvK4AgAACNICAAAWVAIAACByAgAAUmACAAAWVAIABAUAAgAF6iICAAIw+AIAEC7GAgAC2QwCAAP+QgIAAvvIAgAAOp4CAAALBAIABLIIQ///8CACAAHgWAIAABZ4AgADNVnA= Date: Thu, 11 Sep 2014 09:03:57 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D91A60559@DAPHNIS.office.hd> References: <5410CEF2.2010809@earthlink.net> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/C9sLDFk45211q4uvme8GNBZElq8 Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 11 Sep 2014 09:04:11 -0000 No issue with logical vs. physical ID. But I am wondering about two things: Operation is clear to me in case a single MNID is present in a message and = I see the value in being flexible to choose from different sub-types. If multiple MNIDs with differe= nt sub-types are present in a single message, which one should e.g. the LMA take for the BC lookup.. No= big problem to solve, but to be considered in implementations.=20 If the reason for multiple present MNIDs with different sub-types is to do = other things than identifying the node or using the ID as key for a lookup, I am wondering if it would no= t be more appropriate to go for a different container option to carry such information. Something= like a complementary identifier option. marco >-----Original Message----- >From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] >Sent: Donnerstag, 11. September 2014 00:42 >To: Charlie Perkins; Marco Liebsch; dmm@ietf.org >Cc: Vijay Devarapalli >Subject: Re: [DMM] regarding the re-chartering.. > >Hello Charlie, > >Agree with that. MN-Id as its defined today is a logical identifier. It do= es not >require the identifier to be bound to a physical device or a interface ide= ntity. >But, we have clearly seen requirements where the need is for generating >identifiers based on some physical identifiers. Those physical identifiers= include >IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the sou= rce >and the rules for generating MN-ID based using those sources, the sender a= nd >receiver will have clear guidance on how to use the spec. Some pointers, >explanation and examples for each of those identifiers will greatly help a= void >inter-op issues. > > >Regards >Sri > > > > > > > >On 9/10/14 3:21 PM, "Charlie Perkins" >wrote: > >> >>Hello folks, >> >>I think it's best to consider the MNID as simply living in a space of >>identifiers, and not worry too much about whether it's a logical >>identifier or a physical identifier. If the former, then somewhere >>(perhaps below the network layer) the logical identifier has been bound >>to something in the physical interface, but that's not our problem. >> >>The number space for types of MNIDs is likely to stay pretty empty, so >>I'd say we could add as many types as would be convenient for the >>software designers. So, we could conceivably have several MNIDs >>defined that all "looked like" NAIs (which, themselves, "look like" >>FQDNs). >> >>Regards, >>Charlie P. >> >> >> >>On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote: >>> Yes. Currently, the MNID is if the nai format and is overloaded. The >>>MNID in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the >>>IMSI. Ex: >>> "@epc.mnc.mcc.3gppnetwork.org=B2 >>> >>> We also have MAC48@REALM; >>> >>> We also have approaches to transform MAC to Pseudo IMSI, and then >>> carry IMSI-NAI as the MN-ID. >>> >>> >>> So, we need unique sub-types for each of the types/sources. >>> >>> MN-Id based on IMSI, MSISDN, IMEI, MAC .. >>> >>> Also, do we need to distinguish between IMSI and IMSI-NAI ? >>> >>> Sri >>> >>> >>> >>> On 9/10/14 6:29 AM, "Marco Liebsch" wrote: >>> >>>> It seems the MNID is somehow overloaded to carry both, node-specific >>>>IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI. >>>> There may be value in adding the IMEI to the list of possible types >>>>of node-specific IDs. >>>> >>>> marco >>>> >>>>> -----Original Message----- >>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >>>>> (sgundave) >>>>> Sent: Dienstag, 9. September 2014 23:30 >>>>> To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org >>>>> Cc: Vijay Devarapalli >>>>> Subject: Re: [DMM] regarding the re-chartering.. >>>>> >>>>> Two more comments. >>>>> >>>>> >>>>> >>>>> 4.) I'd also use sub-type value of (2) for IMSI. Just to align with >>>>>the sub-types defined for MN Id defined for ICMP. I suspect there >>>>>are some implementations already using sub-type (2). Please see >>>>>the other thread. >>>>> >>>>> >>>>> 5.) For each of the sub-types, we need text including examples and >>>>>some >>>>> explanation on how they are used. >>>>> >>>>> >>>>> Sri >>>>> >>>>> >>>>> >>>>> On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" >>>>> wrote: >>>>> >>>>>> Hi Charlie, >>>>>> >>>>>> This is good. Thanks. >>>>>> >>>>>> >>>>>> 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.= 2 >>>>>> address, why do we need to two sub-types ? Why not have just one >>>>>> sub-type for mac based identifiers ? >>>>>> >>>>>> 2.) Sub type value (1) is currently used. Its currently overloaded >>>>>>for >>>>>> IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the >>>>>> definition of new sub-types, we need some text explaining the >>>>>> motivation >>>>>> >>>>>> 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is >>>>>> this ? Are these CGA-based IPv6 addresses ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> New Mobile Node Identifier Types >>>>>> >>>>>> +-----------------+------------------------+ >>>>>> | Identifier Type | Identifier Type Number | >>>>>> +-----------------+------------------------+ >>>>>> | IPv6 Address | 2 | >>>>>> | | | >>>>>> | IMSI | 3 | >>>>>> | | | >>>>>> | P-TMSI | 4 | >>>>>> | | | >>>>>> | EUI-48 address | 5 | >>>>>> | | | >>>>>> | EUI-64 address | 6 | >>>>>> | | | >>>>>> | GUTI | 7 | >>>>>> +-----------------+------------------------+ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> Sri >>>>>> PS: Good to see Vijay back >>>>>> >>>>>> >>>>>> On 9/9/14 1:28 PM, "Charlie Perkins" >>>>>> wrote: >>>>>> >>>>>>> Hello folks, >>>>>>> >>>>>>> Here's the last Internet Draft that we did, long ago expired: >>>>>>> http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt >>>>>>> >>>>>>> I'll resubmit it with a few updates as a personal draft to dmm. >>>>>>> >>>>>>> Regards, >>>>>>> Charlie P. >>>>>> _______________________________________________ >>>>>> 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 Sep 11 05:27:50 2014 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 5CEDE1A0709 for ; Thu, 11 Sep 2014 05:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.23 X-Spam-Level: X-Spam-Status: No, score=-3.23 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, GB_I_INVITATION=-2, RCVD_IN_SORBS_WEB=0.77, 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 3BPPfw8bQ2Dm for ; Thu, 11 Sep 2014 05:27:45 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84351A06F2 for ; Thu, 11 Sep 2014 05:27:44 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so2673164qcy.29 for ; Thu, 11 Sep 2014 05:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e6Fecn1yJFE68OCGtcLkLAE1vZbwvaUJpjBzPqKM/4Y=; b=ZPznK2ZbjCoJX9kPyNYivHRp9Y0ROQxyRAuvy7BGnjY8hxJZ/ji7Qg4july3CjCAnV uiQhiOde7hIryuDtY/K+eNGPItImM3JMLbP1l8dHF1XbFtaSPRSp45A0k3ckP0r76GnX yWu0HnusCogxCV1/VaBiJfFwIp0KLVTMq0SMBUHfyw9rogNoDM/TBiX6nYZafRISDOHX Z9AaMQC0w4We+RF8Phi+EHyStjNwwm0Zcasgb1U6XeOv//G0xoh2qcFzeVfg5MtaYdct 5CP23/RNg3yevtKOl4P7nLFJ4e0/ffP1onD3Mwjsx5L6SekmBb117e5f6kflhEdo4v8G 1L0Q== X-Received: by 10.224.129.1 with SMTP id m1mr1110201qas.0.1410438463403; Thu, 11 Sep 2014 05:27:43 -0700 (PDT) Received: from [10.201.5.61] ([209.29.74.150]) by mx.google.com with ESMTPSA id h2sm490521qah.35.2014.09.11.05.27.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 05:27:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jouni X-Mailer: iPhone Mail (11D257) In-Reply-To: <686AD61A-799B-479A-915D-F8E49C00AA6C@yegin.org> Date: Thu, 11 Sep 2014 08:27:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9B201EEA-A58E-44F8-80AF-962F2AEA1B61@gmail.com> References: <54106584.2030203@gmail.com> <3AE602C1-2927-4999-8552-6BA5F03C2C35@yegin.org> <686AD61A-799B-479A-915D-F8E49C00AA6C@yegin.org> To: Alper Yegin Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/wYMWwa0ywGwflRVlByHYRNTVEfw Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] qyery DMM interim call #3 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, 11 Sep 2014 12:27:47 -0000 There is doodle but the invitation intended to the list seems still to be si= tting in my email client.. Sigh. Just a moment and I resend it.=20 --=20 Jouni Korhonen Broadcom (Sent from my mobile..) > Alper Yegin kirjoitti 11.9.2014 kello 2.39: >=20 > Let's doodle. >=20 >> On Sep 10, 2014, at 8:38 PM, Alper Yegin wrote: >>=20 >> Jouni, >>=20 >> That date does not work for me. >>=20 >>=20 >> Alper >>=20 >>> On Sep 10, 2014, at 5:51 PM, Jouni Korhonen wrote: >>>=20 >>> Folks, >>>=20 >>> Potential place for the interim call #3 would be: >>> #3 30-Sep-2014 5PM EEST >>>=20 >>> Unless there is heavy opposition, we'll go for this. >>>=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 >=20 From nobody Thu Sep 11 05:56:54 2014 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 F3F2E1A6FA8 for ; Thu, 11 Sep 2014 05:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 V6SbQJ_SrRlA for ; Thu, 11 Sep 2014 05:56:50 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B151A6F9E for ; Thu, 11 Sep 2014 05:56:50 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id c9so21260179qcz.11 for ; Thu, 11 Sep 2014 05:56:50 -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:cc:subject :content-type:content-transfer-encoding; bh=YsM6yRT+3+ZEQznvCT4Vn0IwzkmpPmtWAyDdR8IPhjo=; b=miQvc/CLf0vpO/DeTQuwZOG9u+WB048rhVHUveJ1o7Uu7SdPenCnskpRrys7sOLtr4 cwN6lFK3g3gi8QmiCzVZPw0+fEIcsBzJga1iyOoZMwwBirsd/Jq0qElQMVGisA0cJ2ko Kzlds6kFMq7pcraOfI03T5JQK4OlXYVBI7+8sYxbPbqb8mEKlUdHoNxWl99vFwJ61Xb8 S1e7gKrG7f4rl/tG6P4klTz5Wo3LCNsL81nik/zXTO2gB3clcCLOkdX7n85xKE1Nr/kD 6N/BcUqNbe4lJVv9JLpnPGuWxNLjdg8B3b7wHj8yxpub670+Rq3AhyezM/8axb+Lfjei 3qhg== X-Received: by 10.229.229.135 with SMTP id ji7mr1201090qcb.15.1410440209990; Thu, 11 Sep 2014 05:56:49 -0700 (PDT) Received: from [10.201.0.70] ([209.29.74.150]) by mx.google.com with ESMTPSA id g65sm538726qgd.36.2014.09.11.05.56.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Sep 2014 05:56:49 -0700 (PDT) Message-ID: <54119C10.6020002@gmail.com> Date: Thu, 11 Sep 2014 15:56:48 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/oyOxgaLCD86PGNZD4oMyhH9mlZI Cc: Dapeng Liu Subject: [DMM] DMM interim call #3 - doodle 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, 11 Sep 2014 12:56:52 -0000 Folks, For the call #3 express your preference by Friday 12th EOB PDT. http://doodle.com/kpwphfbtgmtsde3s - Jouni & Dapeng From nobody Thu Sep 11 06:58:17 2014 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 1FB0A1A005E for ; Thu, 11 Sep 2014 06:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 HWIUHamVNCYV for ; Thu, 11 Sep 2014 06:58:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6131A0023 for ; Thu, 11 Sep 2014 06:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11434; q=dns/txt; s=iport; t=1410443892; x=1411653492; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TUl4Qb1b1EL3rxEdFPjhoezdVMrQ3F4QDwih8p5KkgA=; b=S2nGt6NodtJGpUO36Rt76Gs23a6WuBX5Ri14OssJi5gLE3TGFe8FX5yv pjoi1qAqWCqIxY/wav9qORE9UIrvOl6fBcT9/A7thTNNQbhWiApbuZKCY uHhoEBiuxRxyAx1ala2L65soEisMUdCj0AKVfQmBxarqbJ56ueXmSCqDX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAICpEVStJA2F/2dsb2JhbABWCYMNU1cEgnjFQAqHTQEZdxZ4hAMBAQEDAQEBATE6CwUHBgEIEQQBAQEECRoFBCULFAkIAgQBDQUJiCUDCQgNjFicPQaVPgEXgSaLeoFSMBAbBwICAoJtgVkFhh2LLIszlTmDYWwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,506,1406592000"; d="scan'208";a="354386952" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 11 Sep 2014 13:58:10 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s8BDw9Zq019272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 13:58:10 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 08:58:09 -0500 From: "Sri Gundavelli (sgundave)" To: Marco Liebsch , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzchrFTJi/s504kOP81QcxzozOA== Date: Thu, 11 Sep 2014 13:58:09 +0000 Message-ID: In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D91A60559@DAPHNIS.office.hd> 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.21.64.105] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/di38MF9en54Nv7vnl66RjgCHvjs Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 11 Sep 2014 13:58:15 -0000 SSBkbyBub3Qgc2VlIGEgcmVhc29uIHdoeSBtdWx0aXBsZSBNTi1JZCBpbnN0YW5jZXMgbmVlZCB0 byBiZSBwcmVzZW50IGluIGENCnNpbmdsZSBtZXNzYWdlID8gSW4gbXkgZXhwZXJpZW5jZSwgdGhp cyBpcyBzdHJpY3RseSBhIGRlcGxveW1lbnQNCmNvbnNpZGVyYXRpb24sIHdoZW4gdG8gdXNlIHdo YXQgdHlwZSBvZiBpZGVudGlmaWVycy4NCg0KQXNzdW1pbmcgdGhlIGJhY2tlbmQgc3lzdGVtIGNh biB0aWUgYWxsIHRoZSBNTi1JZCdzIHRvIGEgc2luZ2xlDQpzdWJzY3JpcHRpb24sIGFueSBwcmVz ZW50ZWQgaWRlbnRpZmllciBjYW4gYmUgc3VmZmljaWVudCBmb3IgdGhlIGdhdGV3YXkNCnRvIGRv IHRoZSBCQ0UgbG9va3VwLg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5jZXMgY2FuIGJlIHByZXNlbnQs IHRoZW4gd2UgbmVlZCB0byBkZWFsIHdpdGggbW9yZSBlcnJvcg0KY2FzZXMuIElzIHRoYXQgcmVh bGx5IG5lZWRlZCA/DQoNCg0KPiBJIGFtIHdvbmRlcmluZyBpZiBpdCB3b3VsZCBub3QgYmUgbW9y ZSBhcHByb3ByaWF0ZSB0byBnbyBmb3IgYSBkaWZmZXJlbnQNCj5jb250YWluZXIgb3B0aW9uIHRv IGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24uIFNvbWV0aGluZyBsaWtlIGENCj5jb21wbGVtZW50YXJ5 IGlkZW50aWZpZXIgb3B0aW9uLg0KDQpTb3VuZHMgaW50ZXJlc3RpbmcuIEFyZSB5b3Ugc3VnZ2Vz dGluZyB3ZSBsZWF2ZSB0aGUgY3VycmVudCBNTi1JRCBhcyBpdA0KaXMsIGJ1dCB1c2UgYSBuZXcg Y29tcGxlbWVudGFyeSBvcHRpb24gPyBCdXQsIGlmIHRoZSByZXF1aXJlbWVudCBpcyBmb3IgYQ0K TWFjIGJhc2VkIGlkZW50aWZpZXJzLCB3aGF0IHdpbGwgYmUgdGhlcmUgaW4gdGhlIGN1cnJlbnQg TU4tSWQgb3B0aW9uID8gV2UNCnN0aWxsIG5lZWQgdG8gaGF2ZSBpZGVudGlmaWVyIHRoZXJlID8N Cg0KDQoNCg0KU3JpDQoNCg0KDQoNCg0KT24gOS8xMS8xNCAyOjAzIEFNLCAiTWFyY28gTGllYnNj aCIgPE1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PiB3cm90ZToNCg0KPk5vIGlzc3VlIHdpdGggbG9n aWNhbCB2cy4gcGh5c2ljYWwgSUQuIEJ1dCBJIGFtIHdvbmRlcmluZyBhYm91dCB0d28NCj50aGlu Z3M6DQo+DQo+T3BlcmF0aW9uIGlzIGNsZWFyIHRvIG1lIGluIGNhc2UgYSBzaW5nbGUgTU5JRCBp cyBwcmVzZW50IGluIGEgbWVzc2FnZQ0KPmFuZCBJIHNlZSB0aGUgdmFsdWUgaW4gYmVpbmcNCj5m bGV4aWJsZSB0byBjaG9vc2UgZnJvbSBkaWZmZXJlbnQgc3ViLXR5cGVzLiBJZiBtdWx0aXBsZSBN TklEcyB3aXRoDQo+ZGlmZmVyZW50IHN1Yi10eXBlcyBhcmUgcHJlc2VudCBpbg0KPmEgc2luZ2xl IG1lc3NhZ2UsIHdoaWNoIG9uZSBzaG91bGQgZS5nLiB0aGUgTE1BIHRha2UgZm9yIHRoZSBCQyBs b29rdXAuLg0KPk5vIGJpZyBwcm9ibGVtIHRvIHNvbHZlLCBidXQNCj50byBiZSBjb25zaWRlcmVk IGluIGltcGxlbWVudGF0aW9ucy4NCj4NCj5JZiB0aGUgcmVhc29uIGZvciBtdWx0aXBsZSBwcmVz ZW50IE1OSURzIHdpdGggZGlmZmVyZW50IHN1Yi10eXBlcyBpcyB0bw0KPmRvIG90aGVyIHRoaW5n cyB0aGFuIGlkZW50aWZ5aW5nDQo+dGhlIG5vZGUgb3IgdXNpbmcgdGhlIElEIGFzIGtleSBmb3Ig YSBsb29rdXAsIEkgYW0gd29uZGVyaW5nIGlmIGl0IHdvdWxkDQo+bm90IGJlIG1vcmUgYXBwcm9w cmlhdGUNCj50byBnbyBmb3IgYSBkaWZmZXJlbnQgY29udGFpbmVyIG9wdGlvbiB0byBjYXJyeSBz dWNoIGluZm9ybWF0aW9uLg0KPlNvbWV0aGluZyBsaWtlIGEgY29tcGxlbWVudGFyeQ0KPmlkZW50 aWZpZXIgb3B0aW9uLg0KPg0KPm1hcmNvDQo+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PkZyb206IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgW21haWx0bzpzZ3VuZGF2ZUBjaXNj by5jb21dDQo+PlNlbnQ6IERvbm5lcnN0YWcsIDExLiBTZXB0ZW1iZXIgMjAxNCAwMDo0Mg0KPj5U bzogQ2hhcmxpZSBQZXJraW5zOyBNYXJjbyBMaWVic2NoOyBkbW1AaWV0Zi5vcmcNCj4+Q2M6IFZp amF5IERldmFyYXBhbGxpDQo+PlN1YmplY3Q6IFJlOiBbRE1NXSByZWdhcmRpbmcgdGhlIHJlLWNo YXJ0ZXJpbmcuLg0KPj4NCj4+SGVsbG8gQ2hhcmxpZSwNCj4+DQo+PkFncmVlIHdpdGggdGhhdC4g TU4tSWQgYXMgaXRzIGRlZmluZWQgdG9kYXkgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIuIEl0DQo+ PmRvZXMgbm90DQo+PnJlcXVpcmUgdGhlIGlkZW50aWZpZXIgdG8gYmUgYm91bmQgdG8gYSBwaHlz aWNhbCBkZXZpY2Ugb3IgYSBpbnRlcmZhY2UNCj4+aWRlbnRpdHkuDQo+PkJ1dCwgd2UgaGF2ZSBj bGVhcmx5IHNlZW4gcmVxdWlyZW1lbnRzIHdoZXJlIHRoZSBuZWVkIGlzIGZvciBnZW5lcmF0aW5n DQo+PmlkZW50aWZpZXJzIGJhc2VkIG9uIHNvbWUgcGh5c2ljYWwgaWRlbnRpZmllcnMuIFRob3Nl IHBoeXNpY2FsDQo+PmlkZW50aWZpZXJzIGluY2x1ZGUNCj4+SU1TSSwgTVNJU0ROLCBJTUVJLCBN QUMgLi5ldGMuIElmIHdlIGNhbiBkZWZpbmUgYSB0eXBlIGZvciBlYWNoIG9mIHRoZQ0KPj5zb3Vy Y2UNCj4+YW5kIHRoZSBydWxlcyBmb3IgZ2VuZXJhdGluZyBNTi1JRCBiYXNlZCB1c2luZyB0aG9z ZSBzb3VyY2VzLCB0aGUgc2VuZGVyDQo+PmFuZA0KPj5yZWNlaXZlciB3aWxsIGhhdmUgY2xlYXIg Z3VpZGFuY2Ugb24gaG93IHRvIHVzZSB0aGUgc3BlYy4gU29tZSBwb2ludGVycywNCj4+ZXhwbGFu YXRpb24gYW5kIGV4YW1wbGVzIGZvciBlYWNoIG9mIHRob3NlIGlkZW50aWZpZXJzIHdpbGwgZ3Jl YXRseSBoZWxwDQo+PmF2b2lkDQo+PmludGVyLW9wIGlzc3Vlcy4NCj4+DQo+Pg0KPj5SZWdhcmRz DQo+PlNyaQ0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+T24gOS8xMC8xNCAzOjIxIFBN LCAiQ2hhcmxpZSBQZXJraW5zIiA8Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+DQo+Pndy b3RlOg0KPj4NCj4+Pg0KPj4+SGVsbG8gZm9sa3MsDQo+Pj4NCj4+PkkgdGhpbmsgaXQncyBiZXN0 IHRvIGNvbnNpZGVyIHRoZSBNTklEIGFzIHNpbXBseSBsaXZpbmcgaW4gYSBzcGFjZSBvZg0KPj4+ aWRlbnRpZmllcnMsIGFuZCBub3Qgd29ycnkgdG9vIG11Y2ggYWJvdXQgd2hldGhlciBpdCdzIGEg bG9naWNhbA0KPj4+aWRlbnRpZmllciBvciBhIHBoeXNpY2FsIGlkZW50aWZpZXIuICBJZiB0aGUg Zm9ybWVyLCB0aGVuIHNvbWV3aGVyZQ0KPj4+KHBlcmhhcHMgYmVsb3cgdGhlIG5ldHdvcmsgbGF5 ZXIpIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIgaGFzIGJlZW4gYm91bmQNCj4+PnRvIHNvbWV0aGlu ZyBpbiB0aGUgcGh5c2ljYWwgaW50ZXJmYWNlLCBidXQgdGhhdCdzIG5vdCBvdXIgcHJvYmxlbS4N Cj4+Pg0KPj4+VGhlIG51bWJlciBzcGFjZSBmb3IgdHlwZXMgb2YgTU5JRHMgaXMgbGlrZWx5IHRv IHN0YXkgcHJldHR5IGVtcHR5LCBzbw0KPj4+SSdkIHNheSB3ZSBjb3VsZCBhZGQgYXMgbWFueSB0 eXBlcyBhcyB3b3VsZCBiZSBjb252ZW5pZW50IGZvciB0aGUNCj4+PnNvZnR3YXJlIGRlc2lnbmVy cy4gIFNvLCB3ZSBjb3VsZCBjb25jZWl2YWJseSBoYXZlIHNldmVyYWwgTU5JRHMNCj4+PmRlZmlu ZWQgdGhhdCBhbGwgImxvb2tlZCBsaWtlIiBOQUlzICh3aGljaCwgdGhlbXNlbHZlcywgImxvb2sg bGlrZSINCj4+PkZRRE5zKS4NCj4+Pg0KPj4+UmVnYXJkcywNCj4+PkNoYXJsaWUgUC4NCj4+Pg0K Pj4+DQo+Pj4NCj4+Pk9uIDkvMTAvMjAxNCA4OjExIEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRh dmUpIHdyb3RlOg0KPj4+PiBZZXMuIEN1cnJlbnRseSwgdGhlIE1OSUQgaXMgaWYgdGhlIG5haSBm b3JtYXQgYW5kIGlzIG92ZXJsb2FkZWQuIFRoZQ0KPj4+Pk1OSUQgIGluIDNHUFAgc3BlY3MgaXMg dGhlIElNU0ktTkFJIChJTVNJQFJFQUxNKSwgaXRzIGJhc2VkIG9uIHRoZQ0KPj4+PklNU0kuIEV4 Og0KPj4+PiAiPElNU0k+QGVwYy5tbmM8TU5DPi5tY2M8TUNDPi4zZ3BwbmV0d29yay5vcmep9w0K Pj4+Pg0KPj4+PiBXZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07DQo+Pj4+DQo+Pj4+IFdlIGFsc28g aGF2ZSBhcHByb2FjaGVzIHRvIHRyYW5zZm9ybSBNQUMgdG8gUHNldWRvIElNU0ksIGFuZCB0aGVu DQo+Pj4+IGNhcnJ5IElNU0ktTkFJIGFzIHRoZSBNTi1JRC4NCj4+Pj4NCj4+Pj4NCj4+Pj4gU28s IHdlIG5lZWQgdW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBvZiB0aGUgdHlwZXMvc291cmNlcy4N Cj4+Pj4NCj4+Pj4gTU4tSWQgYmFzZWQgb24gSU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi4NCj4+ Pj4NCj4+Pj4gQWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElNU0kgYW5k IElNU0ktTkFJID8NCj4+Pj4NCj4+Pj4gU3JpDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIDkv MTAvMTQgNjoyOSBBTSwgIk1hcmNvIExpZWJzY2giIDxNYXJjby5MaWVic2NoQG5lY2xhYi5ldT4g d3JvdGU6DQo+Pj4+DQo+Pj4+PiBJdCBzZWVtcyB0aGUgTU5JRCBpcyBzb21laG93IG92ZXJsb2Fk ZWQgdG8gY2FycnkgYm90aCwgbm9kZS1zcGVjaWZpYw0KPj4+Pj5JRHMsICBlLmcuIE1BQywgYXMg d2VsbCBhcyBzdWJzY3JpYmVyIElEcywgd2hpY2ggaXMgdGhlIElNU0kuDQo+Pj4+PiBUaGVyZSBt YXkgYmUgdmFsdWUgaW4gYWRkaW5nIHRoZSBJTUVJIHRvIHRoZSBsaXN0IG9mIHBvc3NpYmxlIHR5 cGVzDQo+Pj4+Pm9mICBub2RlLXNwZWNpZmljIElEcy4NCj4+Pj4+DQo+Pj4+PiBtYXJjbw0KPj4+ Pj4NCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IGRtbSBb bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3JpIEd1bmRhdmVsbGkN Cj4+Pj4+PiAoc2d1bmRhdmUpDQo+Pj4+Pj4gU2VudDogRGllbnN0YWcsIDkuIFNlcHRlbWJlciAy MDE0IDIzOjMwDQo+Pj4+Pj4gVG86IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSk7IENoYXJsaWUg UGVya2luczsgZG1tQGlldGYub3JnDQo+Pj4+Pj4gQ2M6IFZpamF5IERldmFyYXBhbGxpDQo+Pj4+ Pj4gU3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hhcnRlcmluZy4uDQo+Pj4+ Pj4NCj4+Pj4+PiBUd28gbW9yZSBjb21tZW50cy4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+ Pj4+PiA0LikgSSdkIGFsc28gdXNlIHN1Yi10eXBlIHZhbHVlIG9mICgyKSBmb3IgSU1TSS4gSnVz dCB0byBhbGlnbiB3aXRoDQo+Pj4+Pj50aGUgIHN1Yi10eXBlcyAgZGVmaW5lZCBmb3IgTU4gSWQg ZGVmaW5lZCBmb3IgSUNNUC4gSSBzdXNwZWN0IHRoZXJlDQo+Pj4+Pj5hcmUgc29tZSAgaW1wbGVt ZW50YXRpb25zICBhbHJlYWR5IHVzaW5nIHN1Yi10eXBlICgyKS4gUGxlYXNlIHNlZQ0KPj4+Pj4+ dGhlIG90aGVyIHRocmVhZC4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gNS4pIEZvciBlYWNoIG9m IHRoZSBzdWItdHlwZXMsIHdlIG5lZWQgdGV4dCBpbmNsdWRpbmcgZXhhbXBsZXMgYW5kDQo+Pj4+ Pj5zb21lDQo+Pj4+Pj4gZXhwbGFuYXRpb24gb24gaG93IHRoZXkgYXJlIHVzZWQuDQo+Pj4+Pj4N Cj4+Pj4+Pg0KPj4+Pj4+IFNyaQ0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IE9uIDkv OS8xNCAyOjIwIFBNLCAiU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSIgPHNndW5kYXZlQGNpc2Nv LmNvbT4NCj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+PiBIaSBDaGFybGllLA0KPj4+Pj4+ Pg0KPj4+Pj4+PiBUaGlzIGlzIGdvb2QuIFRoYW5rcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gMS4pIElmIEVVSS00OCBhbmQgRVVJLTY0IGFkZHJlc3NlcyBhcmUgZGVyaXZlZCBvZiBhIDQ4 LWJpdCBJRUVFDQo+Pj4+Pj4+ODAyLjINCj4+Pj4+Pj4gYWRkcmVzcywgd2h5IGRvIHdlIG5lZWQg dG8gdHdvIHN1Yi10eXBlcyA/IFdoeSBub3QgaGF2ZSBqdXN0IG9uZQ0KPj4+Pj4+PiBzdWItdHlw ZSBmb3IgbWFjIGJhc2VkIGlkZW50aWZpZXJzID8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gMi4pIFN1YiB0 eXBlIHZhbHVlICgxKSBpcyBjdXJyZW50bHkgdXNlZC4gSXRzIGN1cnJlbnRseSBvdmVybG9hZGVk DQo+Pj4+Pj4+Zm9yDQo+Pj4+Pj4+IElNU0ktTkFJICgzR1BQIHNwZWNzKSBhbmQgZ2VuZXJpYyBO QUkgYmFzZWQgaWRlbnRpZmllcnMuIEdpdmVuIHRoZQ0KPj4+Pj4+PiBkZWZpbml0aW9uIG9mIG5l dyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxhaW5pbmcgdGhlDQo+Pj4+Pj4+IG1v dGl2YXRpb24NCj4+Pj4+Pj4NCj4+Pj4+Pj4gMy4pIFByb3Bvc2VkIFN1Yi10eXBlIHZhbHVlIG9m ICgyKSBmb3IgSVB2NiBhZGRyZXNzLiBXaGF0IGV4YWN0bHkNCj4+Pj4+Pj5pcw0KPj4+Pj4+PiB0 aGlzID8gQXJlIHRoZXNlIENHQS1iYXNlZCBJUHY2IGFkZHJlc3NlcyA/DQo+Pj4+Pj4+DQo+Pj4+ Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgIE5ldyBN b2JpbGUgTm9kZSBJZGVudGlmaWVyIFR5cGVzDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pj4+ ICAgICAgICAgICAgICAgIHwgSWRlbnRpZmllciBUeXBlIHwgSWRlbnRpZmllciBUeXBlIE51bWJl ciB8DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgSVB2NiBBZGRyZXNzICAg IHwgMiAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+ICAgICAgICAg ICAgICAgIHwgSU1TSSAgICAgICAgICAgIHwgMyAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+ Pj4+ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICB8DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgUC1UTVNJICAgICAgICAgIHwgNCAgICAg ICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIHwg RVVJLTQ4IGFkZHJlc3MgIHwgNSAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgRVVJLTY0IGFkZHJlc3MgIHwgNiAgICAgICAgICAgICAg ICAgICAgICB8DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgR1VUSSAgICAg ICAgICAgIHwgNyAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+ICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pj4+DQo+ Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+ Pj4+IFJlZ2FyZHMNCj4+Pj4+Pj4gU3JpDQo+Pj4+Pj4+IFBTOiBHb29kIHRvIHNlZSBWaWpheSBi YWNrDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uIDkvOS8xNCAxOjI4IFBNLCAiQ2hhcmxp ZSBQZXJraW5zIg0KPj4+Pj4+PjxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4NCj4+Pj4+ Pj4gd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBIZWxsbyBmb2xrcywNCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiBIZXJlJ3MgdGhlIGxhc3QgSW50ZXJuZXQgRHJhZnQgdGhhdCB3ZSBkaWQsIGxvbmcgYWdv IGV4cGlyZWQ6DQo+Pj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt cGVya2lucy1tZXh0LTQyODNtbmlkcy0wMS50eHQNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJJ2xsIHJl c3VibWl0IGl0IHdpdGggYSBmZXcgdXBkYXRlcyBhcyBhIHBlcnNvbmFsIGRyYWZ0IHRvIGRtbS4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pj4gQ2hhcmxpZSBQLg0KPj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+ PiBkbW0gbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IGRtbUBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gZG1tIG1haWxpbmcgbGlz dA0KPj4+Pj4+IGRtbUBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG1tDQo+Pj4+DQo+Pj4NCj4NCg0K From nobody Thu Sep 11 07:21:55 2014 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 E8CB01A6F1F for ; Thu, 11 Sep 2014 07:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 9Ig_RtifXYjk for ; Thu, 11 Sep 2014 07:21:49 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3011A0028 for ; Thu, 11 Sep 2014 07:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12612; q=dns/txt; s=iport; t=1410445308; x=1411654908; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=/BCNVMTeXcqJ2jlJbgj44FXi05eHCvIVzoCBihpLIb0=; b=j+FJ5cP+7dHM3+f8SwuFwirgy6/8NI9JFcxN1F+59Hkq8rv1g94P5/O+ FYBuC42PyHc0CYZFiDrqoceWk1512V7dfxBtmXi5mbYcUVAHF/gyNadXK +9/QNFI+MGPcQWX4u8NvO5Xtp8jwkQPczs5gS5lBZ5pdF56+evbgQ8IbO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAO+uEVStJA2E/2dsb2JhbABWCYMNU1cEgnjFQQqHTQEZdxZ4hAMBAQEEAQEBMToXBgEZBAEBAQQJGgUEJQsPBQkIAgQBEgmIJQMRDYxVnD0GlTsBF4Emi3qBUjAyAgICgm2BWQWGHYssizOVOYNhbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,506,1406592000"; d="scan'208";a="77019988" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 11 Sep 2014 14:21:47 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8BELl8o017228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 14:21:47 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 09:21:47 -0500 From: "Sri Gundavelli (sgundave)" To: Marco Liebsch , Charlie Perkins , "dmm@ietf.org" Thread-Topic: MNID Types Thread-Index: AQHPzcu4zYG+cpdHeEeoUg336d4LzA== Date: Thu, 11 Sep 2014 14:21:47 +0000 Message-ID: In-Reply-To: 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.21.64.105] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/23XDKAAZE-_k-kjQBoYyoudbmao Subject: [DMM] MNID Types 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, 11 Sep 2014 14:21:52 -0000 DQoNCjxDaGFuZ2luZyB0aGUgc3ViamVjdCBsaW5lIHRvIHJlZmxlY3QgdGhlIE1OSWQgZGlzY3Vz c2lvbj4NCg0KDQpNYXJjbywNCg0KDQpUaGlua2luZyBmdXJ0aGVyIG9uIHRoZSBjb21wbGVtZW50 YXJ5IGlkZW50aWZpZXIgb3B0aW9uLg0KDQotIFRoZXJlIGlzIGFscmVhZHkgdGhlIGxpbmstbGF5 ZXIgaWRlbnRpZmllciBvcHRpb24gdGhhdCBjYW4gYmUgdXNlZCBmb3INCmNhcnJ5aW5nIHRoZSBN YWMgYWRkcmVzcw0KLSBJTUVJIGFuZCBNU0lTRE4gYXJlIGFscmVhZHkgZGVmaW5lZCBpbiAyOS4y NzUgYXMgYSAzR1BQIFZTRSdzDQoNCkluIHNvbWUgc2Vuc2UsIHRoZSBjb21wbGVtZW50YXJ5IGlk ZW50aWZpZXJzIGFyZSBhbHJlYWR5IHByZXNlbnQuDQoNClNyaQ0KDQoNCg0KDQoNCk9uIDkvMTEv MTQgNjo1OCBBTSwgIlNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5j b20+IHdyb3RlOg0KDQo+SSBkbyBub3Qgc2VlIGEgcmVhc29uIHdoeSBtdWx0aXBsZSBNTi1JZCBp bnN0YW5jZXMgbmVlZCB0byBiZSBwcmVzZW50IGluIGENCj5zaW5nbGUgbWVzc2FnZSA/IEluIG15 IGV4cGVyaWVuY2UsIHRoaXMgaXMgc3RyaWN0bHkgYSBkZXBsb3ltZW50DQo+Y29uc2lkZXJhdGlv biwgd2hlbiB0byB1c2Ugd2hhdCB0eXBlIG9mIGlkZW50aWZpZXJzLg0KPg0KPkFzc3VtaW5nIHRo ZSBiYWNrZW5kIHN5c3RlbSBjYW4gdGllIGFsbCB0aGUgTU4tSWQncyB0byBhIHNpbmdsZQ0KPnN1 YnNjcmlwdGlvbiwgYW55IHByZXNlbnRlZCBpZGVudGlmaWVyIGNhbiBiZSBzdWZmaWNpZW50IGZv ciB0aGUgZ2F0ZXdheQ0KPnRvIGRvIHRoZSBCQ0UgbG9va3VwLg0KPg0KPklmIG11bHRpcGxlIGlu c3RhbmNlcyBjYW4gYmUgcHJlc2VudCwgdGhlbiB3ZSBuZWVkIHRvIGRlYWwgd2l0aCBtb3JlIGVy cm9yDQo+Y2FzZXMuIElzIHRoYXQgcmVhbGx5IG5lZWRlZCA/DQo+DQo+DQo+PiBJIGFtIHdvbmRl cmluZyBpZiBpdCB3b3VsZCBub3QgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBnbyBmb3IgYSBkaWZm ZXJlbnQNCj4+Y29udGFpbmVyIG9wdGlvbiB0byBjYXJyeSBzdWNoIGluZm9ybWF0aW9uLiBTb21l dGhpbmcgbGlrZSBhDQo+PmNvbXBsZW1lbnRhcnkgaWRlbnRpZmllciBvcHRpb24uDQo+DQo+U291 bmRzIGludGVyZXN0aW5nLiBBcmUgeW91IHN1Z2dlc3Rpbmcgd2UgbGVhdmUgdGhlIGN1cnJlbnQg TU4tSUQgYXMgaXQNCj5pcywgYnV0IHVzZSBhIG5ldyBjb21wbGVtZW50YXJ5IG9wdGlvbiA/IEJ1 dCwgaWYgdGhlIHJlcXVpcmVtZW50IGlzIGZvciBhDQo+TWFjIGJhc2VkIGlkZW50aWZpZXJzLCB3 aGF0IHdpbGwgYmUgdGhlcmUgaW4gdGhlIGN1cnJlbnQgTU4tSWQgb3B0aW9uID8gV2UNCj5zdGls bCBuZWVkIHRvIGhhdmUgaWRlbnRpZmllciB0aGVyZSA/DQo+DQo+DQo+DQo+DQo+U3JpDQo+DQo+ DQo+DQo+DQo+DQo+T24gOS8xMS8xNCAyOjAzIEFNLCAiTWFyY28gTGllYnNjaCIgPE1hcmNvLkxp ZWJzY2hAbmVjbGFiLmV1PiB3cm90ZToNCj4NCj4+Tm8gaXNzdWUgd2l0aCBsb2dpY2FsIHZzLiBw aHlzaWNhbCBJRC4gQnV0IEkgYW0gd29uZGVyaW5nIGFib3V0IHR3bw0KPj50aGluZ3M6DQo+Pg0K Pj5PcGVyYXRpb24gaXMgY2xlYXIgdG8gbWUgaW4gY2FzZSBhIHNpbmdsZSBNTklEIGlzIHByZXNl bnQgaW4gYSBtZXNzYWdlDQo+PmFuZCBJIHNlZSB0aGUgdmFsdWUgaW4gYmVpbmcNCj4+ZmxleGli bGUgdG8gY2hvb3NlIGZyb20gZGlmZmVyZW50IHN1Yi10eXBlcy4gSWYgbXVsdGlwbGUgTU5JRHMg d2l0aA0KPj5kaWZmZXJlbnQgc3ViLXR5cGVzIGFyZSBwcmVzZW50IGluDQo+PmEgc2luZ2xlIG1l c3NhZ2UsIHdoaWNoIG9uZSBzaG91bGQgZS5nLiB0aGUgTE1BIHRha2UgZm9yIHRoZSBCQyBsb29r dXAuLg0KPj5ObyBiaWcgcHJvYmxlbSB0byBzb2x2ZSwgYnV0DQo+PnRvIGJlIGNvbnNpZGVyZWQg aW4gaW1wbGVtZW50YXRpb25zLg0KPj4NCj4+SWYgdGhlIHJlYXNvbiBmb3IgbXVsdGlwbGUgcHJl c2VudCBNTklEcyB3aXRoIGRpZmZlcmVudCBzdWItdHlwZXMgaXMgdG8NCj4+ZG8gb3RoZXIgdGhp bmdzIHRoYW4gaWRlbnRpZnlpbmcNCj4+dGhlIG5vZGUgb3IgdXNpbmcgdGhlIElEIGFzIGtleSBm b3IgYSBsb29rdXAsIEkgYW0gd29uZGVyaW5nIGlmIGl0IHdvdWxkDQo+Pm5vdCBiZSBtb3JlIGFw cHJvcHJpYXRlDQo+PnRvIGdvIGZvciBhIGRpZmZlcmVudCBjb250YWluZXIgb3B0aW9uIHRvIGNh cnJ5IHN1Y2ggaW5mb3JtYXRpb24uDQo+PlNvbWV0aGluZyBsaWtlIGEgY29tcGxlbWVudGFyeQ0K Pj5pZGVudGlmaWVyIG9wdGlvbi4NCj4+DQo+Pm1hcmNvDQo+Pg0KPj4+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+PkZyb206IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgW21haWx0bzpz Z3VuZGF2ZUBjaXNjby5jb21dDQo+Pj5TZW50OiBEb25uZXJzdGFnLCAxMS4gU2VwdGVtYmVyIDIw MTQgMDA6NDINCj4+PlRvOiBDaGFybGllIFBlcmtpbnM7IE1hcmNvIExpZWJzY2g7IGRtbUBpZXRm Lm9yZw0KPj4+Q2M6IFZpamF5IERldmFyYXBhbGxpDQo+Pj5TdWJqZWN0OiBSZTogW0RNTV0gcmVn YXJkaW5nIHRoZSByZS1jaGFydGVyaW5nLi4NCj4+Pg0KPj4+SGVsbG8gQ2hhcmxpZSwNCj4+Pg0K Pj4+QWdyZWUgd2l0aCB0aGF0LiBNTi1JZCBhcyBpdHMgZGVmaW5lZCB0b2RheSBpcyBhIGxvZ2lj YWwgaWRlbnRpZmllci4gSXQNCj4+PmRvZXMgbm90DQo+Pj5yZXF1aXJlIHRoZSBpZGVudGlmaWVy IHRvIGJlIGJvdW5kIHRvIGEgcGh5c2ljYWwgZGV2aWNlIG9yIGEgaW50ZXJmYWNlDQo+Pj5pZGVu dGl0eS4NCj4+PkJ1dCwgd2UgaGF2ZSBjbGVhcmx5IHNlZW4gcmVxdWlyZW1lbnRzIHdoZXJlIHRo ZSBuZWVkIGlzIGZvciBnZW5lcmF0aW5nDQo+Pj5pZGVudGlmaWVycyBiYXNlZCBvbiBzb21lIHBo eXNpY2FsIGlkZW50aWZpZXJzLiBUaG9zZSBwaHlzaWNhbA0KPj4+aWRlbnRpZmllcnMgaW5jbHVk ZQ0KPj4+SU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi5ldGMuIElmIHdlIGNhbiBkZWZpbmUgYSB0 eXBlIGZvciBlYWNoIG9mIHRoZQ0KPj4+c291cmNlDQo+Pj5hbmQgdGhlIHJ1bGVzIGZvciBnZW5l cmF0aW5nIE1OLUlEIGJhc2VkIHVzaW5nIHRob3NlIHNvdXJjZXMsIHRoZSBzZW5kZXINCj4+PmFu ZA0KPj4+cmVjZWl2ZXIgd2lsbCBoYXZlIGNsZWFyIGd1aWRhbmNlIG9uIGhvdyB0byB1c2UgdGhl IHNwZWMuIFNvbWUgcG9pbnRlcnMsDQo+Pj5leHBsYW5hdGlvbiBhbmQgZXhhbXBsZXMgZm9yIGVh Y2ggb2YgdGhvc2UgaWRlbnRpZmllcnMgd2lsbCBncmVhdGx5IGhlbHANCj4+PmF2b2lkDQo+Pj5p bnRlci1vcCBpc3N1ZXMuDQo+Pj4NCj4+Pg0KPj4+UmVnYXJkcw0KPj4+U3JpDQo+Pj4NCj4+Pg0K Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pk9uIDkvMTAvMTQgMzoyMSBQTSwgIkNoYXJsaWUg UGVya2lucyIgPGNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pg0KPj4+d3JvdGU6DQo+Pj4N Cj4+Pj4NCj4+Pj5IZWxsbyBmb2xrcywNCj4+Pj4NCj4+Pj5JIHRoaW5rIGl0J3MgYmVzdCB0byBj b25zaWRlciB0aGUgTU5JRCBhcyBzaW1wbHkgbGl2aW5nIGluIGEgc3BhY2Ugb2YNCj4+Pj5pZGVu dGlmaWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVjaCBhYm91dCB3aGV0aGVyIGl0J3MgYSBsb2dp Y2FsDQo+Pj4+aWRlbnRpZmllciBvciBhIHBoeXNpY2FsIGlkZW50aWZpZXIuICBJZiB0aGUgZm9y bWVyLCB0aGVuIHNvbWV3aGVyZQ0KPj4+PihwZXJoYXBzIGJlbG93IHRoZSBuZXR3b3JrIGxheWVy KSB0aGUgbG9naWNhbCBpZGVudGlmaWVyIGhhcyBiZWVuIGJvdW5kDQo+Pj4+dG8gc29tZXRoaW5n IGluIHRoZSBwaHlzaWNhbCBpbnRlcmZhY2UsIGJ1dCB0aGF0J3Mgbm90IG91ciBwcm9ibGVtLg0K Pj4+Pg0KPj4+PlRoZSBudW1iZXIgc3BhY2UgZm9yIHR5cGVzIG9mIE1OSURzIGlzIGxpa2VseSB0 byBzdGF5IHByZXR0eSBlbXB0eSwgc28NCj4+Pj5JJ2Qgc2F5IHdlIGNvdWxkIGFkZCBhcyBtYW55 IHR5cGVzIGFzIHdvdWxkIGJlIGNvbnZlbmllbnQgZm9yIHRoZQ0KPj4+PnNvZnR3YXJlIGRlc2ln bmVycy4gIFNvLCB3ZSBjb3VsZCBjb25jZWl2YWJseSBoYXZlIHNldmVyYWwgTU5JRHMNCj4+Pj5k ZWZpbmVkIHRoYXQgYWxsICJsb29rZWQgbGlrZSIgTkFJcyAod2hpY2gsIHRoZW1zZWx2ZXMsICJs b29rIGxpa2UiDQo+Pj4+RlFETnMpLg0KPj4+Pg0KPj4+PlJlZ2FyZHMsDQo+Pj4+Q2hhcmxpZSBQ Lg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pk9uIDkvMTAvMjAxNCA4OjExIEFNLCBTcmkgR3VuZGF2 ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0KPj4+Pj4gWWVzLiBDdXJyZW50bHksIHRoZSBNTklEIGlz IGlmIHRoZSBuYWkgZm9ybWF0IGFuZCBpcyBvdmVybG9hZGVkLiBUaGUNCj4+Pj4+TU5JRCAgaW4g M0dQUCBzcGVjcyBpcyB0aGUgSU1TSS1OQUkgKElNU0lAUkVBTE0pLCBpdHMgYmFzZWQgb24gdGhl DQo+Pj4+PklNU0kuIEV4Og0KPj4+Pj4gIjxJTVNJPkBlcGMubW5jPE1OQz4ubWNjPE1DQz4uM2dw cG5ldHdvcmsub3JnqfcNCj4+Pj4+DQo+Pj4+PiBXZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07DQo+ Pj4+Pg0KPj4+Pj4gV2UgYWxzbyBoYXZlIGFwcHJvYWNoZXMgdG8gdHJhbnNmb3JtIE1BQyB0byBQ c2V1ZG8gSU1TSSwgYW5kIHRoZW4NCj4+Pj4+IGNhcnJ5IElNU0ktTkFJIGFzIHRoZSBNTi1JRC4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gU28sIHdlIG5lZWQgdW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFj aCBvZiB0aGUgdHlwZXMvc291cmNlcy4NCj4+Pj4+DQo+Pj4+PiBNTi1JZCBiYXNlZCBvbiBJTVNJ LCBNU0lTRE4sIElNRUksIE1BQyAuLg0KPj4+Pj4NCj4+Pj4+IEFsc28sIGRvIHdlIG5lZWQgdG8g ZGlzdGluZ3Vpc2ggYmV0d2VlbiBJTVNJIGFuZCBJTVNJLU5BSSA/DQo+Pj4+Pg0KPj4+Pj4gU3Jp DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBPbiA5LzEwLzE0IDY6MjkgQU0sICJNYXJjbyBM aWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBJ dCBzZWVtcyB0aGUgTU5JRCBpcyBzb21laG93IG92ZXJsb2FkZWQgdG8gY2FycnkgYm90aCwgbm9k ZS1zcGVjaWZpYw0KPj4+Pj4+SURzLCAgZS5nLiBNQUMsIGFzIHdlbGwgYXMgc3Vic2NyaWJlciBJ RHMsIHdoaWNoIGlzIHRoZSBJTVNJLg0KPj4+Pj4+IFRoZXJlIG1heSBiZSB2YWx1ZSBpbiBhZGRp bmcgdGhlIElNRUkgdG8gdGhlIGxpc3Qgb2YgcG9zc2libGUgdHlwZXMNCj4+Pj4+Pm9mICBub2Rl LXNwZWNpZmljIElEcy4NCj4+Pj4+Pg0KPj4+Pj4+IG1hcmNvDQo+Pj4+Pj4NCj4+Pj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogZG1tIFttYWlsdG86ZG1tLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmkgR3VuZGF2ZWxsaQ0KPj4+Pj4+PiAoc2d1 bmRhdmUpDQo+Pj4+Pj4+IFNlbnQ6IERpZW5zdGFnLCA5LiBTZXB0ZW1iZXIgMjAxNCAyMzozMA0K Pj4+Pj4+PiBUbzogU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKTsgQ2hhcmxpZSBQZXJraW5zOyBk bW1AaWV0Zi5vcmcNCj4+Pj4+Pj4gQ2M6IFZpamF5IERldmFyYXBhbGxpDQo+Pj4+Pj4+IFN1Ympl Y3Q6IFJlOiBbRE1NXSByZWdhcmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLg0KPj4+Pj4+Pg0KPj4+ Pj4+PiBUd28gbW9yZSBjb21tZW50cy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gNC4pIEknZCBhbHNvIHVzZSBzdWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElNU0kuIEp1c3Qg dG8gYWxpZ24gd2l0aA0KPj4+Pj4+PnRoZSAgc3ViLXR5cGVzICBkZWZpbmVkIGZvciBNTiBJZCBk ZWZpbmVkIGZvciBJQ01QLiBJIHN1c3BlY3QgdGhlcmUNCj4+Pj4+Pj5hcmUgc29tZSAgaW1wbGVt ZW50YXRpb25zICBhbHJlYWR5IHVzaW5nIHN1Yi10eXBlICgyKS4gUGxlYXNlIHNlZQ0KPj4+Pj4+ PnRoZSBvdGhlciB0aHJlYWQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IDUuKSBGb3IgZWFj aCBvZiB0aGUgc3ViLXR5cGVzLCB3ZSBuZWVkIHRleHQgaW5jbHVkaW5nIGV4YW1wbGVzIGFuZA0K Pj4+Pj4+PnNvbWUNCj4+Pj4+Pj4gZXhwbGFuYXRpb24gb24gaG93IHRoZXkgYXJlIHVzZWQuDQo+ Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFNyaQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0K Pj4+Pj4+PiBPbiA5LzkvMTQgMjoyMCBQTSwgIlNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxz Z3VuZGF2ZUBjaXNjby5jb20+DQo+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gSGkg Q2hhcmxpZSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGlzIGlzIGdvb2QuIFRoYW5rcy4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gMS4pIElmIEVVSS00OCBhbmQgRVVJLTY0IGFkZHJlc3Nl cyBhcmUgZGVyaXZlZCBvZiBhIDQ4LWJpdCBJRUVFDQo+Pj4+Pj4+PjgwMi4yDQo+Pj4+Pj4+PiBh ZGRyZXNzLCB3aHkgZG8gd2UgbmVlZCB0byB0d28gc3ViLXR5cGVzID8gV2h5IG5vdCBoYXZlIGp1 c3Qgb25lDQo+Pj4+Pj4+PiBzdWItdHlwZSBmb3IgbWFjIGJhc2VkIGlkZW50aWZpZXJzID8NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiAyLikgU3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJlbnRseSB1c2Vk LiBJdHMgY3VycmVudGx5IG92ZXJsb2FkZWQNCj4+Pj4+Pj4+Zm9yDQo+Pj4+Pj4+PiBJTVNJLU5B SSAoM0dQUCBzcGVjcykgYW5kIGdlbmVyaWMgTkFJIGJhc2VkIGlkZW50aWZpZXJzLiBHaXZlbiB0 aGUNCj4+Pj4+Pj4+IGRlZmluaXRpb24gb2YgbmV3IHN1Yi10eXBlcywgd2UgbmVlZCBzb21lIHRl eHQgZXhwbGFpbmluZyB0aGUNCj4+Pj4+Pj4+IG1vdGl2YXRpb24NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiAzLikgUHJvcG9zZWQgU3ViLXR5cGUgdmFsdWUgb2YgKDIpIGZvciBJUHY2IGFkZHJlc3MuIFdo YXQgZXhhY3RseQ0KPj4+Pj4+Pj5pcw0KPj4+Pj4+Pj4gdGhpcyA/IEFyZSB0aGVzZSBDR0EtYmFz ZWQgSVB2NiBhZGRyZXNzZXMgPw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgIE5ldyBNb2JpbGUgTm9kZSBJZGVudGlm aWVyIFR5cGVzDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+Pj4+ICAgICAgICAgICAgICAg IHwgSWRlbnRpZmllciBUeXBlIHwgSWRlbnRpZmllciBUeXBlIE51bWJlciB8DQo+Pj4+Pj4+PiAg ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KPj4+Pj4+Pj4gICAgICAgICAgICAgICAgfCBJUHY2IEFkZHJlc3MgICAgfCAyICAgICAgICAg ICAgICAgICAgICAgIHwNCj4+Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+PiAgICAgICAgICAgICAgICB8IElN U0kgICAgICAgICAgICB8IDMgICAgICAgICAgICAgICAgICAgICAgfA0KPj4+Pj4+Pj4gICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+ Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgUC1UTVNJICAgICAgICAgIHwgNCAgICAgICAgICAgICAg ICAgICAgICB8DQo+Pj4+Pj4+PiAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgfA0KPj4+Pj4+Pj4gICAgICAgICAgICAgICAgfCBFVUktNDgg YWRkcmVzcyAgfCA1ICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4+Pj4+ICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+ PiAgICAgICAgICAgICAgICB8IEVVSS02NCBhZGRyZXNzICB8IDYgICAgICAgICAgICAgICAgICAg ICAgfA0KPj4+Pj4+Pj4gICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4+Pj4+Pj4+ICAgICAgICAgICAgICAgIHwgR1VUSSAgICAgICAg ICAgIHwgNyAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4+PiAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+IFJlZ2FyZHMNCj4+Pj4+Pj4+IFNyaQ0KPj4+Pj4+Pj4gUFM6IEdvb2QgdG8gc2Vl IFZpamF5IGJhY2sNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gT24gOS85LzE0IDE6Mjgg UE0sICJDaGFybGllIFBlcmtpbnMiDQo+Pj4+Pj4+PjxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5r Lm5ldD4NCj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBIZWxsbyBmb2xrcywN Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEhlcmUncyB0aGUgbGFzdCBJbnRlcm5ldCBEcmFmdCB0aGF0 IHdlIGRpZCwgbG9uZyBhZ28gZXhwaXJlZDoNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pmh0dHA6Ly93 d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1wZXJraW5zLW1leHQtNDI4M21uaWRzLTAxLnR4 dA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSSdsbCByZXN1Ym1pdCBpdCB3aXRoIGEgZmV3IHVwZGF0 ZXMgYXMgYSBwZXJzb25hbCBkcmFmdCB0byBkbW0uDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBSZWdh cmRzLA0KPj4+Pj4+Pj4+IENoYXJsaWUgUC4NCj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+PiBkbW0gbWFpbGluZyBsaXN0DQo+ Pj4+Pj4+PiBkbW1AaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG1tDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4+IGRtbSBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gZG1tQGll dGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1t DQo+Pj4+Pg0KPj4+Pg0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPmRtbSBtYWlsaW5nIGxpc3QNCj5kbW1AaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQo= From nobody Thu Sep 11 07:30:44 2014 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 9B8861A6FD2; Thu, 11 Sep 2014 07:30:37 -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 tpNWqks40Vv1; Thu, 11 Sep 2014 07:30:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D19B1A00DC; Thu, 11 Sep 2014 07:30:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140911143032.19696.37039.idtracker@ietfa.amsl.com> Date: Thu, 11 Sep 2014 07:30:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/VukglEXuxuVBpOTYGUCGrdgYcvQ Cc: dmm@ietf.org Subject: [DMM] Last Call: (Distributed Mobility Management: Current practices and gap analysis) to Informational RFC X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 14:30:37 -0000 The IESG has received a request from the Distributed Mobility Management WG (dmm) to consider the following document: - 'Distributed Mobility Management: Current practices and gap analysis' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Sep 11 08:41:12 2014 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 BC79C1A8930 for ; Thu, 11 Sep 2014 08:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 D9TNVins78jr for ; Thu, 11 Sep 2014 08:41:07 -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 193411A8971 for ; Thu, 11 Sep 2014 08:41:06 -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 s8BFf6IT021584; Thu, 11 Sep 2014 10:41:06 -0500 Received: from XCH-PHX-210.sw.nos.boeing.com (xch-phx-210.sw.nos.boeing.com [130.247.25.65]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8BFewj5021404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 11 Sep 2014 10:40:59 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-PHX-210.sw.nos.boeing.com ([169.254.10.188]) with mapi id 14.03.0181.006; Thu, 11 Sep 2014 08:40:57 -0700 From: "Templin, Fred L" To: "Sri Gundavelli (sgundave)" , "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzUS085cNtlvM5kaPQ9fwALiOyZv68k2AgACFnwCAAJR9EA== Date: Thu, 11 Sep 2014 15:40:56 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D165E0@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D15E20@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/wrtbBEWlrWzw-dP7ifG_rBt_CAU Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 11 Sep 2014 15:41:09 -0000 Hi Sri, Thanks for the balanced reply, and see below for some responses: > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] > Sent: Wednesday, September 10, 2014 4:26 PM > To: Templin, Fred L; sarikaya@ieee.org > Cc: Jouni Korhonen; Dapeng Liu; dmm@ietf.org > Subject: Re: [DMM] DMM Interim call #2 - agenda forming >=20 > Fred, >=20 > I'm not suggesting Aero vs MIP debate. IMO, its simply not worth it. Each > of the protocols have certain properties, which helps in some use-cases > and may be inefficient for some other use-cases. But, you can make all of > them work, MIP, GTP, MOBIKE, AERO ... There is no silver bullet in any on= e > of them, unless some one can prove it. Some architectures are based on > fixed anchors and some such as LISP-based are based on floating anchors. > Solutions based on fixed anchors have properties that suits a SP > deployment; a single point of charging, policy enforcement, LI support, > subscriber control but looses the aspect of optimized routing path. As an > example, "I've the best optimized path for my traffic, but my operator ha= s > no clue where my traffic gets routed out". That works very well for some > cases and does not work for some other deployments. These are all points > of debate and each have to be measures on its own merit. With AERO, as I have already mentioned it does not matter which one of possibly hundreds or thousands of AERO Servers the Client associates with. The Client can also easily change between Servers, e.g., to get better performance, or can even associate with multiple Servers, e.g., for load balancing and to reduce path stretch. AERO also has built-in route optimization where the Client itself requests an optimized route to a potential correspondent Client. But, the network does not need to honor that request, e.g., if it wants to maintain a policy enforcement point, single point of charging, etc. So, the AERO anchors could be either fixed or floating depending on the network's actual policies. > The choice of the protocol is also tied to the legacy and deployed > infrastructure. Many times its about an evolution. I do not know how many > people in this WG have been involved in the AERO protocol development, or > familiar with it, at least I'm not involved in its development. But, I'm > not against AERO or some thing else. If the discussion has to be about a > protocol selection and the approach of multiple options does not work, > then we should just only do that and call for a vote and settle that > matter. I'm suggesting an approach, where we avoid this protocol debate > and allow multiple options. I'm sure, that battle will be bitter and not > worth it. AERO has been a work-in-progress since about the 2002 timeframe. In about 2005, a simplified precursor to AERO was productized and shipped by major network equipment vendors under a different name, but it was really just a stripped down function targeted for hosts in fixed networks. Not really AERO at all, but it did include and validate the NBMA virtual link model AERO is based on. In the later 2000's and into the earlier part of this decade, AERO underwent constructive development in the IRTF RRG - again, under a different name. Then, in 2012 a first edition of AERO was published as RFC6706 through AD sponsorship. Since that time, I have continued development on the second edition as a sole author effort, but with the help of MANY contributors who have been acknowledged in the document. The second edition is now at the point where it would be good to have it brought into a working group home, which might be worth discussing at some point. Thanks - Fred fred.l.templin@boeing.com =20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 9/10/14 3:47 PM, "Templin, Fred L" wrote: >=20 > >Hi Behcet and Sri, > > > >> -----Original Message----- > >> From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > >> Sent: Wednesday, September 10, 2014 3:15 PM > >> To: Sri Gundavelli (sgundave) > >> Cc: Templin, Fred L; Jouni Korhonen; Dapeng Liu; dmm@ietf.org > >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming > >> > >> Hi Sri, > >> > >> On Wed, Sep 10, 2014 at 5:01 PM, Sri Gundavelli (sgundave) > >> wrote: > >> > Hi Fred, > >> > > >> > > >> > IMHO, DMM solution need to be tied to one specific protocol. We don'= t > >>have > >> > to battle this out and come up with one answer. Once we have > >>high-level > >> > view of the solution and the interfaces, its possible to realize tho= se > >> > interfaces using any protocols. You call it MIP, GTP, Aero ..does no= t > >> > matter. The core specs can identify the interface requirements and t= he > >> > specific protocol documents can publish extensions to the protocols. > >>We > >> > let the deployments make the call on the protocol choice. > >> > > > > >There are points of comparison between MIP and AERO that IMHO > >should be taken under consideration. MIP has been around for a > >long time, but AERO is not exactly new either. It has its genesis > >from a long list of earlier RFCs including (in chronologic order): > > > >http://www.rfc-editor.org/rfc/rfc2529.txt > >http://www.rfc-editor.org/rfc/rfc4214.txt > >http://www.rfc-editor.org/rfc/rfc5214.txt > >http://www.rfc-editor.org/rfc/rfc5320.txt > >http://www.rfc-editor.org/rfc/rfc5720.txt > >http://www.rfc-editor.org/rfc/rfc6139.txt > >http://www.rfc-editor.org/rfc/rfc6179.txt > >http://www.rfc-editor.org/rfc/rfc6706.txt > > > >I know a lot of people throughout the IETF and other forums have > >put a tremendous amount of energy into MIP-based solutions, but > >to my understanding the archetype for those solutions is still > >based on a host that goes wandering from its home physical link > >and requires the assist of a home agent on that physical link > >to keep track of its current location. > > > >Conversely, the archetype for AERO is a router that remains > >connected to a virtual link configured over its home network no > >matter where the router moves to. That means that it does not > >matter which "agent" on the virtual link the router associates > >with, and that is why AERO has already solved the DMM problem. > > > >> These are your views. > >> Not mine for sure. > > > >I have heard you say this on multiple occasions, Behcet, and I > >am beginning to wonder if you have a better understanding of the > >situation than I do. But, I do believe solution alternatives > >should be discussed rather than just marching forward without > >considering new approaches. > > > >Thanks - Fred > >fred.l.templin@boeing.com > > > >> Regards, > >> > >> Behcet > >> > > >> > > >> > Regards > >> > Sri > >> > > >> > > >> > > >> > > >> > > >> > On 9/10/14 11:43 AM, "Templin, Fred L" > >>wrote: > >> > > >> >>Hi Jouni, > >> >> > >> >>I'd like to propose a slightly different charter: > >> >> > >> >> "AERO already solves distributed mobility management and provides = a > >> >> a comprehensive mobility solution for any mobile device. AERO > >>should > >> >> therefore be approved as the mobility management solution for DMM= . > >> >> Publication of AERO will therefore conclude the working group's > >> >> activity." > >> >> > >> >>Can we have this on the agenda? > >> >> > >> >>Thanks - Fred > >> >>fred.l.templin@boeing.com > >> >> > >> >>> -----Original Message----- > >> >>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhone= n > >> >>> Sent: Wednesday, September 10, 2014 11:37 AM > >> >>> To: sarikaya@ieee.org > >> >>> Cc: Dapeng Liu; dmm@ietf.org > >> >>> Subject: Re: [DMM] DMM Interim call #2 - agenda forming > >> >>> > >> >>> > >> >>> What do you mean by no agenda? To me it clearly says we use the > >>call #2 > >> >>> for setting up the work split. > >> >>> > >> >>> - Jouni > >> >>> > >> >>> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: > >> >>> > Jouni, why don't we cancel this one (#2) and do the next one (#3= ) > >>with > >> >>> > an agenda? > >> >>> > I hope Alper can attend :-) > >> >>> > > >> >>> > Regards, > >> >>> > > >> >>> > Behcet > >> >>> > > >> >>> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen > >> >>> wrote: > >> >>> >> > >> >>> >> It seems I sent this to a wrong receiver.. that explains why it > >>did > >> >>>not > >> >>> >> appear on the list. > >> >>> >> > >> >>> >> - Jouni > >> >>> >> > >> >>> >> -------- Alkuper=E4inen viesti / Orig.Msg. -------- > >> >>> >> Aihe: DMM Interim call #2 - agenda forming > >> >>> >> P=E4iv=E4ys: Mon, 08 Sep 2014 23:43:24 +0300 > >> >>> >> L=E4hett=E4j=E4: Jouni Korhonen > >> >>> >> Vastaanottaja: dmm-ads@tools.ietf.org > >> >>> >> CC: jouni.nospam@gmail.com, Dapeng Liu > >> > >> >>> >> > >> >>> >> Folks, > >> >>> >> > >> >>> >> The next interim is close. Assuming there are no overwhelming > >>amount > >> >>>of > >> >>> >> comments to the re-charter text, we are ready to start setting > >>up the > >> >>> >> work split on the solution space! Remember the discussion and t= he > >> >>> >> minutes from the IETF#90 Friday session. No other agenda items > >>are > >> >>> >> planned for the next interim. > >> >>> >> > >> >>> >> - 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 > >> >>_______________________________________________ > >> >>dmm mailing list > >> >>dmm@ietf.org > >> >>https://www.ietf.org/mailman/listinfo/dmm > >> > From nobody Thu Sep 11 08:46:17 2014 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 35A991A0410 for ; Thu, 11 Sep 2014 08:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 5BgaMg1mYOWH for ; Thu, 11 Sep 2014 08:46:12 -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 CD5C61A8939 for ; Thu, 11 Sep 2014 08:46:12 -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 s8BFkCWA007434; Thu, 11 Sep 2014 08:46:12 -0700 Received: from XCH-PHX-111.sw.nos.boeing.com (xch-phx-111.sw.nos.boeing.com [130.247.25.132]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8BFk6hL007365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 11 Sep 2014 08:46:06 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-PHX-111.sw.nos.boeing.com ([169.254.11.251]) with mapi id 14.03.0181.006; Thu, 11 Sep 2014 08:46:05 -0700 From: "Templin, Fred L" To: "Sri Gundavelli (sgundave)" , "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzUS085cNtlvM5kaPQ9fwALiOyZv68k2AgACFnwCAAA1uAIAAjc3A Date: Thu, 11 Sep 2014 15:46:04 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D16612@XCH-BLV-504.nw.nos.boeing.com> References: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/cwGWm3WC7yKjYHTC20EFtI2jY68 Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 11 Sep 2014 15:46:16 -0000 Hi Sri, I thumbed through the document, but will do a more careful read and get back to you. One aspect that the two proposals have in common is the use of an internal instance of BGP to keep track of mobile network prefixes while advertising only one or a few aggregated network prefixes to the outside world. AERO (and its predecessor IRON) have been doing that for a long time, having learned the lessons from the Connexion-By-Boeing experience. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] > Sent: Wednesday, September 10, 2014 5:14 PM > To: Sri Gundavelli (sgundave); Templin, Fred L; sarikaya@ieee.org > Cc: Dapeng Liu; dmm@ietf.org > Subject: Re: [DMM] DMM Interim call #2 - agenda forming >=20 > Hi Fred, >=20 > Looking at other solution alternative, there is this proposal from > Satoru-san. >=20 > http://www.ietf.org/id/draft-matsushima-stateless-uplane-vepc-03.txt >=20 > Will be good to know your views on how you see this approach compare with > Aero. >=20 >=20 > Regards > Sri >=20 >=20 >=20 > On 9/10/14 4:25 PM, "Sri Gundavelli (sgundave)" wrot= e: >=20 > >Fred, > > > >I'm not suggesting Aero vs MIP debate. IMO, its simply not worth it. Eac= h > >of the protocols have certain properties, which helps in some use-cases > >and may be inefficient for some other use-cases. But, you can make all o= f > >them work, MIP, GTP, MOBIKE, AERO ... There is no silver bullet in any o= ne > >of them, unless some one can prove it. Some architectures are based on > >fixed anchors and some such as LISP-based are based on floating anchors. > >Solutions based on fixed anchors have properties that suits a SP > >deployment; a single point of charging, policy enforcement, LI support, > >subscriber control but looses the aspect of optimized routing path. As a= n > >example, "I've the best optimized path for my traffic, but my operator h= as > >no clue where my traffic gets routed out". That works very well for some > >cases and does not work for some other deployments. These are all points > >of debate and each have to be measures on its own merit. > > > >The choice of the protocol is also tied to the legacy and deployed > >infrastructure. Many times its about an evolution. I do not know how man= y > >people in this WG have been involved in the AERO protocol development, o= r > >familiar with it, at least I'm not involved in its development. But, I'm > >not against AERO or some thing else. If the discussion has to be about a > >protocol selection and the approach of multiple options does not work, > >then we should just only do that and call for a vote and settle that > >matter. I'm suggesting an approach, where we avoid this protocol debate > >and allow multiple options. I'm sure, that battle will be bitter and not > >worth it. > > > > > >Regards > >Sri > > > > > > > > From nobody Thu Sep 11 08:50:03 2014 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 0DEAE1A0410 for ; Thu, 11 Sep 2014 08:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.68 X-Spam-Level: X-Spam-Status: No, score=-4.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, URG_BIZ=0.573] 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 OKgTr0ZJtRHv for ; Thu, 11 Sep 2014 08:49:57 -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 4631B1A02F5 for ; Thu, 11 Sep 2014 08:49:57 -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 s8BFnuDU029028; Thu, 11 Sep 2014 08:49:57 -0700 Received: from XCH-BLV-207.nw.nos.boeing.com (xch-blv-207.nw.nos.boeing.com [10.57.37.63]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8BFnkqh028784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 11 Sep 2014 08:49:47 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-207.nw.nos.boeing.com ([169.254.7.31]) with mapi id 14.03.0181.006; Thu, 11 Sep 2014 08:49:45 -0700 From: "Templin, Fred L" To: Alper Yegin Thread-Topic: [DMM] "A Day in the Life of an Enterprise Mobile Device User" Thread-Index: AQHPx5ViOP6F+udYnkWXmXXAiU79KZvw/mkAgAAy/oD//9kpQIAJzrUwgAEiiQCAACQoQA== Date: Thu, 11 Sep 2014 15:49:44 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D16635@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D031C3@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D040CD@XCH-BLV-504.nw.nos.boeing.com> <4C4F8606-FBE7-4BAC-8F81-F1B63695357B@yegin.org> <540835D1.5080108@gmail.com> <2134F8430051B64F815C691A62D9831832D060C6@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D15B64@XCH-BLV-504.nw.nos.boeing.com> <9170362B-1EC8-4729-AA67-1D05D5A37745@yegin.org> In-Reply-To: <9170362B-1EC8-4729-AA67-1D05D5A37745@yegin.org> 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: http://mailarchive.ietf.org/arch/msg/dmm/LChbBjyt4VIB5dKRQf2HIR2gzt4 Cc: "dmm@ietf.org" Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User" 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, 11 Sep 2014 15:50:02 -0000 Hi Alper, > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Wednesday, September 10, 2014 11:37 PM > To: Templin, Fred L > Cc: Alexandru Petrescu; dmm@ietf.org > Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User= " >=20 > Hi Fred, >=20 > Actually, you had provided the description of the scenario w/o any refere= nces to the solutions (AERO, > MIP, etc.). The scenario was pulled out of a document titled: "AERO Enterprise Network Model", but then scrubbed to remove references to AERO before posting to the list to provide a neutral platform for discussion. > So, I asked if that scenario could already be handled using existing MIP = protocol. Right, and reasons were given as to why AERO instead of MIP. > I didn't imply it couldn't be done using AERO. Well, again, the scenario was pulled from an AERO-specific document. So I didn't think you were implying it couldn't be done using AERO. Thanks - Fred fred.l.templin@boeing.com > Alper >=20 >=20 >=20 > On Sep 10, 2014, at 11:21 PM, Templin, Fred L wrote: >=20 > > Hi Alper, > > > >>>> Can this scenario not be realized by simply placing an HA in the > >>>> enterprise network and using Mobile IP? > > > > You did not respond to say whether your question was answered. > > I think it is also fair to ask the opposite question: > > > > "Are there scenarios for MIP-based solutions that cannot be realized > > by simply placing an AERO Server in the network and using AERO?" > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L > >> Sent: Thursday, September 04, 2014 7:51 AM > >> To: Alexandru Petrescu; dmm@ietf.org > >> Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device U= ser" > >> > >> Hi Alex and Alper, > >> > >>> -----Original Message----- > >>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petres= cu > >>> Sent: Thursday, September 04, 2014 2:50 AM > >>> To: dmm@ietf.org > >>> Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device = User" > >>> > >>> Le 04/09/2014 08:47, Alper Yegin a =E9crit : > >>>> Hi Fred, > >>>> > >>>> Can this scenario not be realized by simply placing an HA in the > >>>> enterprise network and using Mobile IP? > >>> > >>> I guess yes and no. > >>> > >>> YEs, in that it is a typical Mobile IP scenario with handovers > >>> WiFi/4G/Ethernet. > >> > >> Handovers between diverse access technologies is one aspect of the > >> proposal, yes. The ability to coordinate multiple access technologies > >> simultaneously is also included as part of the architecture, but some > >> future work needs to be done to put that into practice. > >> > >>> No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not > >>> working well together. > >> > >> Right - switching between VPN and non-VPN will be important for > >> enterprise network mobile device users. > >> > >>> No, in that TIP (DHCPv6 Prefix Delegation?) is not clear how to work > >>> with a EUD device ID? Is it Ethernet's, WiFi's or 4G's interface MAC > >>> address? > >> > >> The mobile device applies the TIP to its downstream-attached > >> interfaces and not to the access technology interfaces over > >> which the prefix delegation was received. So the mobile device > >> is really a mobile router. > >> > >> But, maybe you are asking where does the mobile device get its > >> Device-Unique Identifier (DUID) so it can talk to the DHCPv6 > >> server? The DUID need not be based on a MAC address, but could > >> be some other unique ID assigned to the mobile. So, there is > >> no confusion about which MAC address to choose. > >> > >>> No, in that Mobile IP and prefixes are not known to lead to optimal > >>> routes, whereas the scenario says "optimal routes". > >> > >> Route optimization is indeed a key aspect of the proposal, and > >> in fact hard-coded into the name "AERO". Another key aspect is > >> the in-built distributed mobility management (dmm) architecture. > >> The enterprise can from day one deploy hundreds or even > >> thousands of AERO servers, and the mobile devices simply > >> associate with one or more that are close by. Beyond that, it > >> doesn't matter which server the mobile associates with - it > >> will get the same service as from any other server. > >> > >>> No - but this is a stretch - the scenario does not mention the > >>> neceessity of user typing secure information on a screen (authentica= te > >>> to web page on a public hotspot prior to ability to Mobile IP, or use > >>> One-Time Password tokens for VPN connections); any "seamless" mobilit= y > >>> mechanism will need to automate this step; this is even more needed w= hen > >>> considering devices without user interfaces, such as Mobile Routers > >>> using Mobile IP for a vehicle. > >> > >> Aspects of how the VPN link is established (enter password, > >> insert active badge, etc.) are not discussed, but not really > >> relevant to the way in which AERO can provide the mobile with > >> a stable TIP that never changes. Just that the faster the VPN > >> link can be established, the faster the mobile device can resume > >> service as if it were still coming in through an on-campus > >> enterprise network access link. > >> > >> There is still more to this, such as how AERO can provide an > >> assured path MTU over the tunnel, etc. There should also be > >> an expanded use case analysis. I have been coming at this from > >> an enterprise network viewpoint, but as far as I know AERO > >> could also be applied in the traditional use cases envisioned > >> for MIPv6 and its derivatives. So, it would be good to have > >> some of the experts from this community examine the proposal > >> and provide a comparative analysis. > >> > >> Thanks - Fred > >> fred.l.templin@boeing.com > >> > >>> Alex > >>> > >>>> > >>>> Alper > >>>> > >>>> > >>>> On Sep 3, 2014, at 7:37 PM, Templin, Fred L wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> The specific passage from the new draft that I wanted the wg to > >>>>> see is the following (with references to AERO removed). Please > >>>>> review and send questions or comments. > >>>>> > >>>>> Thanks - Fred fred.l.templin@boeing.com > >>>>> > >>>>> --- > >>>>> > >>>>> 3. A Day in the Life of an Enterprise Mobile Device User > >>>>> > >>>>> An enterprise network mobile device user ("Bill") begins his > >>>>> workday by seating his primary end user device (EUD) (e.g., a > >>>>> laptop computer, a tablet, a smart phone, etc.) in a docking > >>>>> station at his office desk and turning the device on. The docking > >>>>> station connects Bill's EUD to the enterprise wired LAN, and the > >>>>> EUD receives a Topologically-Fixed Address (TFA) from the > >>>>> infrastructure. Bill's EUD further discovers the DMM service > >>>>> within the enterprise network and requests a Topology Independent > >>>>> Prefix (TIP)delegation. Bill's EUD receives the same TIP > >>>>> delegation it gets every time it connects to the enterprise > >>>>> network, because the DMM service has an administratively set > >>>>> mapping between the TIP and Bill's EUD device ID. > >>>>> > >>>>> Bill's EUD can then access topologically-fixed enterprise services > >>>>> using its TFA directly, and can access DMM services by using an > >>>>> address from its TIP as the source address for tunneling over the > >>>>> enterprise network. As Bill's workday unfolds, his EUD uses the > >>>>> DMM service to correspond with other EUDs in peer-to-peer > >>>>> sessions, join lengthy virtual conferencing sessions, access > >>>>> enterprise fileshares, etc. The DMM service ensures that optimal > >>>>> routes are maintained so that tunneled communications flow over > >>>>> direct paths and network infrastructure elements are not > >>>>> unnecessarily over-burdened. > >>>>> > >>>>> While communications sessions such as the video conference are > >>>>> still in progress, Bill leaves the office to attend a meeting in a > >>>>> nearby conference room. He disconnects his EUD from the docking > >>>>> station and in the process drops his connection to the wired LAN. > >>>>> The EUD quickly enables a WiFi interface that searches for a > >>>>> Service Set Identifier (SSID) that can provide wireless access > >>>>> within the enterprise network. The EUD authenticates itself to > >>>>> the network via the SSID using its pre-loaded certificates, and > >>>>> uses a securing mechanism such as IEEE 802.1x to assure > >>>>> Confidentiality, Integrity and Availability (CIA). The EUD > >>>>> receives a new TFA from the network, then communicates its new > >>>>> TIP-to-TFA association to the DMM service and any active peer > >>>>> correspondents. Any ongoing communications sessions will continue > >>>>> to see the same (stable) TIP. > >>>>> > >>>>> Bill then leaves the enterprise campus to attend an off-site > >>>>> customer meeting with his EUD still powered on and actively > >>>>> seeking to maintain network connectivity. As Bill departs from > >>>>> the building, the WiFi signal fades until it can no longer support > >>>>> communications, and the EUD quickly enables a 4G cellular wireless > >>>>> interface that connects Bill's EUD to a cellular service provider. > >>>>> The EUD then locates the Internet address of an enterprise network > >>>>> security gateway and initiates a VPN session with the gateway > >>>>> (which also acts participates in the DMM service). The DMM > >>>>> service updates the routing system, and Bill can continue to use > >>>>> the same TIP that was assigned to his EUD when he started his > >>>>> workday even though the EUD is now communicating over a VPN > >>>>> configured over the public Internet instead of over the secured > >>>>> campus LAN. > >>>>> > >>>>> Bill subsequently arrives at the customer meeting at a public > >>>>> restaurant with a WiFi hotspot. His EUD quickly powers up its WiFi > >>>>> interface and powers down the 4G interface. The EUD uses DMM > >>>>> signaling to communicate the new TFA to the security gateway and > >>>>> the VPN survives the mobility event. Moreover, the EUD can > >>>>> continue to use the same TIP it received at the beginning of the > >>>>> workday, and ongoing communication sessions can continue until > >>>>> Bill explicitly discontinues them. > >>>>> > >>>>> After the customer meeting, Bill leaves the restaurant and > >>>>> subsequently passes through several additional transitions from > >>>>> WiFi hotspots to 4G wireless. Again, the DMM service keeps the VPN > >>>>> session alive, and the TIP assigned to the EUD remains in > >>>>> continuous use in active communication sessions as well as to > >>>>> allow Bill to receive notifications and process urgent requests. > >>>>> When Bill returns to his office, the EUD discontinues use of the > >>>>> VPN while keeping its TIP active after re-attaching to the campus > >>>>> LAN. > >>>>> > >>>>> Bill ends his workday, powers down his EUD and returns home. Bill > >>>>> powers on his EUD to check e-mails, and connects to the enterprise > >>>>> network via a VPN configured over his home ISP service. The EUD > >>>>> again receives the same TIP that it used within the enterprise > >>>>> network domain, and Bill can access DMM services the same as if he > >>>>> was in the office. Bill finally shuts down for the evening, and > >>>>> begins his next workday in the same fashion. Again, the EUD > >>>>> receives the same TIP as always regardless of the access network > >>>>> point of connection over which the EUD enters the enterprise. > >>>>> > >>>>>> -----Original Message----- From: dmm > >>>>>> [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: > >>>>>> Tuesday, September 02, 2014 11:05 AM To: dmm@ietf.org Subject: > >>>>>> [DMM] FW: I-D Action: draft-templin-aeroent-00.txt > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>> During the call today, there was some interest expressed in > >>>>>> learning more about the enterprise network mobility use case. I > >>>>>> have submitted a new brief document called "AERO Enterprise > >>>>>> Network Profile" (below) that provides a discussion of > >>>>>> distributed mobility management needs for enterprise networks. > >>>>>> Although the document specifically cites AERO, the use case > >>>>>> applies to any solution alternative that could meet the > >>>>>> requirements. Also, I am not asking this document be considered > >>>>>> as a dmm wg item at this time, but rather offering it for > >>>>>> informational purposes. Please let me know if there are any > >>>>>> questions or comments. > >>>>>> > >>>>>> Thanks - Fred fred.l.templin@boeing.com > >>>>>> > >>>>>> -----Original Message----- From: I-D-Announce > >>>>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > >>>>>> internet-drafts@ietf.org Sent: Tuesday, September 02, 2014 10:51 > >>>>>> AM To: i-d-announce@ietf.org Subject: I-D Action: > >>>>>> draft-templin-aeroent-00.txt > >>>>>> > >>>>>> > >>>>>> A New Internet-Draft is available from the on-line > >>>>>> Internet-Drafts directories. > >>>>>> > >>>>>> > >>>>>> Title : AERO Enterprise Network Profile Author : Fred > >>>>>> L. Templin Filename : draft-templin-aeroent-00.txt Pages > >>>>>> : 12 Date : 2014-09-02 > >>>>>> > >>>>>> Abstract: Enterprise networks provide a secured data > >>>>>> communications infrastructure built for the purpose of > >>>>>> information sharing and increased productivity for end users > >>>>>> within the organization. Enterprise networks are often organized > >>>>>> as private Internets unto themselves that connect to the global > >>>>>> Internet either not at all or via firewalls, proxies, and/or > >>>>>> other network securing devices. This document discusses an AERO > >>>>>> enterprise network profile that outlines new and more flexible > >>>>>> methods for connecting, tracking and managing mobile > >>>>>> organizational assets. > >>>>>> > >>>>>> > >>>>>> The IETF datatracker status page for this draft is: > >>>>>> https://datatracker.ietf.org/doc/draft-templin-aeroent/ > >>>>>> > >>>>>> There's also a htmlized version available at: > >>>>>> http://tools.ietf.org/html/draft-templin-aeroent-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/ > >>>>>> > >>>>>> _______________________________________________ I-D-Announce > >>>>>> mailing list I-D-Announce@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce > >>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or > >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >>>>>> > >>>>>> _______________________________________________ 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 Thu Sep 11 09:17:24 2014 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 93D891ACCEE for ; Thu, 11 Sep 2014 09:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.254 X-Spam-Level: X-Spam-Status: No, score=-4.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-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 9UYbMaTzQLxr for ; Thu, 11 Sep 2014 09:16:42 -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 7D6721ACCE8 for ; Thu, 11 Sep 2014 09:16:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E85FF107EED; Thu, 11 Sep 2014 18:16:37 +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 0y9hdnuoMYgQ; Thu, 11 Sep 2014 18:16:37 +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 CA86D107ED5; Thu, 11 Sep 2014 18:16:29 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.88]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 11 Sep 2014 18:16:29 +0200 From: Marco Liebsch To: "Sri Gundavelli (sgundave)" , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPp4lB4DM2zhzjQk2BPAsjwbgBU5u2760AgAE+DgCACXRoAIAMxHwAgAAPCACACYjsAIAT+UaAgAAUBoCAAHpbAIAAL/CAgAG1KoCAAI37gIAAvK4AgAACNICAAAWVAIAACByAgAAUmACAAAWVAIABAUAAgAF6iICAAIw+AIAEC7GAgAC2QwCAAP+QgIAAvvIAgAAOp4CAAALBAIABLIIQ///8CACAAHgWAIAABZ4AgADNVnCAADK1gIAARcCg Date: Thu, 11 Sep 2014 16:16:28 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D91A6467C@DAPHNIS.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D91A60559@DAPHNIS.office.hd> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/cR_9-W2r-HOKATgySlRVfQ-p89c Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 11 Sep 2014 16:16:58 -0000 Hi Sri, please see inline. >-----Original Message----- >From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] >Sent: Donnerstag, 11. September 2014 15:58 >To: Marco Liebsch; Charlie Perkins; dmm@ietf.org >Cc: Vijay Devarapalli >Subject: Re: [DMM] regarding the re-chartering.. > >I do not see a reason why multiple MN-Id instances need to be present in a >single message ? In my experience, this is strictly a deployment considera= tion, >when to use what type of identifiers. Then there is no issue and it's the cleanest approach. Multiple IDs possibl= e, deployment determines which type to use, single MNID present. Done. > >Assuming the backend system can tie all the MN-Id's to a single subscripti= on, any >presented identifier can be sufficient for the gateway to do the BCE looku= p. > >If multiple instances can be present, then we need to deal with more error >cases. Is that really needed ? Not necessarily for the lookup.=20 Only if multiple IDs should be conveyed to do more than a lookup.. Example: Use the TAC of an IMEI to tailor QoS on the LMA for a certain devi= ce type ;-) Probably that goes beyond what has been proposed in this thread. > > >> I am wondering if it would not be more appropriate to go for a >>different container option to carry such information. Something like a >>complementary identifier option. > >Sounds interesting. Are you suggesting we leave the current MN-ID as it is= , but >use a new complementary option ? But, if the requirement is for a Mac base= d >identifiers, what will be there in the current MN-Id option ? We still nee= d to >have identifier there ? I proposed this only for IDs, which are conveyed to complement the one in t= he MNID and are being used for other things than a BC lookup. marco > > > > >Sri > > > > > >On 9/11/14 2:03 AM, "Marco Liebsch" wrote: > >>No issue with logical vs. physical ID. But I am wondering about two >>things: >> >>Operation is clear to me in case a single MNID is present in a message >>and I see the value in being flexible to choose from different >>sub-types. If multiple MNIDs with different sub-types are present in a >>single message, which one should e.g. the LMA take for the BC lookup.. >>No big problem to solve, but >>to be considered in implementations. >> >>If the reason for multiple present MNIDs with different sub-types is to >>do other things than identifying the node or using the ID as key for a >>lookup, I am wondering if it would not be more appropriate to go for a >>different container option to carry such information. >>Something like a complementary >>identifier option. >> >>marco >> >>>-----Original Message----- >>>From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] >>>Sent: Donnerstag, 11. September 2014 00:42 >>>To: Charlie Perkins; Marco Liebsch; dmm@ietf.org >>>Cc: Vijay Devarapalli >>>Subject: Re: [DMM] regarding the re-chartering.. >>> >>>Hello Charlie, >>> >>>Agree with that. MN-Id as its defined today is a logical identifier. >>>It does not require the identifier to be bound to a physical device or >>>a interface identity. >>>But, we have clearly seen requirements where the need is for >>>generating identifiers based on some physical identifiers. Those >>>physical identifiers include IMSI, MSISDN, IMEI, MAC ..etc. If we can >>>define a type for each of the source and the rules for generating >>>MN-ID based using those sources, the sender and receiver will have >>>clear guidance on how to use the spec. Some pointers, explanation and >>>examples for each of those identifiers will greatly help avoid >>>inter-op issues. >>> >>> >>>Regards >>>Sri >>> >>> >>> >>> >>> >>> >>> >>>On 9/10/14 3:21 PM, "Charlie Perkins" >>>wrote: >>> >>>> >>>>Hello folks, >>>> >>>>I think it's best to consider the MNID as simply living in a space of >>>>identifiers, and not worry too much about whether it's a logical >>>>identifier or a physical identifier. If the former, then somewhere >>>>(perhaps below the network layer) the logical identifier has been >>>>bound to something in the physical interface, but that's not our proble= m. >>>> >>>>The number space for types of MNIDs is likely to stay pretty empty, >>>>so I'd say we could add as many types as would be convenient for the >>>>software designers. So, we could conceivably have several MNIDs >>>>defined that all "looked like" NAIs (which, themselves, "look like" >>>>FQDNs). >>>> >>>>Regards, >>>>Charlie P. >>>> >>>> >>>> >>>>On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote: >>>>> Yes. Currently, the MNID is if the nai format and is overloaded. >>>>>The MNID in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on >>>>>the IMSI. Ex: >>>>> "@epc.mnc.mcc.3gppnetwork.org=B2 >>>>> >>>>> We also have MAC48@REALM; >>>>> >>>>> We also have approaches to transform MAC to Pseudo IMSI, and then >>>>> carry IMSI-NAI as the MN-ID. >>>>> >>>>> >>>>> So, we need unique sub-types for each of the types/sources. >>>>> >>>>> MN-Id based on IMSI, MSISDN, IMEI, MAC .. >>>>> >>>>> Also, do we need to distinguish between IMSI and IMSI-NAI ? >>>>> >>>>> Sri >>>>> >>>>> >>>>> >>>>> On 9/10/14 6:29 AM, "Marco Liebsch" wrote: >>>>> >>>>>> It seems the MNID is somehow overloaded to carry both, >>>>>>node-specific IDs, e.g. MAC, as well as subscriber IDs, which is the= IMSI. >>>>>> There may be value in adding the IMEI to the list of possible >>>>>>types of node-specific IDs. >>>>>> >>>>>> marco >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri >>>>>>> Gundavelli >>>>>>> (sgundave) >>>>>>> Sent: Dienstag, 9. September 2014 23:30 >>>>>>> To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org >>>>>>> Cc: Vijay Devarapalli >>>>>>> Subject: Re: [DMM] regarding the re-chartering.. >>>>>>> >>>>>>> Two more comments. >>>>>>> >>>>>>> >>>>>>> >>>>>>> 4.) I'd also use sub-type value of (2) for IMSI. Just to align >>>>>>>with the sub-types defined for MN Id defined for ICMP. I suspect >>>>>>>there are some implementations already using sub-type (2). >>>>>>>Please see the other thread. >>>>>>> >>>>>>> >>>>>>> 5.) For each of the sub-types, we need text including examples >>>>>>>and some explanation on how they are used. >>>>>>> >>>>>>> >>>>>>> Sri >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Charlie, >>>>>>>> >>>>>>>> This is good. Thanks. >>>>>>>> >>>>>>>> >>>>>>>> 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE >>>>>>>>802.2 >>>>>>>> address, why do we need to two sub-types ? Why not have just one >>>>>>>>sub-type for mac based identifiers ? >>>>>>>> >>>>>>>> 2.) Sub type value (1) is currently used. Its currently >>>>>>>>overloaded for IMSI-NAI (3GPP specs) and generic NAI based >>>>>>>>identifiers. Given the definition of new sub-types, we need some >>>>>>>>text explaining the motivation >>>>>>>> >>>>>>>> 3.) Proposed Sub-type value of (2) for IPv6 address. What >>>>>>>>exactly is this ? Are these CGA-based IPv6 addresses ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> New Mobile Node Identifier Types >>>>>>>> >>>>>>>> +-----------------+------------------------+ >>>>>>>> | Identifier Type | Identifier Type Number | >>>>>>>> +-----------------+------------------------+ >>>>>>>> | IPv6 Address | 2 | >>>>>>>> | | | >>>>>>>> | IMSI | 3 | >>>>>>>> | | | >>>>>>>> | P-TMSI | 4 | >>>>>>>> | | | >>>>>>>> | EUI-48 address | 5 | >>>>>>>> | | | >>>>>>>> | EUI-64 address | 6 | >>>>>>>> | | | >>>>>>>> | GUTI | 7 | >>>>>>>> +-----------------+------------------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> Sri >>>>>>>> PS: Good to see Vijay back >>>>>>>> >>>>>>>> >>>>>>>> On 9/9/14 1:28 PM, "Charlie Perkins" >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hello folks, >>>>>>>>> >>>>>>>>> Here's the last Internet Draft that we did, long ago expired: >>>>>>>>> http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01. >>>>>>>>> txt >>>>>>>>> >>>>>>>>> I'll resubmit it with a few updates as a personal draft to dmm. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Charlie P. >>>>>>>> _______________________________________________ >>>>>>>> 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 Sep 11 10:12:23 2014 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 B030B1A893A for ; Thu, 11 Sep 2014 10:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 QV7ta5RYY1yQ for ; Thu, 11 Sep 2014 10:12:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2609C1A8952 for ; Thu, 11 Sep 2014 10:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=837; q=dns/txt; s=iport; t=1410455537; x=1411665137; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MxQ09UcFuzwSJDz83w3T/++x9qUf/Nl386lyUScdZEY=; b=PwxsNBj3p77OeT+qZjYay4CLJJMODoQckq/f9Y27IFMCaq2JGXI2YBIg 7/Hsmyh+FD08lQ/7iqpsEV+5lcif4193s2hJXkI1ude2CUFenIyzlDYXF 7koLrgwn+QM/rBtvs4th1m8PzNVvTrqTpP+SOsC61DrR5jCy3sCvLxLds I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAG/XEVStJA2N/2dsb2JhbABfgw2BKgTQFQGBERZ4hAMBAQEEOj8MBgEIEQQBAR8JORQJCAIEAQ0FiEK/DwEXjyIrBwaERgEEkUuLNpU7g2FsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,506,1406592000"; d="scan'208";a="354492186" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP; 11 Sep 2014 17:12:16 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8BHCGl4029271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 17:12:16 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 12:12:16 -0500 From: "Sri Gundavelli (sgundave)" To: Marco Liebsch , Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] regarding the re-chartering.. Thread-Index: AQHPzeOIFTJi/s504kOP81QcxzozOA== Date: Thu, 11 Sep 2014 17:12:15 +0000 Message-ID: In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D91A6467C@DAPHNIS.office.hd> 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.21.64.105] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/JDYN__S_mvKxdvrmAB6PWZw7HIM Cc: Vijay Devarapalli Subject: Re: [DMM] regarding the re-chartering.. 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, 11 Sep 2014 17:12:21 -0000 Hi Marco, On 9/11/14 9:16 AM, "Marco Liebsch" wrote: >Hi Sri, please see inline. > >>-----Original Message----- >>From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] >>Sent: Donnerstag, 11. September 2014 15:58 >>To: Marco Liebsch; Charlie Perkins; dmm@ietf.org >>Cc: Vijay Devarapalli >>Subject: Re: [DMM] regarding the re-chartering.. >> >>I do not see a reason why multiple MN-Id instances need to be present in >>a >>single message ? In my experience, this is strictly a deployment >>consideration, >>when to use what type of identifiers. > >Then there is no issue and it's the cleanest approach. Multiple IDs >possible, >deployment determines which type to use, single MNID present. Done. Ack. That will have least impact on the existing specs. Regards Sri From nobody Thu Sep 11 11:03:25 2014 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 2516B1A8AB3 for ; Thu, 11 Sep 2014 11:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 uuuDEkVwckzj for ; Thu, 11 Sep 2014 11:03:06 -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 9C04A1A8BC1 for ; Thu, 11 Sep 2014 11:00:20 -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 s8BI0JYS007625; Thu, 11 Sep 2014 13:00:19 -0500 Received: from XCH-BLV-303.nw.nos.boeing.com (xch-blv-303.nw.nos.boeing.com [130.247.25.215]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8BI0C3s007572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 11 Sep 2014 13:00:13 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.55]) with mapi id 14.03.0181.006; Thu, 11 Sep 2014 11:00:11 -0700 From: "Templin, Fred L" To: "Sri Gundavelli (sgundave)" , Jouni Korhonen , "sarikaya@ieee.org" Thread-Topic: [DMM] DMM Interim call #2 - agenda forming Thread-Index: AQHPzSY685cNtlvM5kaPQ9fwALiOyZv6soAwgAFMcQCAAC5BQA== Date: Thu, 11 Sep 2014 18:00:11 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D1672B@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D1590D@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/YvKaSqmSsILjXHbIlcW49HNm24w Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 11 Sep 2014 18:03:18 -0000 Hi Sri, See below for some follow-up: > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] > Sent: Thursday, September 11, 2014 12:28 AM > To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org > Cc: Dapeng Liu; dmm@ietf.org > Subject: Re: [DMM] DMM Interim call #2 - agenda forming >=20 > Hi Fred, >=20 > The below comment from you made me thinking. I must admit I'm not much > familiar with Aero, have not seen its references in CDMA, WiMAX, > CableLabs, WLAN or LTE architectures. But, if it has all the mobility > features and you believe this can conclude the WG, I thought I will > explore this a bit. I started reviewing the charts that you sent and > started browsing some of the specs. Few high-level questions, if you can > answer or point me to some documents, it will be great. >=20 >=20 > 1.) What is the interface between the Aero Server and the client ? Is it > just DHCPv6 ? There is no other signaling interface ? DHCPv6 is used for PD as well as mobility signaling. IPv6 ND messaging is used for NUD, route optimization, and the functional equivalent of a "binding update" via the use of unsolicited Neighbor Advertisements. =20 > 2.) What is the service authorization model for a Aero client ? How is th= e > client identified by the server ? What is the security model ? The Client is identified by the server via the DHCPv6 DUID. The DUID is most likely based on some serial number or ID that is assigned to the Client by the AERO service administrative staff. The security model is based on a multi-tiered layered security approach. First, the Client must authenticate itself to the network using whatever access layer securing mechanisms that are available, e.g., IEEE802.1x. For Clients that are coming into the network from the Internet, the Client establishes a VPN link to a security gateway at the network border. Second, the Client must prove to the Server that it is authorized to perform DHCPv6 signaling using DHCPv6 Auth or some other DHCPv6 securing mechanism. This is only to protect against an "insider attack" in which a different Client pretends to be the authorized Client in order to hijack the authorized Client's prefix, siphon traffic, etc. Hence, a "better than nothing" authentication such as DHCPv6 Auth is really all that is needed. Third, the network must ensure that link-layer addresses cannot be spoofed. Here, the "link-layer address" is the IP source address of the encapsulating tunnel header. This is typically done through proper application of BCP ingress filtering practices. Finally, the AERO Server/Relay infrastructure provides a trust anchor to facilitate Client-to-Client route optimizations. In particular, Clients trust their Servers but cannot trust each other initially. If a Client receives a route optimization signal from its trusted Server, however, it can safely engage in the route optimization since a chain-of-trust was followed.=20 > 3.) Can the Aero solution support IP nodes that do not have Aero client > stack ? Proxy AERO could be applied in the same manner as for PMIP, but the document does not fully investigate that option at this time. > 4.) If a mobile or a cable SP deploys Aero, where is their point of > control ? Where can they do Accounting, Lawful interception ? Lawful intercept, accounting, etc. can be done at the AERO Servers. In case these functions are mandatory, direct Client-to-Client route optimizations would not be permitted in those environments. However, Client-to-Server-to-Client route optimizations would still be used to reduce path stretch and reduce load on critical infrastructure. > 5.) I assume Aero client can be IPv4 or an IPv6 device ? For an IPv4-only > legacy device, is the interface DHCPv4 ? The AERO data plane can be either IPv4 or IPv6, and can be tunneled over either IPv4 or IPv6 access networks. The AERO control plane is always DHCPv6 and IPv6 ND. In particular, DHCPv6 PD can be used to delegate IPv4 prefixes in the same way that it can delegate IPv6 prefixes. So no; DHCPv4 is not used in the control plane. > 6.) Can an operator enable location-based services for a Aero client ? AERO Clients discover and associate with AERO Servers that are "nearby". They discover nearby Servers by resolving the DNS FQDN "linkupnetworks.[domain]" where "[domain]" is a link- specific DNS suffix. This would provide topological proximity and I guess most often also geographic proximity. Is that what you were asking? > 7.) How can an operator enable IP Flow Mobility type features in an Aero > system ? I am not familiar with IP Flow Mobility, but does it mean spreading traffic load across multiple access links? Like maybe sending streaming video across WLAN while posting short text messages via 4G? If so, AERO supports the use of multiple simultaneous access links - like, keeping both the WLAN and 4G interfaces active at the same time. Or maybe I am mis-understanding IP Flow Mobility? =20 > 8.) Taking a mobile router scenario, how does Aero client support > multi-tenancy ? Is there a single tunnel between the client and the serve= r Again, I am not familiar with the term multi-tenancy, or at least not with its use within this context. In terms of tunnels, however, the tunnel is non-broadcast, multiple access (NBMA) and not point-to-point. So each AERO node sees other AERO nodes as neighbors on the NBMA link. The AERO interface therefore maintains a neighbor cache the same as any IP interface, and uses the neighbor cache entries to track the current L3/L2 address mappings. These mappings may change over time, e.g., as the result of a mobility event. Thanks - Fred fred.l.templin@boeing.com > ? >=20 >=20 > Regards > Sri >=20 >=20 >=20 >=20 > On 9/10/14 11:43 AM, "Templin, Fred L" wrote: >=20 > >Hi Jouni, > > > >I'd like to propose a slightly different charter: > > > > "AERO already solves distributed mobility management and provides a > > a comprehensive mobility solution for any mobile device. AERO should > > therefore be approved as the mobility management solution for DMM. > > Publication of AERO will therefore conclude the working group's > > activity." > > > >Can we have this on the agenda? > > > >Thanks - Fred > >fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > >> Sent: Wednesday, September 10, 2014 11:37 AM > >> To: sarikaya@ieee.org > >> Cc: Dapeng Liu; dmm@ietf.org > >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming > >> > >> > >> What do you mean by no agenda? To me it clearly says we use the call #= 2 > >> for setting up the work split. > >> > >> - Jouni > >> > >> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: > >> > Jouni, why don't we cancel this one (#2) and do the next one (#3) wi= th > >> > an agenda? > >> > I hope Alper can attend :-) > >> > > >> > Regards, > >> > > >> > Behcet > >> > > >> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen > >> wrote: > >> >> > >> >> It seems I sent this to a wrong receiver.. that explains why it did > >>not > >> >> appear on the list. > >> >> > >> >> - Jouni > >> >> > >> >> -------- Alkuper=E4inen viesti / Orig.Msg. -------- > >> >> Aihe: DMM Interim call #2 - agenda forming > >> >> P=E4iv=E4ys: Mon, 08 Sep 2014 23:43:24 +0300 > >> >> L=E4hett=E4j=E4: Jouni Korhonen > >> >> Vastaanottaja: dmm-ads@tools.ietf.org > >> >> CC: jouni.nospam@gmail.com, Dapeng Liu > >> >> > >> >> Folks, > >> >> > >> >> The next interim is close. Assuming there are no overwhelming amoun= t > >>of > >> >> comments to the re-charter text, we are ready to start setting up t= he > >> >> work split on the solution space! Remember the discussion and the > >> >> minutes from the IETF#90 Friday session. No other agenda items are > >> >> planned for the next interim. > >> >> > >> >> - 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 > >_______________________________________________ > >dmm mailing list > >dmm@ietf.org > >https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Sep 11 13:36:32 2014 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 1C6501A0185 for ; Thu, 11 Sep 2014 13:36:31 -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 avBktKRAzNDN for ; Thu, 11 Sep 2014 13:36:29 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD891A0173 for ; Thu, 11 Sep 2014 13:36:29 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id el20so3632664lab.19 for ; Thu, 11 Sep 2014 13:36:27 -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=wUcfzrwPcae0DMf+cwEh2F44jp9iq+EZ8Iddw9WQ36g=; b=Wls3zFtu4NddYsK6wpuba7/Mx/+LMg94khJ3A8cGJRJRyhHSMYMSOkGLelLfCaC1Vj lGOnZMGTmgL9npyujZomgmsPKFvst87a3HhXz7vi5IJWKmFgVYjKnl6ZhRpdagXlEo10 I2Cg4RpCyx1S7em9y7ReDFoF++uYlWSeQT8gSo3mHz3Ql4z6AsEkVzCWrPW50XGrohEX 2iDnhhp9kEyuWsyPmmFDelXXxTuj3U1xV3LJtYwJkRhMQB9ESW0+WZs3XdEeq4yjdQo4 0jYJe7cKT4vjXHWgH92Gaui84aCowy/z+lkL3sHdnUq6v6cFkMnE4hnnteXGv+xB6OFJ EgjQ== MIME-Version: 1.0 X-Received: by 10.112.128.228 with SMTP id nr4mr3692497lbb.42.1410467787535; Thu, 11 Sep 2014 13:36:27 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Thu, 11 Sep 2014 13:36:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Sep 2014 15:36:27 -0500 Message-ID: From: Behcet Sarikaya To: "Sri Gundavelli (sgundave)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/WS7H5R4KGz4AmMnpRbTQLQ0__xM Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM Interim call #2 - agenda forming 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, 11 Sep 2014 20:36:31 -0000 Hi Sri, Let me explain. On Wed, Sep 10, 2014 at 5:38 PM, Sri Gundavelli (sgundave) wrote: > Hi Behcet, > > Look for the qualifiers which states its an opinion. Don't just poke. > Goal is to converge - Read that. > > > If you disagree with this, I assume you want a debate on the protocol > choice. Go for it. > > > Sri > > > > On 9/10/14 3:15 PM, "Behcet Sarikaya" wrote: > >>Hi Sri, >> >>On Wed, Sep 10, 2014 at 5:01 PM, Sri Gundavelli (sgundave) >> wrote: >>> Hi Fred, >>> >>> >>> IMHO, DMM solution need to be tied to one specific protocol. We don't >>>have >>> to battle this out and come up with one answer. Once we have high-level >>> view of the solution and the interfaces, its possible to realize those >>> interfaces using any protocols. You call it MIP, GTP, Aero ..does not >>> matter. The core specs can identify the interface requirements and the >>> specific protocol documents can publish extensions to the protocols. We >>> let the deployments make the call on the protocol choice. >>> You have been saying these things since long time. You made a presentation in Toronto. Before, in dmm calls you showed some slides. I don't understand why you do not come up with a draft containing your solution or parts of it? I know you can write drafts :-) We do have solution drafts. You should also compete with your draft. I think the charter is in no way prescribing a design team type of approach and that makes sense because we already have solution proposals and we certainly may have more. In this step we need to scrutinize all the solution drafts and eventually try to get consensus on one on which we can further work as a group to build the final solution. I saw a lot of discussion in this thread. That is a good sign. Regards, behcet >> >>These are your views. >>Not mine for sure. >> >>Regards, >> >>Behcet >>> >>> >>> Regards >>> Sri >>> >>> >>> >>> >>> >>> On 9/10/14 11:43 AM, "Templin, Fred L" >>>wrote: >>> >>>>Hi Jouni, >>>> >>>>I'd like to propose a slightly different charter: >>>> >>>> "AERO already solves distributed mobility management and provides a >>>> a comprehensive mobility solution for any mobile device. AERO should >>>> therefore be approved as the mobility management solution for DMM. >>>> Publication of AERO will therefore conclude the working group's >>>> activity." >>>> >>>>Can we have this on the agenda? >>>> >>>>Thanks - Fred >>>>fred.l.templin@boeing.com >>>> >>>>> -----Original Message----- >>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>>> Sent: Wednesday, September 10, 2014 11:37 AM >>>>> To: sarikaya@ieee.org >>>>> Cc: Dapeng Liu; dmm@ietf.org >>>>> Subject: Re: [DMM] DMM Interim call #2 - agenda forming >>>>> >>>>> >>>>> What do you mean by no agenda? To me it clearly says we use the call >>>>>#2 >>>>> for setting up the work split. >>>>> >>>>> - Jouni >>>>> >>>>> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti: >>>>> > Jouni, why don't we cancel this one (#2) and do the next one (#3) >>>>>with >>>>> > an agenda? >>>>> > I hope Alper can attend :-) >>>>> > >>>>> > Regards, >>>>> > >>>>> > Behcet >>>>> > >>>>> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen >>>>> wrote: >>>>> >> >>>>> >> It seems I sent this to a wrong receiver.. that explains why it di= d >>>>>not >>>>> >> appear on the list. >>>>> >> >>>>> >> - Jouni >>>>> >> >>>>> >> -------- Alkuper=C3=A4inen viesti / Orig.Msg. -------- >>>>> >> Aihe: DMM Interim call #2 - agenda forming >>>>> >> P=C3=A4iv=C3=A4ys: Mon, 08 Sep 2014 23:43:24 +0300 >>>>> >> L=C3=A4hett=C3=A4j=C3=A4: Jouni Korhonen >>>>> >> Vastaanottaja: dmm-ads@tools.ietf.org >>>>> >> CC: jouni.nospam@gmail.com, Dapeng Liu >>>>> >> >>>>> >> Folks, >>>>> >> >>>>> >> The next interim is close. Assuming there are no overwhelming >>>>>amount >>>>>of >>>>> >> comments to the re-charter text, we are ready to start setting up >>>>>the >>>>> >> work split on the solution space! Remember the discussion and the >>>>> >> minutes from the IETF#90 Friday session. No other agenda items are >>>>> >> planned for the next interim. >>>>> >> >>>>> >> - 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 >>>>_______________________________________________ >>>>dmm mailing list >>>>dmm@ietf.org >>>>https://www.ietf.org/mailman/listinfo/dmm >>> > From nobody Thu Sep 11 13:43:57 2014 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 68CCE1A0154 for ; Thu, 11 Sep 2014 13:43:56 -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 y9h0OTtZye30 for ; Thu, 11 Sep 2014 13:43:55 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE47A1A0135 for ; Thu, 11 Sep 2014 13:43:54 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id w7so8567301lbi.31 for ; Thu, 11 Sep 2014 13:43: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; bh=mrJYPj6Ay3B4DnfG7yZK8NDrMa6JorWCdFMldL2rRfk=; b=p9hKlP5/xUxNK9fK4kxIjxkha7viIM/rgVyW4dLQ3ciczPCIx/v5Sd+IYyYWlxSoQZ HjQp3IA0fKfv++D3+pOqaLsSDKdauasxQl+2zktczAW7Ci1065rdg7p2N0BTtOqouikX XCuB/JaIGsajdjgngEuQRvHDwHWBJ173S44UMIKH44AwZckKNZ26bzy8RHkjoVLRXGIP rRwkJPn1EVx5hJYYnb9P+tNt8V6NXa+ZGCA+RlEH0G3ZBPWrw9qJp/H9wgwgTnOMdFOH fszE+unU4eRopViebaCK78Qf/nmIbArSgoj9Etg32Zs08ydpaU6FmMt+sQyczxyS3WCw M9EA== MIME-Version: 1.0 X-Received: by 10.112.56.206 with SMTP id c14mr3767574lbq.27.1410468233087; Thu, 11 Sep 2014 13:43:53 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Thu, 11 Sep 2014 13:43:53 -0700 (PDT) In-Reply-To: <54119C10.6020002@gmail.com> References: <54119C10.6020002@gmail.com> Date: Thu, 11 Sep 2014 15:43:53 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/q-kaWucNboBSbIufu8v8vF-2uwY Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] DMM interim call #3 - doodle 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, 11 Sep 2014 20:43:56 -0000 Hi Jouni, You have 8am option, I guess it is 8am in Helsinki? Which means 12 midnight in Dallas, 1am in East Coast. So I marked 5pm choices. Regards, Behcet On Thu, Sep 11, 2014 at 7:56 AM, Jouni Korhonen wrote: > > Folks, > > For the call #3 express your preference by Friday 12th EOB PDT. > > http://doodle.com/kpwphfbtgmtsde3s > > - Jouni & Dapeng > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Sep 11 14:46:41 2014 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 7F8471A02DE for ; Thu, 11 Sep 2014 14:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652] 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 dTl1JseZJuQs for ; Thu, 11 Sep 2014 14:46:34 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 221F01A02A2 for ; Thu, 11 Sep 2014 14:46:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Qf5ttSR+a6ClQ6IJxnki3UsjYFoj/SYGQUzGFV5mjkRUYeMBDdqXcCNmXQh1SC3T; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.255.215]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XSCCF-0007XO-BI; Thu, 11 Sep 2014 17:46:32 -0400 Message-ID: <54121835.702@earthlink.net> Date: Thu, 11 Sep 2014 14:46:29 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , Marco Liebsch , dmm@ietf.org, Vijay Devarapalli References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060303040506010605060407" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac716e8ff048f8b53c9b9cefb55b57a42a3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/0z1nN1i1E59ytD73cOqVdQ3bo9Y Subject: Re: [DMM] MNID Types 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, 11 Sep 2014 21:46:37 -0000 This is a multi-part message in MIME format. --------------060303040506010605060407 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit Hello folks, I propose to submit the ....-00.txt document as it is to the Internet Drafts directory, and then to go about making updates according to the discussion on this list. Do you think this is reasonable? Regards, Charlie P. On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote: > > > > > Marco, > > > Thinking further on the complementary identifier option. > > - There is already the link-layer identifier option that can be used for > carrying the Mac address > - IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's > > In some sense, the complementary identifiers are already present. > > Sri > > > > > > On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)" wrote: > >> I do not see a reason why multiple MN-Id instances need to be present in a >> single message ? In my experience, this is strictly a deployment >> consideration, when to use what type of identifiers. >> >> Assuming the backend system can tie all the MN-Id's to a single >> subscription, any presented identifier can be sufficient for the gateway >> to do the BCE lookup. >> >> If multiple instances can be present, then we need to deal with more error >> cases. Is that really needed ? >> >> >>> I am wondering if it would not be more appropriate to go for a different >>> container option to carry such information. Something like a >>> complementary identifier option. >> Sounds interesting. Are you suggesting we leave the current MN-ID as it >> is, but use a new complementary option ? But, if the requirement is for a >> Mac based identifiers, what will be there in the current MN-Id option ? We >> still need to have identifier there ? >> >> >> >> >> Sri >> >> >> >> >> >> On 9/11/14 2:03 AM, "Marco Liebsch" wrote: >> >>> No issue with logical vs. physical ID. But I am wondering about two >>> things: >>> >>> Operation is clear to me in case a single MNID is present in a message >>> and I see the value in being >>> flexible to choose from different sub-types. If multiple MNIDs with >>> different sub-types are present in >>> a single message, which one should e.g. the LMA take for the BC lookup.. >>> No big problem to solve, but >>> to be considered in implementations. >>> >>> If the reason for multiple present MNIDs with different sub-types is to >>> do other things than identifying >>> the node or using the ID as key for a lookup, I am wondering if it would >>> not be more appropriate >>> to go for a different container option to carry such information. >>> Something like a complementary >>> identifier option. >>> >>> marco >>> >>>> -----Original Message----- >>>> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] >>>> Sent: Donnerstag, 11. September 2014 00:42 >>>> To: Charlie Perkins; Marco Liebsch; dmm@ietf.org >>>> Cc: Vijay Devarapalli >>>> Subject: Re: [DMM] regarding the re-chartering.. >>>> >>>> Hello Charlie, >>>> >>>> Agree with that. MN-Id as its defined today is a logical identifier. It >>>> does not >>>> require the identifier to be bound to a physical device or a interface >>>> identity. >>>> But, we have clearly seen requirements where the need is for generating >>>> identifiers based on some physical identifiers. Those physical >>>> identifiers include >>>> IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the >>>> source >>>> and the rules for generating MN-ID based using those sources, the sender >>>> and >>>> receiver will have clear guidance on how to use the spec. Some pointers, >>>> explanation and examples for each of those identifiers will greatly help >>>> avoid >>>> inter-op issues. >>>> >>>> >>>> Regards >>>> Sri >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 9/10/14 3:21 PM, "Charlie Perkins" >>>> wrote: >>>> >>>>> Hello folks, >>>>> >>>>> I think it's best to consider the MNID as simply living in a space of >>>>> identifiers, and not worry too much about whether it's a logical >>>>> identifier or a physical identifier. If the former, then somewhere >>>>> (perhaps below the network layer) the logical identifier has been bound >>>>> to something in the physical interface, but that's not our problem. >>>>> >>>>> The number space for types of MNIDs is likely to stay pretty empty, so >>>>> I'd say we could add as many types as would be convenient for the >>>>> software designers. So, we could conceivably have several MNIDs >>>>> defined that all "looked like" NAIs (which, themselves, "look like" >>>>> FQDNs). >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> >>>>> On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote: >>>>>> Yes. Currently, the MNID is if the nai format and is overloaded. The >>>>>> MNID in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the >>>>>> IMSI. Ex: >>>>>> "@epc.mnc.mcc.3gppnetwork.org©÷ >>>>>> >>>>>> We also have MAC48@REALM; >>>>>> >>>>>> We also have approaches to transform MAC to Pseudo IMSI, and then >>>>>> carry IMSI-NAI as the MN-ID. >>>>>> >>>>>> >>>>>> So, we need unique sub-types for each of the types/sources. >>>>>> >>>>>> MN-Id based on IMSI, MSISDN, IMEI, MAC .. >>>>>> >>>>>> Also, do we need to distinguish between IMSI and IMSI-NAI ? >>>>>> >>>>>> Sri >>>>>> >>>>>> >>>>>> >>>>>> On 9/10/14 6:29 AM, "Marco Liebsch" wrote: >>>>>> >>>>>>> It seems the MNID is somehow overloaded to carry both, node-specific >>>>>>> IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI. >>>>>>> There may be value in adding the IMEI to the list of possible types >>>>>>> of node-specific IDs. >>>>>>> >>>>>>> marco >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >>>>>>>> (sgundave) >>>>>>>> Sent: Dienstag, 9. September 2014 23:30 >>>>>>>> To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org >>>>>>>> Cc: Vijay Devarapalli >>>>>>>> Subject: Re: [DMM] regarding the re-chartering.. >>>>>>>> >>>>>>>> Two more comments. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4.) I'd also use sub-type value of (2) for IMSI. Just to align with >>>>>>>> the sub-types defined for MN Id defined for ICMP. I suspect there >>>>>>>> are some implementations already using sub-type (2). Please see >>>>>>>> the other thread. >>>>>>>> >>>>>>>> >>>>>>>> 5.) For each of the sub-types, we need text including examples and >>>>>>>> some >>>>>>>> explanation on how they are used. >>>>>>>> >>>>>>>> >>>>>>>> Sri >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Charlie, >>>>>>>>> >>>>>>>>> This is good. Thanks. >>>>>>>>> >>>>>>>>> >>>>>>>>> 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE >>>>>>>>> 802.2 >>>>>>>>> address, why do we need to two sub-types ? Why not have just one >>>>>>>>> sub-type for mac based identifiers ? >>>>>>>>> >>>>>>>>> 2.) Sub type value (1) is currently used. Its currently overloaded >>>>>>>>> for >>>>>>>>> IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the >>>>>>>>> definition of new sub-types, we need some text explaining the >>>>>>>>> motivation >>>>>>>>> >>>>>>>>> 3.) Proposed Sub-type value of (2) for IPv6 address. What exactly >>>>>>>>> is >>>>>>>>> this ? Are these CGA-based IPv6 addresses ? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> New Mobile Node Identifier Types >>>>>>>>> >>>>>>>>> +-----------------+------------------------+ >>>>>>>>> | Identifier Type | Identifier Type Number | >>>>>>>>> +-----------------+------------------------+ >>>>>>>>> | IPv6 Address | 2 | >>>>>>>>> | | | >>>>>>>>> | IMSI | 3 | >>>>>>>>> | | | >>>>>>>>> | P-TMSI | 4 | >>>>>>>>> | | | >>>>>>>>> | EUI-48 address | 5 | >>>>>>>>> | | | >>>>>>>>> | EUI-64 address | 6 | >>>>>>>>> | | | >>>>>>>>> | GUTI | 7 | >>>>>>>>> +-----------------+------------------------+ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Sri >>>>>>>>> PS: Good to see Vijay back >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/9/14 1:28 PM, "Charlie Perkins" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hello folks, >>>>>>>>>> >>>>>>>>>> Here's the last Internet Draft that we did, long ago expired: >>>>>>>>>> >>>>>>>>>> http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt >>>>>>>>>> >>>>>>>>>> I'll resubmit it with a few updates as a personal draft to dmm. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Charlie P. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 --------------060303040506010605060407 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 8bit
Hello folks,

I propose to submit the ....-00.txt document as it is to the Internet
Drafts directory, and then to go about making updates according to
the discussion on this list.  Do you think this is reasonable?

Regards,
Charlie P.


On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:

<Changing the subject line to reflect the MNId discussion>


Marco,


Thinking further on the complementary identifier option.

- There is already the link-layer identifier option that can be used for
carrying the Mac address
- IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's

In some sense, the complementary identifiers are already present.

Sri





On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com> wrote:


I do not see a reason why multiple MN-Id instances need to be present in a
single message ? In my experience, this is strictly a deployment
consideration, when to use what type of identifiers.

Assuming the backend system can tie all the MN-Id's to a single
subscription, any presented identifier can be sufficient for the gateway
to do the BCE lookup.

If multiple instances can be present, then we need to deal with more error
cases. Is that really needed ?



I am wondering if it would not be more appropriate to go for a different
container option to carry such information. Something like a
complementary identifier option.

Sounds interesting. Are you suggesting we leave the current MN-ID as it
is, but use a new complementary option ? But, if the requirement is for a
Mac based identifiers, what will be there in the current MN-Id option ? We
still need to have identifier there ?




Sri





On 9/11/14 2:03 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:


No issue with logical vs. physical ID. But I am wondering about two
things:

Operation is clear to me in case a single MNID is present in a message
and I see the value in being
flexible to choose from different sub-types. If multiple MNIDs with
different sub-types are present in
a single message, which one should e.g. the LMA take for the BC lookup..
No big problem to solve, but
to be considered in implementations.

If the reason for multiple present MNIDs with different sub-types is to
do other things than identifying
the node or using the ID as key for a lookup, I am wondering if it would
not be more appropriate
to go for a different container option to carry such information.
Something like a complementary
identifier option.

marco


-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Agree with that. MN-Id as its defined today is a logical identifier. It
does not
require the identifier to be bound to a physical device or a interface
identity.
But, we have clearly seen requirements where the need is for generating
identifiers based on some physical identifiers. Those physical
identifiers include
IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
source
and the rules for generating MN-ID based using those sources, the sender
and
receiver will have clear guidance on how to use the spec. Some pointers,
explanation and examples for each of those identifiers will greatly help
avoid
inter-op issues.


Regards
Sri







On 9/10/14 3:21 PM, "Charlie Perkins" <charles.perkins@earthlink.net>
wrote:


Hello folks,

I think it's best to consider the MNID as simply living in a space of
identifiers, and not worry too much about whether it's a logical
identifier or a physical identifier.  If the former, then somewhere
(perhaps below the network layer) the logical identifier has been bound
to something in the physical interface, but that's not our problem.

The number space for types of MNIDs is likely to stay pretty empty, so
I'd say we could add as many types as would be convenient for the
software designers.  So, we could conceivably have several MNIDs
defined that all "looked like" NAIs (which, themselves, "look like"
FQDNs).

Regards,
Charlie P.



On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:

Yes. Currently, the MNID is if the nai format and is overloaded. The
MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
IMSI. Ex:
"<IMSI>@epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org©÷

We also have MAC48@REALM;

We also have approaches to transform MAC to Pseudo IMSI, and then
carry IMSI-NAI as the MN-ID.


So, we need unique sub-types for each of the types/sources.

MN-Id based on IMSI, MSISDN, IMEI, MAC ..

Also, do we need to distinguish between IMSI and IMSI-NAI ?

Sri



On 9/10/14 6:29 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:


It seems the MNID is somehow overloaded to carry both, node-specific
IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
There may be value in adding the IMEI to the list of possible types
of  node-specific IDs.

marco


-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Dienstag, 9. September 2014 23:30
To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Two more comments.



4.) I'd also use sub-type value of (2) for IMSI. Just to align with
the  sub-types  defined for MN Id defined for ICMP. I suspect there
are some  implementations  already using sub-type (2). Please see
the other thread.


5.) For each of the sub-types, we need text including examples and
some
explanation on how they are used.


Sri



On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
wrote:


Hi Charlie,

This is good. Thanks.


1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
802.2
address, why do we need to two sub-types ? Why not have just one
sub-type for mac based identifiers ?

2.) Sub type value (1) is currently used. Its currently overloaded
for
IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
definition of new sub-types, we need some text explaining the
motivation

3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
is
this ? Are these CGA-based IPv6 addresses ?




                     New Mobile Node Identifier Types

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |
               |                 |                        |
               | IMSI            | 3                      |
               |                 |                        |
               | P-TMSI          | 4                      |
               |                 |                        |
               | EUI-48 address  | 5                      |
               |                 |                        |
               | EUI-64 address  | 6                      |
               |                 |                        |
               | GUTI            | 7                      |
               +-----------------+------------------------+







Regards
Sri
PS: Good to see Vijay back


On 9/9/14 1:28 PM, "Charlie Perkins"
<charles.perkins@earthlink.net>
wrote:


Hello folks,

Here's the last Internet Draft that we did, long ago expired:

http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt

I'll resubmit it with a few updates as a personal draft to dmm.

Regards,
Charlie P.

_______________________________________________
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


    

    

  


--------------060303040506010605060407--


From nobody Thu Sep 11 14:51:23 2014
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 CCA231A028E for ; Thu, 11 Sep 2014 14:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 MuduqR44ZnlI for ; Thu, 11 Sep 2014 14:51:18 -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 9B6D71A01DD for ; Thu, 11 Sep 2014 14:51:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11740; q=dns/txt; s=iport; t=1410472280; x=1411681880; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8LhDX4vgTIFvKAiimXEsq51QPI1O5muK6BPLVyal5X4=; b=gz61xe7a5AcBlNHhnAWP1D2cXbx+h7ojmfzy62dPbYaRnZYMHI0Q7A5W Lvbc3zS0KWDyQ23dhTTic8Al9NKKWglgWLT1wbn2o/GYCm9M8o9tMpMbF 4aCjyEdIiN+9+Av0nlag/8vuX0LT2dK3Wgul35SliBjmHFTwKE836ieEH c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUFAF8YElStJV2b/2dsb2JhbABfgw1TVwTIQQqHTQGBERZ4hAMBAQEEAQEBCWILDAYBCBEEAQEBJygGCxQJCAIEAQ0FG4gTAxENtxcNhmYBEwSKAIMgggIrBwaERgWLAYZKhnCCNoIQjn6GPYFvFoFcbAGBR4EHAQEB
X-IronPort-AV: E=Sophos;i="5.04,507,1406592000"; d="scan'208";a="77168615"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 11 Sep 2014 21:51:19 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8BLpH6l019004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 21:51:17 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 16:51:17 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , Jouni Korhonen , "sarikaya@ieee.org" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHPzgqDJktCHbMEuE+FxRkVXPWSJw==
Date: Thu, 11 Sep 2014 21:51:16 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D1672B@XCH-BLV-504.nw.nos.boeing.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.21.64.105]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <7B76760FA4DBD248BA0740361EFFE9DA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/qjABhUA0uiJ6SecwlXwDqMFFKig
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 11 Sep 2014 21:51:21 -0000

Hi Fred,

Thanks for your responses. I'm beginning to get the picture on how Aero
works. Few more questions and then we should be able have meaningful
discussion. It surely saves me lot of time and I appreciate it.


9.) Are you aware of implementation of a Aero client on iPhone ? Can Aero
client be implemented in today's Apple iOS device, using standard API
interface ? Will the Apple iOS allow an application to setup a tunnel and
setup policy routes to steer a IP flow through that tunnel ?


10.) In today 3G/4G architectures, an application function can notify a
policy function to allocate QoS resources for a flow. Ex: An IMS function
requests a policy function to setup dedicated QoS resources for a RTP flow
and with guaranteed-bit-rate of 32kbps. This policy is enforced on the air
interface and on the path from the client to the gateway. We have RFC7222
providing QoS negotiation semantics on the network path and  then we have
John's draft, draft-ietf-netext-pmip-qos which extends the same to the
802.11 air interface. How do you see this aspect of dynamic QoS work in
Aero-based system ?


11.) To make sure I get the flow right.

- A client attaches to the Aero network
- Chooses a Aero server from a list of servers; DNS lookup, static list
- Sets up a UDP tunnel to a Aero servers; (What triggers the server to
setup the tunnel ? Is the DHCP message that is the trigger here ?)
- The client does DHCPv6 signaling through the tunnel. The server
allocates a special prefix. This prefix is on the Aero virtual link.
Similar to Mobile IP home link ?
- This special prefix is topologically anchored on the server
- Aero server sets up a tunnel route for the prefix towards the client
- All traffic from the client using this prefix will be tunneled through
the server; At least the first packet has to hit the server
- When RO is triggered, there will ICMP redirect messages send in the UDP
header with Aero port;
- The peers communicate directly. I assume there will be a UDP tunnel
between the peers ? If there is no need for tunnel, is ingress filtering
of the transit routers  not an issue ?

- Client moves and attaches to a different IP network; Obtains a DHCP
address
- Client sets up a tunnel to the previously attached Aero server and
continue to use the same prefix ?


The focus is all about rote optimization and by means of triggering


Is the following mapping correct ?

Aero server is almost like a home agent ?
Aero virtual link is Mobile IP home link ?
Aero prefixes given to the client are hosted on the server as in case of
Home Agent ?
Aero tunnel is similar to Mobile IP GRE or UDP tunnel ?
Aero ICMP Redirects are equivalent to the MIP RO procedure ?
Signaling is DHCPv6




Regards
Sri










On 9/11/14 11:00 AM, "Templin, Fred L"  wrote:

>Hi Sri,
>
>See below for some follow-up:
>
>> -----Original Message-----
>> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>> Sent: Thursday, September 11, 2014 12:28 AM
>> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
>> Cc: Dapeng Liu; dmm@ietf.org
>> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>>=20
>> Hi Fred,
>>=20
>> The below comment from you made me thinking. I must admit I'm not much
>> familiar with Aero, have not seen its references in CDMA, WiMAX,
>> CableLabs, WLAN or LTE architectures.  But, if it has all the mobility
>> features and you believe this can conclude the WG, I thought I will
>> explore this a bit. I started reviewing the charts that you sent and
>> started browsing some of the specs. Few high-level questions, if you can
>> answer or point me to some documents, it will be great.
>>=20
>>=20
>> 1.) What is the interface between the Aero Server and the client ? Is it
>> just DHCPv6 ? There is no other signaling interface ?
>
>DHCPv6 is used for PD as well as mobility signaling. IPv6 ND messaging
>is used for NUD, route optimization, and the functional equivalent of
>a "binding update" via the use of unsolicited Neighbor Advertisements.
>=20
>> 2.) What is the service authorization model for a Aero client ? How is
>>the
>> client identified by the server ? What is the security model ?
>
>The Client is identified by the server via the DHCPv6 DUID. The DUID
>is most likely based on some serial number or ID that is assigned to
>the Client by the AERO service administrative staff.
>
>The security model is based on a multi-tiered layered security approach.
>First, the Client must authenticate itself to the network using whatever
>access layer securing mechanisms that are available, e.g., IEEE802.1x.
>For Clients that are coming into the network from the Internet, the
>Client establishes a VPN link to a security gateway at the network
>border.
>
>Second, the Client must prove to the Server that it is authorized to
>perform DHCPv6 signaling using DHCPv6 Auth or some other DHCPv6
>securing mechanism. This is only to protect against an "insider
>attack" in which a different Client pretends to be the authorized
>Client in order to hijack the authorized Client's prefix, siphon
>traffic, etc. Hence, a "better than nothing" authentication such
>as DHCPv6 Auth is really all that is needed.
>
>Third, the network must ensure that link-layer addresses cannot
>be spoofed. Here, the "link-layer address" is the IP source
>address of the encapsulating tunnel header. This is typically
>done through proper application of BCP ingress filtering
>practices.
>
>Finally, the AERO Server/Relay infrastructure provides a trust
>anchor to facilitate Client-to-Client route optimizations. In
>particular, Clients trust their Servers but cannot trust each
>other initially. If a Client receives a route optimization
>signal from its trusted Server, however, it can safely engage
>in the route optimization since a chain-of-trust was followed.
>
>> 3.) Can the Aero solution support IP nodes that do not have Aero client
>> stack ?
>
>Proxy AERO could be applied in the same manner as for PMIP,
>but the document does not fully investigate that option at
>this time.
>
>> 4.) If a mobile or a cable SP deploys Aero, where is their point of
>> control ? Where can they do Accounting, Lawful interception ?
>
>Lawful intercept, accounting, etc. can be done at the AERO Servers.
>In case these functions are mandatory, direct Client-to-Client route
>optimizations would not be permitted in those environments. However,
>Client-to-Server-to-Client route optimizations would still be used
>to reduce path stretch and reduce load on critical infrastructure.
>
>> 5.) I assume Aero client can be IPv4 or an IPv6 device ? For an
>>IPv4-only
>> legacy device, is the interface DHCPv4 ?
>
>The AERO data plane can be either IPv4 or IPv6, and can be tunneled
>over either IPv4 or IPv6 access networks. The AERO control plane is
>always DHCPv6 and IPv6 ND. In particular, DHCPv6 PD can be used to
>delegate IPv4 prefixes in the same way that it can delegate IPv6
>prefixes. So no; DHCPv4 is not used in the control plane.
>
>> 6.) Can an operator enable location-based services for a Aero client ?
>
>AERO Clients discover and associate with AERO Servers that are
>"nearby". They discover nearby Servers by resolving the DNS
>FQDN "linkupnetworks.[domain]" where "[domain]" is a link-
>specific DNS suffix. This would provide topological proximity
>and I guess most often also geographic proximity. Is that what
>you were asking?
>
>> 7.) How can an operator enable IP Flow Mobility type features in an Aero
>> system ?
>
>I am not familiar with IP Flow Mobility, but does it mean spreading
>traffic load across multiple access links? Like maybe sending streaming
>video across WLAN while posting short text messages via 4G? If so,
>AERO supports the use of multiple simultaneous access links - like,
>keeping both the WLAN and 4G interfaces active at the same time. Or
>maybe I am mis-understanding IP Flow Mobility?
>=20
>> 8.) Taking a mobile router scenario, how does Aero client support
>> multi-tenancy ? Is there a single tunnel between the client and the
>>server
>
>Again, I am not familiar with the term multi-tenancy, or at least not
>with its use within this context. In terms of tunnels, however, the
>tunnel is non-broadcast, multiple access (NBMA) and not point-to-point.
>So each AERO node sees other AERO nodes as neighbors on the NBMA link.
>The AERO interface therefore maintains a neighbor cache the same as
>any IP interface, and uses the neighbor cache entries to track the
>current L3/L2 address mappings. These mappings may change over time,
>e.g., as the result of a mobility event.
>
>Thanks - Fred
>fred.l.templin@boeing.com
>
>> ?
>>=20
>>=20
>> Regards
>> Sri
>>=20
>>=20
>>=20
>>=20
>> On 9/10/14 11:43 AM, "Templin, Fred L" 
>>wrote:
>>=20
>> >Hi Jouni,
>> >
>> >I'd like to propose a slightly different charter:
>> >
>> >  "AERO already solves distributed mobility management and provides a
>> >   a comprehensive mobility solution for any mobile device. AERO should
>> >   therefore be approved as the mobility management solution for DMM.
>> >   Publication of AERO will therefore conclude the working group's
>> >   activity."
>> >
>> >Can we have this on the agenda?
>> >
>> >Thanks - Fred
>> >fred.l.templin@boeing.com
>> >
>> >> -----Original Message-----
>> >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen
>> >> Sent: Wednesday, September 10, 2014 11:37 AM
>> >> To: sarikaya@ieee.org
>> >> Cc: Dapeng Liu; dmm@ietf.org
>> >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>> >>
>> >>
>> >> What do you mean by no agenda? To me it clearly says we use the call
>>#2
>> >> for setting up the work split.
>> >>
>> >> - Jouni
>> >>
>> >> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti:
>> >> > Jouni, why don't we cancel this one (#2) and do the next one (#3)
>>with
>> >> > an agenda?
>> >> > I hope Alper can attend :-)
>> >> >
>> >> > Regards,
>> >> >
>> >> > Behcet
>> >> >
>> >> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen
>> >> wrote:
>> >> >>
>> >> >> It seems I sent this to a wrong receiver.. that explains why it
>>did
>> >>not
>> >> >> appear on the list.
>> >> >>
>> >> >> - Jouni
>> >> >>
>> >> >> -------- Alkuper=E4inen viesti / Orig.Msg. --------
>> >> >> Aihe: DMM Interim call #2 - agenda forming
>> >> >> P=E4iv=E4ys: Mon, 08 Sep 2014 23:43:24 +0300
>> >> >> L=E4hett=E4j=E4: Jouni Korhonen 
>> >> >> Vastaanottaja: dmm-ads@tools.ietf.org
>> >> >> CC: jouni.nospam@gmail.com, Dapeng Liu 
>> >> >>
>> >> >> Folks,
>> >> >>
>> >> >> The next interim is close. Assuming there are no overwhelming
>>amount
>> >>of
>> >> >> comments to the re-charter text, we are ready to start setting up
>>the
>> >> >> work split on the solution space! Remember the discussion and the
>> >> >> minutes from the IETF#90 Friday session. No other agenda items are
>> >> >> planned for the next interim.
>> >> >>
>> >> >> - 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
>> >_______________________________________________
>> >dmm mailing list
>> >dmm@ietf.org
>> >https://www.ietf.org/mailman/listinfo/dmm
>


From nobody Thu Sep 11 14:57:28 2014
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 79F0A1A02E1 for ; Thu, 11 Sep 2014 14:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level: 
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 0rw9n0MPDevo for ; Thu, 11 Sep 2014 14:57:23 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9521A026F for ; Thu, 11 Sep 2014 14:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30340; q=dns/txt; s=iport; t=1410472634; x=1411682234; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=aVSe9yNuFlkSf0qA/FH+g0YQ8BtI+rJjsJBdVOzbR9E=; b=Mat+K/K9VR5Nj0hmhldNdCOkw+eOetJf0YjyXbpUqn1DH+Pr4E9V7NKK GSqfzEYzoxDg52qkj84W+QUJI5eCrssS2YdT9fqs5b0rbL3D7FBgRrYub m0fFaCopnuYB4rYoa4rZ/z8ARP52nZmpJF/fLMx7prThS2ZhNGwREGDeM c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMFAKAZElStJV2Y/2dsb2JhbABWCYJHRlNXBIJ4xUkBCYdNARl4FniEAwEBAQQBAQFrFwYBCA4DAwEBAQ4aBQQlCxQJCAIEARIJiCUDEQ2LYZw9Bo5oG4ZYAReNEBCBUjAJBwoYAgSCbYFZBYYeiReCFos2lTuDYWwBgUeBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,508,1406592000";  d="scan'208,217";a="354523311"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 11 Sep 2014 21:57:13 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8BLvCDx015332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 21:57:12 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 16:57:12 -0500
From: "Sri Gundavelli (sgundave)" 
To: Charlie Perkins , Marco Liebsch , "dmm@ietf.org" , Vijay Devarapalli 
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHPzgtXaaKIRu1CzUiapIsrZvteqQ==
Date: Thu, 11 Sep 2014 21:57:11 +0000
Message-ID: 
In-Reply-To: <54121835.702@earthlink.net>
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.21.64.105]
Content-Type: multipart/alternative; boundary="_000_D03767BD163EA7sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/OlByXlU4Q1ipEVJ7sgLaoJy_hh4
Subject: Re: [DMM] MNID Types
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, 11 Sep 2014 21:57:26 -0000

--_000_D03767BD163EA7sgundaveciscocom_
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64

SGkgQ2hhcmxpZSwNCg0KRmV3IG1vcmUgcmV2aWV3cy9kaXNjdXNzaW9ucyBhbmQgY2FwdHVyaW5n
IHRoZSBjb25zZW5zdXMgaW4gdGhlIGJhc2UgdmVyc2lvbiB3aWxsIGhlbHAuIEJ1dCwgSSdtIG9r
IGVpdGhlciB3YXkgoaYNCg0KDQpSZWdhcmRzDQpTcmkNCg0KRnJvbTogQ2hhcmxpZSBQZXJraW5z
IDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDxtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVh
cnRobGluay5uZXQ+Pg0KRGF0ZTogVGh1cnNkYXksIFNlcHRlbWJlciAxMSwgMjAxNCAyOjQ2IFBN
DQpUbzogU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVA
Y2lzY28uY29tPj4sIE1hcmNvIExpZWJzY2ggPE1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PG1haWx0
bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldT4+LCAiZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0
Zi5vcmc+IiA8ZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+PiwgVmlqYXkgRGV2YXJh
cGFsbGkgPGR2aWpheUByb2NrZXRtYWlsLmNvbTxtYWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29t
Pj4NClN1YmplY3Q6IFJlOiBbRE1NXSBNTklEIFR5cGVzDQoNCg0KSGVsbG8gZm9sa3MsDQoNCkkg
cHJvcG9zZSB0byBzdWJtaXQgdGhlIC4uLi4tMDAudHh0IGRvY3VtZW50IGFzIGl0IGlzIHRvIHRo
ZSBJbnRlcm5ldA0KRHJhZnRzIGRpcmVjdG9yeSwgYW5kIHRoZW4gdG8gZ28gYWJvdXQgbWFraW5n
IHVwZGF0ZXMgYWNjb3JkaW5nIHRvDQp0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3QuICBEbyB5
b3UgdGhpbmsgdGhpcyBpcyByZWFzb25hYmxlPw0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoN
Ck9uIDkvMTEvMjAxNCA3OjIxIEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0K
DQo8Q2hhbmdpbmcgdGhlIHN1YmplY3QgbGluZSB0byByZWZsZWN0IHRoZSBNTklkIGRpc2N1c3Np
b24+DQoNCg0KTWFyY28sDQoNCg0KVGhpbmtpbmcgZnVydGhlciBvbiB0aGUgY29tcGxlbWVudGFy
eSBpZGVudGlmaWVyIG9wdGlvbi4NCg0KLSBUaGVyZSBpcyBhbHJlYWR5IHRoZSBsaW5rLWxheWVy
IGlkZW50aWZpZXIgb3B0aW9uIHRoYXQgY2FuIGJlIHVzZWQgZm9yDQpjYXJyeWluZyB0aGUgTWFj
IGFkZHJlc3MNCi0gSU1FSSBhbmQgTVNJU0ROIGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gMjkuMjc1
IGFzIGEgM0dQUCBWU0Uncw0KDQpJbiBzb21lIHNlbnNlLCB0aGUgY29tcGxlbWVudGFyeSBpZGVu
dGlmaWVycyBhcmUgYWxyZWFkeSBwcmVzZW50Lg0KDQpTcmkNCg0KDQoNCg0KDQpPbiA5LzExLzE0
IDY6NTggQU0sICJTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIiA8c2d1bmRhdmVAY2lzY28uY29t
PjxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPiB3cm90ZToNCg0KDQpJIGRvIG5vdCBzZWUgYSBy
ZWFzb24gd2h5IG11bHRpcGxlIE1OLUlkIGluc3RhbmNlcyBuZWVkIHRvIGJlIHByZXNlbnQgaW4g
YQ0Kc2luZ2xlIG1lc3NhZ2UgPyBJbiBteSBleHBlcmllbmNlLCB0aGlzIGlzIHN0cmljdGx5IGEg
ZGVwbG95bWVudA0KY29uc2lkZXJhdGlvbiwgd2hlbiB0byB1c2Ugd2hhdCB0eXBlIG9mIGlkZW50
aWZpZXJzLg0KDQpBc3N1bWluZyB0aGUgYmFja2VuZCBzeXN0ZW0gY2FuIHRpZSBhbGwgdGhlIE1O
LUlkJ3MgdG8gYSBzaW5nbGUNCnN1YnNjcmlwdGlvbiwgYW55IHByZXNlbnRlZCBpZGVudGlmaWVy
IGNhbiBiZSBzdWZmaWNpZW50IGZvciB0aGUgZ2F0ZXdheQ0KdG8gZG8gdGhlIEJDRSBsb29rdXAu
DQoNCklmIG11bHRpcGxlIGluc3RhbmNlcyBjYW4gYmUgcHJlc2VudCwgdGhlbiB3ZSBuZWVkIHRv
IGRlYWwgd2l0aCBtb3JlIGVycm9yDQpjYXNlcy4gSXMgdGhhdCByZWFsbHkgbmVlZGVkID8NCg0K
DQoNCg0KSSBhbSB3b25kZXJpbmcgaWYgaXQgd291bGQgbm90IGJlIG1vcmUgYXBwcm9wcmlhdGUg
dG8gZ28gZm9yIGEgZGlmZmVyZW50DQpjb250YWluZXIgb3B0aW9uIHRvIGNhcnJ5IHN1Y2ggaW5m
b3JtYXRpb24uIFNvbWV0aGluZyBsaWtlIGENCmNvbXBsZW1lbnRhcnkgaWRlbnRpZmllciBvcHRp
b24uDQoNCg0KU291bmRzIGludGVyZXN0aW5nLiBBcmUgeW91IHN1Z2dlc3Rpbmcgd2UgbGVhdmUg
dGhlIGN1cnJlbnQgTU4tSUQgYXMgaXQNCmlzLCBidXQgdXNlIGEgbmV3IGNvbXBsZW1lbnRhcnkg
b3B0aW9uID8gQnV0LCBpZiB0aGUgcmVxdWlyZW1lbnQgaXMgZm9yIGENCk1hYyBiYXNlZCBpZGVu
dGlmaWVycywgd2hhdCB3aWxsIGJlIHRoZXJlIGluIHRoZSBjdXJyZW50IE1OLUlkIG9wdGlvbiA/
IFdlDQpzdGlsbCBuZWVkIHRvIGhhdmUgaWRlbnRpZmllciB0aGVyZSA/DQoNCg0KDQoNClNyaQ0K
DQoNCg0KDQoNCk9uIDkvMTEvMTQgMjowMyBBTSwgIk1hcmNvIExpZWJzY2giIDxNYXJjby5MaWVi
c2NoQG5lY2xhYi5ldT48bWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PiB3cm90ZToNCg0K
DQoNCk5vIGlzc3VlIHdpdGggbG9naWNhbCB2cy4gcGh5c2ljYWwgSUQuIEJ1dCBJIGFtIHdvbmRl
cmluZyBhYm91dCB0d28NCnRoaW5nczoNCg0KT3BlcmF0aW9uIGlzIGNsZWFyIHRvIG1lIGluIGNh
c2UgYSBzaW5nbGUgTU5JRCBpcyBwcmVzZW50IGluIGEgbWVzc2FnZQ0KYW5kIEkgc2VlIHRoZSB2
YWx1ZSBpbiBiZWluZw0KZmxleGlibGUgdG8gY2hvb3NlIGZyb20gZGlmZmVyZW50IHN1Yi10eXBl
cy4gSWYgbXVsdGlwbGUgTU5JRHMgd2l0aA0KZGlmZmVyZW50IHN1Yi10eXBlcyBhcmUgcHJlc2Vu
dCBpbg0KYSBzaW5nbGUgbWVzc2FnZSwgd2hpY2ggb25lIHNob3VsZCBlLmcuIHRoZSBMTUEgdGFr
ZSBmb3IgdGhlIEJDIGxvb2t1cC4uDQpObyBiaWcgcHJvYmxlbSB0byBzb2x2ZSwgYnV0DQp0byBi
ZSBjb25zaWRlcmVkIGluIGltcGxlbWVudGF0aW9ucy4NCg0KSWYgdGhlIHJlYXNvbiBmb3IgbXVs
dGlwbGUgcHJlc2VudCBNTklEcyB3aXRoIGRpZmZlcmVudCBzdWItdHlwZXMgaXMgdG8NCmRvIG90
aGVyIHRoaW5ncyB0aGFuIGlkZW50aWZ5aW5nDQp0aGUgbm9kZSBvciB1c2luZyB0aGUgSUQgYXMg
a2V5IGZvciBhIGxvb2t1cCwgSSBhbSB3b25kZXJpbmcgaWYgaXQgd291bGQNCm5vdCBiZSBtb3Jl
IGFwcHJvcHJpYXRlDQp0byBnbyBmb3IgYSBkaWZmZXJlbnQgY29udGFpbmVyIG9wdGlvbiB0byBj
YXJyeSBzdWNoIGluZm9ybWF0aW9uLg0KU29tZXRoaW5nIGxpa2UgYSBjb21wbGVtZW50YXJ5DQpp
ZGVudGlmaWVyIG9wdGlvbi4NCg0KbWFyY28NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIFttYWlsdG86c2d1bmRhdmVAY2lz
Y28uY29tXQ0KU2VudDogRG9ubmVyc3RhZywgMTEuIFNlcHRlbWJlciAyMDE0IDAwOjQyDQpUbzog
Q2hhcmxpZSBQZXJraW5zOyBNYXJjbyBMaWVic2NoOyBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBp
ZXRmLm9yZz4NCkNjOiBWaWpheSBEZXZhcmFwYWxsaQ0KU3ViamVjdDogUmU6IFtETU1dIHJlZ2Fy
ZGluZyB0aGUgcmUtY2hhcnRlcmluZy4uDQoNCkhlbGxvIENoYXJsaWUsDQoNCkFncmVlIHdpdGgg
dGhhdC4gTU4tSWQgYXMgaXRzIGRlZmluZWQgdG9kYXkgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIu
IEl0DQpkb2VzIG5vdA0KcmVxdWlyZSB0aGUgaWRlbnRpZmllciB0byBiZSBib3VuZCB0byBhIHBo
eXNpY2FsIGRldmljZSBvciBhIGludGVyZmFjZQ0KaWRlbnRpdHkuDQpCdXQsIHdlIGhhdmUgY2xl
YXJseSBzZWVuIHJlcXVpcmVtZW50cyB3aGVyZSB0aGUgbmVlZCBpcyBmb3IgZ2VuZXJhdGluZw0K
aWRlbnRpZmllcnMgYmFzZWQgb24gc29tZSBwaHlzaWNhbCBpZGVudGlmaWVycy4gVGhvc2UgcGh5
c2ljYWwNCmlkZW50aWZpZXJzIGluY2x1ZGUNCklNU0ksIE1TSVNETiwgSU1FSSwgTUFDIC4uZXRj
LiBJZiB3ZSBjYW4gZGVmaW5lIGEgdHlwZSBmb3IgZWFjaCBvZiB0aGUNCnNvdXJjZQ0KYW5kIHRo
ZSBydWxlcyBmb3IgZ2VuZXJhdGluZyBNTi1JRCBiYXNlZCB1c2luZyB0aG9zZSBzb3VyY2VzLCB0
aGUgc2VuZGVyDQphbmQNCnJlY2VpdmVyIHdpbGwgaGF2ZSBjbGVhciBndWlkYW5jZSBvbiBob3cg
dG8gdXNlIHRoZSBzcGVjLiBTb21lIHBvaW50ZXJzLA0KZXhwbGFuYXRpb24gYW5kIGV4YW1wbGVz
IGZvciBlYWNoIG9mIHRob3NlIGlkZW50aWZpZXJzIHdpbGwgZ3JlYXRseSBoZWxwDQphdm9pZA0K
aW50ZXItb3AgaXNzdWVzLg0KDQoNClJlZ2FyZHMNClNyaQ0KDQoNCg0KDQoNCg0KDQpPbiA5LzEw
LzE0IDM6MjEgUE0sICJDaGFybGllIFBlcmtpbnMiIDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5r
Lm5ldD48bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pg0Kd3JvdGU6DQoNCg0K
DQpIZWxsbyBmb2xrcywNCg0KSSB0aGluayBpdCdzIGJlc3QgdG8gY29uc2lkZXIgdGhlIE1OSUQg
YXMgc2ltcGx5IGxpdmluZyBpbiBhIHNwYWNlIG9mDQppZGVudGlmaWVycywgYW5kIG5vdCB3b3Jy
eSB0b28gbXVjaCBhYm91dCB3aGV0aGVyIGl0J3MgYSBsb2dpY2FsDQppZGVudGlmaWVyIG9yIGEg
cGh5c2ljYWwgaWRlbnRpZmllci4gIElmIHRoZSBmb3JtZXIsIHRoZW4gc29tZXdoZXJlDQoocGVy
aGFwcyBiZWxvdyB0aGUgbmV0d29yayBsYXllcikgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciBoYXMg
YmVlbiBib3VuZA0KdG8gc29tZXRoaW5nIGluIHRoZSBwaHlzaWNhbCBpbnRlcmZhY2UsIGJ1dCB0
aGF0J3Mgbm90IG91ciBwcm9ibGVtLg0KDQpUaGUgbnVtYmVyIHNwYWNlIGZvciB0eXBlcyBvZiBN
TklEcyBpcyBsaWtlbHkgdG8gc3RheSBwcmV0dHkgZW1wdHksIHNvDQpJJ2Qgc2F5IHdlIGNvdWxk
IGFkZCBhcyBtYW55IHR5cGVzIGFzIHdvdWxkIGJlIGNvbnZlbmllbnQgZm9yIHRoZQ0Kc29mdHdh
cmUgZGVzaWduZXJzLiAgU28sIHdlIGNvdWxkIGNvbmNlaXZhYmx5IGhhdmUgc2V2ZXJhbCBNTklE
cw0KZGVmaW5lZCB0aGF0IGFsbCAibG9va2VkIGxpa2UiIE5BSXMgKHdoaWNoLCB0aGVtc2VsdmVz
LCAibG9vayBsaWtlIg0KRlFETnMpLg0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCg0KT24g
OS8xMC8yMDE0IDg6MTEgQU0sIFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6DQoNCg0K
WWVzLiBDdXJyZW50bHksIHRoZSBNTklEIGlzIGlmIHRoZSBuYWkgZm9ybWF0IGFuZCBpcyBvdmVy
bG9hZGVkLiBUaGUNCk1OSUQgIGluIDNHUFAgc3BlY3MgaXMgdGhlIElNU0ktTkFJIChJTVNJQFJF
QUxNKSwgaXRzIGJhc2VkIG9uIHRoZQ0KSU1TSS4gRXg6DQoiPElNU0k+QGVwYy5tbmM8TU5DPi5t
Y2M8TUNDPi4zZ3BwbmV0d29yay5vcmep9w0KDQpXZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07DQoN
CldlIGFsc28gaGF2ZSBhcHByb2FjaGVzIHRvIHRyYW5zZm9ybSBNQUMgdG8gUHNldWRvIElNU0ks
IGFuZCB0aGVuDQpjYXJyeSBJTVNJLU5BSSBhcyB0aGUgTU4tSUQuDQoNCg0KU28sIHdlIG5lZWQg
dW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBvZiB0aGUgdHlwZXMvc291cmNlcy4NCg0KTU4tSWQg
YmFzZWQgb24gSU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi4NCg0KQWxzbywgZG8gd2UgbmVlZCB0
byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElNU0kgYW5kIElNU0ktTkFJID8NCg0KU3JpDQoNCg0KDQpP
biA5LzEwLzE0IDY6MjkgQU0sICJNYXJjbyBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIu
ZXU+PG1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldT4gd3JvdGU6DQoNCg0KDQpJdCBzZWVt
cyB0aGUgTU5JRCBpcyBzb21laG93IG92ZXJsb2FkZWQgdG8gY2FycnkgYm90aCwgbm9kZS1zcGVj
aWZpYw0KSURzLCAgZS5nLiBNQUMsIGFzIHdlbGwgYXMgc3Vic2NyaWJlciBJRHMsIHdoaWNoIGlz
IHRoZSBJTVNJLg0KVGhlcmUgbWF5IGJlIHZhbHVlIGluIGFkZGluZyB0aGUgSU1FSSB0byB0aGUg
bGlzdCBvZiBwb3NzaWJsZSB0eXBlcw0Kb2YgIG5vZGUtc3BlY2lmaWMgSURzLg0KDQptYXJjbw0K
DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRtbSBbbWFpbHRvOmRtbS1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3JpIEd1bmRhdmVsbGkNCihzZ3VuZGF2ZSkN
ClNlbnQ6IERpZW5zdGFnLCA5LiBTZXB0ZW1iZXIgMjAxNCAyMzozMA0KVG86IFNyaSBHdW5kYXZl
bGxpIChzZ3VuZGF2ZSk7IENoYXJsaWUgUGVya2luczsgZG1tQGlldGYub3JnPG1haWx0bzpkbW1A
aWV0Zi5vcmc+DQpDYzogVmlqYXkgRGV2YXJhcGFsbGkNClN1YmplY3Q6IFJlOiBbRE1NXSByZWdh
cmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLg0KDQpUd28gbW9yZSBjb21tZW50cy4NCg0KDQoNCjQu
KSBJJ2QgYWxzbyB1c2Ugc3ViLXR5cGUgdmFsdWUgb2YgKDIpIGZvciBJTVNJLiBKdXN0IHRvIGFs
aWduIHdpdGgNCnRoZSAgc3ViLXR5cGVzICBkZWZpbmVkIGZvciBNTiBJZCBkZWZpbmVkIGZvciBJ
Q01QLiBJIHN1c3BlY3QgdGhlcmUNCmFyZSBzb21lICBpbXBsZW1lbnRhdGlvbnMgIGFscmVhZHkg
dXNpbmcgc3ViLXR5cGUgKDIpLiBQbGVhc2Ugc2VlDQp0aGUgb3RoZXIgdGhyZWFkLg0KDQoNCjUu
KSBGb3IgZWFjaCBvZiB0aGUgc3ViLXR5cGVzLCB3ZSBuZWVkIHRleHQgaW5jbHVkaW5nIGV4YW1w
bGVzIGFuZA0Kc29tZQ0KZXhwbGFuYXRpb24gb24gaG93IHRoZXkgYXJlIHVzZWQuDQoNCg0KU3Jp
DQoNCg0KDQpPbiA5LzkvMTQgMjoyMCBQTSwgIlNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxz
Z3VuZGF2ZUBjaXNjby5jb20+PG1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20+DQp3cm90ZToNCg0K
DQoNCkhpIENoYXJsaWUsDQoNClRoaXMgaXMgZ29vZC4gVGhhbmtzLg0KDQoNCjEuKSBJZiBFVUkt
NDggYW5kIEVVSS02NCBhZGRyZXNzZXMgYXJlIGRlcml2ZWQgb2YgYSA0OC1iaXQgSUVFRQ0KODAy
LjINCmFkZHJlc3MsIHdoeSBkbyB3ZSBuZWVkIHRvIHR3byBzdWItdHlwZXMgPyBXaHkgbm90IGhh
dmUganVzdCBvbmUNCnN1Yi10eXBlIGZvciBtYWMgYmFzZWQgaWRlbnRpZmllcnMgPw0KDQoyLikg
U3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJlbnRseSB1c2VkLiBJdHMgY3VycmVudGx5IG92ZXJs
b2FkZWQNCmZvcg0KSU1TSS1OQUkgKDNHUFAgc3BlY3MpIGFuZCBnZW5lcmljIE5BSSBiYXNlZCBp
ZGVudGlmaWVycy4gR2l2ZW4gdGhlDQpkZWZpbml0aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5l
ZWQgc29tZSB0ZXh0IGV4cGxhaW5pbmcgdGhlDQptb3RpdmF0aW9uDQoNCjMuKSBQcm9wb3NlZCBT
dWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElQdjYgYWRkcmVzcy4gV2hhdCBleGFjdGx5DQppcw0K
dGhpcyA/IEFyZSB0aGVzZSBDR0EtYmFzZWQgSVB2NiBhZGRyZXNzZXMgPw0KDQoNCg0KDQogICAg
ICAgICAgICAgICAgICAgICBOZXcgTW9iaWxlIE5vZGUgSWRlbnRpZmllciBUeXBlcw0KDQogICAg
ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0K
ICAgICAgICAgICAgICAgfCBJZGVudGlmaWVyIFR5cGUgfCBJZGVudGlmaWVyIFR5cGUgTnVtYmVy
IHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0rDQogICAgICAgICAgICAgICB8IElQdjYgQWRkcmVzcyAgICB8IDIgICAgICAgICAgICAg
ICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg
ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgSU1TSSAgICAgICAgICAgIHwgMyAgICAg
ICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAg
ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBQLVRNU0kgICAgICAgICAg
fCA0ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8IEVVSS00OCBh
ZGRyZXNzICB8IDUgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwg
RVVJLTY0IGFkZHJlc3MgIHwgNiAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg
ICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg
ICAgICAgfCBHVVRJICAgICAgICAgICAgfCA3ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg
ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoN
Cg0KDQoNCg0KDQoNClJlZ2FyZHMNClNyaQ0KUFM6IEdvb2QgdG8gc2VlIFZpamF5IGJhY2sNCg0K
DQpPbiA5LzkvMTQgMToyOCBQTSwgIkNoYXJsaWUgUGVya2lucyINCjxjaGFybGVzLnBlcmtpbnNA
ZWFydGhsaW5rLm5ldD48bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pg0Kd3Jv
dGU6DQoNCg0KDQpIZWxsbyBmb2xrcywNCg0KSGVyZSdzIHRoZSBsYXN0IEludGVybmV0IERyYWZ0
IHRoYXQgd2UgZGlkLCBsb25nIGFnbyBleHBpcmVkOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2Fy
Y2hpdmUvaWQvZHJhZnQtcGVya2lucy1tZXh0LTQyODNtbmlkcy0wMS50eHQNCg0KSSdsbCByZXN1
Ym1pdCBpdCB3aXRoIGEgZmV3IHVwZGF0ZXMgYXMgYSBwZXJzb25hbCBkcmFmdCB0byBkbW0uDQoN
ClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86
ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFp
bGluZyBsaXN0DQpkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1h
aWx0bzpkbW1AaWV0Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k
bW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRt
bSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCg==

--_000_D03767BD163EA7sgundaveciscocom_
Content-Type: text/html; charset="euc-kr"
Content-ID: <799E57FC42B3CA458A205995DCFECDCD@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13
cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i
cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog
MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2PkhpIENoYXJs
aWUsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5GZXcgbW9yZSByZXZpZXdzL2Rpc2N1
c3Npb25zIGFuZCBjYXB0dXJpbmcgdGhlIGNvbnNlbnN1cyBpbiB0aGUgYmFzZSB2ZXJzaW9uIHdp
bGwgaGVscC4gQnV0LCBJJ20gb2sgZWl0aGVyIHdheSChpjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4NCjxkaXY+U3JpPC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk
aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWdu
OmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxF
RlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsg
UEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVS
LVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9u
dC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkNoYXJsaWUgUGVya2lucyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Ij5jaGFybGVzLnBlcmtpbnNAZWFy
dGhsaW5rLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRh
dGU6IDwvc3Bhbj5UaHVyc2RheSwgU2VwdGVtYmVyIDExLCAyMDE0IDI6NDYgUE08YnI+DQo8c3Bh
biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5TcmkgR3VuZGF2ZWxsaSAmbHQ7
PGEgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSI+c2d1bmRhdmVAY2lzY28uY29tPC9h
PiZndDssIE1hcmNvIExpZWJzY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpNYXJjby5MaWVic2NoQG5l
Y2xhYi5ldSI+TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i
bWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPiZndDssDQogVmlqYXkgRGV2YXJh
cGFsbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20iPmR2aWpheUBy
b2NrZXRtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi
PlN1YmplY3Q6IDwvc3Bhbj5SZTogW0RNTV0gTU5JRCBUeXBlczxicj4NCjwvZGl2Pg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAi
Pjxicj4NCjxmb250IGZhY2U9IkNhbGlicmkiPjxiaWc+SGVsbG8gZm9sa3MsPGJyPg0KPGJyPg0K
SSBwcm9wb3NlIHRvIHN1Ym1pdCB0aGUgLi4uLi0wMC50eHQgZG9jdW1lbnQgYXMgaXQgaXMgdG8g
dGhlIEludGVybmV0PGJyPg0KRHJhZnRzIGRpcmVjdG9yeSwgYW5kIHRoZW4gdG8gZ28gYWJvdXQg
bWFraW5nIHVwZGF0ZXMgYWNjb3JkaW5nIHRvPGJyPg0KdGhlIGRpc2N1c3Npb24gb24gdGhpcyBs
aXN0LiZuYnNwOyBEbyB5b3UgdGhpbmsgdGhpcyBpcyByZWFzb25hYmxlPzxicj4NCjxicj4NClJl
Z2FyZHMsPGJyPg0KQ2hhcmxpZSBQLjxicj4NCjxicj4NCjwvYmlnPjwvZm9udD48YnI+DQo8ZGl2
IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDkvMTEvMjAxNCA3OjIxIEFNLCBTcmkgR3VuZGF2
ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlk
OkQwMzZGQjVGLjE2M0M5RCUyNXNndW5kYXZlQGNpc2NvLmNvbSIgdHlwZT0iY2l0ZSI+DQo8cHJl
IHdyYXA9IiI+Jmx0O0NoYW5naW5nIHRoZSBzdWJqZWN0IGxpbmUgdG8gcmVmbGVjdCB0aGUgTU5J
ZCBkaXNjdXNzaW9uJmd0Ow0KDQoNCk1hcmNvLA0KDQoNClRoaW5raW5nIGZ1cnRoZXIgb24gdGhl
IGNvbXBsZW1lbnRhcnkgaWRlbnRpZmllciBvcHRpb24uDQoNCi0gVGhlcmUgaXMgYWxyZWFkeSB0
aGUgbGluay1sYXllciBpZGVudGlmaWVyIG9wdGlvbiB0aGF0IGNhbiBiZSB1c2VkIGZvcg0KY2Fy
cnlpbmcgdGhlIE1hYyBhZGRyZXNzDQotIElNRUkgYW5kIE1TSVNETiBhcmUgYWxyZWFkeSBkZWZp
bmVkIGluIDI5LjI3NSBhcyBhIDNHUFAgVlNFJ3MNCg0KSW4gc29tZSBzZW5zZSwgdGhlIGNvbXBs
ZW1lbnRhcnkgaWRlbnRpZmllcnMgYXJlIGFscmVhZHkgcHJlc2VudC4NCg0KU3JpDQoNCg0KDQoN
Cg0KT24gOS8xMS8xNCA2OjU4IEFNLCAmcXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1
b3Q7IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpzZ3VuZGF2
ZUBjaXNjby5jb20iPiZsdDtzZ3VuZGF2ZUBjaXNjby5jb20mZ3Q7PC9hPiB3cm90ZToNCjwvcHJl
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+SSBkbyBub3Qgc2VlIGEg
cmVhc29uIHdoeSBtdWx0aXBsZSBNTi1JZCBpbnN0YW5jZXMgbmVlZCB0byBiZSBwcmVzZW50IGlu
IGENCnNpbmdsZSBtZXNzYWdlID8gSW4gbXkgZXhwZXJpZW5jZSwgdGhpcyBpcyBzdHJpY3RseSBh
IGRlcGxveW1lbnQNCmNvbnNpZGVyYXRpb24sIHdoZW4gdG8gdXNlIHdoYXQgdHlwZSBvZiBpZGVu
dGlmaWVycy4NCg0KQXNzdW1pbmcgdGhlIGJhY2tlbmQgc3lzdGVtIGNhbiB0aWUgYWxsIHRoZSBN
Ti1JZCdzIHRvIGEgc2luZ2xlDQpzdWJzY3JpcHRpb24sIGFueSBwcmVzZW50ZWQgaWRlbnRpZmll
ciBjYW4gYmUgc3VmZmljaWVudCBmb3IgdGhlIGdhdGV3YXkNCnRvIGRvIHRoZSBCQ0UgbG9va3Vw
Lg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5jZXMgY2FuIGJlIHByZXNlbnQsIHRoZW4gd2UgbmVlZCB0
byBkZWFsIHdpdGggbW9yZSBlcnJvcg0KY2FzZXMuIElzIHRoYXQgcmVhbGx5IG5lZWRlZCA/DQoN
Cg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUgd3JhcD0iIj5JIGFtIHdv
bmRlcmluZyBpZiBpdCB3b3VsZCBub3QgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBnbyBmb3IgYSBk
aWZmZXJlbnQNCmNvbnRhaW5lciBvcHRpb24gdG8gY2Fycnkgc3VjaCBpbmZvcm1hdGlvbi4gU29t
ZXRoaW5nIGxpa2UgYQ0KY29tcGxlbWVudGFyeSBpZGVudGlmaWVyIG9wdGlvbi4NCjwvcHJlPg0K
PC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiPlNvdW5kcyBpbnRlcmVzdGluZy4gQXJlIHlvdSBz
dWdnZXN0aW5nIHdlIGxlYXZlIHRoZSBjdXJyZW50IE1OLUlEIGFzIGl0DQppcywgYnV0IHVzZSBh
IG5ldyBjb21wbGVtZW50YXJ5IG9wdGlvbiA/IEJ1dCwgaWYgdGhlIHJlcXVpcmVtZW50IGlzIGZv
ciBhDQpNYWMgYmFzZWQgaWRlbnRpZmllcnMsIHdoYXQgd2lsbCBiZSB0aGVyZSBpbiB0aGUgY3Vy
cmVudCBNTi1JZCBvcHRpb24gPyBXZQ0Kc3RpbGwgbmVlZCB0byBoYXZlIGlkZW50aWZpZXIgdGhl
cmUgPw0KDQoNCg0KDQpTcmkNCg0KDQoNCg0KDQpPbiA5LzExLzE0IDI6MDMgQU0sICZxdW90O01h
cmNvIExpZWJzY2gmcXVvdDsgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0i
bWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1Ij4mbHQ7TWFyY28uTGllYnNjaEBuZWNsYWIu
ZXUmZ3Q7PC9hPiB3cm90ZToNCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxw
cmUgd3JhcD0iIj5ObyBpc3N1ZSB3aXRoIGxvZ2ljYWwgdnMuIHBoeXNpY2FsIElELiBCdXQgSSBh
bSB3b25kZXJpbmcgYWJvdXQgdHdvDQp0aGluZ3M6DQoNCk9wZXJhdGlvbiBpcyBjbGVhciB0byBt
ZSBpbiBjYXNlIGEgc2luZ2xlIE1OSUQgaXMgcHJlc2VudCBpbiBhIG1lc3NhZ2UNCmFuZCBJIHNl
ZSB0aGUgdmFsdWUgaW4gYmVpbmcNCmZsZXhpYmxlIHRvIGNob29zZSBmcm9tIGRpZmZlcmVudCBz
dWItdHlwZXMuIElmIG11bHRpcGxlIE1OSURzIHdpdGgNCmRpZmZlcmVudCBzdWItdHlwZXMgYXJl
IHByZXNlbnQgaW4NCmEgc2luZ2xlIG1lc3NhZ2UsIHdoaWNoIG9uZSBzaG91bGQgZS5nLiB0aGUg
TE1BIHRha2UgZm9yIHRoZSBCQyBsb29rdXAuLg0KTm8gYmlnIHByb2JsZW0gdG8gc29sdmUsIGJ1
dA0KdG8gYmUgY29uc2lkZXJlZCBpbiBpbXBsZW1lbnRhdGlvbnMuDQoNCklmIHRoZSByZWFzb24g
Zm9yIG11bHRpcGxlIHByZXNlbnQgTU5JRHMgd2l0aCBkaWZmZXJlbnQgc3ViLXR5cGVzIGlzIHRv
DQpkbyBvdGhlciB0aGluZ3MgdGhhbiBpZGVudGlmeWluZw0KdGhlIG5vZGUgb3IgdXNpbmcgdGhl
IElEIGFzIGtleSBmb3IgYSBsb29rdXAsIEkgYW0gd29uZGVyaW5nIGlmIGl0IHdvdWxkDQpub3Qg
YmUgbW9yZSBhcHByb3ByaWF0ZQ0KdG8gZ28gZm9yIGEgZGlmZmVyZW50IGNvbnRhaW5lciBvcHRp
b24gdG8gY2Fycnkgc3VjaCBpbmZvcm1hdGlvbi4NClNvbWV0aGluZyBsaWtlIGEgY29tcGxlbWVu
dGFyeQ0KaWRlbnRpZmllciBvcHRpb24uDQoNCm1hcmNvDQoNCjwvcHJlPg0KPGJsb2NrcXVvdGUg
dHlwZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJl
ZXRleHQiIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iPm1haWx0bzpzZ3VuZGF2ZUBj
aXNjby5jb208L2E+XQ0KU2VudDogRG9ubmVyc3RhZywgMTEuIFNlcHRlbWJlciAyMDE0IDAwOjQy
DQpUbzogQ2hhcmxpZSBQZXJraW5zOyBNYXJjbyBMaWVic2NoOyA8YSBjbGFzcz0ibW96LXR4dC1s
aW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8
L2E+DQpDYzogVmlqYXkgRGV2YXJhcGFsbGkNClN1YmplY3Q6IFJlOiBbRE1NXSByZWdhcmRpbmcg
dGhlIHJlLWNoYXJ0ZXJpbmcuLg0KDQpIZWxsbyBDaGFybGllLA0KDQpBZ3JlZSB3aXRoIHRoYXQu
IE1OLUlkIGFzIGl0cyBkZWZpbmVkIHRvZGF5IGlzIGEgbG9naWNhbCBpZGVudGlmaWVyLiBJdA0K
ZG9lcyBub3QNCnJlcXVpcmUgdGhlIGlkZW50aWZpZXIgdG8gYmUgYm91bmQgdG8gYSBwaHlzaWNh
bCBkZXZpY2Ugb3IgYSBpbnRlcmZhY2UNCmlkZW50aXR5Lg0KQnV0LCB3ZSBoYXZlIGNsZWFybHkg
c2VlbiByZXF1aXJlbWVudHMgd2hlcmUgdGhlIG5lZWQgaXMgZm9yIGdlbmVyYXRpbmcNCmlkZW50
aWZpZXJzIGJhc2VkIG9uIHNvbWUgcGh5c2ljYWwgaWRlbnRpZmllcnMuIFRob3NlIHBoeXNpY2Fs
DQppZGVudGlmaWVycyBpbmNsdWRlDQpJTVNJLCBNU0lTRE4sIElNRUksIE1BQyAuLmV0Yy4gSWYg
d2UgY2FuIGRlZmluZSBhIHR5cGUgZm9yIGVhY2ggb2YgdGhlDQpzb3VyY2UNCmFuZCB0aGUgcnVs
ZXMgZm9yIGdlbmVyYXRpbmcgTU4tSUQgYmFzZWQgdXNpbmcgdGhvc2Ugc291cmNlcywgdGhlIHNl
bmRlcg0KYW5kDQpyZWNlaXZlciB3aWxsIGhhdmUgY2xlYXIgZ3VpZGFuY2Ugb24gaG93IHRvIHVz
ZSB0aGUgc3BlYy4gU29tZSBwb2ludGVycywNCmV4cGxhbmF0aW9uIGFuZCBleGFtcGxlcyBmb3Ig
ZWFjaCBvZiB0aG9zZSBpZGVudGlmaWVycyB3aWxsIGdyZWF0bHkgaGVscA0KYXZvaWQNCmludGVy
LW9wIGlzc3Vlcy4NCg0KDQpSZWdhcmRzDQpTcmkNCg0KDQoNCg0KDQoNCg0KT24gOS8xMC8xNCAz
OjIxIFBNLCAmcXVvdDtDaGFybGllIFBlcmtpbnMmcXVvdDsgPGEgY2xhc3M9Im1vei10eHQtbGlu
ay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Ij4m
bHQ7Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQmZ3Q7PC9hPg0Kd3JvdGU6DQoNCjwvcHJl
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+SGVsbG8gZm9sa3MsDQoN
CkkgdGhpbmsgaXQncyBiZXN0IHRvIGNvbnNpZGVyIHRoZSBNTklEIGFzIHNpbXBseSBsaXZpbmcg
aW4gYSBzcGFjZSBvZg0KaWRlbnRpZmllcnMsIGFuZCBub3Qgd29ycnkgdG9vIG11Y2ggYWJvdXQg
d2hldGhlciBpdCdzIGEgbG9naWNhbA0KaWRlbnRpZmllciBvciBhIHBoeXNpY2FsIGlkZW50aWZp
ZXIuICBJZiB0aGUgZm9ybWVyLCB0aGVuIHNvbWV3aGVyZQ0KKHBlcmhhcHMgYmVsb3cgdGhlIG5l
dHdvcmsgbGF5ZXIpIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIgaGFzIGJlZW4gYm91bmQNCnRvIHNv
bWV0aGluZyBpbiB0aGUgcGh5c2ljYWwgaW50ZXJmYWNlLCBidXQgdGhhdCdzIG5vdCBvdXIgcHJv
YmxlbS4NCg0KVGhlIG51bWJlciBzcGFjZSBmb3IgdHlwZXMgb2YgTU5JRHMgaXMgbGlrZWx5IHRv
IHN0YXkgcHJldHR5IGVtcHR5LCBzbw0KSSdkIHNheSB3ZSBjb3VsZCBhZGQgYXMgbWFueSB0eXBl
cyBhcyB3b3VsZCBiZSBjb252ZW5pZW50IGZvciB0aGUNCnNvZnR3YXJlIGRlc2lnbmVycy4gIFNv
LCB3ZSBjb3VsZCBjb25jZWl2YWJseSBoYXZlIHNldmVyYWwgTU5JRHMNCmRlZmluZWQgdGhhdCBh
bGwgJnF1b3Q7bG9va2VkIGxpa2UmcXVvdDsgTkFJcyAod2hpY2gsIHRoZW1zZWx2ZXMsICZxdW90
O2xvb2sgbGlrZSZxdW90Ow0KRlFETnMpLg0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCg0K
T24gOS8xMC8yMDE0IDg6MTEgQU0sIFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6DQo8
L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSB3cmFwPSIiPlllcy4gQ3VycmVu
dGx5LCB0aGUgTU5JRCBpcyBpZiB0aGUgbmFpIGZvcm1hdCBhbmQgaXMgb3ZlcmxvYWRlZC4gVGhl
DQpNTklEICBpbiAzR1BQIHNwZWNzIGlzIHRoZSBJTVNJLU5BSSAoSU1TSUBSRUFMTSksIGl0cyBi
YXNlZCBvbiB0aGUNCklNU0kuIEV4Og0KJnF1b3Q7Jmx0O0lNU0kmZ3Q7QGVwYy5tbmMmbHQ7TU5D
Jmd0Oy5tY2MmbHQ7TUNDJmd0Oy4zZ3BwbmV0d29yay5vcmep9w0KDQpXZSBhbHNvIGhhdmUgTUFD
NDhAUkVBTE07DQoNCldlIGFsc28gaGF2ZSBhcHByb2FjaGVzIHRvIHRyYW5zZm9ybSBNQUMgdG8g
UHNldWRvIElNU0ksIGFuZCB0aGVuDQpjYXJyeSBJTVNJLU5BSSBhcyB0aGUgTU4tSUQuDQoNCg0K
U28sIHdlIG5lZWQgdW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBvZiB0aGUgdHlwZXMvc291cmNl
cy4NCg0KTU4tSWQgYmFzZWQgb24gSU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi4NCg0KQWxzbywg
ZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElNU0kgYW5kIElNU0ktTkFJID8NCg0K
U3JpDQoNCg0KDQpPbiA5LzEwLzE0IDY6MjkgQU0sICZxdW90O01hcmNvIExpZWJzY2gmcXVvdDsg
PGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOk1hcmNvLkxpZWJz
Y2hAbmVjbGFiLmV1Ij4mbHQ7TWFyY28uTGllYnNjaEBuZWNsYWIuZXUmZ3Q7PC9hPiB3cm90ZToN
Cg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUgd3JhcD0iIj5JdCBzZWVt
cyB0aGUgTU5JRCBpcyBzb21laG93IG92ZXJsb2FkZWQgdG8gY2FycnkgYm90aCwgbm9kZS1zcGVj
aWZpYw0KSURzLCAgZS5nLiBNQUMsIGFzIHdlbGwgYXMgc3Vic2NyaWJlciBJRHMsIHdoaWNoIGlz
IHRoZSBJTVNJLg0KVGhlcmUgbWF5IGJlIHZhbHVlIGluIGFkZGluZyB0aGUgSU1FSSB0byB0aGUg
bGlzdCBvZiBwb3NzaWJsZSB0eXBlcw0Kb2YgIG5vZGUtc3BlY2lmaWMgSURzLg0KDQptYXJjbw0K
DQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSB3cmFwPSIiPi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkbW0gWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJl
ZXRleHQiIGhyZWY9Im1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRtbS1ib3Vu
Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFNyaSBHdW5kYXZlbGxpDQooc2d1bmRhdmUp
DQpTZW50OiBEaWVuc3RhZywgOS4gU2VwdGVtYmVyIDIwMTQgMjM6MzANClRvOiBTcmkgR3VuZGF2
ZWxsaSAoc2d1bmRhdmUpOyBDaGFybGllIFBlcmtpbnM7IDxhIGNsYXNzPSJtb3otdHh0LWxpbmst
YWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT4N
CkNjOiBWaWpheSBEZXZhcmFwYWxsaQ0KU3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUg
cmUtY2hhcnRlcmluZy4uDQoNClR3byBtb3JlIGNvbW1lbnRzLg0KDQoNCg0KNC4pIEknZCBhbHNv
IHVzZSBzdWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElNU0kuIEp1c3QgdG8gYWxpZ24gd2l0aA0K
dGhlICBzdWItdHlwZXMgIGRlZmluZWQgZm9yIE1OIElkIGRlZmluZWQgZm9yIElDTVAuIEkgc3Vz
cGVjdCB0aGVyZQ0KYXJlIHNvbWUgIGltcGxlbWVudGF0aW9ucyAgYWxyZWFkeSB1c2luZyBzdWIt
dHlwZSAoMikuIFBsZWFzZSBzZWUNCnRoZSBvdGhlciB0aHJlYWQuDQoNCg0KNS4pIEZvciBlYWNo
IG9mIHRoZSBzdWItdHlwZXMsIHdlIG5lZWQgdGV4dCBpbmNsdWRpbmcgZXhhbXBsZXMgYW5kDQpz
b21lDQpleHBsYW5hdGlvbiBvbiBob3cgdGhleSBhcmUgdXNlZC4NCg0KDQpTcmkNCg0KDQoNCk9u
IDkvOS8xNCAyOjIwIFBNLCAmcXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7IDxh
IGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNj
by5jb20iPiZsdDtzZ3VuZGF2ZUBjaXNjby5jb20mZ3Q7PC9hPg0Kd3JvdGU6DQoNCjwvcHJlPg0K
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIHdyYXA9IiI+SGkgQ2hhcmxpZSwNCg0KVGhp
cyBpcyBnb29kLiBUaGFua3MuDQoNCg0KMS4pIElmIEVVSS00OCBhbmQgRVVJLTY0IGFkZHJlc3Nl
cyBhcmUgZGVyaXZlZCBvZiBhIDQ4LWJpdCBJRUVFDQo4MDIuMg0KYWRkcmVzcywgd2h5IGRvIHdl
IG5lZWQgdG8gdHdvIHN1Yi10eXBlcyA/IFdoeSBub3QgaGF2ZSBqdXN0IG9uZQ0Kc3ViLXR5cGUg
Zm9yIG1hYyBiYXNlZCBpZGVudGlmaWVycyA/DQoNCjIuKSBTdWIgdHlwZSB2YWx1ZSAoMSkgaXMg
Y3VycmVudGx5IHVzZWQuIEl0cyBjdXJyZW50bHkgb3ZlcmxvYWRlZA0KZm9yDQpJTVNJLU5BSSAo
M0dQUCBzcGVjcykgYW5kIGdlbmVyaWMgTkFJIGJhc2VkIGlkZW50aWZpZXJzLiBHaXZlbiB0aGUN
CmRlZmluaXRpb24gb2YgbmV3IHN1Yi10eXBlcywgd2UgbmVlZCBzb21lIHRleHQgZXhwbGFpbmlu
ZyB0aGUNCm1vdGl2YXRpb24NCg0KMy4pIFByb3Bvc2VkIFN1Yi10eXBlIHZhbHVlIG9mICgyKSBm
b3IgSVB2NiBhZGRyZXNzLiBXaGF0IGV4YWN0bHkNCmlzDQp0aGlzID8gQXJlIHRoZXNlIENHQS1i
YXNlZCBJUHY2IGFkZHJlc3NlcyA/DQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgIE5ldyBN
b2JpbGUgTm9kZSBJZGVudGlmaWVyIFR5cGVzDQoNCiAgICAgICAgICAgICAgICYjNDM7LS0tLS0t
LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7DQogICAgICAgICAg
ICAgICB8IElkZW50aWZpZXIgVHlwZSB8IElkZW50aWZpZXIgVHlwZSBOdW1iZXIgfA0KICAgICAg
ICAgICAgICAgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tJiM0MzsNCiAgICAgICAgICAgICAgIHwgSVB2NiBBZGRyZXNzICAgIHwgMiAgICAgICAgICAg
ICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBJTVNJICAgICAgICAgICAgfCAzICAg
ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwg
ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8IFAtVE1TSSAgICAgICAg
ICB8IDQgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgRVVJLTQ4
IGFkZHJlc3MgIHwgNSAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAg
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg
fCBFVUktNjQgYWRkcmVzcyAgfCA2ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAg
ICAgICAgICB8IEdVVEkgICAgICAgICAgICB8IDcgICAgICAgICAgICAgICAgICAgICAgfA0KICAg
ICAgICAgICAgICAgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tJiM0MzsNCg0KDQoNCg0KDQoNCg0KUmVnYXJkcw0KU3JpDQpQUzogR29vZCB0byBzZWUg
VmlqYXkgYmFjaw0KDQoNCk9uIDkvOS8xNCAxOjI4IFBNLCAmcXVvdDtDaGFybGllIFBlcmtpbnMm
cXVvdDsNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpjaGFy
bGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCI+Jmx0O2NoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsu
bmV0Jmd0OzwvYT4NCndyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K
PHByZSB3cmFwPSIiPkhlbGxvIGZvbGtzLA0KDQpIZXJlJ3MgdGhlIGxhc3QgSW50ZXJuZXQgRHJh
ZnQgdGhhdCB3ZSBkaWQsIGxvbmcgYWdvIGV4cGlyZWQ6DQoNCjxhIGNsYXNzPSJtb3otdHh0LWxp
bmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1w
ZXJraW5zLW1leHQtNDI4M21uaWRzLTAxLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9hcmNoaXZl
L2lkL2RyYWZ0LXBlcmtpbnMtbWV4dC00MjgzbW5pZHMtMDEudHh0PC9hPg0KDQpJJ2xsIHJlc3Vi
bWl0IGl0IHdpdGggYSBmZXcgdXBkYXRlcyBhcyBhIHBlcnNvbmFsIGRyYWZ0IHRvIGRtbS4NCg0K
UmVnYXJkcywNCkNoYXJsaWUgUC4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIi
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFp
bGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWls
dG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGEgY2xhc3M9Im1vei10eHQtbGluay1m
cmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0i
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjwvcHJlPg0KPC9i
bG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5r
LWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+
PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kbW0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZG1tPC9hPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3
cmFwPSIiPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiPjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiPjwvcHJlPg0KPC9ibG9ja3F1b3Rl
Pg0KPHByZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlh
dGVkIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGEgY2xhc3M9
Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9kbW0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1t
PC9hPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQo8YSBjbGFz
cz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5k
bW1AaWV0Zi5vcmc8L2E+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D03767BD163EA7sgundaveciscocom_--


From nobody Thu Sep 11 15:05:17 2014
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 1C3CB1A017D for ; Thu, 11 Sep 2014 15:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level: 
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 RsRMZims07yj for ; Thu, 11 Sep 2014 15:04: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 003BA1A006D for ; Thu, 11 Sep 2014 15:04:56 -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 s8BM4u62023262; Thu, 11 Sep 2014 15:04:56 -0700
Received: from XCH-BLV-308.nw.nos.boeing.com (xch-blv-308.nw.nos.boeing.com [130.247.25.220]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8BM4klY023154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 11 Sep 2014 15:04:46 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-308.nw.nos.boeing.com ([169.254.8.89]) with mapi id 14.03.0181.006; Thu, 11 Sep 2014 15:04:45 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "sarikaya@ieee.org" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHPzUS085cNtlvM5kaPQ9fwALiOyZv68k2AgACFnwCAAA1uAIAA4psw
Date: Thu, 11 Sep 2014 22:04:45 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D16AD6@XCH-BLV-504.nw.nos.boeing.com>
References:  
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/mOYEix6ecb-1Kx3gk_AZOuMN_zA
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 11 Sep 2014 22:05:11 -0000

Hi Sri,

I had to read through this document several times since it is a very
different operational world from the "traditional" enterprise networks
I am familiar with. But, figures 3 and 6 I think show useful points of
comparison with AERO. In figure 3, for example:

  - eNodeB is the place where AERO Client would go, i.e., with AERO
    operating in "proxy" mode. Otherwise, if tunneling were allowed
    all the way to the UE then the UE would be the AERO Client
  - EPC-E is analogous to AERO Server
  - RTR is analogous to AERO Relay

In both vEPC and AERO, there can be many EPC-Es (i.e., AERO Servers)
and these can be lightweight VMs in hypervisors. We already have
several AERO Servers deployed in hypervisors within Boeing.

vEPC specifies an anycast discovery service for discovering EPC-Es,
and this same approach has already been adopted by earlier solutions
such as 6to4 [RFC3068] and 6rd [RFC5969]. AERO could easily adopt an
anycast discovery approach as well, but would be used for discovery
purposes only - after discovering the closest Server via anycast,
the Client would switch to using a unicast address of the Server so
that neighbor cache state could be established. Note that this
neighbor cache state is used instead of an explicit tunnel, since
the AERO tunnel is NBMA.

With the approach in the current version of the AERO spec, however,
the AERO Client is presented with the unicast addresses of potentially
many nearby AERO Servers. The Client can then associate with one or
more Servers simultaneously and can change between Servers if necessary,
e.g., to get better performance. So, the Client chooses the best
Server(s) to use instead of leaving it up to the vagaries of the
routing system.=20

As for vEPC's RTRs, AERO can have potentially many Relays. As for
vEPC, the AERO Servers and Relays also engage in an interior BGP
routing instance to track mobile node prefixes. With AERO, however,
the BGP peerings are unidirectional from Servers to Relays. So,
the Servers only need to know about their current set of associated
Clients, while the Relays get full topology information. This is a
very simple system - all Servers establish a TCP connection with
each Relay and then simply announce and withdraw routes over the
TCP connections. Conversely, the Relays never tell the Servers
anything. Unlike vEPC, however, Servers and Relays exchange packets
via tunneling - they do not use a non-tunneled routing domain,
although I suppose they could. But, one aspect of tunneling is that
it does not matter which IP protocol version is used in the IP core
network - it could be IPv4 or IPv6.

There are data flow paths for AERO that seem different from vEPC.
For example:

  1) Client A <-> Server <-> Client B (when both Clients associate
     with the same Server
  2) Client A <-> Server A <-> Relay <-> Server B <-> Client B
     (when the Clients associate with different Servers and before
     route optimization)
  3) Client A <-> Server A <-> Server B <-> Client B (when Server
     to-Server route optimization is applied)
  4) Client A -> Server B -> Client B, and
     Client B -> Server A -> Client A when Client-to-Server route
     optimization is applied
  5) Client A <-> Client B when Client-to-Client route optimization
     is applied

With vEPC I am not sure whether options 4 or 5 are available (but
maybe option 5 is not desired because it doesn't go through a
policy enforcement point?).

Other than that, I think the way AERO manages mobile node network
prefixes is probably quite different from vEPC. AERO always uses
DHCPv6 PD to delegate at least a /64 to each mobile node, and
can also delegate shorter prefixes. The mobile node gets the
same service no matter which Server it associates with, so if
it gets prefix P from Server A it will also get prefix P from
Server B.

That is about all I was able to glean from my first read, but
certainly willing to consider further.

Thanks - Fred
fred.l.templin@boeing.com


> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> Sent: Wednesday, September 10, 2014 5:14 PM
> To: Sri Gundavelli (sgundave); Templin, Fred L; sarikaya@ieee.org
> Cc: Dapeng Liu; dmm@ietf.org
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>=20
> Hi Fred,
>=20
> Looking at other solution alternative, there is this proposal from
> Satoru-san.
>=20
> http://www.ietf.org/id/draft-matsushima-stateless-uplane-vepc-03.txt
>=20
> Will be good to know your views on how you see this approach compare with
> Aero.
>=20
>=20
> Regards
> Sri
>=20
>=20
>=20
> On 9/10/14 4:25 PM, "Sri Gundavelli (sgundave)"  wrot=
e:
>=20
> >Fred,
> >
> >I'm not suggesting Aero vs MIP debate. IMO, its simply not worth it. Eac=
h
> >of the protocols have certain properties, which helps in some use-cases
> >and may be inefficient for some other use-cases. But, you can make all o=
f
> >them work, MIP, GTP, MOBIKE, AERO ... There is no silver bullet in any o=
ne
> >of them, unless some one can prove it. Some architectures are based on
> >fixed anchors and some such as LISP-based are based on floating anchors.
> >Solutions based on fixed anchors have properties that suits a SP
> >deployment;  a single point of charging, policy enforcement, LI support,
> >subscriber control but looses the aspect of optimized routing path. As a=
n
> >example, "I've the best optimized path for my traffic, but my operator h=
as
> >no clue where my traffic gets routed out". That works very well for some
> >cases and does not work for some other deployments. These are all points
> >of debate and each have to be measures on its own merit.
> >
> >The choice of the protocol is also tied to the legacy and deployed
> >infrastructure. Many times its about an evolution. I do not know how man=
y
> >people in this WG have been involved in the AERO protocol development, o=
r
> >familiar with it, at least I'm not involved in its development. But, I'm
> >not against AERO or some thing else. If the discussion has to be about a
> >protocol selection and the approach of multiple options does not work,
> >then we should just only do that and call for a vote and settle that
> >matter. I'm suggesting an approach, where we avoid this protocol debate
> >and allow multiple options. I'm sure, that battle will be bitter and not
> >worth it.
> >
> >
> >Regards
> >Sri
> >
> >
> >
> >


From nobody Thu Sep 11 16:07:30 2014
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 84C141A0263 for ; Thu, 11 Sep 2014 16:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level: 
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 0B88coKV5_s7 for ; Thu, 11 Sep 2014 16:07:23 -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 ADEE01A0201 for ; Thu, 11 Sep 2014 16:07:23 -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 s8BN7NGd012325; Thu, 11 Sep 2014 16:07:23 -0700
Received: from XCH-PHX-510.sw.nos.boeing.com (xch-phx-510.sw.nos.boeing.com [10.57.37.27]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8BN7Dmm011803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 11 Sep 2014 16:07:13 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-PHX-510.sw.nos.boeing.com ([169.254.10.42]) with mapi id 14.03.0181.006; Thu, 11 Sep 2014 16:07:12 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , Jouni Korhonen , "sarikaya@ieee.org" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHPzSY685cNtlvM5kaPQ9fwALiOyZv6soAwgAFMcQCAAC5BQIAAwuAA//+Qf6A=
Date: Thu, 11 Sep 2014 23:07:11 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D16DCE@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D1672B@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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Nbzejl54RaLjPM-gkdv7DFP0-Qo
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 11 Sep 2014 23:07:28 -0000

Hi Sri,

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> Sent: Thursday, September 11, 2014 2:51 PM
> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
> Cc: Dapeng Liu; dmm@ietf.org
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>=20
> Hi Fred,
>=20
> Thanks for your responses. I'm beginning to get the picture on how Aero
> works. Few more questions and then we should be able have meaningful
> discussion. It surely saves me lot of time and I appreciate it.
>=20
>=20
> 9.) Are you aware of implementation of a Aero client on iPhone ? Can Aero
> client be implemented in today's Apple iOS device, using standard API
> interface ? Will the Apple iOS allow an application to setup a tunnel and
> setup policy routes to steer a IP flow through that tunnel ?

We have AERO Client implemented on linux in a lightweight
user-level daemon and have it on our TODO list to port to
Android. This is all user-level code and no kernel changes
required. We haven't really looked at Apple iOS yet.

However, our target integration goal is OpenVPN since we will
then be able to use the same tool for AERO Client whether going
across a VPN or non-VPN connection. I haven't checked yet, but
if OpenVPN works on iOS, then AERO will also work on iOS when
we get this integration done.

> 10.) In today 3G/4G architectures, an application function can notify a
> policy function to allocate QoS resources for a flow. Ex: An IMS function
> requests a policy function to setup dedicated QoS resources for a RTP flo=
w
> and with guaranteed-bit-rate of 32kbps. This policy is enforced on the ai=
r
> interface and on the path from the client to the gateway. We have RFC7222
> providing QoS negotiation semantics on the network path and  then we have
> John's draft, draft-ietf-netext-pmip-qos which extends the same to the
> 802.11 air interface. How do you see this aspect of dynamic QoS work in
> Aero-based system ?

I really hadn't given that any thought, but looking at Section 4
of RFC7222 there is no reason the option defined there could not
be included in AERO messaging. Is this a control plane option
only, or is it also for the data plane?

I am sure there are also many other adjunct mechanisms associated
with MIP/PMIP that I haven't investigated yet. But I don't see any
reason why many/most could not be adapted for use with AERO.

> 11.) To make sure I get the flow right.
>=20
> - A client attaches to the Aero network
> - Chooses a Aero server from a list of servers; DNS lookup, static list

Yes.

> - Sets up a UDP tunnel to a Aero servers; (What triggers the server to
> setup the tunnel ? Is the DHCP message that is the trigger here ?)

AERO operates without explicit tunnels. Think of the AERO interface
as an ordinary NBMA IPv6 interface that maintains a neighbor cache
the same as any IPv6 interface. All nodes are single-hop neighbors
on the AERO interface, and hence can engage in IPv6 ND and DHCPv6
exchanges as on-link neighbors.

When an AERO Client discovers the address of an AERO Server, it
performs a DHCPv6 PD exchange with the Server over the AERO
interface. In the process, the Server creates an AERO interface
neighbor cache entry for the Client and the Client creates an
AERO interface neighbor cache entry for the Server and marks
the Server as "default". (RS/RA still work, but I haven't found
a need for them yet.) =20

> - The client does DHCPv6 signaling through the tunnel. The server
> allocates a special prefix. This prefix is on the Aero virtual link.
> Similar to Mobile IP home link ?

The Server delegates an AERO Client Prefix (ACP). The Client then
autoconfigures an AERO link-local address based on the ACP. So,
for example, if the ACP is 2001:db8:1:2::/64 then the AERO address
is fe80::2001:db8:1:2. The address is guaranteed to be unique,
since it is based on the ACP assigned by the Server. The Client
then uses this AERO address in all subsequent IPv6 ND messaging
over the AERO link. At the same time, it sub-delegates the ACP
to its downstream-attached links - it DOES NOT assign the ACP
to the AERO interface.

> - This special prefix is topologically anchored on the server

I would rather say that it is topologically anchored on the
Relays, since the Client can associate with multiple Servers
at the same time. But, the Relays will keep track of all
Client/Server associations.

> - Aero server sets up a tunnel route for the prefix towards the client

Actually, it does not need to set up an IP route because it
already has a neighbor cache entry with the Client's AERO
address, and the "interface ID" portion of the AERO address
can be used for IP forwarding decisions.

> - All traffic from the client using this prefix will be tunneled through
> the server; At least the first packet has to hit the server

The first packet (or first few packets) out will go through
one of the Client's associated Servers, but the Client can
at the same time send a Route Optimization request. If it
gets back a route optimization reply, it can then start
sending packets directly toward the route optimization target
without impacting the Server further.

> - When RO is triggered, there will ICMP redirect messages send in the UDP
> header with Aero port;

Yes, the RO "request" is known as a "Predirect". (I suppose it
could also be called a "Redirect Solicitation", but the acronym
"RS" is already taken.) When the target gets a Predirect, it
returns a Redircet.

> - The peers communicate directly. I assume there will be a UDP tunnel
> between the peers ?

Yes, peers communicate directly via tunneling.

> If there is no need for tunnel, is ingress filtering
> of the transit routers  not an issue ?

The Predirect/Redirect exchange sets up neighbor cache entries that
list the acceptable link-layer address(es) allowed to be used for
the node's claimed network-layer prefix. So, the nodes do a simple
data origin test to make sure that packets are coming from an
acceptable L2 address.

> - Client moves and attaches to a different IP network; Obtains a DHCP
> address

When the Client moves, it will stay with the same Server if it hasn't
moved too far. If so, the Client sends a DHCPv6 Rebind to the Server
to inform the Server of its new link-layer address. If the Client
has moved too far away from the previous Server, it contacts a new
Server then tells its old Server goodbye.

> - Client sets up a tunnel to the previously attached Aero server and
> continue to use the same prefix ?

Again, Clients may be associated with multiple Servers, and it
is the Client's responsibility to make sure that its current
set of Servers are good ones. The Client will always update
its current set of Servers whenever it moves. The Client gets
to use its same prefix wherever it moves to.
=20
> The focus is all about rote optimization and by means of triggering

Route optimization is one aspect. Maintaining a stable, unchanging
Client network prefix in spite of mobility events is another.=20

> Is the following mapping correct ?
>=20
> Aero server is almost like a home agent ?

I would rather say that the AERO Relay is like a home agent.
The AERO Relay is the entry point to the AERO virtual link
from the outside world. The AERO Relay is the one who knows
where all Clients are located. The AERO Servers are more
like L2 (L2.5?) devices that keep AERO Clients grouped into
manageable sets so that the load is spread and Clients get
good performance.=20

> Aero virtual link is Mobile IP home link ?

Yes. However, unlike MIP Clients, the AERO Clients never leave
the virtual link no matter where they move to, and the virtual
link is link-local-only. So, there is really no concept of
Home Address/Care-of Address.

> Aero prefixes given to the client are hosted on the server as in case of
> Home Agent ?

The AERO Relay is analogous to the MIP Home Agent and host all
AERO Client Prefixes. AERO Servers are "L2.5" devices that keep
track of a dynamically changing subset of all prefixes.

> Aero tunnel is similar to Mobile IP GRE or UDP tunnel ?

AERO can use any tunnel type. AERO has an assigned UDP port
number (8060) and by default does IP-in-UDP-in-IP tunneling.
But, the same AERO messaging can be used over any tunnel
type (GRE, IPsec, probably GTP but I haven't looked at that
very closely, etc.).

> Aero ICMP Redirects are equivalent to the MIP RO procedure ?

AERO Predirect/Redirect signaling is pretty unique (first
documented in RFC6706) and is unidirectional (i.e., first
A gets redirected to B, then B gets redirected to A). Is
that equivalent to MIP RO?

> Signaling is DHCPv6

and IPv6 ND, yes.

Thanks - Fred
fred.l.templin@boeing.com

> Regards
> Sri
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On 9/11/14 11:00 AM, "Templin, Fred L"  wrote:
>=20
> >Hi Sri,
> >
> >See below for some follow-up:
> >
> >> -----Original Message-----
> >> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> >> Sent: Thursday, September 11, 2014 12:28 AM
> >> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
> >> Cc: Dapeng Liu; dmm@ietf.org
> >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> >>
> >> Hi Fred,
> >>
> >> The below comment from you made me thinking. I must admit I'm not much
> >> familiar with Aero, have not seen its references in CDMA, WiMAX,
> >> CableLabs, WLAN or LTE architectures.  But, if it has all the mobility
> >> features and you believe this can conclude the WG, I thought I will
> >> explore this a bit. I started reviewing the charts that you sent and
> >> started browsing some of the specs. Few high-level questions, if you c=
an
> >> answer or point me to some documents, it will be great.
> >>
> >>
> >> 1.) What is the interface between the Aero Server and the client ? Is =
it
> >> just DHCPv6 ? There is no other signaling interface ?
> >
> >DHCPv6 is used for PD as well as mobility signaling. IPv6 ND messaging
> >is used for NUD, route optimization, and the functional equivalent of
> >a "binding update" via the use of unsolicited Neighbor Advertisements.
> >
> >> 2.) What is the service authorization model for a Aero client ? How is
> >>the
> >> client identified by the server ? What is the security model ?
> >
> >The Client is identified by the server via the DHCPv6 DUID. The DUID
> >is most likely based on some serial number or ID that is assigned to
> >the Client by the AERO service administrative staff.
> >
> >The security model is based on a multi-tiered layered security approach.
> >First, the Client must authenticate itself to the network using whatever
> >access layer securing mechanisms that are available, e.g., IEEE802.1x.
> >For Clients that are coming into the network from the Internet, the
> >Client establishes a VPN link to a security gateway at the network
> >border.
> >
> >Second, the Client must prove to the Server that it is authorized to
> >perform DHCPv6 signaling using DHCPv6 Auth or some other DHCPv6
> >securing mechanism. This is only to protect against an "insider
> >attack" in which a different Client pretends to be the authorized
> >Client in order to hijack the authorized Client's prefix, siphon
> >traffic, etc. Hence, a "better than nothing" authentication such
> >as DHCPv6 Auth is really all that is needed.
> >
> >Third, the network must ensure that link-layer addresses cannot
> >be spoofed. Here, the "link-layer address" is the IP source
> >address of the encapsulating tunnel header. This is typically
> >done through proper application of BCP ingress filtering
> >practices.
> >
> >Finally, the AERO Server/Relay infrastructure provides a trust
> >anchor to facilitate Client-to-Client route optimizations. In
> >particular, Clients trust their Servers but cannot trust each
> >other initially. If a Client receives a route optimization
> >signal from its trusted Server, however, it can safely engage
> >in the route optimization since a chain-of-trust was followed.
> >
> >> 3.) Can the Aero solution support IP nodes that do not have Aero clien=
t
> >> stack ?
> >
> >Proxy AERO could be applied in the same manner as for PMIP,
> >but the document does not fully investigate that option at
> >this time.
> >
> >> 4.) If a mobile or a cable SP deploys Aero, where is their point of
> >> control ? Where can they do Accounting, Lawful interception ?
> >
> >Lawful intercept, accounting, etc. can be done at the AERO Servers.
> >In case these functions are mandatory, direct Client-to-Client route
> >optimizations would not be permitted in those environments. However,
> >Client-to-Server-to-Client route optimizations would still be used
> >to reduce path stretch and reduce load on critical infrastructure.
> >
> >> 5.) I assume Aero client can be IPv4 or an IPv6 device ? For an
> >>IPv4-only
> >> legacy device, is the interface DHCPv4 ?
> >
> >The AERO data plane can be either IPv4 or IPv6, and can be tunneled
> >over either IPv4 or IPv6 access networks. The AERO control plane is
> >always DHCPv6 and IPv6 ND. In particular, DHCPv6 PD can be used to
> >delegate IPv4 prefixes in the same way that it can delegate IPv6
> >prefixes. So no; DHCPv4 is not used in the control plane.
> >
> >> 6.) Can an operator enable location-based services for a Aero client ?
> >
> >AERO Clients discover and associate with AERO Servers that are
> >"nearby". They discover nearby Servers by resolving the DNS
> >FQDN "linkupnetworks.[domain]" where "[domain]" is a link-
> >specific DNS suffix. This would provide topological proximity
> >and I guess most often also geographic proximity. Is that what
> >you were asking?
> >
> >> 7.) How can an operator enable IP Flow Mobility type features in an Ae=
ro
> >> system ?
> >
> >I am not familiar with IP Flow Mobility, but does it mean spreading
> >traffic load across multiple access links? Like maybe sending streaming
> >video across WLAN while posting short text messages via 4G? If so,
> >AERO supports the use of multiple simultaneous access links - like,
> >keeping both the WLAN and 4G interfaces active at the same time. Or
> >maybe I am mis-understanding IP Flow Mobility?
> >
> >> 8.) Taking a mobile router scenario, how does Aero client support
> >> multi-tenancy ? Is there a single tunnel between the client and the
> >>server
> >
> >Again, I am not familiar with the term multi-tenancy, or at least not
> >with its use within this context. In terms of tunnels, however, the
> >tunnel is non-broadcast, multiple access (NBMA) and not point-to-point.
> >So each AERO node sees other AERO nodes as neighbors on the NBMA link.
> >The AERO interface therefore maintains a neighbor cache the same as
> >any IP interface, and uses the neighbor cache entries to track the
> >current L3/L2 address mappings. These mappings may change over time,
> >e.g., as the result of a mobility event.
> >
> >Thanks - Fred
> >fred.l.templin@boeing.com
> >
> >> ?
> >>
> >>
> >> Regards
> >> Sri
> >>
> >>
> >>
> >>
> >> On 9/10/14 11:43 AM, "Templin, Fred L" 
> >>wrote:
> >>
> >> >Hi Jouni,
> >> >
> >> >I'd like to propose a slightly different charter:
> >> >
> >> >  "AERO already solves distributed mobility management and provides a
> >> >   a comprehensive mobility solution for any mobile device. AERO shou=
ld
> >> >   therefore be approved as the mobility management solution for DMM.
> >> >   Publication of AERO will therefore conclude the working group's
> >> >   activity."
> >> >
> >> >Can we have this on the agenda?
> >> >
> >> >Thanks - Fred
> >> >fred.l.templin@boeing.com
> >> >
> >> >> -----Original Message-----
> >> >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen
> >> >> Sent: Wednesday, September 10, 2014 11:37 AM
> >> >> To: sarikaya@ieee.org
> >> >> Cc: Dapeng Liu; dmm@ietf.org
> >> >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> >> >>
> >> >>
> >> >> What do you mean by no agenda? To me it clearly says we use the cal=
l
> >>#2
> >> >> for setting up the work split.
> >> >>
> >> >> - Jouni
> >> >>
> >> >> 9/10/2014 9:06 PM, Behcet Sarikaya kirjoitti:
> >> >> > Jouni, why don't we cancel this one (#2) and do the next one (#3)
> >>with
> >> >> > an agenda?
> >> >> > I hope Alper can attend :-)
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Behcet
> >> >> >
> >> >> > On Wed, Sep 10, 2014 at 1:02 PM, Jouni Korhonen
> >> >> wrote:
> >> >> >>
> >> >> >> It seems I sent this to a wrong receiver.. that explains why it
> >>did
> >> >>not
> >> >> >> appear on the list.
> >> >> >>
> >> >> >> - Jouni
> >> >> >>
> >> >> >> -------- Alkuper=E4inen viesti / Orig.Msg. --------
> >> >> >> Aihe: DMM Interim call #2 - agenda forming
> >> >> >> P=E4iv=E4ys: Mon, 08 Sep 2014 23:43:24 +0300
> >> >> >> L=E4hett=E4j=E4: Jouni Korhonen 
> >> >> >> Vastaanottaja: dmm-ads@tools.ietf.org
> >> >> >> CC: jouni.nospam@gmail.com, Dapeng Liu 
> >> >> >>
> >> >> >> Folks,
> >> >> >>
> >> >> >> The next interim is close. Assuming there are no overwhelming
> >>amount
> >> >>of
> >> >> >> comments to the re-charter text, we are ready to start setting u=
p
> >>the
> >> >> >> work split on the solution space! Remember the discussion and th=
e
> >> >> >> minutes from the IETF#90 Friday session. No other agenda items a=
re
> >> >> >> planned for the next interim.
> >> >> >>
> >> >> >> - 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
> >> >_______________________________________________
> >> >dmm mailing list
> >> >dmm@ietf.org
> >> >https://www.ietf.org/mailman/listinfo/dmm
> >


From nobody Thu Sep 11 17:59:29 2014
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 6F0B71A02D4 for ; Thu, 11 Sep 2014 17:59:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 h3-urY4iVT5y for ; Thu, 11 Sep 2014 17:59:24 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B037A1A0263 for ; Thu, 11 Sep 2014 17:59:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2623; q=dns/txt; s=iport; t=1410483566; x=1411693166; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hTJgo++iOJkJPgGNiWuQTcAmXrQ/lAX72C/Dsm8Gw3Q=; b=fq52P+6yMOmXMC/Dp/vbzyXQSrlSjqPqbiCyB+LXe0tHZ6lRYsVipPhO tZlpkjCClXO9rkW0OXZXpy3jTk05EorPiKmgocLQnkuFUz1Mp8P/xB73Y qb4ZkHUFbbQTknhqDCCPI20QuQpNYax6WkoFjyfIL/H0vjpKkvZRKDz8T k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAONEElStJV2U/2dsb2JhbABfgw2BKgTQHAGBCxZ4hAQCBDo/EgEINkIlAgQBDQUUB4gnvgsBF49NB4RMBYUMjD+LNpU7gW8WgVxsAYFHgQcBAQE
X-IronPort-AV: E=Sophos;i="5.04,509,1406592000"; d="scan'208";a="354581667"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 12 Sep 2014 00:59:25 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8C0xNwF029372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 00:59:23 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 19:59:23 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , Jouni Korhonen , "sarikaya@ieee.org" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHPziTK5XxA9a/zI0SzZXA1gKHq8w==
Date: Fri, 12 Sep 2014 00:59:23 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D16DCE@XCH-BLV-504.nw.nos.boeing.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.21.64.105]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/2QeNVJsDbxX4YSFKD9JJXww2C3w
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 12 Sep 2014 00:59:26 -0000

Hi Fred,

Thanks again for your responses.

Lets zoom into the following two points.





On 9/11/14 4:07 PM, "Templin, Fred L"  wrote:

>
>>=20
>>=20
>> 9.) Are you aware of implementation of a Aero client on iPhone ? Can
>>Aero
>> client be implemented in today's Apple iOS device, using standard API
>> interface ? Will the Apple iOS allow an application to setup a tunnel
>>and
>> setup policy routes to steer a IP flow through that tunnel ?
>
>We have AERO Client implemented on linux in a lightweight
>user-level daemon and have it on our TODO list to port to
>Android. This is all user-level code and no kernel changes
>required. We haven't really looked at Apple iOS yet.
>
>However, our target integration goal is OpenVPN since we will
>then be able to use the same tool for AERO Client whether going
>across a VPN or non-VPN connection. I haven't checked yet, but
>if OpenVPN works on iOS, then AERO will also work on iOS when
>we get this integration done.


I understand, this can be realized in Android and in Linux based
platforms. However, from what I understand, the Apple's published SDK does
not allow applications to create IP tunnels and setup forwarding of IP
packets through those tunnels. Essentially, we may not be able to build a
Aero client for the currently deployed millions of iOS devices.

Forget alone the tunnel part, the MIP community over the years realized
that managing a client-eco system is not trivial. In the glory days of
Microsoft window's rule, Microsoft they never integrated MIP stack in
their windows operating system and the industry struggled to see the MIP
client eco-system and eventually that forced us to look at network-based
approaches. We invested in mobility models that did not require client
support. All thought MIP flourished during the CDMA days, as Qualcom
integrated the stack into the chipset, but however operators chose a
network-based approach for 4G architectures.

=20



>
>>
>> >> 3.) Can the Aero solution support IP nodes that do not have Aero
>>client
>> >> stack ?
>> >
>> >Proxy AERO could be applied in the same manner as for PMIP,
>> >but the document does not fully investigate that option at
>> >this time.
>> >


Ok. So, the current experimental AERO RFC does not support network-based
approaches and we cannot build client for a platform with most dominant
market share.


Based on these points #3 and #9, can we conclude that we cannot apply AERO
for DMM ? If not, how do we apply and deploy Aero for DMM networks ?





Regards
Sri
















From nobody Fri Sep 12 02:36:35 2014
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 155AB1A06B5 for ; Fri, 12 Sep 2014 02:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.383
X-Spam-Level: 
X-Spam-Status: No, score=-4.383 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, J_CHICKENPOX_36=0.6, 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 QJASs5Ohp0Ox for ; Fri, 12 Sep 2014 02:36:29 -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 B29AC1A06A8 for ; Fri, 12 Sep 2014 02:36:28 -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 s8C9aKG6024991; Fri, 12 Sep 2014 11:36:20 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DEC18204BC0; Fri, 12 Sep 2014 11:36:46 +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 C78A9204B76; Fri, 12 Sep 2014 11:36:46 +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 s8C9aE1e026818; Fri, 12 Sep 2014 11:36:20 +0200
Message-ID: <5412BE8E.7020500@gmail.com>
Date: Fri, 12 Sep 2014 11:36:14 +0200
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: "Sri Gundavelli (sgundave)" , "Templin, Fred L" , "dmm@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Q8XmEgLtOaw2jhbZ4RIH1AVk1yI
Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User"
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, 12 Sep 2014 09:36:31 -0000

Le 11/09/2014 00:00, Sri Gundavelli (sgundave) a écrit :
> Hi Fred,
>
> On 9/4/14 7:50 AM, "Templin, Fred L"  wrote:
>
>>> No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not
>>> working well together.
>>
>> Right - switching between VPN and non-VPN will be important for
>> enterprise network mobile device users.
>
>
> I think Alex is referring to the DSMIP and IKEv2 interactions and I don't
> believe his point is about switching across VPN and non-VPN modes.
>
> FWIW, the 3GPP S2b interface allows a mobile node to perform handovers
> from 3GPP access (S5/S8) to non-3GPP access (S2b).
>
> There are other examples of Mobile VPN solutions that are deployed and are
> based on Mobile IP protocols. RFC5265 is only one example.

Sri - I agree that specifications allow certain handovers.

I am not sure what do you mean by Mobile VPN?  Mobile IP using a MH-HA 
tunnel with a VPN-style tunnel?  A VPN which changes the source address 
with a new IKE exchange?  These are two different things.

In my experience, once I successfully set up a VPN tunnel on a Host 
computer its Mobile IP implementation will no longer work, and 
vice-versa; although each one can support mobility ok, independently, to 
a certain extent.

Alex

>
>
> Regards
> Sri
>
>
>
>



From nobody Fri Sep 12 06:51:36 2014
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 88AD11A6F0E for ; Fri, 12 Sep 2014 06:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Level: 
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 I8larKPEKChS for ; Fri, 12 Sep 2014 06:51:32 -0700 (PDT)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833841A6F0D for ; Fri, 12 Sep 2014 06:51:32 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id x3so828868qcv.16 for ; Fri, 12 Sep 2014 06:51:31 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jJK9PxnL7kmbTn4O9ibfl5B2E/UjJbgFo/tve3hzXUo=; b=ZXtjfKn3eBkATuqvso3LA+ZwqQEO/3+1eSNtHFVuZ5YxZKGsmi4Tdu9eIWqtNZe7Db qFgmAz8ZGkzsFgG8kf9io3LJPz5ybHwsA3vBKGljSVEMjM0lB/9Xxuc7y31/aywaO38k hPNtjKNrwKzv26eC7cqPuocOcacjhk5rIsBXTitZ9PyMU2R3cqZa1FQnnnQR6qEZPxkN jlHfka4nAh8eRxKkztpuY6XbZOslcvnVCog2V8mTn2sXgltaAVWg6O6uHYcnZ0DbwgKS hfZb70TyXRzHYbTGkjJX3Gj94GMNjAKl6KVRPGqjWzbjOasIUQNd4BlNfxi+PWgUMUYO OQAw==
X-Received: by 10.224.28.133 with SMTP id m5mr12108247qac.16.1410529889868; Fri, 12 Sep 2014 06:51:29 -0700 (PDT)
Received: from [10.201.5.218] ([209.29.74.150]) by mx.google.com with ESMTPSA id i1sm3021957qaz.28.2014.09.12.06.51.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 06:51:29 -0700 (PDT)
Message-ID: <5412FA5F.9080002@gmail.com>
Date: Fri, 12 Sep 2014 16:51:27 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dmm@ietf.org" 
References: <540E14EC.8070404@gmail.com> <54109247.4090500@gmail.com>
In-Reply-To: <54109247.4090500@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/HuilbUJC8ke4B53lMK3U_gkz_30
Cc: Dapeng Liu 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 12 Sep 2014 13:51:34 -0000

Folks,

I've learned that I may have a force majeure at the time of interim call 
#2. Fortunately we got two chairs so Dapeng will lead the call.

- Jouni

9/10/2014 9:02 PM, Jouni Korhonen kirjoitti:
>
> It seems I sent this to a wrong receiver.. that explains why it did not
> appear on the list.
>
> - Jouni
>
> -------- Alkuperäinen viesti / Orig.Msg. --------
> Aihe: DMM Interim call #2 - agenda forming
> Päiväys: Mon, 08 Sep 2014 23:43:24 +0300
> Lähettäjä: Jouni Korhonen 
> Vastaanottaja: dmm-ads@tools.ietf.org
> CC: jouni.nospam@gmail.com, Dapeng Liu 
>
> Folks,
>
> The next interim is close. Assuming there are no overwhelming amount of
> comments to the re-charter text, we are ready to start setting up the
> work split on the solution space! Remember the discussion and the
> minutes from the IETF#90 Friday session. No other agenda items are
> planned for the next interim.
>
> - Jouni & Dapeng
>
>


From nobody Fri Sep 12 07:03:36 2014
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 2F3C21A6ED8 for ; Fri, 12 Sep 2014 07:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Level: 
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 rA-tAv28hEUI for ; Fri, 12 Sep 2014 07:03:33 -0700 (PDT)
Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A04FB1A064F for ; Fri, 12 Sep 2014 07:03:33 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id x13so837362qcv.23 for ; Fri, 12 Sep 2014 07:03:29 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=roPy6JCDy9tssc49INd+j+w5MTgCfFwvVc8FEi7yz7s=; b=BgneIrbo2tcZG2DL4w38g/ler2v5nNtX3LhfK7dFMtBCe8FrrtAXxk3uYzC8QlNSSI KkbgbZtsBH0df1BxQxocv6eAG5C/1CzCb7oqNSRJ6Auk5x+pZpBI2/yMtxQRiByI/8Td qJzVQ8EEUDcx2abZlyUa3Yy3SFvtSiZZ/SFAwWbqe4H/QSdltBTqar9HEBLhRQtNQobg v1uSDRdjcdvvNUks2El3fi6gLSoPkJmvb63xgMKajk7rbO3UUIVfr80TxwOq64cEGTTw ouI6wm1CwUAKKm2w7nA/lOiUkrThI/cSGcI21r6dgFvpzAn1uxvGMsZ9t8zlOJQUjz6p TYsQ==
X-Received: by 10.224.46.133 with SMTP id j5mr12046124qaf.92.1410530607606; Fri, 12 Sep 2014 07:03:27 -0700 (PDT)
Received: from [10.201.5.218] ([209.29.74.150]) by mx.google.com with ESMTPSA id p20sm3010836qgp.41.2014.09.12.07.03.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 07:03:27 -0700 (PDT)
Message-ID: <5412FD2F.8090305@gmail.com>
Date: Fri, 12 Sep 2014 17:03:27 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dmm@ietf.org" 
References: <540E14EC.8070404@gmail.com> <54109247.4090500@gmail.com>
In-Reply-To: <54109247.4090500@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Hejn-fdEujh7q39Tlkn4ioOl35E
Cc: Dapeng Liu 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 12 Sep 2014 14:03:35 -0000

The interim #2 agenda is now also online:
http://www.ietf.org/proceedings/interim/2014/09/16/dmm/agenda/agenda-interim-2014-dmm-2

- jouni

9/10/2014 9:02 PM, Jouni Korhonen kirjoitti:
>
> It seems I sent this to a wrong receiver.. that explains why it did not
> appear on the list.
>
> - Jouni
>
> -------- Alkuperäinen viesti / Orig.Msg. --------
> Aihe: DMM Interim call #2 - agenda forming
> Päiväys: Mon, 08 Sep 2014 23:43:24 +0300
> Lähettäjä: Jouni Korhonen 
> Vastaanottaja: dmm-ads@tools.ietf.org
> CC: jouni.nospam@gmail.com, Dapeng Liu 
>
> Folks,
>
> The next interim is close. Assuming there are no overwhelming amount of
> comments to the re-charter text, we are ready to start setting up the
> work split on the solution space! Remember the discussion and the
> minutes from the IETF#90 Friday session. No other agenda items are
> planned for the next interim.
>
> - Jouni & Dapeng
>
>


From nobody Fri Sep 12 08:17:26 2014
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 6013C1A06D8 for ; Fri, 12 Sep 2014 08:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level: 
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 Fb9PNqcch963 for ; Fri, 12 Sep 2014 08:17:15 -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 1E53F1A06D2 for ; Fri, 12 Sep 2014 08:17:15 -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 s8CFHECx003505; Fri, 12 Sep 2014 10:17:14 -0500
Received: from XCH-BLV-303.nw.nos.boeing.com (xch-blv-303.nw.nos.boeing.com [130.247.25.215]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8CFH7tR003458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 12 Sep 2014 10:17:08 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.55]) with mapi id 14.03.0181.006; Fri, 12 Sep 2014 08:17:06 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , Jouni Korhonen , "sarikaya@ieee.org" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHPzSY685cNtlvM5kaPQ9fwALiOyZv6soAwgAFMcQCAAC5BQIAAwuAA//+Qf6CAAKQQgIAAdvdw
Date: Fri, 12 Sep 2014 15:17:06 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D17467@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D16DCE@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/feIqohH9FbncnvWsEWBWx5vvvUY
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 12 Sep 2014 15:17:23 -0000

Hi Sri,

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> Sent: Thursday, September 11, 2014 5:59 PM
> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
> Cc: Dapeng Liu; dmm@ietf.org
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>=20
> Hi Fred,
>=20
> Thanks again for your responses.
>=20
> Lets zoom into the following two points.
>=20
>=20
>=20
>=20
>=20
> On 9/11/14 4:07 PM, "Templin, Fred L"  wrote:
>=20
> >
> >>
> >>
> >> 9.) Are you aware of implementation of a Aero client on iPhone ? Can
> >>Aero
> >> client be implemented in today's Apple iOS device, using standard API
> >> interface ? Will the Apple iOS allow an application to setup a tunnel
> >>and
> >> setup policy routes to steer a IP flow through that tunnel ?
> >
> >We have AERO Client implemented on linux in a lightweight
> >user-level daemon and have it on our TODO list to port to
> >Android. This is all user-level code and no kernel changes
> >required. We haven't really looked at Apple iOS yet.
> >
> >However, our target integration goal is OpenVPN since we will
> >then be able to use the same tool for AERO Client whether going
> >across a VPN or non-VPN connection. I haven't checked yet, but
> >if OpenVPN works on iOS, then AERO will also work on iOS when
> >we get this integration done.
>=20
>=20
> I understand, this can be realized in Android and in Linux based
> platforms. However, from what I understand, the Apple's published SDK doe=
s
> not allow applications to create IP tunnels and setup forwarding of IP
> packets through those tunnels. Essentially, we may not be able to build a
> Aero client for the currently deployed millions of iOS devices.

I'll be honest that I have not had a chance to look into iOS, but
surely those devices must support some form of VPN solution - I
guess OpenVPN? If an iOS phone can be made to do OpenVPN, then
it can be made to do AERO.

> Forget alone the tunnel part, the MIP community over the years realized
> that managing a client-eco system is not trivial. In the glory days of
> Microsoft window's rule, Microsoft they never integrated MIP stack in
> their windows operating system and the industry struggled to see the MIP
> client eco-system and eventually that forced us to look at network-based
> approaches. We invested in mobility models that did not require client
> support. All thought MIP flourished during the CDMA days, as Qualcom
> integrated the stack into the chipset, but however operators chose a
> network-based approach for 4G architectures.

I don't mind talking about proxy-AERO - which should be a trivial
extension of the base mechanisms. The only problem with that is
that it has to exist in the access routers, and AFAICT it would
be difficult to switch between different data link technologies
on the fly, e.g., going from a wired LAN to WiFi, going from
WiFi to 4G, going from non-VPN to VPN, etc. Do the proxy
solutions talk about this?

> >> >> 3.) Can the Aero solution support IP nodes that do not have Aero
> >>client
> >> >> stack ?
> >> >
> >> >Proxy AERO could be applied in the same manner as for PMIP,
> >> >but the document does not fully investigate that option at
> >> >this time.
> >> >
>=20
>=20
> Ok. So, the current experimental AERO RFC does not support network-based
> approaches and we cannot build client for a platform with most dominant
> market share.

This version of AERO is far evolved from the experimental RFC.
If you want it to talk about proxy AERO, then I don't mind
talking about new text to add to the current draft.

> Based on these points #3 and #9, can we conclude that we cannot apply AER=
O
> for DMM ? If not, how do we apply and deploy Aero for DMM networks ?

I don't think so. Surely we can do proxy AERO, and surely iOS
phones can do VPN. So, pick one or both of these alternatives
and I think the concern is addressed?

Thanks - Fred
fred.l.templin@boeing.com
=20
>=20
>=20
>=20
>=20
> Regards
> Sri
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20


From nobody Fri Sep 12 09:32:49 2014
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 19B5F1A6FBC for ; Fri, 12 Sep 2014 09:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 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, J_CHICKENPOX_36=0.6, 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 JmkaKwjuf4HZ for ; Fri, 12 Sep 2014 09:32:45 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6881A6FB9 for ; Fri, 12 Sep 2014 09:32:44 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id ty20so1298431lab.9 for ; Fri, 12 Sep 2014 09:32:43 -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=IRzo2DtY8db35xPSgG/L7qKWJ50HjtAtM7Wfhdn8DJ4=; b=b4qMax5/N+SbG7Sy94sEVHaWgjkkqACmMmRppJGrc8TnXnXUcAgtx5UYotO/tIckdM B/G7GWq9ubjOMMW1JoUMumGUZCD2yDilGKvSszK0CgftshcWGtYRYeqLka5E/zOkbhXe T9wuOzN6gO/8M6wOtE3QQ2YPrn2frJHcipFYcYQoi9aI8ukQ0RQ98yWv6VUau1DgZFj3 459pzZno720NOEtmzVQ23/it3W2SqXrrt6gC1dPabs5lYcQgarcoc620NNPdAU+oKWOl ujaqV2TsiX40C1B/lSN7s7byVg6JEUZb0PylaLJfsML05qHbjgWv0xN3+EdUklhaStg3 aF4g==
MIME-Version: 1.0
X-Received: by 10.112.150.106 with SMTP id uh10mr9523372lbb.11.1410539563009;  Fri, 12 Sep 2014 09:32:43 -0700 (PDT)
Received: by 10.114.77.37 with HTTP; Fri, 12 Sep 2014 09:32:42 -0700 (PDT)
In-Reply-To: <5412BE8E.7020500@gmail.com>
References:  <5412BE8E.7020500@gmail.com>
Date: Fri, 12 Sep 2014 11:32:42 -0500
Message-ID: 
From: Behcet Sarikaya 
To: Alexandru Petrescu 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/BE6uZr3Sp4jDLltjKTCguCDTpbE
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User"
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, 12 Sep 2014 16:32:46 -0000

On Fri, Sep 12, 2014 at 4:36 AM, Alexandru Petrescu
 wrote:
> Le 11/09/2014 00:00, Sri Gundavelli (sgundave) a =C3=A9crit :
>>
>> Hi Fred,
>>
>> On 9/4/14 7:50 AM, "Templin, Fred L"  wrote:
>>
>>>> No, in that "VPN" is cited in the scenario and VPN+Mobile IP are not
>>>> working well together.
>>>
>>>
>>> Right - switching between VPN and non-VPN will be important for
>>> enterprise network mobile device users.
>>
>>
>>
>> I think Alex is referring to the DSMIP and IKEv2 interactions and I don'=
t
>> believe his point is about switching across VPN and non-VPN modes.
>>
>> FWIW, the 3GPP S2b interface allows a mobile node to perform handovers
>> from 3GPP access (S5/S8) to non-3GPP access (S2b).
>>
>> There are other examples of Mobile VPN solutions that are deployed and a=
re
>> based on Mobile IP protocols. RFC5265 is only one example.
>
>
> Sri - I agree that specifications allow certain handovers.
>
> I am not sure what do you mean by Mobile VPN?  Mobile IP using a MH-HA
> tunnel with a VPN-style tunnel?  A VPN which changes the source address w=
ith
> a new IKE exchange?  These are two different things.
>
> In my experience, once I successfully set up a VPN tunnel on a Host compu=
ter
> its Mobile IP implementation will no longer work, and vice-versa; althoug=
h
> each one can support mobility ok, independently, to a certain extent.
>

Alex, there is something called MOBIKE RFC 4621. I think it moves
IPSec tunnel when MN's address changes. So that could be used with
VPN.

Regards,

Behcet


> Alex
>
>
>>
>>
>> Regards
>> Sri
>>
>>
>>
>>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Fri Sep 12 09:46:36 2014
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 846701A6FCA for ; Fri, 12 Sep 2014 09:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.253
X-Spam-Level: 
X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 VX-66ckA5Onp for ; Fri, 12 Sep 2014 09:46:32 -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 C6BDF1A6FC9 for ; Fri, 12 Sep 2014 09:46: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 s8CGkWMb008243; Fri, 12 Sep 2014 09:46:32 -0700
Received: from XCH-BLV-104.nw.nos.boeing.com (xch-blv-104.nw.nos.boeing.com [130.247.25.120]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8CGkMxZ008190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 12 Sep 2014 09:46:23 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-104.nw.nos.boeing.com ([169.254.4.175]) with mapi id 14.03.0181.006; Fri, 12 Sep 2014 09:46:21 -0700
From: "Templin, Fred L" 
To: "sarikaya@ieee.org" , Alexandru Petrescu 
Thread-Topic: [DMM] "A Day in the Life of an Enterprise Mobile Device User"
Thread-Index: AQHPzqcsOP6F+udYnkWXmXXAiU79KZv9s6uw
Date: Fri, 12 Sep 2014 16:46:21 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D17640@XCH-BLV-504.nw.nos.boeing.com>
References:  <5412BE8E.7020500@gmail.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/4z8SXDtfiTZXWHTGvFw1MIFU7x8
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User"
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, 12 Sep 2014 16:46:34 -0000

SGkgQmVoY2V0LA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlaGNl
dCBTYXJpa2F5YSBbbWFpbHRvOnNhcmlrYXlhMjAxMkBnbWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRh
eSwgU2VwdGVtYmVyIDEyLCAyMDE0IDk6MzMgQU0NCj4gVG86IEFsZXhhbmRydSBQZXRyZXNjdQ0K
PiBDYzogU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKTsgVGVtcGxpbiwgRnJlZCBMOyBkbW1AaWV0
Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtETU1dICJBIERheSBpbiB0aGUgTGlmZSBvZiBhbiBFbnRl
cnByaXNlIE1vYmlsZSBEZXZpY2UgVXNlciINCj4gDQo+IE9uIEZyaSwgU2VwIDEyLCAyMDE0IGF0
IDQ6MzYgQU0sIEFsZXhhbmRydSBQZXRyZXNjdQ0KPiA8YWxleGFuZHJ1LnBldHJlc2N1QGdtYWls
LmNvbT4gd3JvdGU6DQo+ID4gTGUgMTEvMDkvMjAxNCAwMDowMCwgU3JpIEd1bmRhdmVsbGkgKHNn
dW5kYXZlKSBhIMOpY3JpdCA6DQo+ID4+DQo+ID4+IEhpIEZyZWQsDQo+ID4+DQo+ID4+IE9uIDkv
NC8xNCA3OjUwIEFNLCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNv
bT4gd3JvdGU6DQo+ID4+DQo+ID4+Pj4gTm8sIGluIHRoYXQgIlZQTiIgaXMgY2l0ZWQgaW4gdGhl
IHNjZW5hcmlvIGFuZCBWUE4rTW9iaWxlIElQIGFyZSBub3QNCj4gPj4+PiB3b3JraW5nIHdlbGwg
dG9nZXRoZXIuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFJpZ2h0IC0gc3dpdGNoaW5nIGJldHdlZW4g
VlBOIGFuZCBub24tVlBOIHdpbGwgYmUgaW1wb3J0YW50IGZvcg0KPiA+Pj4gZW50ZXJwcmlzZSBu
ZXR3b3JrIG1vYmlsZSBkZXZpY2UgdXNlcnMuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEkgdGhp
bmsgQWxleCBpcyByZWZlcnJpbmcgdG8gdGhlIERTTUlQIGFuZCBJS0V2MiBpbnRlcmFjdGlvbnMg
YW5kIEkgZG9uJ3QNCj4gPj4gYmVsaWV2ZSBoaXMgcG9pbnQgaXMgYWJvdXQgc3dpdGNoaW5nIGFj
cm9zcyBWUE4gYW5kIG5vbi1WUE4gbW9kZXMuDQo+ID4+DQo+ID4+IEZXSVcsIHRoZSAzR1BQIFMy
YiBpbnRlcmZhY2UgYWxsb3dzIGEgbW9iaWxlIG5vZGUgdG8gcGVyZm9ybSBoYW5kb3ZlcnMNCj4g
Pj4gZnJvbSAzR1BQIGFjY2VzcyAoUzUvUzgpIHRvIG5vbi0zR1BQIGFjY2VzcyAoUzJiKS4NCj4g
Pj4NCj4gPj4gVGhlcmUgYXJlIG90aGVyIGV4YW1wbGVzIG9mIE1vYmlsZSBWUE4gc29sdXRpb25z
IHRoYXQgYXJlIGRlcGxveWVkIGFuZCBhcmUNCj4gPj4gYmFzZWQgb24gTW9iaWxlIElQIHByb3Rv
Y29scy4gUkZDNTI2NSBpcyBvbmx5IG9uZSBleGFtcGxlLg0KPiA+DQo+ID4NCj4gPiBTcmkgLSBJ
IGFncmVlIHRoYXQgc3BlY2lmaWNhdGlvbnMgYWxsb3cgY2VydGFpbiBoYW5kb3ZlcnMuDQo+ID4N
Cj4gPiBJIGFtIG5vdCBzdXJlIHdoYXQgZG8geW91IG1lYW4gYnkgTW9iaWxlIFZQTj8gIE1vYmls
ZSBJUCB1c2luZyBhIE1ILUhBDQo+ID4gdHVubmVsIHdpdGggYSBWUE4tc3R5bGUgdHVubmVsPyAg
QSBWUE4gd2hpY2ggY2hhbmdlcyB0aGUgc291cmNlIGFkZHJlc3Mgd2l0aA0KPiA+IGEgbmV3IElL
RSBleGNoYW5nZT8gIFRoZXNlIGFyZSB0d28gZGlmZmVyZW50IHRoaW5ncy4NCj4gPg0KPiA+IElu
IG15IGV4cGVyaWVuY2UsIG9uY2UgSSBzdWNjZXNzZnVsbHkgc2V0IHVwIGEgVlBOIHR1bm5lbCBv
biBhIEhvc3QgY29tcHV0ZXINCj4gPiBpdHMgTW9iaWxlIElQIGltcGxlbWVudGF0aW9uIHdpbGwg
bm8gbG9uZ2VyIHdvcmssIGFuZCB2aWNlLXZlcnNhOyBhbHRob3VnaA0KPiA+IGVhY2ggb25lIGNh
biBzdXBwb3J0IG1vYmlsaXR5IG9rLCBpbmRlcGVuZGVudGx5LCB0byBhIGNlcnRhaW4gZXh0ZW50
Lg0KPiA+DQo+IA0KPiBBbGV4LCB0aGVyZSBpcyBzb21ldGhpbmcgY2FsbGVkIE1PQklLRSBSRkMg
NDYyMS4gSSB0aGluayBpdCBtb3Zlcw0KPiBJUFNlYyB0dW5uZWwgd2hlbiBNTidzIGFkZHJlc3Mg
Y2hhbmdlcy4gU28gdGhhdCBjb3VsZCBiZSB1c2VkIHdpdGgNCj4gVlBOLg0KDQpBRVJPIHdvdWxk
IGJlIGNvbXBhdGlibGUgd2l0aCBNT0JJS0UsIHllcy4gT3IsIGl0IGNvdWxkIGJlIHVzZWQgaW4N
CnBsYWNlIG9mIE1PQklLRS4gSWYgTU9CS0lFIHdlcmUgdXNlZCwgdGhlIEFFUk8gQ2xpZW50IHdv
dWxkIG5vdCBuZWVkDQp0byBpc3N1ZSBESENQdjYgUmViaW5kIHdoZW4gaXQgbW92ZXMsIGJ1dCBh
bGwgb3RoZXIgQUVSTyBmdW5jdGlvbnMNCndvdWxkIHN0aWxsIGJlIHVzZWQuIFRoaXMgaXMgaW1w
b3J0YW50IGVzcGVjaWFsbHkgd2hlbiBhbiBBRVJPDQpDbGllbnQgbW92ZXMgaXRzIFZQTiBlbmRw
b2ludCBmcm9tIGEgZmlyc3Qgc2VjdXJpdHkgZ2F0ZXdheSB0byBhDQpzZWNvbmQgc2VjdXJpdHkg
Z2F0ZXdheSwgZS5nLiwgaWYgaXQgZGlzY292ZXJzIHRoYXQgdGhlIHNlY29uZA0Kc2VjdXJpdHkg
Z2F0ZXdheSBpcyBjbG9zZXIgYW5kL29yIGNvdWxkIGdpdmUgYmV0dGVyIHBlcmZvcm1hbmNlLg0K
DQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tIA0KIA0KPiBSZWdhcmRz
LA0KPiANCj4gQmVoY2V0DQo+IA0KPiANCj4gPiBBbGV4DQo+ID4NCj4gPg0KPiA+Pg0KPiA+Pg0K
PiA+PiBSZWdhcmRzDQo+ID4+IFNyaQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+DQo+ID4N
Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+
IGRtbSBtYWlsaW5nIGxpc3QNCj4gPiBkbW1AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0K


From nobody Fri Sep 12 18:38:35 2014
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 0A0D21A01E0 for ; Fri, 12 Sep 2014 18:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 GNyjPA8gy14M for ; Fri, 12 Sep 2014 18:38:30 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A0F1A0199 for ; Fri, 12 Sep 2014 18:38:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=990; q=dns/txt; s=iport; t=1410572310; x=1411781910; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=bu0w3tT5MOtK/pphIOVAjeVaY8s5qRGMiQiXu6J61AY=; b=NyeTywBH0fP/zs2CCpEpeqlm3AMLnfSULIjBnWLoGo8rjZCx9+O650ji BnKozseDWDK0L9IKObRB+zvfOylJhSnoF79z9pNkHB9w2Occ1jEs6LEuH lZFNBU9wpV5RS1DeBHT3qiBvewtfJ/SfPK8LmmtvPJWvCztMJRpBMoCDu 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFABGfE1StJA2E/2dsb2JhbABfgw2BKgTQSAGBChZ4hAQCBDpRAQg2MREXAQ0CBAESGYgRAxG1bw2GdQEXjSCCNIRLAQSRTYkrghCPAYY+gW8WgVlsgUiBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,516,1406592000"; d="scan'208";a="354874150"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 13 Sep 2014 01:38:30 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8D1cT6X005561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Sep 2014 01:38:29 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 20:38:29 -0500
From: "Sri Gundavelli (sgundave)" 
To: Alexandru Petrescu , "Templin, Fred L" , "dmm@ietf.org" 
Thread-Topic: [DMM] "A Day in the Life of an Enterprise Mobile Device User"
Thread-Index: AQHPzvNrUyB6ZjbWjkuv0yAUfDvguQ==
Date: Sat, 13 Sep 2014 01:38:29 +0000
Message-ID: 
In-Reply-To: <5412BE8E.7020500@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.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <92270C995DAEBE4298B7E334495F9ACE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/GlfwyffPy-tpbXO5lsaUC1U4pxo
Subject: Re: [DMM] "A Day in the Life of an Enterprise Mobile Device User"
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, 13 Sep 2014 01:38:33 -0000

On 9/12/14 2:36 AM, "Alexandru Petrescu" 
wrote:

>Sri - I agree that specifications allow certain handovers.
>
>I am not sure what do you mean by Mobile VPN?  Mobile IP using a MH-HA
>tunnel with a VPN-style tunnel?  A VPN which changes the source address
>with a new IKE exchange?  These are two different things.
>
>In my experience, once I successfully set up a VPN tunnel on a Host
>computer its Mobile IP implementation will no longer work, and
>vice-versa; although each one can support mobility ok, independently, to
>a certain extent.

Alex,

No. Depends on how you tie the Mobile IP and IKE session. Sure, if you use
CoA for IKE/IPsec, your IPsec session is dead after each Mobile IP handoff.

Instead, use the HoA for IKE transaction; Mobile IP offers mobility to
HoA. IKE/IPsec session is an application using that HoA :)

The result is Mobile VPN :) It works, we had a product on Windows many
years back.



Sri=20


From nobody Fri Sep 12 19:02:21 2014
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 1303F1A0270 for ; Fri, 12 Sep 2014 19:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 PWUXRq0wjQZk for ; Fri, 12 Sep 2014 19:02:18 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C831A024F for ; Fri, 12 Sep 2014 19:02:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2265; q=dns/txt; s=iport; t=1410573738; x=1411783338; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/9lvg0Vkh5LVMe0kFn1nJdUYBuVsslGU+fGG3Ga4D0U=; b=GRO1LoBLAm7pilEsgq+i7HSU4J2e40Q3WXs6vde7ta4h5z2Jg0LvP8OE 1fLi9N0nyr4pWmVlAB1AbYyVFPMMVSf/kj69ala/PAltDbz/CQ5zG5If1 +Wdn+Bf0A/QUILWCDBvSmQJi5Icxlbw97IcnC7g6eCAvwh3oTrAeCxmBk A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAHekE1StJV2c/2dsb2JhbABfgw2BKgTQSAGBChZ4hAQCBDo/EgEINkIlAgQBDQUUB4gjvG0BF451WAeESwWRTYs7lT+BbxaBWWwBgQVCgQIBAQE
X-IronPort-AV: E=Sophos;i="5.04,516,1406592000"; d="scan'208";a="354844937"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 13 Sep 2014 02:02:17 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8D22H23023576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Sep 2014 02:02:17 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 21:02:17 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , Jouni Korhonen , "sarikaya@ieee.org" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHPzva+O8gLyB97CkycZoCemwu/YA==
Date: Sat, 13 Sep 2014 02:02:16 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D17467@XCH-BLV-504.nw.nos.boeing.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.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/vihfCaMDoSo2CJ5dT5-nls1MIg4
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 13 Sep 2014 02:02:20 -0000

Hi Fred,


On 9/12/14 8:17 AM, "Templin, Fred L"  wrote:

>>
>>Based on these points #3 and #9, can we conclude that we cannot apply
>>AERO
>>for DMM ? If not, how do we apply and deploy Aero for DMM networks ?
>
>I don't think so. Surely we can do proxy AERO, and surely iOS
>phones can do VPN. So, pick one or both of these alternatives
>and I think the concern is addressed?


If the latest releases of iOS has support for tunnel interface and route
management, I'll be happy to know the specifics. For a minute, lets go
with that assumption we can realize Aero client on iOS. That immediately
makes the solution relevant (assuming it supports other basic
capabilities) to a class of solutions that are client-based and not
network-based. As I said earlier, the MIP community has failed to realize
client eco-system and any proposals that are client-based have limited
value. Lets talk about RO for an IP flow between a host and an application
server in some SP's data center. The probability that the peer supports RO
capabilities defined by a protocol are close to zero. MIPv6 has RO in the
form of IPv6 Type-2 routing header, defined as part of baseline IPv6
specs, but still the MIP community almost gave up on client-based
solutions. This is one data point.

I understand, Aero can be extended to support a Proxy function. But, will
it not look exactly like Proxy Mobile IP ? I'm looking for fundamental
properties which are unique to Aero and that PMIP/MIPv6 lacks ?

Instead of the approach, "Aero may be extended to do it", what is that one
capability that Aero offers and that the current mobility protocols lack ?
One line of thinking could be to integrate such unique ideas, if any, to
protocols that are feature rich and were defined before, standardized,
integrated in SDO architectures and has a deployment base.

Aero uses DHCP/ND as a signaling interface, instead of dedicated signaling
interface, and uses tunnels to setup the overlay routing path. For RO, it
uses ICMP, where as MIP uses special messages HoTi/CoTi (please ask
Charlie why they chose those terms :)). Furthermore, it misses all the
features that the other protocols already can support.



Regards
Sri




From nobody Fri Sep 12 23:25:26 2014
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 3D7FD1A0472 for ; Fri, 12 Sep 2014 23:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 5T6fLieUNPjm for ; Fri, 12 Sep 2014 23:25:22 -0700 (PDT)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B301A046B for ; Fri, 12 Sep 2014 23:25:22 -0700 (PDT)
Received: by mail-qa0-f42.google.com with SMTP id j7so1778042qaq.29 for ; Fri, 12 Sep 2014 23:25:21 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UOiVA7NYUQyCd1okP8NNlp8Ff+H4FLcx0g4STa6axW8=; b=I8LV8TxQ5abZgCFIiUozW7SdM3gyflP7Rv2aF46ZKjyfOw0WnLdMy0NQu6sxzOrIzM +sPqp4f7W6UBxBvUwQBXC9fJuiyvKdeFCg7Bjd2KAfP8bfzPaikIhaHqiHkwvTe0/W1X 4FkyI/o9DWZ0F3XY8jbxNErfPGh5SV+Prh3Qe/sWrIzhU3YP1PVUMbyrErQ56ZiM8qRh kQjU+rGBRgc6e8Jwgr0OCejudOUX2g0uYODl7XN1RQ5eiKYmn4Ji/8SLYDwnrW9g0d93 QQ0+rVGj3LOktBcb6OrcZgkIqP/ATQtph215pyYuKGpp71rXlXxaQlFM5j1C3QEOsogK ljWA==
X-Received: by 10.224.103.65 with SMTP id j1mr19404574qao.17.1410589521706; Fri, 12 Sep 2014 23:25:21 -0700 (PDT)
Received: from [10.53.147.53] ([88.128.80.73]) by mx.google.com with ESMTPSA id k52sm4684808qge.42.2014.09.12.23.25.20 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 23:25:20 -0700 (PDT)
Message-ID: <5413E34F.4020302@gmail.com>
Date: Sat, 13 Sep 2014 09:25:19 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dmm@ietf.org
References: <54063B90.9020909@gmail.com>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/-RuLFl-cuoTuPMJZ5mmKpf12Kak
Cc: dmm-chairs@tools.ietf.org
Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaICBpbnRlcmltIGNhbGwgIzEgYW5kIHJlY2hh?= =?utf-8?q?ter_text?=
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, 13 Sep 2014 06:25:24 -0000

Folks,

There was no comments on the re-charter that would have caused any 
changes. Chairs will proceed with the current text and ship it forward.

- Jouni & Dapeng

9/5/2014 1:11 PM, Jouni kirjoitti:
>
> Folks,
>
> This mail start a one week period to comment and propose changes to the re-charter text. The call ends 12th Sep.
> All the material from the Interim call#1 including the latest re-charter text is available at:
> http://www.ietf.org/proceedings/interim/2014/09/02/dmm/proceedings.html
>
> If you have comments / corrections to propose, include the concrete change proposal with a justification, for example in a form:
>
> OLD:
>    Feb 2015 - Submit 'Forwarding path and signaling management' as a
>               working group document. To be Proposed Standard.
>
> NEW:
>    May 2019 - Submit 'Forwarding path and signaling management' as a
>               working group document. To be Proposed Standard.
>
> WHY:
>    I need to concentrate bettering my golf handicap for the next three
>    years, thus I have no time to contribute until early 2019.
>
>
> And of course the rest of the WG needs to agree (even for the simplest
> change I hope people acking it with 'ok' or alike oneliner).
>
>
>
>
> - Jouni & Dapeng
>
>
> On Sep 5, 2014, at 9:40 AM, Max wrote:
>
>> Folks,
>>
>> The meeting minutes is uploaded: http://www.ietf.org/proceedings/interim/2014/09/02/dmm/minutes/minutes-interim-2014-dmm-1
>>
>> --
>> Dapeng Liu
>>
>> 在 2014å¹´9月3æ—¥ 星期三，5:50，Jouni Korhonen 写é“：
>>
>>> Folks,
>>>
>>> Check the charter text we came up with during the interim call #1. The
>>> diffs are here:
>>> https://github.com/jounikor/dmm-re-charter/commit/4475c1c7aeac024171f6b669d330cfae98bdc283
>>>
>>> And the "clean" text is here:
>>> https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt
>>>
>>> Have a look at the text. If you agree with the content we'll start
>>> moving this forward.
>>>
>>> The minutes and stuff from the interim call will follow shortly.
>>>
>>>
>>> - Jouni & Dapeng
>>>
>>> _______________________________________________
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>>
>


From nobody Sat Sep 13 05:22:47 2014
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 5B1651A8860 for ; Sat, 13 Sep 2014 05:22:46 -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 uO_dgyPYsrWY for ; Sat, 13 Sep 2014 05:22:44 -0700 (PDT)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE751A8848 for ; Sat, 13 Sep 2014 05:22:44 -0700 (PDT)
Received: by mail-qg0-f43.google.com with SMTP id a108so1946846qge.2 for ; Sat, 13 Sep 2014 05:22:43 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K3UsCLjg7klgVJKBw4sf3NRFfrcL8K16XkPE2Whb8m4=; b=CFrGdBhXCX48N1uHzP41U/g9EcWk3V0ohAa901yMGZx0tnpo9/ksfWzqn4t6gvfnwN HxNxNv7/r7g4kOLjsJGbmu2ewOjW4XmEFnM2Fuc8KC+WK2jOuDuyzQU89Wp+8UekU0th YDBT0TAOyEtowrWDPiUp/gVdPi0aZBiKth3gRWQZhIOkmB5LovQ/4wGxDa/S/SGit8vI HuQjQVMxqZytJKWqbVsD6kAV/3V5ZoNl2LDwp7kG9rIMct8AuJB+V9RGDTX/t0RcEQif iZh2fxPpoH4RX70XEt/ds7lN4/Ub3v5PjXPOUv0NHOHdhOat7hCWmdJcIx40qCcpkwB4 kESg==
X-Received: by 10.224.67.65 with SMTP id q1mr21209345qai.89.1410610963851; Sat, 13 Sep 2014 05:22:43 -0700 (PDT)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id 75sm5127468qgg.25.2014.09.13.05.22.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Sep 2014 05:22:43 -0700 (PDT)
Message-ID: <54143711.2010008@gmail.com>
Date: Sat, 13 Sep 2014 15:22:41 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dmm@ietf.org" 
References: <54119C10.6020002@gmail.com>
In-Reply-To: <54119C10.6020002@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/eWrixo8eCMQSacauXd9y5G1Yu7w
Cc: Dapeng Liu 
Subject: Re: [DMM] DMM interim call #3 - doodle
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, 13 Sep 2014 12:22:46 -0000

Folks,

The poll is closed and the outcome was not that good. I'll open another 
poll soon with diffrent time and possibly dates.

- Jouni & Dapeng

9/11/2014 3:56 PM, Jouni Korhonen kirjoitti:
>
> Folks,
>
> For the call #3 express your preference by Friday 12th EOB PDT.
>
> http://doodle.com/kpwphfbtgmtsde3s
>
> - Jouni & Dapeng


From nobody Sat Sep 13 05:41:16 2014
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 4311F1A070C for ; Sat, 13 Sep 2014 05:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.538
X-Spam-Level: 
X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FORGED_REPLYTO=2.095, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SMF_FM_FORGED_REPLYTO=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 kKAd7PkHyPLh for ; Sat, 13 Sep 2014 05:39:21 -0700 (PDT)
Received: from worker1.doodle.com (worker1.doodle.com [188.92.145.81]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631661A8863 for ; Sat, 13 Sep 2014 05:39:21 -0700 (PDT)
Received: from worker1.doodle.com (localhost [127.0.0.1]) by worker1.doodle.com (Postfix) with ESMTP id CBE67104E196 for ; Sat, 13 Sep 2014 14:39:18 +0200 (CEST)
Date: Sat, 13 Sep 2014 14:39:18 +0200 (CEST)
From: "Jouni Korhonen (via Doodle)" 
To: 
Message-ID: <1708773899.1524299.1410611958832.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE.doodle@worker1>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1524298_8151380.1410611958831"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/iWrudCcOWHVEswEuGvhPQs3lm88
X-Mailman-Approved-At: Sat, 13 Sep 2014 05:41:11 -0700
Subject: [DMM] DMM interim 3
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Jouni Korhonen 
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Sep 2014 12:39:24 -0000

------=_Part_1524298_8151380.1410611958831
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi there,

Jouni Korhonen (jounikor@gmail.com) invites you to participate in the
Doodle poll "DMM interim 3".

Jouni Korhonen says:
DMM Interim call #3. Give your preferences by Tuesday 30th Sep.

Participate now
https://doodle.com/bg8yw8udk8vawxd8?tmail=3Dpoll_invitecontact_participant_=
invitation_with_message&tlink=3Dpollbtn

What is Doodle? Doodle is a web service that helps Jouni Korhonen to
find a suitable date for meeting with a group of people. Learn more
about how Doodle works.
(https://doodle.com/main.html?tlink=3DcheckOutLink&tmail=3Dpoll_inviteconta=
ct_participant_invitation_with_message)

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

You have received this e-mail because "Jouni Korhonen" has invited you
to participate in the Doodle poll "DMM interim 3."

----

Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

------=_Part_1524298_8151380.1410611958831
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=

    

    =09
Jouni Korhonen invites you =
to participate in the Doodle poll "DMM interim 3."

    =09

        =09
            =09
                =09

                    =09
                    =09=09
=09=09    =09=09=09=09=09=09=09
=09=09   =09=09=09=09=09
=09=09=09=09=09=09=09
=09=09=09=09=09=09=09=09
=09

=09=09=09=09=09=09=09
=09=09=09=09=09=09=09=09
=09

=09=09
=09=09=09
=09=09    =09
=09=09    
=09=09    
=09=09    =09
=09=09        
=09=09=09    
=09=09        
=09=09    
=09=09    
=09=09    =09
=09=09    
=09=09

=09=09        =09
=09=09      =09
=09=09=09    =09
=09=09=09    

=09		


=09=09
=09=09=09
=09=09=09=09
=09=09=09=09=09

=09=09=09=09=09=09

=09=09
=09=09=09
=09=09=09=09
=09=09=09=09=09
=09=09=09=09=09=09=09
=09=09=09=09=09=09=09=09
=09
=09=09=09=09=09=09=09
=09=09=09=09=09=09=09=09
=09
=09=09=09=09=09=09=09
=09=09=09=09=09=09=09=09
=09
=09=09=09=09=09=09=09
=09=09=09=09=09=09=09=09
=09
=09=09=09=09=09=09=09
=09=09=09=09=09=09=09=09
=09
=09
=09=09

=09=09=09=09=09=09

=09=09
=09=09
=09=09=09
=09=09=09=09
=09=09=09=09=09
=09=09=09=09
=09=09=09
=09=09

=09=09=09=09=09=09
"DMM interim=
 3".
=09=09=09=09=09=09

=09=09=09=09=09

=09=09
=09



=09=09
=09=09=09
=09=09=09=09
=09=09=09=09=09
=09=09=09=09
=09=09=09
=09=09

=09=09=09=09=09=09

=09=09=09=09=09=09=09Jouni Korhonen says:
=09=09=09=09=09=09

=09=09=09=09=09=09

=09=09=09=09=09=09=09DMM Interim call #3. Give your preferences by Tuesday =
30th Sep.
=09=09=09=09=09=09

=09=09=09=09=09
=20
=09		


=09=09
=09=09=09
=09=09=09=09
=09=09=09=09=09
=09=09=09=09
=09=09=09=09
=09=09=09=09=09
=09=09=09=09
=09=09=09=09
=09=09=09=09=09
=09=09=09=09
=09=09=09
=09=09
=


=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09
=09=09=09=09=09=09

=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09=09=09=09

=09=09=09=09=09=09=09=09Participate now
=09=09=09=09=09=09=09

=09=09=09=09=09
=


=09		


=09=09
=09=09=09
=09=09=09=09
=09=09=09=09=09
=09=09=09=09=09
=09=09=09=09
=09=09=09
=09=09

=09=09=09=09=09=09
=09=09=09=09=09
=09=09=09=09=09=09

                           =20
=09=09=09=09=09=09=09    What is Doodle? Doodle is a web service that helps Jouni Korhonen to find a suitable dat=
e for meeting with a group of people. Learn more about how Doodle works.

                           =20
=09=09=09=09=09=09

=09=09=09=09=09

=09		


=09=09
=09=09  =09
=09=09  =09=09
=09=09  =09
=09=09  =09
=09=09  =09
=09=09    =09
=09=09    
=09=09    
=09=09    =09
=09=09    
=09=09   =20
=09=09

=09=09        =09You have received this e-mail because "Jouni Korhonen=
" has invited you to participate in the Doodle poll "DMM interim =
3."
=09=09        

=09		


=09
=09=09
=09=09=09
=09=09=09=09
=09=09=09=09=09

=09=09=09=09=09=09
 Jouni Korhonen says:
> DMM Interim call #3. Give your preferences by Tuesday 30th Sep.
> Participate now 						=09
> =09
> What is Doodle? Doodle is a web service that helps Jouni Korhonen to =
find a suitable date for meeting with a group of people. Learn more =
about how Doodle works.
> You have received this e-mail because "Jouni Korhonen" has invited you =
to participate in the Doodle poll "DMM interim 3."
> Doodle AG, Werdstrasse 21, 8021 Z=FCrich
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Sat Sep 13 14:44:16 2014
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 6DF201A0032 for ; Sat, 13 Sep 2014 14:44:14 -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 aV5bC2qXQqCW for ; Sat, 13 Sep 2014 14:44:13 -0700 (PDT)
Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F881A0089 for ; Sat, 13 Sep 2014 14:44:12 -0700 (PDT)
Received: by mail-qc0-f180.google.com with SMTP id m20so1142199qcx.25 for ; Sat, 13 Sep 2014 14:44:12 -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=zy/Yv5qajodA8cUJv4/vUl5It7z2e4OYD6oPFNQ43oo=; b=blLHQlmOgzyfFyA8FS64BTZDxMA8vxTT417K+OuTohA+E5CJdQSNrPQvjVzL4P/1s2 HE2YmuBbyHuzzDe6e37zLoSc3Qs5G9WBF7ynLsAOlPh0/Y6v08D0hD6In2cx70agzXdZ Iu172/86wAxpsusVUIPYVHDjOqyDVqZrQ0zbm7pFkSHnZJuFzoW9GMPMmKxQZboEQxWd NBHXx1VCW27SQBabeTwAvH3nbqEcbTPW6l5SsTMYC9bE1qtJIagO16XbWP8lUP2eINm/ lp2OadSOlyAUJJyMniCo5SmNoRxxFdeC2RMdXvnM1uCC8mDBn533CXCzH+7KfPtJzaAa BvAA==
X-Received: by 10.224.64.201 with SMTP id f9mr25279064qai.64.1410644652227; Sat, 13 Sep 2014 14:44:12 -0700 (PDT)
Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id l10sm6080455qac.43.2014.09.13.14.44.11 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Sep 2014 14:44:11 -0700 (PDT)
Message-ID: <5414BAA9.6030207@gmail.com>
Date: Sun, 14 Sep 2014 00:44:09 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dmm@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Y-5FeTqiedwPc_mDIsLnpJyJ4Vc
Subject: [DMM] IETF#91 meeting getting closer
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, 13 Sep 2014 21:44:14 -0000

November is soon here. We are also supposed to have two interims before 
the IETF#91 meeting. For the face-to-face in November the current plan 
is to ask for one 2.5h meeting slot. That should be enough.

- Jouni & Dapeng


From nobody Mon Sep 15 08:14:39 2014
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 3834D1A037D for ; Mon, 15 Sep 2014 08:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.755
X-Spam-Level: 
X-Spam-Status: No, score=0.755 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, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, 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 OW2DHpOK6joI for ; Mon, 15 Sep 2014 08:14:34 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AEF91A037F for ; Mon, 15 Sep 2014 08:14:34 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id ge10so4690747lab.26 for ; Mon, 15 Sep 2014 08:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=date:from:to:message-id:subject:mime-version:content-type; bh=McQV7GdtPQyCLIerWps0lyvZ/bzhuE/qWvTpLbdZb8k=; b=W2bzE3Rzr677+k3j+6xUPKGv1Sm6oSBHRD4b8QzBRNPuO/7xs7QXhiuAsZIi0uhpHY mNRZ10MDQ8alIcMstBWrQWUF/ew0pAUN8odtElDDun1UBlhtSnKO6VSvzZX7rMtnVvfo 2zEQRi1i27slpmp49Lr6hGz9B/f4UWJhuFycSY25cQOsRgkcJn2SFZNpX/B5Myhxnsdc EaxLuAB2jMjbos2kHbGMDR4FPWRkg4wAIHRRcezL05btuV8jmWJjLKi/Gq2Vl8P5KdVL jm2+fQW3X6TK94cXYT05xN89uNfQTDuS93UKYTjYHLLMD3l8SgmS7cTkRu4BJLkXHpPg q9KA==
X-Received: by 10.152.43.99 with SMTP id v3mr27868993lal.13.1410794071268; Mon, 15 Sep 2014 08:14:31 -0700 (PDT)
Received: from [10.100.21.252] (62-50-228-234.client.stsn.net. [62.50.228.234]) by mx.google.com with ESMTPSA id r6sm4312041lbp.29.2014.09.15.08.14.29 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 15 Sep 2014 08:14:30 -0700 (PDT)
Date: Mon, 15 Sep 2014 23:18:16 +0800
From: Max 
To: "=?utf-8?Q?dmm=40ietf.org?=" 
Message-ID: <9A33654220D2489D8394B430CB529331@gmail.com>
X-Mailer: sparrow 1.6.3 (build 1173)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="54170338_515f007c_6043"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/gMDDtW1YzWsl8_JO8dUl7qP4ouc
Subject: [DMM] DMM interim 2
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, 15 Sep 2014 15:14:36 -0000

--54170338_515f007c_6043
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Folks, 

Bellow is the webex information for interim 2.

------------------------------------------------------- 
Meeting information
-------------------------------------------------------
Topic: DMM Interim
Date: Tuesday 16 September 2014
Time: 8:00, Northern Europe Summer Time (Helsinki, GMT+03:00) Meeting Number: 646 119 560 Meeting Password: dmm1911

------------------------------------------------------- 
To start or join the online meeting
-------------------------------------------------------
Go to
https://ietf.webex.com/ietf/j.php?MTID=mcde205ac1a64e90782a666e44e312d6a

------------------------------------------------------- 
Audio conference information
-------------------------------------------------------
Call-in toll number (US/Canada): 1-650-479-3208

Access code:646 119 560 

------------------------------------------------------- 
For assistance
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".
To add this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://ietf.webex.com/ietf/j.php?MTID=mb0a21914ed70392b9917c7ce3352d954

To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ietf.webex.com/ietf/systemdiagnosis.php. 

http://www.webex.com 

CCM:+16504793208x646119560# 

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation.


-- 
Dapeng Liu&Jouni


--54170338_515f007c_6043
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                

                    =46olks,
                

Bellow is the webex information=
 for interim 2.

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


Me=
eting information


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


To=
pic: DMM Interim


Da=
te: Tuesday 16 September 2014


Ti=
me: 8:00, Northern Europe Summer Time (Helsinki, GMT+03:00) Meeting Numbe=
r: 646 119 560 Meeting Password: dmm1911





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


To=
 start or join the online meeting


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


Go=
 to


http=
s://ietf.webex.com/ietf/j.php=3FMTID=3Dmcde205ac1a64e90782a666e44e312d6a<=
/span>





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


Au=
dio conference information


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


Ca=
ll-in toll number (US/Canada): 1-650-479-3208





Ac=
cess code:646 119 560





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


=46=
or assistance


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


1. Go to https://ietf.webex.com/i=
etf/mc


2.=
 On the left navigation bar, click =22Support=22.


To=
 add this meeting to your calendar program (for example Microsoft Outlook=
), click this link:


http=
s://ietf.webex.com/ietf/j.php=3FMTID=3Dmb0a21914ed70392b9917c7ce3352d954<=
/span>





To=
 check whether you have the appropriate players installed for UC=46 (Univ=
ersal Communications =46ormat) rich media files, go to https://ietf.webex.com/ie=
tf/systemdiagnosis.php.





http=
://www.webex.com





CC=
M:+16504793208x646119560=23





IM=
PORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the sessi=
on to be recorded. You should inform all meeting attendees prior to recor=
ding if you intend to record the meeting. Please note that any such recor=
dings may be subject to discovery in the event of litigation.


                

-- 
Dapeng Liu&am=
p;Jouni

            
--54170338_515f007c_6043--


From nobody Mon Sep 15 08:54:12 2014
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 E483A1A6FCA for ; Mon, 15 Sep 2014 08:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level: 
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 baEeL0BsKf7W for ; Mon, 15 Sep 2014 08:54:06 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573881A7005 for ; Mon, 15 Sep 2014 08:43:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s8FFhsxU025272; Mon, 15 Sep 2014 10:43:55 -0500
Received: from XCH-BLV-306.nw.nos.boeing.com (xch-blv-306.nw.nos.boeing.com [130.247.25.218]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8FFhl0M025193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Sep 2014 10:43:48 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-306.nw.nos.boeing.com ([169.254.6.59]) with mapi id 14.03.0181.006; Mon, 15 Sep 2014 08:43:47 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , Jouni Korhonen , "sarikaya@ieee.org" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHPzSY685cNtlvM5kaPQ9fwALiOyZv6soAwgAFMcQCAAC5BQIAAwuAA//+Qf6CAAKQQgIAAdvdwgAEs8ACAA4DnUA==
Date: Mon, 15 Sep 2014 15:43:46 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D19FD3@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D17467@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/7IhlVK3CH_0oS4whFrI6C6-FAr4
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 15 Sep 2014 15:54:11 -0000

Hi Sri,

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> Sent: Friday, September 12, 2014 7:02 PM
> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
> Cc: Dapeng Liu; dmm@ietf.org
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>=20
> Hi Fred,
>=20
>=20
> On 9/12/14 8:17 AM, "Templin, Fred L"  wrote:
>=20
> >>
> >>Based on these points #3 and #9, can we conclude that we cannot apply
> >>AERO
> >>for DMM ? If not, how do we apply and deploy Aero for DMM networks ?
> >
> >I don't think so. Surely we can do proxy AERO, and surely iOS
> >phones can do VPN. So, pick one or both of these alternatives
> >and I think the concern is addressed?
>=20
>=20
> If the latest releases of iOS has support for tunnel interface and route
> management, I'll be happy to know the specifics. For a minute, lets go
> with that assumption we can realize Aero client on iOS.

iOS supports the TUN half of the TUN/TAP interface. OpenVPN uses
the TUN interface, and runs on iOS. AERO assumes OpenVPN as its
target integration platform, and requires no kernel changes nor
any kernel routing table nor neighbor cache manipulations. AERO
can therefore go anywhere OpenVPN can go, including iOS.

> That immediately
> makes the solution relevant (assuming it supports other basic
> capabilities) to a class of solutions that are client-based and not
> network-based.

My "day in the life" thread shows a use case for a client-based
solution.

> As I said earlier, the MIP community has failed to realize
> client eco-system and any proposals that are client-based have limited
> value.

Client-based solutions are necessary for the enterprise mobility
use case, as expressed in "day in the life" as well as:

https://datatracker.ietf.org/doc/draft-templin-aeroent/

> Lets talk about RO for an IP flow between a host and an application
> server in some SP's data center.

AERO supports RO for two peers that both participate in the same
AERO service domain. It is not for peers that participate in
different AERO service domains, nor when one peer is AERO and
the other is non-AERO.

> The probability that the peer supports RO
> capabilities defined by a protocol are close to zero. MIPv6 has RO in the
> form of IPv6 Type-2 routing header, defined as part of baseline IPv6

AERO requires no kernel changes nor any special IPv6 headers.

> specs, but still the MIP community almost gave up on client-based
> solutions. This is one data point.

AERO route optimization is different. AERO route optimization
manipulates the neighbor cache (usually an application-based
neighbor cache and not a kernel-resident one) based on IPv6 ND
messaging. Client AERO addresses are used to key the neighbor
cache entries.

> I understand, Aero can be extended to support a Proxy function. But, will
> it not look exactly like Proxy Mobile IP ? I'm looking for fundamental
> properties which are unique to Aero and that PMIP/MIPv6 lacks ?

The AERO proxy messaging would be based on DHCPv6 request/release.
I will put this in the next draft version since, as you said, the
framework is similar to PMIP.

In the AERO model, the AERO Client is analogous to the PMIP MAG and
the AERO Server is analogous to the PMIP LMA. However, AERO uses an
NBMA tunnel virtual link model that connects all Client and Servers
instead of point-to-point tunnels. It also uses neighbor cache
entries based on the Client's AERO address(es) instead of explicit
tunnel state. Most importantly, it does not matter which Server the
Client associates because the mobile node's home network prefixes
are not bound to the Server -they are bound to AERO Relays instead.

> Instead of the approach, "Aero may be extended to do it", what is that on=
e
> capability that Aero offers and that the current mobility protocols lack =
?

AERO can be applied at multiple levels, both as a network-based proxy
system and as a Client-based end system. Consider an AERO Client that
is based in a home enterprise network and is currently using its 4G
interface. The Client would use one instance of AERO to coordinate
with its home network, while the 4G network would use its own
instance of AERO to provide the Client with network-based mobility
management services within the cellular provider network. AERO can
therefore be applied recursively.

Consider also a "nested NEMO" situation in which a first mobile
router provides an access link to a second mobile router, the
second mobile router provides an access link to a third mobile
router, the third mobile router ... etc. In such a scenario,
a separate AERO instance could be applied at each level.

There is still more (including distributed mobility management,
route optimization, etc.) that AERO handles easily where the other
approaches may not handle so easily.

> One line of thinking could be to integrate such unique ideas, if any, to
> protocols that are feature rich and were defined before, standardized,
> integrated in SDO architectures and has a deployment base.

To name one thing, the tunnel virtual link model is a point of
departure and I think an area where AERO provides a better model
especially for handling route optimization and distributed
mobility management.
=20
> Aero uses DHCP/ND as a signaling interface, instead of dedicated signalin=
g
> interface, and uses tunnels to setup the overlay routing path. For RO, it
> uses ICMP, where as MIP uses special messages HoTi/CoTi (please ask
> Charlie why they chose those terms :)).

OK.

> Furthermore, it misses all the
> features that the other protocols already can support.

You lost me there. What features? And could they not be used on
AERO the same as they are used with the other protocols?


Thanks - Fred
fred.l.templin@boeing.com

> Regards
> Sri
>=20
>=20


From nobody Mon Sep 15 15:32:41 2014
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 7A8C61A8785 for ; Mon, 15 Sep 2014 15:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 RN2ZmnINdHIo for ; Mon, 15 Sep 2014 15:32:33 -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 92FFA1A87E9 for ; Mon, 15 Sep 2014 15:32:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7412; q=dns/txt; s=iport; t=1410820350; x=1412029950; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=47jQgFTiFLdkegRUpo70zHswBtr/LsobCgghYcaHi7k=; b=d/IqWPqsCgl7MR+rbeqBtjGI00yQbeTtVmzTQWjhW0Wu/sVt4kwkg/lh Pnx6ApBk2zipBg3PowNkvr5YNUdnZV3AXJ1LpE82WIW7GZQ9C1i4/QSKj +4OJNIxAhQ5AIel9j5efJagUr6eJlK+Yv8IF9+DoI9455ZzdA1FB5xFRH Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AikFADhoF1StJA2L/2dsb2JhbABggw1TVwTKcodOAYEbFniEAwEBAQMBOj8FBwYBCBEEAQEBHgk5FAkIAgQBDQUUBQKIGwgNuzIBF451LSsHBoRFBY83ghaEN4cEgV+TYIFvFoFZbAGBBUKBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,531,1406592000"; d="scan'208";a="78201643"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP; 15 Sep 2014 22:32:29 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8FMWTxL029373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Sep 2014 22:32:29 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 15 Sep 2014 17:32:29 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , Jouni Korhonen , "sarikaya@ieee.org" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHP0TTuSWFgq92e1kOwuKoLvtCdeA==
Date: Mon, 15 Sep 2014 22:32:28 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D19FD3@XCH-BLV-504.nw.nos.boeing.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.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/lmzNqBGVAKd3an-th8E6u-qVVXc
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 15 Sep 2014 22:32:39 -0000

Hi Fred,

Thanks for your response.

> To name one thing, the tunnel virtual link model is a point of
departure and I think an area where AERO provides a better model
especially for handling route optimization and distributed
mobility management.


Lets focus on the Route Optimization. If you can share some views on how
the above model is better compared to the below standardized approaches,
it will really help.

To your comment on feature gaps, I will try to compile a list and send it
out. I also owe you a response on the thread related to Sataru-san's draft.



In MIP architectures, we have Route optimization support in two modes:

1.) Client-based=20

- Signaling is based on MIPv6; (http://tools.ietf.org/html/rfc6275#page-25
)
- User-plane RO management based on Type-2 Routing
header;(http://tools.ietf.org/html/rfc6275#page-55)
- Scope is global
- Requires Mobile IPv6 software functionality



2.) Network-based

- Signaling is based on PMIPv6; (http://tools.ietf.org/html/rfc6705#page-8)
- User plane is based on direct tunneling
- Scope is localized PMIP domain
- Works with any mobile node with no additional software capabilities

=20
Regards
Sri








On 9/15/14 8:43 AM, "Templin, Fred L"  wrote:

>Hi Sri,
>
>> -----Original Message-----
>> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>> Sent: Friday, September 12, 2014 7:02 PM
>> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
>> Cc: Dapeng Liu; dmm@ietf.org
>> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>>=20
>> Hi Fred,
>>=20
>>=20
>> On 9/12/14 8:17 AM, "Templin, Fred L"  wrote:
>>=20
>> >>
>> >>Based on these points #3 and #9, can we conclude that we cannot apply
>> >>AERO
>> >>for DMM ? If not, how do we apply and deploy Aero for DMM networks ?
>> >
>> >I don't think so. Surely we can do proxy AERO, and surely iOS
>> >phones can do VPN. So, pick one or both of these alternatives
>> >and I think the concern is addressed?
>>=20
>>=20
>> If the latest releases of iOS has support for tunnel interface and route
>> management, I'll be happy to know the specifics. For a minute, lets go
>> with that assumption we can realize Aero client on iOS.
>
>iOS supports the TUN half of the TUN/TAP interface. OpenVPN uses
>the TUN interface, and runs on iOS. AERO assumes OpenVPN as its
>target integration platform, and requires no kernel changes nor
>any kernel routing table nor neighbor cache manipulations. AERO
>can therefore go anywhere OpenVPN can go, including iOS.
>
>> That immediately
>> makes the solution relevant (assuming it supports other basic
>> capabilities) to a class of solutions that are client-based and not
>> network-based.
>
>My "day in the life" thread shows a use case for a client-based
>solution.
>
>> As I said earlier, the MIP community has failed to realize
>> client eco-system and any proposals that are client-based have limited
>> value.
>
>Client-based solutions are necessary for the enterprise mobility
>use case, as expressed in "day in the life" as well as:
>
>https://datatracker.ietf.org/doc/draft-templin-aeroent/
>
>> Lets talk about RO for an IP flow between a host and an application
>> server in some SP's data center.
>
>AERO supports RO for two peers that both participate in the same
>AERO service domain. It is not for peers that participate in
>different AERO service domains, nor when one peer is AERO and
>the other is non-AERO.
>
>> The probability that the peer supports RO
>> capabilities defined by a protocol are close to zero. MIPv6 has RO in
>>the
>> form of IPv6 Type-2 routing header, defined as part of baseline IPv6
>
>AERO requires no kernel changes nor any special IPv6 headers.
>
>> specs, but still the MIP community almost gave up on client-based
>> solutions. This is one data point.
>
>AERO route optimization is different. AERO route optimization
>manipulates the neighbor cache (usually an application-based
>neighbor cache and not a kernel-resident one) based on IPv6 ND
>messaging. Client AERO addresses are used to key the neighbor
>cache entries.
>
>> I understand, Aero can be extended to support a Proxy function. But,
>>will
>> it not look exactly like Proxy Mobile IP ? I'm looking for fundamental
>> properties which are unique to Aero and that PMIP/MIPv6 lacks ?
>
>The AERO proxy messaging would be based on DHCPv6 request/release.
>I will put this in the next draft version since, as you said, the
>framework is similar to PMIP.
>
>In the AERO model, the AERO Client is analogous to the PMIP MAG and
>the AERO Server is analogous to the PMIP LMA. However, AERO uses an
>NBMA tunnel virtual link model that connects all Client and Servers
>instead of point-to-point tunnels. It also uses neighbor cache
>entries based on the Client's AERO address(es) instead of explicit
>tunnel state. Most importantly, it does not matter which Server the
>Client associates because the mobile node's home network prefixes
>are not bound to the Server -they are bound to AERO Relays instead.
>
>> Instead of the approach, "Aero may be extended to do it", what is that
>>one
>> capability that Aero offers and that the current mobility protocols
>>lack ?
>
>AERO can be applied at multiple levels, both as a network-based proxy
>system and as a Client-based end system. Consider an AERO Client that
>is based in a home enterprise network and is currently using its 4G
>interface. The Client would use one instance of AERO to coordinate
>with its home network, while the 4G network would use its own
>instance of AERO to provide the Client with network-based mobility
>management services within the cellular provider network. AERO can
>therefore be applied recursively.
>
>Consider also a "nested NEMO" situation in which a first mobile
>router provides an access link to a second mobile router, the
>second mobile router provides an access link to a third mobile
>router, the third mobile router ... etc. In such a scenario,
>a separate AERO instance could be applied at each level.
>
>There is still more (including distributed mobility management,
>route optimization, etc.) that AERO handles easily where the other
>approaches may not handle so easily.
>
>> One line of thinking could be to integrate such unique ideas, if any, to
>> protocols that are feature rich and were defined before, standardized,
>> integrated in SDO architectures and has a deployment base.
>
>To name one thing, the tunnel virtual link model is a point of
>departure and I think an area where AERO provides a better model
>especially for handling route optimization and distributed
>mobility management.
>=20
>> Aero uses DHCP/ND as a signaling interface, instead of dedicated
>>signaling
>> interface, and uses tunnels to setup the overlay routing path. For RO,
>>it
>> uses ICMP, where as MIP uses special messages HoTi/CoTi (please ask
>> Charlie why they chose those terms :)).
>
>OK.
>
>> Furthermore, it misses all the
>> features that the other protocols already can support.
>
>You lost me there. What features? And could they not be used on
>AERO the same as they are used with the other protocols?
>
>
>Thanks - Fred
>fred.l.templin@boeing.com
>
>> Regards
>> Sri
>>=20
>>=20
>


From nobody Mon Sep 15 16:02:25 2014
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 3457A1A87F1 for ; Mon, 15 Sep 2014 16:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.853
X-Spam-Level: 
X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_37=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 CPhNvqTGPyMj for ; Mon, 15 Sep 2014 16:02:19 -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 B79501A8785 for ; Mon, 15 Sep 2014 16:02:19 -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 s8FN2JT7019639; Mon, 15 Sep 2014 16:02:19 -0700
Received: from XCH-BLV-401.nw.nos.boeing.com (xch-blv-401.nw.nos.boeing.com [130.247.25.18]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8FN2B0f019613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Sep 2014 16:02:11 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-401.nw.nos.boeing.com ([169.254.1.253]) with mapi id 14.03.0181.006; Mon, 15 Sep 2014 16:02:11 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , Jouni Korhonen , "sarikaya@ieee.org" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHPzSY685cNtlvM5kaPQ9fwALiOyZv6soAwgAFMcQCAAC5BQIAAwuAA//+Qf6CAAKQQgIAAdvdwgAEs8ACAA4DnUIAA+3kA//+LhBA=
Date: Mon, 15 Sep 2014 23:02:10 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D1ABF8@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D19FD3@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/SX9LF7q2EpxGjd-jgLbr5HeD3-A
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 15 Sep 2014 23:02:22 -0000

Hi Sri,

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> Sent: Monday, September 15, 2014 3:32 PM
> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
> Cc: Dapeng Liu; dmm@ietf.org
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>=20
> Hi Fred,
>=20
> Thanks for your response.
>=20
> > To name one thing, the tunnel virtual link model is a point of
> departure and I think an area where AERO provides a better model
> especially for handling route optimization and distributed
> mobility management.
>=20
>=20
> Lets focus on the Route Optimization. If you can share some views on how
> the above model is better compared to the below standardized approaches,
> it will really help.
>=20
> To your comment on feature gaps, I will try to compile a list and send it
> out. I also owe you a response on the thread related to Sataru-san's draf=
t.
>=20
>=20
>=20
> In MIP architectures, we have Route optimization support in two modes:
>=20
> 1.) Client-based
>=20
> - Signaling is based on MIPv6; (http://tools.ietf.org/html/rfc6275#page-2=
5
> )
> - User-plane RO management based on Type-2 Routing
> header;(http://tools.ietf.org/html/rfc6275#page-55)
> - Scope is global
> - Requires Mobile IPv6 software functionality

AERO route optimization is quite different than this. AERO route
optimization is based on a chain-of-trust whereby the RO requests
and replys always come from the Client's trusted Server instead
of an untrusted node. AERO RO is unidirectional - to set up a
bidirectional RO requires two unidirectional ROs. These can
happen simultaneously or separately, and in some cases it may
even be preferable to have only one of the two directions
optimized.

In the process of setting up the RO, the Clients also come to know
the permissible encapsulation IP address or addresses for the
encapsulated address. So, the RO also provides a simple data
origin authentication capability.=20
=20
> 2.) Network-based
>=20
> - Signaling is based on PMIPv6; (http://tools.ietf.org/html/rfc6705#page-=
8)
> - User plane is based on direct tunneling
> - Scope is localized PMIP domain
> - Works with any mobile node with no additional software capabilities

This looks very close to the way AERO handles RO in the network
based case. In this case, the AERO Client is analogous to the=20
PMIPv6 MAG, and the RO can go MN1<->Client1<->Client2<->MN2.

One of the key differences again is that the AERO NBMA virtual
link does not require any explicit tunnel configurations. So,
tunneling between Client1<->Client2 is guided by neighbor cache
information on the NBMA link.

Thanks - Fred
fred.l.templin@boeing.com

> Regards
> Sri
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On 9/15/14 8:43 AM, "Templin, Fred L"  wrote:
>=20
> >Hi Sri,
> >
> >> -----Original Message-----
> >> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> >> Sent: Friday, September 12, 2014 7:02 PM
> >> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
> >> Cc: Dapeng Liu; dmm@ietf.org
> >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> >>
> >> Hi Fred,
> >>
> >>
> >> On 9/12/14 8:17 AM, "Templin, Fred L"  wrot=
e:
> >>
> >> >>
> >> >>Based on these points #3 and #9, can we conclude that we cannot appl=
y
> >> >>AERO
> >> >>for DMM ? If not, how do we apply and deploy Aero for DMM networks ?
> >> >
> >> >I don't think so. Surely we can do proxy AERO, and surely iOS
> >> >phones can do VPN. So, pick one or both of these alternatives
> >> >and I think the concern is addressed?
> >>
> >>
> >> If the latest releases of iOS has support for tunnel interface and rou=
te
> >> management, I'll be happy to know the specifics. For a minute, lets go
> >> with that assumption we can realize Aero client on iOS.
> >
> >iOS supports the TUN half of the TUN/TAP interface. OpenVPN uses
> >the TUN interface, and runs on iOS. AERO assumes OpenVPN as its
> >target integration platform, and requires no kernel changes nor
> >any kernel routing table nor neighbor cache manipulations. AERO
> >can therefore go anywhere OpenVPN can go, including iOS.
> >
> >> That immediately
> >> makes the solution relevant (assuming it supports other basic
> >> capabilities) to a class of solutions that are client-based and not
> >> network-based.
> >
> >My "day in the life" thread shows a use case for a client-based
> >solution.
> >
> >> As I said earlier, the MIP community has failed to realize
> >> client eco-system and any proposals that are client-based have limited
> >> value.
> >
> >Client-based solutions are necessary for the enterprise mobility
> >use case, as expressed in "day in the life" as well as:
> >
> >https://datatracker.ietf.org/doc/draft-templin-aeroent/
> >
> >> Lets talk about RO for an IP flow between a host and an application
> >> server in some SP's data center.
> >
> >AERO supports RO for two peers that both participate in the same
> >AERO service domain. It is not for peers that participate in
> >different AERO service domains, nor when one peer is AERO and
> >the other is non-AERO.
> >
> >> The probability that the peer supports RO
> >> capabilities defined by a protocol are close to zero. MIPv6 has RO in
> >>the
> >> form of IPv6 Type-2 routing header, defined as part of baseline IPv6
> >
> >AERO requires no kernel changes nor any special IPv6 headers.
> >
> >> specs, but still the MIP community almost gave up on client-based
> >> solutions. This is one data point.
> >
> >AERO route optimization is different. AERO route optimization
> >manipulates the neighbor cache (usually an application-based
> >neighbor cache and not a kernel-resident one) based on IPv6 ND
> >messaging. Client AERO addresses are used to key the neighbor
> >cache entries.
> >
> >> I understand, Aero can be extended to support a Proxy function. But,
> >>will
> >> it not look exactly like Proxy Mobile IP ? I'm looking for fundamental
> >> properties which are unique to Aero and that PMIP/MIPv6 lacks ?
> >
> >The AERO proxy messaging would be based on DHCPv6 request/release.
> >I will put this in the next draft version since, as you said, the
> >framework is similar to PMIP.
> >
> >In the AERO model, the AERO Client is analogous to the PMIP MAG and
> >the AERO Server is analogous to the PMIP LMA. However, AERO uses an
> >NBMA tunnel virtual link model that connects all Client and Servers
> >instead of point-to-point tunnels. It also uses neighbor cache
> >entries based on the Client's AERO address(es) instead of explicit
> >tunnel state. Most importantly, it does not matter which Server the
> >Client associates because the mobile node's home network prefixes
> >are not bound to the Server -they are bound to AERO Relays instead.
> >
> >> Instead of the approach, "Aero may be extended to do it", what is that
> >>one
> >> capability that Aero offers and that the current mobility protocols
> >>lack ?
> >
> >AERO can be applied at multiple levels, both as a network-based proxy
> >system and as a Client-based end system. Consider an AERO Client that
> >is based in a home enterprise network and is currently using its 4G
> >interface. The Client would use one instance of AERO to coordinate
> >with its home network, while the 4G network would use its own
> >instance of AERO to provide the Client with network-based mobility
> >management services within the cellular provider network. AERO can
> >therefore be applied recursively.
> >
> >Consider also a "nested NEMO" situation in which a first mobile
> >router provides an access link to a second mobile router, the
> >second mobile router provides an access link to a third mobile
> >router, the third mobile router ... etc. In such a scenario,
> >a separate AERO instance could be applied at each level.
> >
> >There is still more (including distributed mobility management,
> >route optimization, etc.) that AERO handles easily where the other
> >approaches may not handle so easily.
> >
> >> One line of thinking could be to integrate such unique ideas, if any, =
to
> >> protocols that are feature rich and were defined before, standardized,
> >> integrated in SDO architectures and has a deployment base.
> >
> >To name one thing, the tunnel virtual link model is a point of
> >departure and I think an area where AERO provides a better model
> >especially for handling route optimization and distributed
> >mobility management.
> >
> >> Aero uses DHCP/ND as a signaling interface, instead of dedicated
> >>signaling
> >> interface, and uses tunnels to setup the overlay routing path. For RO,
> >>it
> >> uses ICMP, where as MIP uses special messages HoTi/CoTi (please ask
> >> Charlie why they chose those terms :)).
> >
> >OK.
> >
> >> Furthermore, it misses all the
> >> features that the other protocols already can support.
> >
> >You lost me there. What features? And could they not be used on
> >AERO the same as they are used with the other protocols?
> >
> >
> >Thanks - Fred
> >fred.l.templin@boeing.com
> >
> >> Regards
> >> Sri
> >>
> >>
> >


From nobody Tue Sep 16 02:07:19 2014
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 586531A016F for ; Tue, 16 Sep 2014 02:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.553
X-Spam-Level: 
X-Spam-Status: No, score=-8.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 Z1-xBOpVVCPj for ; Tue, 16 Sep 2014 02:07:16 -0700 (PDT)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 718BF1A02EB for ; Tue, 16 Sep 2014 02:07:14 -0700 (PDT)
Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 16 Sep 2014 02:01:03 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.04,533,1406617200"; d="scan'208";a="573738425"
Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga001.jf.intel.com with ESMTP; 16 Sep 2014 02:07:12 -0700
Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Sep 2014 02:07:11 -0700
Received: from hasmsx108.ger.corp.intel.com (10.184.198.18) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Sep 2014 02:07:03 -0700
Received: from hasmsx106.ger.corp.intel.com ([169.254.2.253]) by hasmsx108.ger.corp.intel.com ([10.184.198.18]) with mapi id 14.03.0195.001; Tue, 16 Sep 2014 12:07:01 +0300
From: "Moses, Danny" 
To: "dmm@ietf.org" 
Thread-Topic: [DMM] APIs
Thread-Index: AQHPx0jGItcAa/Geqke6iVoM0zFpQ5wDin5w
Date: Tue, 16 Sep 2014 09:07:00 +0000
Message-ID: 
References: <57645B37-C2CB-404D-9F38-4F596ADB2488@yegin.org>
In-Reply-To: <57645B37-C2CB-404D-9F38-4F596ADB2488@yegin.org>
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="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/0GcC5gzCr8LE-AY7AzOYlr4zXWw
Subject: Re: [DMM] APIs
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, 16 Sep 2014 09:07:17 -0000

I agree.

In the past, applications were quite indifferent to the platform they are e=
xecuting on and were very limited in the controlling how their generated da=
ta is transmitted (or received). Today, applications need to be much more a=
ware and 'behave' appropriately in various aspects like: Power management, =
cost saving (amount of bytes transfer over an expensive cellular connection=
) and even mobility aspects.

In order to control (and monitor) communication aspects, applications requi=
re APIs. I also believe (and hope) that we can address these needs through =
Socket enhancements.

	/Danny

>From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
>Sent: Wednesday, September 03, 2014 10:29
>To: dmm@ietf.org
>Subject: [DMM] APIs
>
>Folks,
>
>There was discussion about necessity of APIs for DMM yesterday.
>Let's continue that discussion here.
>
>It is true that IETF's primary focus is "protocol design".
>But when it's necessary, IETF also defines APIs.
>See, IPv6 basic socket API, for example.
>And, as a very relevant item, see RFC 5014, source address selection API.
>
>In RFC 5014, there's even consideration to "mobility", in terms of apps se=
lecting home address vs care-of address as their source address.
>
>I think by now it's clear to everyone that we can no longer treat all IP f=
lows equally when it comes to providing IP mobility treatment to them.
>This is already recognized in the charter.
>
>The way to take apps' mobility need into account is to give them an API. R=
FC 5014 already made an attempt at that, but fell short. Now that we have a=
 better >understanding of the issues, we should extend that API.
>
>Once we define that API, other APIs (OS specific ones that are not under t=
he control of IETF) can follow the same path.
>
>Discussion welcome.
>
>Alper
>






_______________________________________________
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 Tue Sep 16 16:46:25 2014
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 BB6561A01F7 for ; Tue, 16 Sep 2014 16:44: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 YEfl_0Ea-3FD for ; Tue, 16 Sep 2014 16:44:50 -0700 (PDT)
Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516B21A004D for ; Tue, 16 Sep 2014 16:44:50 -0700 (PDT)
Received: by mail-qc0-f172.google.com with SMTP id i17so1013903qcy.3 for ; Tue, 16 Sep 2014 16:44: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 :content-type:content-transfer-encoding; bh=cTc2uq00jrj0VH7MkBpX0nqI0CgoXM48TkYSDM3bKIE=; b=wphKmZEBoTzFllVvC/w2RKxGyI7/QFJCtdUjdEqKXt0vOG0sKBlTwiy2G3TBdARueB 8+3veoDDtAc7fWqiVNLP+xshjXXQ2JB6RqGGGOP4UINJZsrr07KA+c9/lf7qrfoRy0ou g0xaqTpfEImXv8cZWCh6IRfMh+E8e+tNqLIjZ35LR7DNQFqF24QAreCk9IWgAkriZmKJ KrUdA9GMF8lHrhY5S26ebBqjI4UAMehyemEXC0oKlkggY1lBNbIxoDspyINp8Fd7CB5H LzzOuCWSZBHOaZXyxgGorfhIncwmnsk+5tyk/1T2aoUxUs38UH8qafZEXnDhyZz465in CkHA==
X-Received: by 10.140.98.166 with SMTP id o35mr11108704qge.21.1410911089502; Tue, 16 Sep 2014 16:44:49 -0700 (PDT)
Received: from [172.20.7.77] ([183.62.128.251]) by mx.google.com with ESMTPSA id i1sm13067556qaz.28.2014.09.16.16.44.46 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Sep 2014 16:44:48 -0700 (PDT)
Message-ID: <5418CB69.9090907@gmail.com>
Date: Wed, 17 Sep 2014 02:44:41 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dmm@ietf.org" , jouni.nospam@gmail.com,  Dapeng Liu 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/P68azmz-ym8LSCiqDD3fEdVJnQI
X-Mailman-Approved-At: Tue, 16 Sep 2014 16:46:15 -0700
Subject: [DMM] DMM Interim call #3
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, 16 Sep 2014 23:44:51 -0000

Folks,

The winner for the next interim call is:
	Tuesday, October 7, 2014 5:00 PM (Helsinki time)

- JOuni & Dapeng


From nobody Wed Sep 17 08:29:36 2014
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 5E0BB1A0347; Wed, 17 Sep 2014 08:29:34 -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 HoLF7FLk3fPU; Wed, 17 Sep 2014 08:29:32 -0700 (PDT)
Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E2B1A0194; Wed, 17 Sep 2014 08:29:32 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id i8so2326998qcq.18 for ; Wed, 17 Sep 2014 08:29:31 -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:cc:subject :content-type; bh=zF5dUIxJHARrwiOEiwqbMBYdiSWh7x04b28xVgdolX0=; b=rnnRjPfNtNgR8K0JdQywNMqnmWMJUscX4vqKvMihopS9JgQe5MNaikvympBYPHp6+i lTg0GUz6mKXHjUt6Ijuv3mnQ1TEyxxOpYNRHI9PBj4s0avRKqQ+uupFtL99uo9kwRw2P MCO+hkiBzT0coUquy5Mqy/UJG4nmCEVRCFzsSgfQ1U9UPVaCtNLl6qv6PEON/dw+geXH R8bEpcr3jmm4iAkVJK2zijpZXm5mINwt6qa+gwWmDGKMRP5zuXC2o/OYxKuVLAenMVxQ iNiQEeoE/8CNp9HqskHvBICfL4FipLCVOfDkZtjYPFquwXU8mL2vDgkKXqRvahA55U9H fJQA==
X-Received: by 10.140.95.234 with SMTP id i97mr930534qge.93.1410967771390; Wed, 17 Sep 2014 08:29:31 -0700 (PDT)
Received: from [172.20.7.77] ([183.62.128.251]) by mx.google.com with ESMTPSA id f46sm14378031qgd.21.2014.09.17.08.29.27 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Sep 2014 08:29:30 -0700 (PDT)
Message-ID: <5419A8D4.30804@gmail.com>
Date: Wed, 17 Sep 2014 18:29:24 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: iesg-secretary@ietf.org, "dmm@ietf.org" 
Content-Type: multipart/mixed; boundary="------------000202050702030006060005"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/fUcvWkusQ_CtDGijMxYePOLqdvM
Cc: "dmm-chairs@tools.ietf.org" 
Subject: [DMM] DMM interim conference call #3
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, 17 Sep 2014 15:29:34 -0000

This is a multi-part message in MIME format.
--------------000202050702030006060005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The DMM WG will hold its third interim conference calls during October:
	7th October, 5PM (Helsinki time, EEST)

The conference call lasts max 2 hours. The detailed agenda will be
available later but it is around progressing the new work we are
pursuing.

--------------------------------------------
Webex details
--------------------------------------------

Join WebEx meeting
https://ietf.webex.com/ietf/j.php?MTID=mf5c5e188b03e86378ddf2d9a19a160d4

Meeting number: 	317 354 563
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: 317 354 563
Toll-free calling restrictions
http://www.webex.com/pdf/tollfree_restrictions.pdf

Can't join the meeting? Contact support.
https://ietf.webex.com/ietf/mc

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

--------------000202050702030006060005
Content-Type: text/calendar;
 name="WebEx_Meeting.ics"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="WebEx_Meeting.ics"

BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Northern Europe Time
BEGIN:STANDARD
DTSTART:20121001T030000
RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:Standard Time
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20120301T020000
RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:Daylight Savings Time
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;CN=3D"Dime Working Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAI=
LTO:dime-chairs@tools.ietf.org
ORGANIZER;CN=3D"Dime Working Group":MAILTO:dime-chairs@tools.ietf.org
DTSTART;TZID=3D"Northern Europe Time":20141007T050000
DTEND;TZID=3D"Northern Europe Time":20141007T063000
LOCATION:https://ietf.webex.com/ietf
TRANSP:OPAQUE
SEQUENCE:1
UID:WEBEX-MEETING CENTER-6.0456680-55831383-SU=3Dietf
DTSTAMP:20141007T020000Z
DESCRIPTION:\n\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?M=
TID=3Dmf5c5e188b03e86378ddf2d9a19a160d4\nMeeting number: 317 354 563\nMee=
ting password: dmm1911\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll fr=
ee number (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nA=
ccess code: 317 354 563\n\nToll-free dialing restrictions: \nhttp://www.w=
ebex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join the meeting? Con=
tact support here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE:=
 Please note that this WebEx service allows audio and other information s=
ent during the session to be recorded, which may be discoverable in a leg=
al matter. By joining this session, you automatically consent to such rec=
ordings. If you do not consent to being recorded, discuss your concerns w=
ith the host or do not join the session.\n
X-ALT-DESC;FMTTYPE=3Dtext/html:	  		Join WebEx meeting						=
	
											Mee=
ting number:																317 354 563									
			
			<=
table>
Meeting p=
assword:dmm1911
		 
 
Join by phone  
1-877-668-4493 Call-in toll free number (US/Canada)  
1-650-479-3208&n=
bsp;Call-in toll number (US/Canada)  
Access code: 317 354 563  
<=
a href=3D"http://www.webex.com/pdf/tollfree_restrictions.pdf">Toll-free calling restrictions   


	 
					Can't join the meeting?		Contact support.	 
 
IMPORTANT NOTICE: Please note that this WebE=
x service allows audio and other information sent during the session to b=
e recorded, which may be discoverable in a legal matter. By joining this =
session, you automatically consent to such recordings. If you do not cons=
ent to being recorded, discuss your concerns with the host or do not join=
 the session.
SUMMARY:DMM Interim call #3
PRIORITY:5
CLASS:PUBLIC
BEGIN:VALARM
TRIGGER:-PT5M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR

--------------000202050702030006060005--


From nobody Wed Sep 17 17:47:06 2014
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 9C1AE1A6F66 for ; Wed, 17 Sep 2014 17:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.153
X-Spam-Level: 
X-Spam-Status: No, score=-15.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_37=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 Y4zK8e71JM8n for ; Wed, 17 Sep 2014 17:47:00 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857521A6F14 for ; Wed, 17 Sep 2014 17:47:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5433; q=dns/txt; s=iport; t=1411001220; x=1412210820; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=kGYuaqGOb69L/8pEgjxrcf4QQv3e04dsV/b3VZ9A4GU=; b=NEMpqUiHYQ4lpYcTkS36Q0TCx9atRYzgqJYb8hRR+cEXSdkWXmnQm7Kc DigDhHvjA1V8B6MNFTQhVFfPvR/Tp9ISbYxvQKKaSTH/XMUAF5D8GvAIp CtrSYJPLqAcekXZe4j/prrRVywwm36ihgbatBSM8JPbaLYHuUS2yo7QQ6 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAGMqGlStJV2Q/2dsb2JhbABhgw1TVwTJPIdNAYEYFgF5hAMBAQEDAScTOAcFBwYBCBEEAQEfCTkUCQgCBA4FG4gbCA3ACwEXj0wrBwIEhEUFkU6EN4cHgWCTaINebAGBR4ECAQEB
X-IronPort-AV: E=Sophos;i="5.04,543,1406592000"; d="scan'208";a="78880062"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP; 18 Sep 2014 00:46:59 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8I0kxqC012606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Sep 2014 00:46:59 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 19:46:58 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHP0toMlh9WNg7Ku0CIaplsY5C3NQ==
Date: Thu, 18 Sep 2014 00:46:57 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D1ABF8@XCH-BLV-504.nw.nos.boeing.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.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7C9343F835F14F4590CECD1B7FCA279D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/fNBhSc7TwmS811Hy-WRtgAwYUzg
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 18 Sep 2014 00:47:04 -0000

Hi Fred,


>This looks very close to the way AERO handles RO in the network
>based case. In this case, the AERO Client is analogous to the
>PMIPv6 MAG, and the RO can go MN1<->Client1<->Client2<->MN2.
>
>One of the key differences again is that the AERO NBMA virtual
>link does not require any explicit tunnel configurations. So,
>tunneling between Client1<->Client2 is guided by neighbor cache
>information on the NBMA link.


There is no explicit tunnel configuration in any of the mobility
architectures. The tunnel state creation is dynamic and is created based
on the events from the signaling functions. The tunnel is a standard L3
tunnel with standard encapsulation methods such as GRE, IP-in-IP and UDP.

I'm trying to understand the advantages of this NBMA virtual link. I
assumed the encapsulation is a standard encapsulation such as with UDP.
The specific rules for selection of the IP traffic for tunneling, or
tunnel header selection is a more implementation specific aspect. One can
create a tunnel between two points A and B and apply a policy route, which
state all traffic from MAc-1/IP-1 needs to be encapsulated with tunnel
header A-B. If I'm monitoring the link of a tunneled traffic, I would not
know the difference between traffic tunneled from a NBMA virtual link and
a tunneled traffic with dynamically created tunnels. How we realize
tunneling is internal to the operating system and has no bearing on the
interoperability  ?. Do you agree with this ?
=20


> AERO route optimization is quite different than this. AERO route
optimization is based on a chain-of-trust whereby the RO requests
and replys always come from the Client's trusted Server instead
of an untrusted node. AERO RO is unidirectional - to set up a
bidirectional RO requires two unidirectional ROs. These can
happen simultaneously or separately, and in some cases it may
even be preferable to have only one of the two directions
optimized.



Ok. In MIPv6 RO scheme the MN's trusted entity is the home agent and it
provides the frame work for a CN to trust the MN's relation/association
with its home address (anchored on HA) and its care-of address (direct
route). The approach does not require both the peers to have a mobility
anchor, but the Return Routability test procedure assures any
correspondent node to trust the HoA to CoA relation and use direct routing
paths. I'm not sure how one approach is better over the other.

Again, I've my views against using any client-based solutions for RO
solutions.
=20


Regards
Sri




On 9/15/14 4:02 PM, "Templin, Fred L"  wrote:

>Hi Sri,
>
>> -----Original Message-----
>> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>> Sent: Monday, September 15, 2014 3:32 PM
>> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
>> Cc: Dapeng Liu; dmm@ietf.org
>> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>>=20
>> Hi Fred,
>>=20
>> Thanks for your response.
>>=20
>> > To name one thing, the tunnel virtual link model is a point of
>> departure and I think an area where AERO provides a better model
>> especially for handling route optimization and distributed
>> mobility management.
>>=20
>>=20
>> Lets focus on the Route Optimization. If you can share some views on how
>> the above model is better compared to the below standardized approaches,
>> it will really help.
>>=20
>> To your comment on feature gaps, I will try to compile a list and send
>>it
>> out. I also owe you a response on the thread related to Sataru-san's
>>draft.
>>=20
>>=20
>>=20
>> In MIP architectures, we have Route optimization support in two modes:
>>=20
>> 1.) Client-based
>>=20
>> - Signaling is based on MIPv6;
>>(http://tools.ietf.org/html/rfc6275#page-25
>> )
>> - User-plane RO management based on Type-2 Routing
>> header;(http://tools.ietf.org/html/rfc6275#page-55)
>> - Scope is global
>> - Requires Mobile IPv6 software functionality
>
>AERO route optimization is quite different than this. AERO route
>optimization is based on a chain-of-trust whereby the RO requests
>and replys always come from the Client's trusted Server instead
>of an untrusted node. AERO RO is unidirectional - to set up a
>bidirectional RO requires two unidirectional ROs. These can
>happen simultaneously or separately, and in some cases it may
>even be preferable to have only one of the two directions
>optimized.
>
>In the process of setting up the RO, the Clients also come to know
>the permissible encapsulation IP address or addresses for the
>encapsulated address. So, the RO also provides a simple data
>origin authentication capability.
>=20
>> 2.) Network-based
>>=20
>> - Signaling is based on PMIPv6;
>>(http://tools.ietf.org/html/rfc6705#page-8)
>> - User plane is based on direct tunneling
>> - Scope is localized PMIP domain
>> - Works with any mobile node with no additional software capabilities
>
>This looks very close to the way AERO handles RO in the network
>based case. In this case, the AERO Client is analogous to the
>PMIPv6 MAG, and the RO can go MN1<->Client1<->Client2<->MN2.
>
>One of the key differences again is that the AERO NBMA virtual
>link does not require any explicit tunnel configurations. So,
>tunneling between Client1<->Client2 is guided by neighbor cache
>information on the NBMA link.

>


From nobody Thu Sep 18 10:15:11 2014
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 B60E51A0659; Thu, 18 Sep 2014 10:15:06 -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 8K5Iflmjc0be; Thu, 18 Sep 2014 10:15:04 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B3F1A0651; Thu, 18 Sep 2014 10:15:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IESG Secretary 
To: IETF Announcement List 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p6
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140918171503.13411.96623.idtracker@ietfa.amsl.com>
Date: Thu, 18 Sep 2014 10:15:03 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/aCNzvdYMr7lGpQdU7UiyIUvSKrA
Cc: dmm@ietf.org
Subject: [DMM] DMM WG Virtual Interim Meeting, October 7, 2014
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Sep 2014 17:15:07 -0000

The DMM WG will hold its third interim conference calls during October:
7th October, 5PM Helsinki time (EEST) / 1400 UTC.

The conference call lasts max 2 hours. The detailed agenda will be
available later but it is around progressing the new work we are
pursuing.

--------------------------------------------
Webex details
--------------------------------------------

Join WebEx meeting
https://ietf.webex.com/ietf/j.php?MTID=mf5c5e188b03e86378ddf2d9a19a160d4

Meeting number: 317 354 563
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: 317 354 563
Toll-free calling restrictions
http://www.webex.com/pdf/tollfree_restrictions.pdf

Can't join the meeting? Contact support.
https://ietf.webex.com/ietf/mc

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


From nobody Thu Sep 18 11:34:38 2014
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 9E5341A06A5 for ; Thu, 18 Sep 2014 11:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.853
X-Spam-Level: 
X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_37=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 4MZR4f2nsywF for ; Thu, 18 Sep 2014 11:34:31 -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 59EDB1A069C for ; Thu, 18 Sep 2014 11:33:51 -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 s8IIXoNs014736; Thu, 18 Sep 2014 11:33:51 -0700
Received: from XCH-BLV-303.nw.nos.boeing.com (xch-blv-303.nw.nos.boeing.com [130.247.25.215]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8IIXjnD014226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 18 Sep 2014 11:33:45 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-303.nw.nos.boeing.com ([169.254.3.55]) with mapi id 14.03.0181.006; Thu, 18 Sep 2014 11:33:44 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" 
Thread-Topic: [DMM] DMM Interim call #2 - agenda forming
Thread-Index: AQHPzSY685cNtlvM5kaPQ9fwALiOyZv6soAwgAFMcQCAAC5BQIAAwuAA//+Qf6CAAKQQgIAAdvdwgAEs8ACAA4DnUIAA+3kA//+LhBCAA765gIAAr9sA
Date: Thu, 18 Sep 2014 18:33:44 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D1E8BF@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D1ABF8@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/aEjQWf6vyZ8Bt3bHvMao57OpGxM
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] DMM Interim call #2 - agenda forming
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, 18 Sep 2014 18:34:33 -0000

Hi Sri,

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> Sent: Wednesday, September 17, 2014 5:47 PM
> To: Templin, Fred L
> Cc: dmm@ietf.org
> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
>=20
> Hi Fred,
>=20
>=20
> >This looks very close to the way AERO handles RO in the network
> >based case. In this case, the AERO Client is analogous to the
> >PMIPv6 MAG, and the RO can go MN1<->Client1<->Client2<->MN2.
> >
> >One of the key differences again is that the AERO NBMA virtual
> >link does not require any explicit tunnel configurations. So,
> >tunneling between Client1<->Client2 is guided by neighbor cache
> >information on the NBMA link.
>=20
>=20
> There is no explicit tunnel configuration in any of the mobility
> architectures. The tunnel state creation is dynamic and is created based
> on the events from the signaling functions. The tunnel is a standard L3
> tunnel with standard encapsulation methods such as GRE, IP-in-IP and UDP.
>=20
> I'm trying to understand the advantages of this NBMA virtual link. I
> assumed the encapsulation is a standard encapsulation such as with UDP.

The AERO NBMA virtual link mode applies to any tunnel type (UDP, GRE,
IP-in-IP, GTP (I guess), etc.).

> The specific rules for selection of the IP traffic for tunneling, or
> tunnel header selection is a more implementation specific aspect. One can
> create a tunnel between two points A and B and apply a policy route, whic=
h
> state all traffic from MAc-1/IP-1 needs to be encapsulated with tunnel
> header A-B. If I'm monitoring the link of a tunneled traffic, I would not
> know the difference between traffic tunneled from a NBMA virtual link and
> a tunneled traffic with dynamically created tunnels. How we realize
> tunneling is internal to the operating system and has no bearing on the
> interoperability  ?. Do you agree with this ?

Right, there is no difference in the way the tunneled packets appear
as bits-over-the-wire. The difference is that the AERO NBMA virtual
link model allows for L2 address resolution via IPv6 ND messaging
the same as on any IP interface.=20

> > AERO route optimization is quite different than this. AERO route
> optimization is based on a chain-of-trust whereby the RO requests
> and replys always come from the Client's trusted Server instead
> of an untrusted node. AERO RO is unidirectional - to set up a
> bidirectional RO requires two unidirectional ROs. These can
> happen simultaneously or separately, and in some cases it may
> even be preferable to have only one of the two directions
> optimized.
>=20
>=20
>=20
> Ok. In MIPv6 RO scheme the MN's trusted entity is the home agent and it
> provides the frame work for a CN to trust the MN's relation/association
> with its home address (anchored on HA) and its care-of address (direct
> route). The approach does not require both the peers to have a mobility
> anchor, but the Return Routability test procedure assures any
> correspondent node to trust the HoA to CoA relation and use direct routin=
g
> paths. I'm not sure how one approach is better over the other.

Let me think about this.

> Again, I've my views against using any client-based solutions for RO
> solutions.

AERO RO is initiated by the source Client and directed toward the
target Client. When the source Client sends packets destined for
a target Client, the source also sends a RO message. Both the data
packets and the RO message are sent via a routing chain. In the
PMIPv6 deployment model, it would go as:

  MAG1 -> LMA1 -> (some forwarding agent) -> LMA2 -> MAG2

After the RO, subsequent communications would go directly as:

  MAG1 -> MAG2

But, it is important to note that AERO generalizes to any mobility
scenario, and not just the PMIP deployment model. For AERO RO, mobile
Clients may have no way of trusting each other without involving some
chain of trust as provided by the AERO Servers and Relays.

Thanks - Fred
fred.l.templin@boeing.com=20

> Regards
> Sri
>=20
>=20
>=20
>=20
> On 9/15/14 4:02 PM, "Templin, Fred L"  wrote:
>=20
> >Hi Sri,
> >
> >> -----Original Message-----
> >> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> >> Sent: Monday, September 15, 2014 3:32 PM
> >> To: Templin, Fred L; Jouni Korhonen; sarikaya@ieee.org
> >> Cc: Dapeng Liu; dmm@ietf.org
> >> Subject: Re: [DMM] DMM Interim call #2 - agenda forming
> >>
> >> Hi Fred,
> >>
> >> Thanks for your response.
> >>
> >> > To name one thing, the tunnel virtual link model is a point of
> >> departure and I think an area where AERO provides a better model
> >> especially for handling route optimization and distributed
> >> mobility management.
> >>
> >>
> >> Lets focus on the Route Optimization. If you can share some views on h=
ow
> >> the above model is better compared to the below standardized approache=
s,
> >> it will really help.
> >>
> >> To your comment on feature gaps, I will try to compile a list and send
> >>it
> >> out. I also owe you a response on the thread related to Sataru-san's
> >>draft.
> >>
> >>
> >>
> >> In MIP architectures, we have Route optimization support in two modes:
> >>
> >> 1.) Client-based
> >>
> >> - Signaling is based on MIPv6;
> >>(http://tools.ietf.org/html/rfc6275#page-25
> >> )
> >> - User-plane RO management based on Type-2 Routing
> >> header;(http://tools.ietf.org/html/rfc6275#page-55)
> >> - Scope is global
> >> - Requires Mobile IPv6 software functionality
> >
> >AERO route optimization is quite different than this. AERO route
> >optimization is based on a chain-of-trust whereby the RO requests
> >and replys always come from the Client's trusted Server instead
> >of an untrusted node. AERO RO is unidirectional - to set up a
> >bidirectional RO requires two unidirectional ROs. These can
> >happen simultaneously or separately, and in some cases it may
> >even be preferable to have only one of the two directions
> >optimized.
> >
> >In the process of setting up the RO, the Clients also come to know
> >the permissible encapsulation IP address or addresses for the
> >encapsulated address. So, the RO also provides a simple data
> >origin authentication capability.
> >
> >> 2.) Network-based
> >>
> >> - Signaling is based on PMIPv6;
> >>(http://tools.ietf.org/html/rfc6705#page-8)
> >> - User plane is based on direct tunneling
> >> - Scope is localized PMIP domain
> >> - Works with any mobile node with no additional software capabilities
> >
> >This looks very close to the way AERO handles RO in the network
> >based case. In this case, the AERO Client is analogous to the
> >PMIPv6 MAG, and the RO can go MN1<->Client1<->Client2<->MN2.
> >
> >One of the key differences again is that the AERO NBMA virtual
> >link does not require any explicit tunnel configurations. So,
> >tunneling between Client1<->Client2 is guided by neighbor cache
> >information on the NBMA link.
>=20
> >


From nobody Thu Sep 18 13:03:54 2014
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 894231A0B9C for ; Thu, 18 Sep 2014 13:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level: 
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 IpxjHBwcrfnn for ; Thu, 18 Sep 2014 13:03:51 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE8A1A88DB for ; Thu, 18 Sep 2014 13:03:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2058; q=dns/txt; s=iport; t=1411070631; x=1412280231; h=from:to:subject:date:message-id:mime-version; bh=9ZhHFSmtekdeQtyHb9C+aV5fQmpWhyeGIcX1lqRYz7c=; b=Yvvq4b2PloZPC3GjWH5f7wk5Hoo+bathiQITlbiTXOcIq+BwlOjyKNXH 1GvExBAlmYrNrRmAUIwCFQwl3hKuLI4Xovdz5J34AvxCPpaa8KlZfYkmq Bz39BFLMjsu4hEKOkJGJicd1FhZlQ+7d59bk+8RxpXfx6JkmSLtL/Fwa0 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApIHAD86G1StJV2Z/2dsb2JhbABggkdGgS7SIBYBcQiECoELAQwBcycEiFGcYaVRF48ghSkFkU6LPpVIg16Bc0GBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,549,1406592000";  d="scan'208,217";a="353276114"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 18 Sep 2014 20:03:51 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8IK3ohn006650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Sep 2014 20:03:50 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 18 Sep 2014 15:03:50 -0500
From: "Sri Gundavelli (sgundave)" 
To: "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH7w==
Date: Thu, 18 Sep 2014 20:03:50 +0000
Message-ID: 
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.217]
Content-Type: multipart/alternative; boundary="_000_D04088B4165884sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/xmT8RXp-UjhPqbN6yW7paUcf8YE
Subject: [DMM] Signaling Message Fragmentation
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, 18 Sep 2014 20:03:52 -0000

--_000_D04088B4165884sgundaveciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

[Discussion under the maintenance scope]

With the standardization of all the new mobility options (ANI, QoS, IFOM, M=
NP..etc)   and specially with the NAI/Domain type fields in some of those o=
ptions, we are almost close to hitting the PBU/BU fragmentation limit.

Any thoughts on how to deal with this ? How is it solved in other message b=
ased protocols ? I've seen some work on IPSecme WG on IKEv2 message fragmen=
tation for the same issue.

Should we do some thing here ? Or, if any one has invested time on this and=
 has a proposal ? Comments ?



Regards
Sri

--_000_D04088B4165884sgundaveciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







[Discussion under the maintenance scope] 







With the standardization of all the new mobility options (ANI, QoS, IF=
OM, MNP..etc)   and specially with the NAI/Domain type fields in =
some of those options, we are almost close to hitting the PBU/BU fragmentat=
ion limit. 







Any thoughts on how to deal with this ? How is it solved in other mess=
age based protocols ? I've seen some work on IPSecme WG on IKEv2 message fr=
agmentation for the same issue. 







Should we do some thing here ? Or, if any one has invested time on thi=
s and has a proposal ? Comments ?

















Regards


Sri




--_000_D04088B4165884sgundaveciscocom_--


From nobody Fri Sep 19 08:53:15 2014
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 4D7E71A011B for ; Fri, 19 Sep 2014 08:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level: 
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 0s9mZ6qxf7ZB for ; Fri, 19 Sep 2014 08:53:13 -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 E9A8C1A0162 for ; Fri, 19 Sep 2014 08:53:12 -0700 (PDT)
Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0MNsrt-1XPE0U3rxL-007T8G; Fri, 19 Sep 2014 17:53:11 +0200
From: Alper Yegin 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Sep 2014 18:53:08 +0300
Message-Id: <2F475F09-51A8-414B-B7BD-BCEDB69A58ED@yegin.org>
To: dmm@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:s8C3+khUcawYYhp95iBsxk6W/1uuUizwK0Ec0+CqYRR e71PsplVr2ujKFczxlKY9PlkAHRFrekls1IOoCdBO0Z52ic6e7 h4cc28giL2FUpRYAOeSgwUY8C9yc9pPTInLrnvusPnk8MOr5R6 wtTc4/E/NFxJiUc3ot5zyNlwxFHLooqWQY2xxovRIZwgwP22kN WfHnvLqZHApSSTz59wfeK8p5lOlEtCHb+mWGXnyAgXHGLsJZWm BaVmdXJdCZgsd6BXojs8gy0wF7aRc2Znp9AvnW9sC23UtyzylL ObSQtDIlDB3mKzwFLIJgHtO/d80krN3kI+CQInP7DGo5dyDhYK miHaw9RLzfhIU3P3q7AS7a7bvkyWQvZoL+jH+PUftbxVS3MdE7 QDyO+mhGCrjDQ==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/DG7wAamFGqDZl6rX3O1svtJWnSU
Subject: [DMM] Coordination of mobility solutions
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, 19 Sep 2014 15:53:14 -0000

As promised, let me enumerate the "protocol" worked involved for =
solutions aimed at "discovery, selection, and coordinated execution of =
mobility protocols at multiple layers".=20

- Discovering network's mobility capabilities:

Whether it supports PMIP, LISP,  etc.
Possible approach is to define new DHCP options to deliver this "network =
info" to the terminal.

- Discovering corresponding node's mobility capabilities:

Whether it supports MPTCP, MIP route optimization, etc.
Possible approach is to use DNS-based discovery.


Discovering the MN's own mobility capabilities does not involve any =
protocol work. It may be based on platform-specific methods, API, =
application profiling, etc.

How the terminal selects the mobility protocol(s) to apply to a given =
flow, and how it coordinates execution of them are materials for an =
"informational" document that'd also refer to the aforementioned =
discovery elements.

Like Danny was suggesting, we can tackle this in the working team that =
deals with the source address selection, as there's an interaction  =
between the two. Whether a flow needs a fixed or sustained or nomadic IP =
address is influenced by whether the application traffic would need =
IP-layer mobility or not.

Alper





From nobody Fri Sep 19 12:35:41 2014
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 8F7461A87EF for ; Fri, 19 Sep 2014 12:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level: 
X-Spam-Status: No, score=-16.153 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, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, 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 8XKXwzafFcCh for ; Fri, 19 Sep 2014 12:35:38 -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 2F6011A8785 for ; Fri, 19 Sep 2014 12:35:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2069; q=dns/txt; s=iport; t=1411155338; x=1412364938; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Fp9etyrTNKexZ7VodDKK0DEXEx/EEDNL1OFx3YItsIU=; b=iawDWcMGhfn23YnjGcOs8HmzXIBSbqKTb6krMd2KhXJxDUL5pyvzJKHw PlqCnsNjk91mic5Bo53UEMxK9PPEkM+jEjxPkdhrsDuquxRZahhoB9Yod f9JAL+rUCA9LeJVqFQa/w4+QYWCSAhIyJb4Jc5WzhJnf5OkNnlNq/iAy9 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAICEHFStJV2d/2dsb2JhbABWCoMNU1cEyWsKh00BgQQWAXmEBAEBBAEBATc0HQEINjcLJQIEARIbiCMNwyQBEwSPJWOESwWPPoIXiz6VToNfbIFIgQIBAQE
X-IronPort-AV: E=Sophos;i="5.04,556,1406592000"; d="scan'208";a="79557840"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 19 Sep 2014 19:35:36 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8JJZaQn009780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 19:35:36 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 14:35:36 -0500
From: "Sri Gundavelli (sgundave)" 
To: Alper Yegin , "dmm@ietf.org" 
Thread-Topic: [DMM] Coordination of mobility solutions
Thread-Index: AQHP1EDi1qR7RLEAE0K/GglL3tj0ow==
Date: Fri, 19 Sep 2014 19:35:35 +0000
Message-ID: 
In-Reply-To: <2F475F09-51A8-414B-B7BD-BCEDB69A58ED@yegin.org>
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.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/FSVj4nSooi2doQwtPtJrSEe498U
Subject: Re: [DMM] Coordination of mobility solutions
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, 19 Sep 2014 19:35:39 -0000

Hi Alper,

Please see inline.

On 9/19/14 8:53 AM, "Alper Yegin"  wrote:

>As promised, let me enumerate the "protocol" worked involved for
>solutions aimed at "discovery, selection, and coordinated execution of
>mobility protocols at multiple layers".
>
>- Discovering network's mobility capabilities:
>
>Whether it supports PMIP, LISP,  etc.
>Possible approach is to define new DHCP options to deliver this "network
>info" to the terminal.


Agree. If you can identify the client behavior and as how this information
is used by the client will really help.



>
>- Discovering corresponding node's mobility capabilities:
>
>Whether it supports MPTCP, MIP route optimization, etc.
>Possible approach is to use DNS-based discovery.
>

During SIPTO (RFC6909) standardization, there was a IESG DISCUSS on this.
The concern was that the network is offloading some traffic without the
client being notified. May be this approach of enabling the client with
such details will eliminate that concern. The key point is on the details
on how the client leverages this network information will really help
justify the work.

Regards
Sri



>
>Discovering the MN's own mobility capabilities does not involve any
>protocol work. It may be based on platform-specific methods, API,
>application profiling, etc.
>
>How the terminal selects the mobility protocol(s) to apply to a given
>flow, and how it coordinates execution of them are materials for an
>"informational" document that'd also refer to the aforementioned
>discovery elements.
>
>Like Danny was suggesting, we can tackle this in the working team that
>deals with the source address selection, as there's an interaction
>between the two. Whether a flow needs a fixed or sustained or nomadic IP
>address is influenced by whether the application traffic would need
>IP-layer mobility or not.
>
>Alper
>
>
>
>
>_______________________________________________
>dmm mailing list
>dmm@ietf.org
>https://www.ietf.org/mailman/listinfo/dmm


From nobody Sun Sep 21 09:59:47 2014
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 606641A010D for ; Sun, 21 Sep 2014 09:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.386
X-Spam-Level: 
X-Spam-Status: No, score=-13.386 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 5lmWMLPN3xA9 for ; Sun, 21 Sep 2014 09:59:41 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A031A00BF for ; Sun, 21 Sep 2014 09:59:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37856; q=dns/txt; s=iport; t=1411318781; x=1412528381; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=0GigVcJaqoUbSh/KygjcWgdVeWkAMfcH/UvlRfU9AY8=; b=GtsBu2FQCP989G71cRLXJ1+WSJ2KqA7gMJXHRRgakCHBdw4rCvNelysu VNaAfX2TKd1CS7RPCu+57/c04IdFRXcyIgxRpB6XRvAfp7o4G0UB1kFzs /CsBc02u8EMOox8Eom6O2XWZmSWMD7KfYK77tPgl4Ed5ip9+rKh4FYX07 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak8FACwDH1StJV2b/2dsb2JhbABXCYJIRlNXBIJ9xloBCYdNARllFgF5hAMBAQEEAQEBIEsLDAYBCBEDAQEBDhMHAwIEJQsUCQgCBA4FCYghAxENrV2OBBuHIQEXjUcQgVQwCQcKBwYEBgECBIJygVMFhiCJIIIXiz+VUoNhbAGBR4ECAQEB
X-IronPort-AV: E=Sophos; i="5.04,566,1406592000"; d="scan'208,217"; a="79905339"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 21 Sep 2014 16:59:40 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8LGxd5i017037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 21 Sep 2014 16:59:39 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Sun, 21 Sep 2014 11:59:39 -0500
From: "Sri Gundavelli (sgundave)" 
To: Hakima Chaouchi 
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHP1b1uPLofbJDy10WBm5vmIWHogw==
Date: Sun, 21 Sep 2014 16:59:38 +0000
Message-ID: 
In-Reply-To: <2007180277.6484923.1411312300022.JavaMail.zimbra@telecom-sudparis.eu>
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.217]
Content-Type: multipart/alternative; boundary="_000_D04450E516608Fsgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/2HIclcw9dL-OlRziMFczYABGldM
Cc: Charlie Perkins , Vijay Devarapalli , "dmm@ietf.org" 
Subject: Re: [DMM] MNID Types
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, 21 Sep 2014 16:59:44 -0000

--_000_D04450E516608Fsgundaveciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSGFraW1hLA0KDQpUaGF0IGlzIGEgZ29vZCBpZGVhLiBXZSBzaG91bGQgcmVnaXN0ZXIgYSB0
eXBlIGZvciB0aGUgRG9kLTk2IGlkZW50aWZpZXIgYXMgd2VsbC4NCg0KDQpSZWdhcmRzDQpTcmkN
Cg0KDQpGcm9tOiBIYWtpbWEgQ2hhb3VjaGkgPGhha2ltYS5jaGFvdWNoaUB0ZWxlY29tLXN1ZHBh
cmlzLmV1PG1haWx0bzpoYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJpcy5ldT4+DQpEYXRl
OiBTdW5kYXksIFNlcHRlbWJlciAyMSwgMjAxNCA4OjExIEFNDQpUbzogU3JpIEd1bmRhdmVsbGkg
PHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4NCkNjOiBDaGFy
bGllIFBlcmtpbnMgPGNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PG1haWx0bzpjaGFybGVz
LnBlcmtpbnNAZWFydGhsaW5rLm5ldD4+LCBNYXJjbyBMaWVic2NoIDxNYXJjby5MaWVic2NoQG5l
Y2xhYi5ldTxtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PiwgImRtbUBpZXRmLm9yZzxt
YWlsdG86ZG1tQGlldGYub3JnPiIgPGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPj4s
IFZpamF5IERldmFyYXBhbGxpIDxkdmlqYXlAcm9ja2V0bWFpbC5jb208bWFpbHRvOmR2aWpheUBy
b2NrZXRtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0KDQpIZWxsbyBG
b2xrcywNCg0KRG8geW91IHRoaW5rIHRoYXQgY29uc2lkZXJpbmcgc3BlY2lmaWMgYnV0IG5lZWRl
ZCB0ZWNobm9sb2dpZXMgZm9yIG1vdmluZyBvYmplY3RzIGluICBJbnRlcm5ldCBvZiBUaGluZ3Mg
IHN1Y2ggYXMgUkZJRCAoUmFkaW8gRnJlcXVlbmN5IElkZW50aWZpZXIpIHdpdGggOTYgYml0cyBp
ZGVudGlmaWVycyB3aWxsIGJlIGFsc28gcmVsZXZlbnQgdG8gQ2hhcmxpZSdzIGN1cnJlbnQgZHJh
ZnQgYW5kIHRoZSBlZmZvcnRzIHJlbGF0ZWQgdG8gTU5JRD8NCg0KUmVnYXJkcywNCg0KSGFraW1h
DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRlOiAiU3JpIEd1bmRhdmVs
bGkgKHNndW5kYXZlKSIgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28u
Y29tPj4NCsOAOiAiQ2hhcmxpZSBQZXJraW5zIiA8Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5u
ZXQ8bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pj4sICJNYXJjbyBMaWVic2No
IiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8bWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1
Pj4sIGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiwgIlZpamF5IERldmFyYXBhbGxp
IiA8ZHZpamF5QHJvY2tldG1haWwuY29tPG1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20+Pg0K
RW52b3nDqTogSmV1ZGkgMTEgU2VwdGVtYnJlIDIwMTQgMjM6NTc6MTENCk9iamV0OiBSZTogW0RN
TV0gTU5JRCBUeXBlcw0KDQpIaSBDaGFybGllLA0KDQpGZXcgbW9yZSByZXZpZXdzL2Rpc2N1c3Np
b25zIGFuZCBjYXB0dXJpbmcgdGhlIGNvbnNlbnN1cyBpbiB0aGUgYmFzZSB2ZXJzaW9uIHdpbGwg
aGVscC4gQnV0LCBJJ20gb2sgZWl0aGVyIHdheSDigKYNCg0KDQpSZWdhcmRzDQpTcmkNCg0KRnJv
bTogQ2hhcmxpZSBQZXJraW5zIDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDxtYWlsdG86
Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+Pg0KRGF0ZTogVGh1cnNkYXksIFNlcHRlbWJl
ciAxMSwgMjAxNCAyOjQ2IFBNDQpUbzogU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNv
bTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4sIE1hcmNvIExpZWJzY2ggPE1hcmNvLkxpZWJz
Y2hAbmVjbGFiLmV1PG1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldT4+LCAiZG1tQGlldGYu
b3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+IiA8ZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5v
cmc+PiwgVmlqYXkgRGV2YXJhcGFsbGkgPGR2aWpheUByb2NrZXRtYWlsLmNvbTxtYWlsdG86ZHZp
amF5QHJvY2tldG1haWwuY29tPj4NClN1YmplY3Q6IFJlOiBbRE1NXSBNTklEIFR5cGVzDQoNCg0K
SGVsbG8gZm9sa3MsDQoNCkkgcHJvcG9zZSB0byBzdWJtaXQgdGhlIC4uLi4tMDAudHh0IGRvY3Vt
ZW50IGFzIGl0IGlzIHRvIHRoZSBJbnRlcm5ldA0KRHJhZnRzIGRpcmVjdG9yeSwgYW5kIHRoZW4g
dG8gZ28gYWJvdXQgbWFraW5nIHVwZGF0ZXMgYWNjb3JkaW5nIHRvDQp0aGUgZGlzY3Vzc2lvbiBv
biB0aGlzIGxpc3QuICBEbyB5b3UgdGhpbmsgdGhpcyBpcyByZWFzb25hYmxlPw0KDQpSZWdhcmRz
LA0KQ2hhcmxpZSBQLg0KDQoNCk9uIDkvMTEvMjAxNCA3OjIxIEFNLCBTcmkgR3VuZGF2ZWxsaSAo
c2d1bmRhdmUpIHdyb3RlOg0KDQo8Q2hhbmdpbmcgdGhlIHN1YmplY3QgbGluZSB0byByZWZsZWN0
IHRoZSBNTklkIGRpc2N1c3Npb24+DQoNCg0KTWFyY28sDQoNCg0KVGhpbmtpbmcgZnVydGhlciBv
biB0aGUgY29tcGxlbWVudGFyeSBpZGVudGlmaWVyIG9wdGlvbi4NCg0KLSBUaGVyZSBpcyBhbHJl
YWR5IHRoZSBsaW5rLWxheWVyIGlkZW50aWZpZXIgb3B0aW9uIHRoYXQgY2FuIGJlIHVzZWQgZm9y
DQpjYXJyeWluZyB0aGUgTWFjIGFkZHJlc3MNCi0gSU1FSSBhbmQgTVNJU0ROIGFyZSBhbHJlYWR5
IGRlZmluZWQgaW4gMjkuMjc1IGFzIGEgM0dQUCBWU0Uncw0KDQpJbiBzb21lIHNlbnNlLCB0aGUg
Y29tcGxlbWVudGFyeSBpZGVudGlmaWVycyBhcmUgYWxyZWFkeSBwcmVzZW50Lg0KDQpTcmkNCg0K
DQoNCg0KDQpPbiA5LzExLzE0IDY6NTggQU0sICJTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIiA8
c2d1bmRhdmVAY2lzY28uY29tPjxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPiB3cm90ZToNCg0K
DQpJIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5IG11bHRpcGxlIE1OLUlkIGluc3RhbmNlcyBuZWVk
IHRvIGJlIHByZXNlbnQgaW4gYQ0Kc2luZ2xlIG1lc3NhZ2UgPyBJbiBteSBleHBlcmllbmNlLCB0
aGlzIGlzIHN0cmljdGx5IGEgZGVwbG95bWVudA0KY29uc2lkZXJhdGlvbiwgd2hlbiB0byB1c2Ug
d2hhdCB0eXBlIG9mIGlkZW50aWZpZXJzLg0KDQpBc3N1bWluZyB0aGUgYmFja2VuZCBzeXN0ZW0g
Y2FuIHRpZSBhbGwgdGhlIE1OLUlkJ3MgdG8gYSBzaW5nbGUNCnN1YnNjcmlwdGlvbiwgYW55IHBy
ZXNlbnRlZCBpZGVudGlmaWVyIGNhbiBiZSBzdWZmaWNpZW50IGZvciB0aGUgZ2F0ZXdheQ0KdG8g
ZG8gdGhlIEJDRSBsb29rdXAuDQoNCklmIG11bHRpcGxlIGluc3RhbmNlcyBjYW4gYmUgcHJlc2Vu
dCwgdGhlbiB3ZSBuZWVkIHRvIGRlYWwgd2l0aCBtb3JlIGVycm9yDQpjYXNlcy4gSXMgdGhhdCBy
ZWFsbHkgbmVlZGVkID8NCg0KDQoNCg0KSSBhbSB3b25kZXJpbmcgaWYgaXQgd291bGQgbm90IGJl
IG1vcmUgYXBwcm9wcmlhdGUgdG8gZ28gZm9yIGEgZGlmZmVyZW50DQpjb250YWluZXIgb3B0aW9u
IHRvIGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24uIFNvbWV0aGluZyBsaWtlIGENCmNvbXBsZW1lbnRh
cnkgaWRlbnRpZmllciBvcHRpb24uDQoNCg0KU291bmRzIGludGVyZXN0aW5nLiBBcmUgeW91IHN1
Z2dlc3Rpbmcgd2UgbGVhdmUgdGhlIGN1cnJlbnQgTU4tSUQgYXMgaXQNCmlzLCBidXQgdXNlIGEg
bmV3IGNvbXBsZW1lbnRhcnkgb3B0aW9uID8gQnV0LCBpZiB0aGUgcmVxdWlyZW1lbnQgaXMgZm9y
IGENCk1hYyBiYXNlZCBpZGVudGlmaWVycywgd2hhdCB3aWxsIGJlIHRoZXJlIGluIHRoZSBjdXJy
ZW50IE1OLUlkIG9wdGlvbiA/IFdlDQpzdGlsbCBuZWVkIHRvIGhhdmUgaWRlbnRpZmllciB0aGVy
ZSA/DQoNCg0KDQoNClNyaQ0KDQoNCg0KDQoNCk9uIDkvMTEvMTQgMjowMyBBTSwgIk1hcmNvIExp
ZWJzY2giIDxNYXJjby5MaWVic2NoQG5lY2xhYi5ldT48bWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVj
bGFiLmV1PiB3cm90ZToNCg0KDQoNCk5vIGlzc3VlIHdpdGggbG9naWNhbCB2cy4gcGh5c2ljYWwg
SUQuIEJ1dCBJIGFtIHdvbmRlcmluZyBhYm91dCB0d28NCnRoaW5nczoNCg0KT3BlcmF0aW9uIGlz
IGNsZWFyIHRvIG1lIGluIGNhc2UgYSBzaW5nbGUgTU5JRCBpcyBwcmVzZW50IGluIGEgbWVzc2Fn
ZQ0KYW5kIEkgc2VlIHRoZSB2YWx1ZSBpbiBiZWluZw0KZmxleGlibGUgdG8gY2hvb3NlIGZyb20g
ZGlmZmVyZW50IHN1Yi10eXBlcy4gSWYgbXVsdGlwbGUgTU5JRHMgd2l0aA0KZGlmZmVyZW50IHN1
Yi10eXBlcyBhcmUgcHJlc2VudCBpbg0KYSBzaW5nbGUgbWVzc2FnZSwgd2hpY2ggb25lIHNob3Vs
ZCBlLmcuIHRoZSBMTUEgdGFrZSBmb3IgdGhlIEJDIGxvb2t1cC4uDQpObyBiaWcgcHJvYmxlbSB0
byBzb2x2ZSwgYnV0DQp0byBiZSBjb25zaWRlcmVkIGluIGltcGxlbWVudGF0aW9ucy4NCg0KSWYg
dGhlIHJlYXNvbiBmb3IgbXVsdGlwbGUgcHJlc2VudCBNTklEcyB3aXRoIGRpZmZlcmVudCBzdWIt
dHlwZXMgaXMgdG8NCmRvIG90aGVyIHRoaW5ncyB0aGFuIGlkZW50aWZ5aW5nDQp0aGUgbm9kZSBv
ciB1c2luZyB0aGUgSUQgYXMga2V5IGZvciBhIGxvb2t1cCwgSSBhbSB3b25kZXJpbmcgaWYgaXQg
d291bGQNCm5vdCBiZSBtb3JlIGFwcHJvcHJpYXRlDQp0byBnbyBmb3IgYSBkaWZmZXJlbnQgY29u
dGFpbmVyIG9wdGlvbiB0byBjYXJyeSBzdWNoIGluZm9ybWF0aW9uLg0KU29tZXRoaW5nIGxpa2Ug
YSBjb21wbGVtZW50YXJ5DQppZGVudGlmaWVyIG9wdGlvbi4NCg0KbWFyY28NCg0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIFtt
YWlsdG86c2d1bmRhdmVAY2lzY28uY29tXQ0KU2VudDogRG9ubmVyc3RhZywgMTEuIFNlcHRlbWJl
ciAyMDE0IDAwOjQyDQpUbzogQ2hhcmxpZSBQZXJraW5zOyBNYXJjbyBMaWVic2NoOyBkbW1AaWV0
Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCkNjOiBWaWpheSBEZXZhcmFwYWxsaQ0KU3ViamVj
dDogUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hhcnRlcmluZy4uDQoNCkhlbGxvIENoYXJs
aWUsDQoNCkFncmVlIHdpdGggdGhhdC4gTU4tSWQgYXMgaXRzIGRlZmluZWQgdG9kYXkgaXMgYSBs
b2dpY2FsIGlkZW50aWZpZXIuIEl0DQpkb2VzIG5vdA0KcmVxdWlyZSB0aGUgaWRlbnRpZmllciB0
byBiZSBib3VuZCB0byBhIHBoeXNpY2FsIGRldmljZSBvciBhIGludGVyZmFjZQ0KaWRlbnRpdHku
DQpCdXQsIHdlIGhhdmUgY2xlYXJseSBzZWVuIHJlcXVpcmVtZW50cyB3aGVyZSB0aGUgbmVlZCBp
cyBmb3IgZ2VuZXJhdGluZw0KaWRlbnRpZmllcnMgYmFzZWQgb24gc29tZSBwaHlzaWNhbCBpZGVu
dGlmaWVycy4gVGhvc2UgcGh5c2ljYWwNCmlkZW50aWZpZXJzIGluY2x1ZGUNCklNU0ksIE1TSVNE
TiwgSU1FSSwgTUFDIC4uZXRjLiBJZiB3ZSBjYW4gZGVmaW5lIGEgdHlwZSBmb3IgZWFjaCBvZiB0
aGUNCnNvdXJjZQ0KYW5kIHRoZSBydWxlcyBmb3IgZ2VuZXJhdGluZyBNTi1JRCBiYXNlZCB1c2lu
ZyB0aG9zZSBzb3VyY2VzLCB0aGUgc2VuZGVyDQphbmQNCnJlY2VpdmVyIHdpbGwgaGF2ZSBjbGVh
ciBndWlkYW5jZSBvbiBob3cgdG8gdXNlIHRoZSBzcGVjLiBTb21lIHBvaW50ZXJzLA0KZXhwbGFu
YXRpb24gYW5kIGV4YW1wbGVzIGZvciBlYWNoIG9mIHRob3NlIGlkZW50aWZpZXJzIHdpbGwgZ3Jl
YXRseSBoZWxwDQphdm9pZA0KaW50ZXItb3AgaXNzdWVzLg0KDQoNClJlZ2FyZHMNClNyaQ0KDQoN
Cg0KDQoNCg0KDQpPbiA5LzEwLzE0IDM6MjEgUE0sICJDaGFybGllIFBlcmtpbnMiIDxjaGFybGVz
LnBlcmtpbnNAZWFydGhsaW5rLm5ldD48bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsu
bmV0Pg0Kd3JvdGU6DQoNCg0KDQpIZWxsbyBmb2xrcywNCg0KSSB0aGluayBpdCdzIGJlc3QgdG8g
Y29uc2lkZXIgdGhlIE1OSUQgYXMgc2ltcGx5IGxpdmluZyBpbiBhIHNwYWNlIG9mDQppZGVudGlm
aWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVjaCBhYm91dCB3aGV0aGVyIGl0J3MgYSBsb2dpY2Fs
DQppZGVudGlmaWVyIG9yIGEgcGh5c2ljYWwgaWRlbnRpZmllci4gIElmIHRoZSBmb3JtZXIsIHRo
ZW4gc29tZXdoZXJlDQoocGVyaGFwcyBiZWxvdyB0aGUgbmV0d29yayBsYXllcikgdGhlIGxvZ2lj
YWwgaWRlbnRpZmllciBoYXMgYmVlbiBib3VuZA0KdG8gc29tZXRoaW5nIGluIHRoZSBwaHlzaWNh
bCBpbnRlcmZhY2UsIGJ1dCB0aGF0J3Mgbm90IG91ciBwcm9ibGVtLg0KDQpUaGUgbnVtYmVyIHNw
YWNlIGZvciB0eXBlcyBvZiBNTklEcyBpcyBsaWtlbHkgdG8gc3RheSBwcmV0dHkgZW1wdHksIHNv
DQpJJ2Qgc2F5IHdlIGNvdWxkIGFkZCBhcyBtYW55IHR5cGVzIGFzIHdvdWxkIGJlIGNvbnZlbmll
bnQgZm9yIHRoZQ0Kc29mdHdhcmUgZGVzaWduZXJzLiAgU28sIHdlIGNvdWxkIGNvbmNlaXZhYmx5
IGhhdmUgc2V2ZXJhbCBNTklEcw0KZGVmaW5lZCB0aGF0IGFsbCAibG9va2VkIGxpa2UiIE5BSXMg
KHdoaWNoLCB0aGVtc2VsdmVzLCAibG9vayBsaWtlIg0KRlFETnMpLg0KDQpSZWdhcmRzLA0KQ2hh
cmxpZSBQLg0KDQoNCg0KT24gOS8xMC8yMDE0IDg6MTEgQU0sIFNyaSBHdW5kYXZlbGxpIChzZ3Vu
ZGF2ZSkgd3JvdGU6DQoNCg0KWWVzLiBDdXJyZW50bHksIHRoZSBNTklEIGlzIGlmIHRoZSBuYWkg
Zm9ybWF0IGFuZCBpcyBvdmVybG9hZGVkLiBUaGUNCk1OSUQgIGluIDNHUFAgc3BlY3MgaXMgdGhl
IElNU0ktTkFJIChJTVNJQFJFQUxNKSwgaXRzIGJhc2VkIG9uIHRoZQ0KSU1TSS4gRXg6DQoiPElN
U0k+QGVwYy5tbmM8TU5DPi5tY2M8TUNDPi4zZ3BwbmV0d29yay5vcmfCsg0KDQpXZSBhbHNvIGhh
dmUgTUFDNDhAUkVBTE07DQoNCldlIGFsc28gaGF2ZSBhcHByb2FjaGVzIHRvIHRyYW5zZm9ybSBN
QUMgdG8gUHNldWRvIElNU0ksIGFuZCB0aGVuDQpjYXJyeSBJTVNJLU5BSSBhcyB0aGUgTU4tSUQu
DQoNCg0KU28sIHdlIG5lZWQgdW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBvZiB0aGUgdHlwZXMv
c291cmNlcy4NCg0KTU4tSWQgYmFzZWQgb24gSU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi4NCg0K
QWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElNU0kgYW5kIElNU0ktTkFJ
ID8NCg0KU3JpDQoNCg0KDQpPbiA5LzEwLzE0IDY6MjkgQU0sICJNYXJjbyBMaWVic2NoIiA8TWFy
Y28uTGllYnNjaEBuZWNsYWIuZXU+PG1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldT4gd3Jv
dGU6DQoNCg0KDQpJdCBzZWVtcyB0aGUgTU5JRCBpcyBzb21laG93IG92ZXJsb2FkZWQgdG8gY2Fy
cnkgYm90aCwgbm9kZS1zcGVjaWZpYw0KSURzLCAgZS5nLiBNQUMsIGFzIHdlbGwgYXMgc3Vic2Ny
aWJlciBJRHMsIHdoaWNoIGlzIHRoZSBJTVNJLg0KVGhlcmUgbWF5IGJlIHZhbHVlIGluIGFkZGlu
ZyB0aGUgSU1FSSB0byB0aGUgbGlzdCBvZiBwb3NzaWJsZSB0eXBlcw0Kb2YgIG5vZGUtc3BlY2lm
aWMgSURzLg0KDQptYXJjbw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3JpIEd1bmRh
dmVsbGkNCihzZ3VuZGF2ZSkNClNlbnQ6IERpZW5zdGFnLCA5LiBTZXB0ZW1iZXIgMjAxNCAyMzoz
MA0KVG86IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSk7IENoYXJsaWUgUGVya2luczsgZG1tQGll
dGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpDYzogVmlqYXkgRGV2YXJhcGFsbGkNClN1Ympl
Y3Q6IFJlOiBbRE1NXSByZWdhcmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLg0KDQpUd28gbW9yZSBj
b21tZW50cy4NCg0KDQoNCjQuKSBJJ2QgYWxzbyB1c2Ugc3ViLXR5cGUgdmFsdWUgb2YgKDIpIGZv
ciBJTVNJLiBKdXN0IHRvIGFsaWduIHdpdGgNCnRoZSAgc3ViLXR5cGVzICBkZWZpbmVkIGZvciBN
TiBJZCBkZWZpbmVkIGZvciBJQ01QLiBJIHN1c3BlY3QgdGhlcmUNCmFyZSBzb21lICBpbXBsZW1l
bnRhdGlvbnMgIGFscmVhZHkgdXNpbmcgc3ViLXR5cGUgKDIpLiBQbGVhc2Ugc2VlDQp0aGUgb3Ro
ZXIgdGhyZWFkLg0KDQoNCjUuKSBGb3IgZWFjaCBvZiB0aGUgc3ViLXR5cGVzLCB3ZSBuZWVkIHRl
eHQgaW5jbHVkaW5nIGV4YW1wbGVzIGFuZA0Kc29tZQ0KZXhwbGFuYXRpb24gb24gaG93IHRoZXkg
YXJlIHVzZWQuDQoNCg0KU3JpDQoNCg0KDQpPbiA5LzkvMTQgMjoyMCBQTSwgIlNyaSBHdW5kYXZl
bGxpIChzZ3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb20+PG1haWx0bzpzZ3VuZGF2ZUBjaXNj
by5jb20+DQp3cm90ZToNCg0KDQoNCkhpIENoYXJsaWUsDQoNClRoaXMgaXMgZ29vZC4gVGhhbmtz
Lg0KDQoNCjEuKSBJZiBFVUktNDggYW5kIEVVSS02NCBhZGRyZXNzZXMgYXJlIGRlcml2ZWQgb2Yg
YSA0OC1iaXQgSUVFRQ0KODAyLjINCmFkZHJlc3MsIHdoeSBkbyB3ZSBuZWVkIHRvIHR3byBzdWIt
dHlwZXMgPyBXaHkgbm90IGhhdmUganVzdCBvbmUNCnN1Yi10eXBlIGZvciBtYWMgYmFzZWQgaWRl
bnRpZmllcnMgPw0KDQoyLikgU3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJlbnRseSB1c2VkLiBJ
dHMgY3VycmVudGx5IG92ZXJsb2FkZWQNCmZvcg0KSU1TSS1OQUkgKDNHUFAgc3BlY3MpIGFuZCBn
ZW5lcmljIE5BSSBiYXNlZCBpZGVudGlmaWVycy4gR2l2ZW4gdGhlDQpkZWZpbml0aW9uIG9mIG5l
dyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxhaW5pbmcgdGhlDQptb3RpdmF0aW9u
DQoNCjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElQdjYgYWRkcmVzcy4g
V2hhdCBleGFjdGx5DQppcw0KdGhpcyA/IEFyZSB0aGVzZSBDR0EtYmFzZWQgSVB2NiBhZGRyZXNz
ZXMgPw0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICBOZXcgTW9iaWxlIE5vZGUgSWRlbnRp
ZmllciBUeXBlcw0KDQogICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgfCBJZGVudGlmaWVyIFR5cGUgfCBJZGVu
dGlmaWVyIFR5cGUgTnVtYmVyIHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSst
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICB8IElQdjYgQWRkcmVzcyAg
ICB8IDIgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgSU1TSSAg
ICAgICAgICAgIHwgMyAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAg
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg
fCBQLVRNU0kgICAgICAgICAgfCA0ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg
ICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAg
ICAgICAgICB8IEVVSS00OCBhZGRyZXNzICB8IDUgICAgICAgICAgICAgICAgICAgICAgfA0KICAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgICAgICAgICAgICAgIHwgRVVJLTY0IGFkZHJlc3MgIHwgNiAgICAgICAgICAgICAgICAgICAg
ICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg
ICAgICAgfA0KICAgICAgICAgICAgICAgfCBHVVRJICAgICAgICAgICAgfCA3ICAgICAgICAgICAg
ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0rDQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMNClNyaQ0KUFM6IEdvb2QgdG8g
c2VlIFZpamF5IGJhY2sNCg0KDQpPbiA5LzkvMTQgMToyOCBQTSwgIkNoYXJsaWUgUGVya2lucyIN
CjxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD48bWFpbHRvOmNoYXJsZXMucGVya2luc0Bl
YXJ0aGxpbmsubmV0Pg0Kd3JvdGU6DQoNCg0KDQpIZWxsbyBmb2xrcywNCg0KSGVyZSdzIHRoZSBs
YXN0IEludGVybmV0IERyYWZ0IHRoYXQgd2UgZGlkLCBsb25nIGFnbyBleHBpcmVkOg0KDQpodHRw
Oi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVya2lucy1tZXh0LTQyODNtbmlkcy0w
MS50eHQNCg0KSSdsbCByZXN1Ym1pdCBpdCB3aXRoIGEgZmV3IHVwZGF0ZXMgYXMgYSBwZXJzb25h
bCBkcmFmdCB0byBkbW0uDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCg0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRt
bUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZG1tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRm
Lm9yZz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlz
dA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9kbW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1t
QGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWls
aW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0KDQoNCi0tDQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCkhha2ltYSBDaGFvdWNoaQ0KUHJvZmVzc29yDQpUZWxlY29tIFN1
ZCBQYXJpcw0KSW5zdGl0dXQgTWluZXMgVGVsZWNvbQ0KOSBydWUgQ2hhcmxlcyBGb3VyaWVyDQo5
MTAxMSBFdnJ5DQowMTYwNzY0NDQzDQoNCg==

--_000_D04450E516608Fsgundaveciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <2C116A780C6A7F4F86167BAB8F798E49@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+SGkgSGFraW1h
LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhdCBpcyBhIGdvb2QgaWRlYS4gV2Ug
c2hvdWxkIHJlZ2lzdGVyIGEgdHlwZSBmb3IgdGhlIERvZC05NiBpZGVudGlmaWVyIGFzIHdlbGwu
PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJk
czwvZGl2Pg0KPGRpdj5Tcmk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQt
ZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJs
YWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25l
OyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDog
MGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0g
bm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+
RnJvbTogPC9zcGFuPkhha2ltYSBDaGFvdWNoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhha2ltYS5j
aGFvdWNoaUB0ZWxlY29tLXN1ZHBhcmlzLmV1Ij5oYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRw
YXJpcy5ldTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6
IDwvc3Bhbj5TdW5kYXksIFNlcHRlbWJlciAyMSwgMjAxNCA4OjExIEFNPGJyPg0KPHNwYW4gc3R5
bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+U3JpIEd1bmRhdmVsbGkgJmx0OzxhIGhy
ZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iPnNndW5kYXZlQGNpc2NvLmNvbTwvYT4mZ3Q7
PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+Q2hhcmxpZSBQ
ZXJraW5zICZsdDs8YSBocmVmPSJtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQi
PmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PC9hPiZndDssIE1hcmNvIExpZWJzY2ggJmx0
OzxhIGhyZWY9Im1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldSI+TWFyY28uTGllYnNjaEBu
ZWNsYWIuZXU8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1t
QGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5k
bW1AaWV0Zi5vcmc8L2E+Jmd0OywgVmlqYXkgRGV2YXJhcGFsbGkgJmx0OzxhIGhyZWY9Im1haWx0
bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20iPmR2aWpheUByb2NrZXRtYWlsLmNvbTwvYT4mZ3Q7PGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0RN
TV0gTU5JRCBUeXBlczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRp
bWVzLCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMCI+DQo8ZGl2PkhlbGxv
IEZvbGtzLDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RG8geW91IHRoaW5r
IHRoYXQgY29uc2lkZXJpbmcgc3BlY2lmaWMgYnV0IG5lZWRlZCB0ZWNobm9sb2dpZXMgZm9yIG1v
dmluZyBvYmplY3RzIGluJm5ic3A7IEludGVybmV0IG9mIFRoaW5ncyZuYnNwOyBzdWNoIGFzIFJG
SUQgKFJhZGlvIEZyZXF1ZW5jeSBJZGVudGlmaWVyKSB3aXRoIDk2IGJpdHMgaWRlbnRpZmllcnMg
d2lsbCBiZSBhbHNvIHJlbGV2ZW50IHRvIENoYXJsaWUncyBjdXJyZW50IGRyYWZ0IGFuZCB0aGUg
ZWZmb3J0cyByZWxhdGVkIHRvIE1OSUQ/Jm5ic3A7DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj5IYWtpbWE8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGhyIGlkPSJ6d2NociI+DQo8ZGl2IHN0eWxlPSJjb2xvcjojMDAwO2ZvbnQtd2VpZ2h0Om5v
cm1hbDtmb250LXN0eWxlOm5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LWZhbWlseTpI
ZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTJwdDsiPg0KPGI+RGU6IDwvYj4m
cXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86
c2d1bmRhdmVAY2lzY28uY29tIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPsOA
OiA8L2I+JnF1b3Q7Q2hhcmxpZSBQZXJraW5zJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hh
cmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQiPmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0
PC9hPiZndDssICZxdW90O01hcmNvIExpZWJzY2gmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpN
YXJjby5MaWVic2NoQG5lY2xhYi5ldSI+TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8L2E+Jmd0OywN
CjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT4sICZxdW90O1Zp
amF5IERldmFyYXBhbGxpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHZpamF5QHJvY2tldG1h
aWwuY29tIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkVudm95w6k6IDwv
Yj5KZXVkaSAxMSBTZXB0ZW1icmUgMjAxNCAyMzo1NzoxMTxicj4NCjxiPk9iamV0OiA8L2I+UmU6
IFtETU1dIE1OSUQgVHlwZXM8YnI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5IaSBDaGFybGll
LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RmV3IG1vcmUgcmV2aWV3cy9kaXNjdXNz
aW9ucyBhbmQgY2FwdHVyaW5nIHRoZSBjb25zZW5zdXMgaW4gdGhlIGJhc2UgdmVyc2lvbiB3aWxs
IGhlbHAuIEJ1dCwgSSdtIG9rIGVpdGhlciB3YXkg4oCmPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkczwvZGl2Pg0KPGRpdj5Tcmk8L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRp
diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246
bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVG
VDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQ
QURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVIt
UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250
LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Q2hhcmxpZSBQZXJraW5zICZsdDs8YSBocmVmPSJt
YWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQiIHRhcmdldD0iX2JsYW5rIj5jaGFy
bGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt
d2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgU2VwdGVtYmVyIDExLCAyMDE0IDI6
NDYgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5Tcmkg
R3VuZGF2ZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPnNndW5kYXZlQGNpc2NvLmNvbTwvYT4mZ3Q7LCBNYXJjbyBMaWVic2NoICZsdDs8
YSBocmVmPSJtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXUiIHRhcmdldD0iX2JsYW5rIj5N
YXJjby5MaWVic2NoQG5lY2xhYi5ldTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZG1t
QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8
YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3Jn
PC9hPiZndDssIFZpamF5IERldmFyYXBhbGxpICZsdDs8YSBocmVmPSJtYWlsdG86ZHZpamF5QHJv
Y2tldG1haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHZpamF5QHJvY2tldG1haWwuY29tPC9hPiZn
dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJl
OiBbRE1NXSBNTklEIFR5cGVzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgZGF0YS1tY2Ut
c3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyIgZmFjZT0iQ2FsaWJyaSI+PGJpZz5IZWxsbyBm
b2xrcyw8YnI+DQo8YnI+DQpJIHByb3Bvc2UgdG8gc3VibWl0IHRoZSAuLi4uLTAwLnR4dCBkb2N1
bWVudCBhcyBpdCBpcyB0byB0aGUgSW50ZXJuZXQ8YnI+DQpEcmFmdHMgZGlyZWN0b3J5LCBhbmQg
dGhlbiB0byBnbyBhYm91dCBtYWtpbmcgdXBkYXRlcyBhY2NvcmRpbmcgdG88YnI+DQp0aGUgZGlz
Y3Vzc2lvbiBvbiB0aGlzIGxpc3QuJm5ic3A7IERvIHlvdSB0aGluayB0aGlzIGlzIHJlYXNvbmFi
bGU/PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpDaGFybGllIFAuPGJyPg0KPGJyPg0KPC9iaWc+
PC9zcGFuPjxicj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gOS8xMS8yMDE0IDc6
MjEgQU0sIFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6PGJyPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSBjaXRlPSJtaWQ6RDAzNkZCNUYuMTYzQzlEJTI1c2d1bmRhdmVAY2lzY28uY29tIj4N
CjxwcmU+Jmx0O0NoYW5naW5nIHRoZSBzdWJqZWN0IGxpbmUgdG8gcmVmbGVjdCB0aGUgTU5JZCBk
aXNjdXNzaW9uJmd0Ow0KDQoNCk1hcmNvLA0KDQoNClRoaW5raW5nIGZ1cnRoZXIgb24gdGhlIGNv
bXBsZW1lbnRhcnkgaWRlbnRpZmllciBvcHRpb24uDQoNCi0gVGhlcmUgaXMgYWxyZWFkeSB0aGUg
bGluay1sYXllciBpZGVudGlmaWVyIG9wdGlvbiB0aGF0IGNhbiBiZSB1c2VkIGZvcg0KY2Fycnlp
bmcgdGhlIE1hYyBhZGRyZXNzDQotIElNRUkgYW5kIE1TSVNETiBhcmUgYWxyZWFkeSBkZWZpbmVk
IGluIDI5LjI3NSBhcyBhIDNHUFAgVlNFJ3MNCg0KSW4gc29tZSBzZW5zZSwgdGhlIGNvbXBsZW1l
bnRhcnkgaWRlbnRpZmllcnMgYXJlIGFscmVhZHkgcHJlc2VudC4NCg0KU3JpDQoNCg0KDQoNCg0K
T24gOS8xMS8xNCA2OjU4IEFNLCAmcXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7
IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBj
aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj4mbHQ7c2d1bmRhdmVAY2lzY28uY29tJmd0OzwvYT4g
d3JvdGU6DQo8L3ByZT4NCjxibG9ja3F1b3RlPg0KPHByZT5JIGRvIG5vdCBzZWUgYSByZWFzb24g
d2h5IG11bHRpcGxlIE1OLUlkIGluc3RhbmNlcyBuZWVkIHRvIGJlIHByZXNlbnQgaW4gYQ0Kc2lu
Z2xlIG1lc3NhZ2UgPyBJbiBteSBleHBlcmllbmNlLCB0aGlzIGlzIHN0cmljdGx5IGEgZGVwbG95
bWVudA0KY29uc2lkZXJhdGlvbiwgd2hlbiB0byB1c2Ugd2hhdCB0eXBlIG9mIGlkZW50aWZpZXJz
Lg0KDQpBc3N1bWluZyB0aGUgYmFja2VuZCBzeXN0ZW0gY2FuIHRpZSBhbGwgdGhlIE1OLUlkJ3Mg
dG8gYSBzaW5nbGUNCnN1YnNjcmlwdGlvbiwgYW55IHByZXNlbnRlZCBpZGVudGlmaWVyIGNhbiBi
ZSBzdWZmaWNpZW50IGZvciB0aGUgZ2F0ZXdheQ0KdG8gZG8gdGhlIEJDRSBsb29rdXAuDQoNCklm
IG11bHRpcGxlIGluc3RhbmNlcyBjYW4gYmUgcHJlc2VudCwgdGhlbiB3ZSBuZWVkIHRvIGRlYWwg
d2l0aCBtb3JlIGVycm9yDQpjYXNlcy4gSXMgdGhhdCByZWFsbHkgbmVlZGVkID8NCg0KDQo8L3By
ZT4NCjxibG9ja3F1b3RlPg0KPHByZT5JIGFtIHdvbmRlcmluZyBpZiBpdCB3b3VsZCBub3QgYmUg
bW9yZSBhcHByb3ByaWF0ZSB0byBnbyBmb3IgYSBkaWZmZXJlbnQNCmNvbnRhaW5lciBvcHRpb24g
dG8gY2Fycnkgc3VjaCBpbmZvcm1hdGlvbi4gU29tZXRoaW5nIGxpa2UgYQ0KY29tcGxlbWVudGFy
eSBpZGVudGlmaWVyIG9wdGlvbi4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5Tb3VuZHMg
aW50ZXJlc3RpbmcuIEFyZSB5b3Ugc3VnZ2VzdGluZyB3ZSBsZWF2ZSB0aGUgY3VycmVudCBNTi1J
RCBhcyBpdA0KaXMsIGJ1dCB1c2UgYSBuZXcgY29tcGxlbWVudGFyeSBvcHRpb24gPyBCdXQsIGlm
IHRoZSByZXF1aXJlbWVudCBpcyBmb3IgYQ0KTWFjIGJhc2VkIGlkZW50aWZpZXJzLCB3aGF0IHdp
bGwgYmUgdGhlcmUgaW4gdGhlIGN1cnJlbnQgTU4tSWQgb3B0aW9uID8gV2UNCnN0aWxsIG5lZWQg
dG8gaGF2ZSBpZGVudGlmaWVyIHRoZXJlID8NCg0KDQoNCg0KU3JpDQoNCg0KDQoNCg0KT24gOS8x
MS8xNCAyOjAzIEFNLCAmcXVvdDtNYXJjbyBMaWVic2NoJnF1b3Q7IDxhIGNsYXNzPSJtb3otdHh0
LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldSIgdGFy
Z2V0PSJfYmxhbmsiPiZsdDtNYXJjby5MaWVic2NoQG5lY2xhYi5ldSZndDs8L2E+IHdyb3RlOg0K
DQo8L3ByZT4NCjxibG9ja3F1b3RlPg0KPHByZT5ObyBpc3N1ZSB3aXRoIGxvZ2ljYWwgdnMuIHBo
eXNpY2FsIElELiBCdXQgSSBhbSB3b25kZXJpbmcgYWJvdXQgdHdvDQp0aGluZ3M6DQoNCk9wZXJh
dGlvbiBpcyBjbGVhciB0byBtZSBpbiBjYXNlIGEgc2luZ2xlIE1OSUQgaXMgcHJlc2VudCBpbiBh
IG1lc3NhZ2UNCmFuZCBJIHNlZSB0aGUgdmFsdWUgaW4gYmVpbmcNCmZsZXhpYmxlIHRvIGNob29z
ZSBmcm9tIGRpZmZlcmVudCBzdWItdHlwZXMuIElmIG11bHRpcGxlIE1OSURzIHdpdGgNCmRpZmZl
cmVudCBzdWItdHlwZXMgYXJlIHByZXNlbnQgaW4NCmEgc2luZ2xlIG1lc3NhZ2UsIHdoaWNoIG9u
ZSBzaG91bGQgZS5nLiB0aGUgTE1BIHRha2UgZm9yIHRoZSBCQyBsb29rdXAuLg0KTm8gYmlnIHBy
b2JsZW0gdG8gc29sdmUsIGJ1dA0KdG8gYmUgY29uc2lkZXJlZCBpbiBpbXBsZW1lbnRhdGlvbnMu
DQoNCklmIHRoZSByZWFzb24gZm9yIG11bHRpcGxlIHByZXNlbnQgTU5JRHMgd2l0aCBkaWZmZXJl
bnQgc3ViLXR5cGVzIGlzIHRvDQpkbyBvdGhlciB0aGluZ3MgdGhhbiBpZGVudGlmeWluZw0KdGhl
IG5vZGUgb3IgdXNpbmcgdGhlIElEIGFzIGtleSBmb3IgYSBsb29rdXAsIEkgYW0gd29uZGVyaW5n
IGlmIGl0IHdvdWxkDQpub3QgYmUgbW9yZSBhcHByb3ByaWF0ZQ0KdG8gZ28gZm9yIGEgZGlmZmVy
ZW50IGNvbnRhaW5lciBvcHRpb24gdG8gY2Fycnkgc3VjaCBpbmZvcm1hdGlvbi4NClNvbWV0aGlu
ZyBsaWtlIGEgY29tcGxlbWVudGFyeQ0KaWRlbnRpZmllciBvcHRpb24uDQoNCm1hcmNvDQoNCjwv
cHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t
OiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIFs8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0
ZXh0IiBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFp
bHRvOnNndW5kYXZlQGNpc2NvLmNvbTwvYT5dDQpTZW50OiBEb25uZXJzdGFnLCAxMS4gU2VwdGVt
YmVyIDIwMTQgMDA6NDINClRvOiBDaGFybGllIFBlcmtpbnM7IE1hcmNvIExpZWJzY2g7IDxhIGNs
YXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+DQpDYzogVmlqYXkgRGV2YXJhcGFsbGkN
ClN1YmplY3Q6IFJlOiBbRE1NXSByZWdhcmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLg0KDQpIZWxs
byBDaGFybGllLA0KDQpBZ3JlZSB3aXRoIHRoYXQuIE1OLUlkIGFzIGl0cyBkZWZpbmVkIHRvZGF5
IGlzIGEgbG9naWNhbCBpZGVudGlmaWVyLiBJdA0KZG9lcyBub3QNCnJlcXVpcmUgdGhlIGlkZW50
aWZpZXIgdG8gYmUgYm91bmQgdG8gYSBwaHlzaWNhbCBkZXZpY2Ugb3IgYSBpbnRlcmZhY2UNCmlk
ZW50aXR5Lg0KQnV0LCB3ZSBoYXZlIGNsZWFybHkgc2VlbiByZXF1aXJlbWVudHMgd2hlcmUgdGhl
IG5lZWQgaXMgZm9yIGdlbmVyYXRpbmcNCmlkZW50aWZpZXJzIGJhc2VkIG9uIHNvbWUgcGh5c2lj
YWwgaWRlbnRpZmllcnMuIFRob3NlIHBoeXNpY2FsDQppZGVudGlmaWVycyBpbmNsdWRlDQpJTVNJ
LCBNU0lTRE4sIElNRUksIE1BQyAuLmV0Yy4gSWYgd2UgY2FuIGRlZmluZSBhIHR5cGUgZm9yIGVh
Y2ggb2YgdGhlDQpzb3VyY2UNCmFuZCB0aGUgcnVsZXMgZm9yIGdlbmVyYXRpbmcgTU4tSUQgYmFz
ZWQgdXNpbmcgdGhvc2Ugc291cmNlcywgdGhlIHNlbmRlcg0KYW5kDQpyZWNlaXZlciB3aWxsIGhh
dmUgY2xlYXIgZ3VpZGFuY2Ugb24gaG93IHRvIHVzZSB0aGUgc3BlYy4gU29tZSBwb2ludGVycywN
CmV4cGxhbmF0aW9uIGFuZCBleGFtcGxlcyBmb3IgZWFjaCBvZiB0aG9zZSBpZGVudGlmaWVycyB3
aWxsIGdyZWF0bHkgaGVscA0KYXZvaWQNCmludGVyLW9wIGlzc3Vlcy4NCg0KDQpSZWdhcmRzDQpT
cmkNCg0KDQoNCg0KDQoNCg0KT24gOS8xMC8xNCAzOjIxIFBNLCAmcXVvdDtDaGFybGllIFBlcmtp
bnMmcXVvdDsgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmNo
YXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2NoYXJsZXMu
cGVya2luc0BlYXJ0aGxpbmsubmV0Jmd0OzwvYT4NCndyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1
b3RlPg0KPHByZT5IZWxsbyBmb2xrcywNCg0KSSB0aGluayBpdCdzIGJlc3QgdG8gY29uc2lkZXIg
dGhlIE1OSUQgYXMgc2ltcGx5IGxpdmluZyBpbiBhIHNwYWNlIG9mDQppZGVudGlmaWVycywgYW5k
IG5vdCB3b3JyeSB0b28gbXVjaCBhYm91dCB3aGV0aGVyIGl0J3MgYSBsb2dpY2FsDQppZGVudGlm
aWVyIG9yIGEgcGh5c2ljYWwgaWRlbnRpZmllci4gIElmIHRoZSBmb3JtZXIsIHRoZW4gc29tZXdo
ZXJlDQoocGVyaGFwcyBiZWxvdyB0aGUgbmV0d29yayBsYXllcikgdGhlIGxvZ2ljYWwgaWRlbnRp
ZmllciBoYXMgYmVlbiBib3VuZA0KdG8gc29tZXRoaW5nIGluIHRoZSBwaHlzaWNhbCBpbnRlcmZh
Y2UsIGJ1dCB0aGF0J3Mgbm90IG91ciBwcm9ibGVtLg0KDQpUaGUgbnVtYmVyIHNwYWNlIGZvciB0
eXBlcyBvZiBNTklEcyBpcyBsaWtlbHkgdG8gc3RheSBwcmV0dHkgZW1wdHksIHNvDQpJJ2Qgc2F5
IHdlIGNvdWxkIGFkZCBhcyBtYW55IHR5cGVzIGFzIHdvdWxkIGJlIGNvbnZlbmllbnQgZm9yIHRo
ZQ0Kc29mdHdhcmUgZGVzaWduZXJzLiAgU28sIHdlIGNvdWxkIGNvbmNlaXZhYmx5IGhhdmUgc2V2
ZXJhbCBNTklEcw0KZGVmaW5lZCB0aGF0IGFsbCAmcXVvdDtsb29rZWQgbGlrZSZxdW90OyBOQUlz
ICh3aGljaCwgdGhlbXNlbHZlcywgJnF1b3Q7bG9vayBsaWtlJnF1b3Q7DQpGUUROcykuDQoNClJl
Z2FyZHMsDQpDaGFybGllIFAuDQoNCg0KDQpPbiA5LzEwLzIwMTQgODoxMSBBTSwgU3JpIEd1bmRh
dmVsbGkgKHNndW5kYXZlKSB3cm90ZToNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPlllcy4g
Q3VycmVudGx5LCB0aGUgTU5JRCBpcyBpZiB0aGUgbmFpIGZvcm1hdCBhbmQgaXMgb3ZlcmxvYWRl
ZC4gVGhlDQpNTklEICBpbiAzR1BQIHNwZWNzIGlzIHRoZSBJTVNJLU5BSSAoSU1TSUBSRUFMTSks
IGl0cyBiYXNlZCBvbiB0aGUNCklNU0kuIEV4Og0KJnF1b3Q7Jmx0O0lNU0kmZ3Q7QGVwYy5tbmMm
bHQ7TU5DJmd0Oy5tY2MmbHQ7TUNDJmd0Oy4zZ3BwbmV0d29yay5vcmfCsg0KDQpXZSBhbHNvIGhh
dmUgTUFDNDhAUkVBTE07DQoNCldlIGFsc28gaGF2ZSBhcHByb2FjaGVzIHRvIHRyYW5zZm9ybSBN
QUMgdG8gUHNldWRvIElNU0ksIGFuZCB0aGVuDQpjYXJyeSBJTVNJLU5BSSBhcyB0aGUgTU4tSUQu
DQoNCg0KU28sIHdlIG5lZWQgdW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBvZiB0aGUgdHlwZXMv
c291cmNlcy4NCg0KTU4tSWQgYmFzZWQgb24gSU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi4NCg0K
QWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElNU0kgYW5kIElNU0ktTkFJ
ID8NCg0KU3JpDQoNCg0KDQpPbiA5LzEwLzE0IDY6MjkgQU0sICZxdW90O01hcmNvIExpZWJzY2gm
cXVvdDsgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOk1hcmNv
LkxpZWJzY2hAbmVjbGFiLmV1IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O01hcmNvLkxpZWJzY2hAbmVj
bGFiLmV1Jmd0OzwvYT4gd3JvdGU6DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPkl0IHNl
ZW1zIHRoZSBNTklEIGlzIHNvbWVob3cgb3ZlcmxvYWRlZCB0byBjYXJyeSBib3RoLCBub2RlLXNw
ZWNpZmljDQpJRHMsICBlLmcuIE1BQywgYXMgd2VsbCBhcyBzdWJzY3JpYmVyIElEcywgd2hpY2gg
aXMgdGhlIElNU0kuDQpUaGVyZSBtYXkgYmUgdmFsdWUgaW4gYWRkaW5nIHRoZSBJTUVJIHRvIHRo
ZSBsaXN0IG9mIHBvc3NpYmxlIHR5cGVzDQpvZiAgbm9kZS1zcGVjaWZpYyBJRHMuDQoNCm1hcmNv
DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBkbW0gWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Im1haWx0
bzpkbW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpkbW0tYm91bmNl
c0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTcmkgR3VuZGF2ZWxsaQ0KKHNndW5kYXZlKQ0K
U2VudDogRGllbnN0YWcsIDkuIFNlcHRlbWJlciAyMDE0IDIzOjMwDQpUbzogU3JpIEd1bmRhdmVs
bGkgKHNndW5kYXZlKTsgQ2hhcmxpZSBQZXJraW5zOyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFi
YnJldmlhdGVkIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1t
QGlldGYub3JnPC9hPg0KQ2M6IFZpamF5IERldmFyYXBhbGxpDQpTdWJqZWN0OiBSZTogW0RNTV0g
cmVnYXJkaW5nIHRoZSByZS1jaGFydGVyaW5nLi4NCg0KVHdvIG1vcmUgY29tbWVudHMuDQoNCg0K
DQo0LikgSSdkIGFsc28gdXNlIHN1Yi10eXBlIHZhbHVlIG9mICgyKSBmb3IgSU1TSS4gSnVzdCB0
byBhbGlnbiB3aXRoDQp0aGUgIHN1Yi10eXBlcyAgZGVmaW5lZCBmb3IgTU4gSWQgZGVmaW5lZCBm
b3IgSUNNUC4gSSBzdXNwZWN0IHRoZXJlDQphcmUgc29tZSAgaW1wbGVtZW50YXRpb25zICBhbHJl
YWR5IHVzaW5nIHN1Yi10eXBlICgyKS4gUGxlYXNlIHNlZQ0KdGhlIG90aGVyIHRocmVhZC4NCg0K
DQo1LikgRm9yIGVhY2ggb2YgdGhlIHN1Yi10eXBlcywgd2UgbmVlZCB0ZXh0IGluY2x1ZGluZyBl
eGFtcGxlcyBhbmQNCnNvbWUNCmV4cGxhbmF0aW9uIG9uIGhvdyB0aGV5IGFyZSB1c2VkLg0KDQoN
ClNyaQ0KDQoNCg0KT24gOS85LzE0IDI6MjAgUE0sICZxdW90O1NyaSBHdW5kYXZlbGxpIChzZ3Vu
ZGF2ZSkmcXVvdDsgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRv
OnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtzZ3VuZGF2ZUBjaXNjby5j
b20mZ3Q7PC9hPg0Kd3JvdGU6DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPkhpIENoYXJs
aWUsDQoNClRoaXMgaXMgZ29vZC4gVGhhbmtzLg0KDQoNCjEuKSBJZiBFVUktNDggYW5kIEVVSS02
NCBhZGRyZXNzZXMgYXJlIGRlcml2ZWQgb2YgYSA0OC1iaXQgSUVFRQ0KODAyLjINCmFkZHJlc3Ms
IHdoeSBkbyB3ZSBuZWVkIHRvIHR3byBzdWItdHlwZXMgPyBXaHkgbm90IGhhdmUganVzdCBvbmUN
CnN1Yi10eXBlIGZvciBtYWMgYmFzZWQgaWRlbnRpZmllcnMgPw0KDQoyLikgU3ViIHR5cGUgdmFs
dWUgKDEpIGlzIGN1cnJlbnRseSB1c2VkLiBJdHMgY3VycmVudGx5IG92ZXJsb2FkZWQNCmZvcg0K
SU1TSS1OQUkgKDNHUFAgc3BlY3MpIGFuZCBnZW5lcmljIE5BSSBiYXNlZCBpZGVudGlmaWVycy4g
R2l2ZW4gdGhlDQpkZWZpbml0aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0
IGV4cGxhaW5pbmcgdGhlDQptb3RpdmF0aW9uDQoNCjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1
ZSBvZiAoMikgZm9yIElQdjYgYWRkcmVzcy4gV2hhdCBleGFjdGx5DQppcw0KdGhpcyA/IEFyZSB0
aGVzZSBDR0EtYmFzZWQgSVB2NiBhZGRyZXNzZXMgPw0KDQoNCg0KDQogICAgICAgICAgICAgICAg
ICAgICBOZXcgTW9iaWxlIE5vZGUgSWRlbnRpZmllciBUeXBlcw0KDQogICAgICAgICAgICAgICAm
IzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOw0K
ICAgICAgICAgICAgICAgfCBJZGVudGlmaWVyIFR5cGUgfCBJZGVudGlmaWVyIFR5cGUgTnVtYmVy
IHwNCiAgICAgICAgICAgICAgICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSYjNDM7DQogICAgICAgICAgICAgICB8IElQdjYgQWRkcmVzcyAgICB8IDIg
ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg
fCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgSU1TSSAgICAgICAg
ICAgIHwgMyAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBQLVRN
U0kgICAgICAgICAgfCA0ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwg
ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg
ICB8IEVVSS00OCBhZGRyZXNzICB8IDUgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg
ICAgICAgICAgIHwgRVVJLTY0IGFkZHJlc3MgIHwgNiAgICAgICAgICAgICAgICAgICAgICB8DQog
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg
fA0KICAgICAgICAgICAgICAgfCBHVVRJICAgICAgICAgICAgfCA3ICAgICAgICAgICAgICAgICAg
ICAgIHwNCiAgICAgICAgICAgICAgICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLSYjNDM7DQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMNClNyaQ0KUFM6IEdv
b2QgdG8gc2VlIFZpamF5IGJhY2sNCg0KDQpPbiA5LzkvMTQgMToyOCBQTSwgJnF1b3Q7Q2hhcmxp
ZSBQZXJraW5zJnF1b3Q7DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJt
YWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQiIHRhcmdldD0iX2JsYW5rIj4mbHQ7
Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQmZ3Q7PC9hPg0Kd3JvdGU6DQoNCjwvcHJlPg0K
PGJsb2NrcXVvdGU+DQo8cHJlPkhlbGxvIGZvbGtzLA0KDQpIZXJlJ3MgdGhlIGxhc3QgSW50ZXJu
ZXQgRHJhZnQgdGhhdCB3ZSBkaWQsIGxvbmcgYWdvIGV4cGlyZWQ6DQoNCjxhIGNsYXNzPSJtb3ot
dHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9k
cmFmdC1wZXJraW5zLW1leHQtNDI4M21uaWRzLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6
Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1wZXJraW5zLW1leHQtNDI4M21uaWRzLTAx
LnR4dDwvYT4NCg0KSSdsbCByZXN1Ym1pdCBpdCB3aXRoIGEgZmV3IHVwZGF0ZXMgYXMgYSBwZXJz
b25hbCBkcmFmdCB0byBkbW0uDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQo8L3ByZT4NCjwvYmxv
Y2txdW90ZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0
ZWQiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5v
cmc8L2E+PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvYT48YnIgZGF0YS1tY2UtYm9ndXM9IjEi
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQt
bGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPmRtbUBpZXRmLm9yZzwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxh
bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjxiciBkYXRh
LW1jZS1ib2d1cz0iMSI+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJl
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv
Y2txdW90ZT4NCjxwcmU+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQo8YSBj
bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmst
ZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1t
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k
bW08L2E+PGJyIGRhdGEtbWNlLWJvZ3VzPSIxIj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWls
aW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0
bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGEgY2xhc3M9
Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2RtbTwvYT48YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48YnI+DQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0K
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjxicj4NCjwvZGl2Pg0KPGRp
dj48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0tIDxicj4NCjwv
ZGl2Pg0KPGRpdj48c3BhbiBuYW1lPSJ4Ij48L3NwYW4+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRpdj5IYWtpbWEgQ2hhb3VjaGk8L2Rpdj4NCjxkaXY+
UHJvZmVzc29yPC9kaXY+DQo8ZGl2PlRlbGVjb20gU3VkIFBhcmlzPC9kaXY+DQo8ZGl2Pkluc3Rp
dHV0IE1pbmVzIFRlbGVjb208L2Rpdj4NCjxkaXY+OSBydWUgQ2hhcmxlcyBGb3VyaWVyPC9kaXY+
DQo8ZGl2PjkxMDExIEV2cnk8L2Rpdj4NCjxkaXY+MDE2MDc2NDQ0MzwvZGl2Pg0KPHNwYW4gbmFt
ZT0ieCI+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFu
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_D04450E516608Fsgundaveciscocom_--


From nobody Mon Sep 22 16:45:05 2014
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 135711A02C0 for ; Mon, 22 Sep 2014 16:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.087
X-Spam-Level: 
X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 P9aWynrJl00i for ; Mon, 22 Sep 2014 16:44:57 -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 454941A6F5D for ; Mon, 22 Sep 2014 16:44:55 -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 s8MNitS5018819; Mon, 22 Sep 2014 16:44:55 -0700
Received: from XCH-BLV-108.nw.nos.boeing.com (xch-blv-108.nw.nos.boeing.com [130.247.25.137]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8MNikqo018277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 22 Sep 2014 16:44:47 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-108.nw.nos.boeing.com ([169.254.13.75]) with mapi id 14.03.0181.006; Mon, 22 Sep 2014 16:44:46 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1Ykw
Date: Mon, 22 Sep 2014 23:44:46 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D23D03@XCH-BLV-504.nw.nos.boeing.com>
References: 
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_2134F8430051B64F815C691A62D9831832D23D03XCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/5GkxexDo8bC6S8wtz6lHPs5AG4k
Subject: Re: [DMM] Signaling Message Fragmentation
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, 22 Sep 2014 23:45:00 -0000

--_000_2134F8430051B64F815C691A62D9831832D23D03XCHBLV504nwnosb_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Sri,

My understanding is that if a source sends fragmented messages it must have=
 assurance
that the destination has a large enough reassembly buffer. Since the minimu=
m IPv6
reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmented p=
ackets
larger than 1500 bytes unless there is some other means of determining whet=
her the
destination's reassembly buffer can accommodate the larger size.

How big do you need?

Thanks - Fred

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda=
ve)
Sent: Thursday, September 18, 2014 1:04 PM
To: dmm@ietf.org
Subject: [DMM] Signaling Message Fragmentation

[Discussion under the maintenance scope]

With the standardization of all the new mobility options (ANI, QoS, IFOM, M=
NP..etc)   and specially with the NAI/Domain type fields in some of those o=
ptions, we are almost close to hitting the PBU/BU fragmentation limit.

Any thoughts on how to deal with this ? How is it solved in other message b=
ased protocols ? I've seen some work on IPSecme WG on IKEv2 message fragmen=
tation for the same issue.

Should we do some thing here ? Or, if any one has invested time on this and=
 has a proposal ? Comments ?



Regards
Sri

--_000_2134F8430051B64F815C691A62D9831832D23D03XCHBLV504nwnosb_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Sri,=



 <=
/p>

My understanding is that =
if a source sends fragmented messages it must have assurance


that the destination has =
a large enough reassembly buffer. Since the minimum IPv6<=
/p>

reassembly unit is only 1=
500 bytes, the source SHOULD NOT send fragmented packets<=
/p>

larger than 1500 bytes un=
less there is some other means of determining whether the=



destination’s reass=
embly buffer can accommodate the larger size.


 <=
/p>

How big do you need?=



 <=
/p>

Thanks - Fred<=
/span>


 <=
/p>







From: dmm [mai=
lto:dmm-bounces@ietf.org]
On Behalf Of Sri Gundavelli (sgundave)

Sent: Thursday, September 18, 2014 1:04 PM

To: dmm@ietf.org

Subject: [DMM] Signaling Message Fragmentation






 




[Discussion under the maint=
enance scope] 






 





With the standardization of=
 all the new mobility options (ANI, QoS, IFOM, MNP..etc)   and sp=
ecially with the NAI/Domain type fields in some of those options,
 we are almost close to hitting the PBU/BU fragmentation limit. <=
/o:p>






 





Any thoughts on how to deal=
 with this ? How is it solved in other message based protocols ? I've seen =
some work on IPSecme WG on IKEv2 message fragmentation for
 the same issue. 






 





Should we do some thing her=
e ? Or, if any one has invested time on this and has a proposal ? Comments =
?






 





 





 





Regards





Sri










--_000_2134F8430051B64F815C691A62D9831832D23D03XCHBLV504nwnosb_--


From nobody Tue Sep 23 08:50:42 2014
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 417A71A8727 for ; Tue, 23 Sep 2014 08:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 9-A5XquvVTwV for ; Tue, 23 Sep 2014 08:50:38 -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 A2E891A86FA for ; Tue, 23 Sep 2014 08:50:38 -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 s8NFobpa019694; Tue, 23 Sep 2014 08:50:38 -0700
Received: from XCH-BLV-103.nw.nos.boeing.com (xch-blv-103.nw.nos.boeing.com [130.247.25.118]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8NFoaOw019206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Sep 2014 08:50:36 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-103.nw.nos.boeing.com ([169.254.3.198]) with mapi id 14.03.0181.006; Tue, 23 Sep 2014 08:50:36 -0700
From: "Templin, Fred L" 
To: "Templin, Fred L" , "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1YkwgAEM+6A=
Date: Tue, 23 Sep 2014 15:50:35 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D25696@XCH-BLV-504.nw.nos.boeing.com>
References:  <2134F8430051B64F815C691A62D9831832D23D03@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832D23D03@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/VF1FPktD8mleVkjYsG3w-ggy6_Q
Subject: Re: [DMM] Signaling Message Fragmentation
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, 23 Sep 2014 15:50:40 -0000

Sri,

> I've seen some work on IPSecme WG on IKEv2 message fragmentation
> for the same issue.

I looked at this, and the approach is roughly the same as what I have
been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
years. In other words, perform fragmentation and reassembly at a level
above the encapsulating IP protocol headers and below the encapsulated
IP protocol headers - a mid-layer fragmentation and reassembly.

So, this brings up a few questions:

  1) Does the concern apply only to large control messages, or also to
     large data packets?
  2) How big can the control messages get - not only for just today but
     also going forward into the future?
  3) Are we really so concerned about IP fragment dropping that we need
     to bump this up to a mid-layer frag/reass?

Thanks - Fred
fred.l.templin@boeing.com

---

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L
Sent: Monday, September 22, 2014 4:45 PM
To: Sri Gundavelli (sgundave); dmm@ietf.org
Subject: Re: [DMM] Signaling Message Fragmentation

Hi Sri,

My understanding is that if a source sends fragmented messages it must have=
 assurance
that the destination has a large enough reassembly buffer. Since the minimu=
m IPv6
reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmented p=
ackets
larger than 1500 bytes unless there is some other means of determining whet=
her the
destination's reassembly buffer can accommodate the larger size.

How big do you need?

Thanks - Fred

From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgunda=
ve)
Sent: Thursday, September 18, 2014 1:04 PM
To: dmm@ietf.org
Subject: [DMM] Signaling Message Fragmentation

[Discussion under the maintenance scope]=A0

With the standardization of all the new mobility options (ANI, QoS, IFOM, M=
NP..etc) =A0=A0and specially with the NAI/Domain type fields in some of tho=
se options, we are almost close to hitting the PBU/BU fragmentation limit.=
=A0

Any thoughts on how to deal with this ? How is it solved in other message b=
ased protocols ? I've seen some work on IPSecme WG on IKEv2 message fragmen=
tation for the same issue.=A0

Should we do some thing here ? Or, if any one has invested time on this and=
 has a proposal ? Comments ?



Regards
Sri


From nobody Tue Sep 23 10:30:06 2014
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 B9F5F1A87DE for ; Tue, 23 Sep 2014 10:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 EOa0vpXCCHJu for ; Tue, 23 Sep 2014 10:30:03 -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 84B4E1A87C6 for ; Tue, 23 Sep 2014 10:30:03 -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 s8NHU3br013212; Tue, 23 Sep 2014 10:30:03 -0700
Received: from XCH-BLV-305.nw.nos.boeing.com (xch-blv-305.nw.nos.boeing.com [130.247.25.217]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8NHTt5g012580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Sep 2014 10:29:56 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-305.nw.nos.boeing.com ([169.254.5.16]) with mapi id 14.03.0181.006; Tue, 23 Sep 2014 10:29:55 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1YkwgAEM+6CAAB4W0A==
Date: Tue, 23 Sep 2014 17:29:55 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D25885@XCH-BLV-504.nw.nos.boeing.com>
References:  <2134F8430051B64F815C691A62D9831832D23D03@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D25696@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832D25696@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/2KpIFQJfugHkKJr4QXLJGP4wLJQ
Subject: Re: [DMM] Signaling Message Fragmentation
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, 23 Sep 2014 17:30:04 -0000

Hi Sri,

I will make this even easier and reduce it to a single question:

  1) How big??

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Templin, Fred L
> Sent: Tuesday, September 23, 2014 8:51 AM
> To: Templin, Fred L; Sri Gundavelli (sgundave); dmm@ietf.org
> Subject: RE: Signaling Message Fragmentation
>=20
> Sri,
>=20
> > I've seen some work on IPSecme WG on IKEv2 message fragmentation
> > for the same issue.
>=20
> I looked at this, and the approach is roughly the same as what I have
> been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
> years. In other words, perform fragmentation and reassembly at a level
> above the encapsulating IP protocol headers and below the encapsulated
> IP protocol headers - a mid-layer fragmentation and reassembly.
>=20
> So, this brings up a few questions:
>=20
>   1) Does the concern apply only to large control messages, or also to
>      large data packets?
>   2) How big can the control messages get - not only for just today but
>      also going forward into the future?
>   3) Are we really so concerned about IP fragment dropping that we need
>      to bump this up to a mid-layer frag/reass?
>=20
> Thanks - Fred
> fred.l.templin@boeing.com
>=20
> ---
>=20
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Monday, September 22, 2014 4:45 PM
> To: Sri Gundavelli (sgundave); dmm@ietf.org
> Subject: Re: [DMM] Signaling Message Fragmentation
>=20
> Hi Sri,
>=20
> My understanding is that if a source sends fragmented messages it must ha=
ve assurance
> that the destination has a large enough reassembly buffer. Since the mini=
mum IPv6
> reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmented=
 packets
> larger than 1500 bytes unless there is some other means of determining wh=
ether the
> destination's reassembly buffer can accommodate the larger size.
>=20
> How big do you need?
>=20
> Thanks - Fred
>=20
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgun=
dave)
> Sent: Thursday, September 18, 2014 1:04 PM
> To: dmm@ietf.org
> Subject: [DMM] Signaling Message Fragmentation
>=20
> [Discussion under the maintenance scope]
>=20
> With the standardization of all the new mobility options (ANI, QoS, IFOM,=
 MNP..etc) =A0=A0and specially
> with the NAI/Domain type fields in some of those options, we are almost c=
lose to hitting the PBU/BU
> fragmentation limit.
>=20
> Any thoughts on how to deal with this ? How is it solved in other message=
 based protocols ? I've seen
> some work on IPSecme WG on IKEv2 message fragmentation for the same issue=
.
>=20
> Should we do some thing here ? Or, if any one has invested time on this a=
nd has a proposal ? Comments
> ?
>=20
>=20
>=20
> Regards
> Sri


From nobody Tue Sep 23 11:55:31 2014
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 9C62C1A8856 for ; Tue, 23 Sep 2014 11:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 6Et02Rl_etot for ; Tue, 23 Sep 2014 11:55:27 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CD81A8839 for ; Tue, 23 Sep 2014 11:55:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s8NItQ1N019028; Tue, 23 Sep 2014 13:55:26 -0500
Received: from XCH-PHX-411.sw.nos.boeing.com (xch-phx-411.sw.nos.boeing.com [10.57.37.42]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8NItNCs019006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Sep 2014 13:55:24 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-PHX-411.sw.nos.boeing.com ([169.254.11.238]) with mapi id 14.03.0181.006;  Tue, 23 Sep 2014 11:55:23 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1YkwgAEM+6CAAB4W0IAAF9qA
Date: Tue, 23 Sep 2014 18:55:22 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D259AA@XCH-BLV-504.nw.nos.boeing.com>
References:  <2134F8430051B64F815C691A62D9831832D23D03@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D25696@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832D25885@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832D25885@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/lF3-CLMc1h7wcOdfOZkYdD1rAI4
Subject: Re: [DMM] Signaling Message Fragmentation
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, 23 Sep 2014 18:55:29 -0000

>   1) How big??

Still no answer. I guess then we will have to assume 64KB.
Anything larger than that will have to go as a jumbogram.

Thanks - Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Tuesday, September 23, 2014 10:30 AM
> To: Sri Gundavelli (sgundave); dmm@ietf.org
> Subject: Re: [DMM] Signaling Message Fragmentation
>=20
> Hi Sri,
>=20
> I will make this even easier and reduce it to a single question:
>=20
>   1) How big??
>=20
> Thanks - Fred
> fred.l.templin@boeing.com
>=20
> > -----Original Message-----
> > From: Templin, Fred L
> > Sent: Tuesday, September 23, 2014 8:51 AM
> > To: Templin, Fred L; Sri Gundavelli (sgundave); dmm@ietf.org
> > Subject: RE: Signaling Message Fragmentation
> >
> > Sri,
> >
> > > I've seen some work on IPSecme WG on IKEv2 message fragmentation
> > > for the same issue.
> >
> > I looked at this, and the approach is roughly the same as what I have
> > been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
> > years. In other words, perform fragmentation and reassembly at a level
> > above the encapsulating IP protocol headers and below the encapsulated
> > IP protocol headers - a mid-layer fragmentation and reassembly.
> >
> > So, this brings up a few questions:
> >
> >   1) Does the concern apply only to large control messages, or also to
> >      large data packets?
> >   2) How big can the control messages get - not only for just today but
> >      also going forward into the future?
> >   3) Are we really so concerned about IP fragment dropping that we need
> >      to bump this up to a mid-layer frag/reass?
> >
> > Thanks - Fred
> > fred.l.templin@boeing.com
> >
> > ---
> >
> > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L
> > Sent: Monday, September 22, 2014 4:45 PM
> > To: Sri Gundavelli (sgundave); dmm@ietf.org
> > Subject: Re: [DMM] Signaling Message Fragmentation
> >
> > Hi Sri,
> >
> > My understanding is that if a source sends fragmented messages it must =
have assurance
> > that the destination has a large enough reassembly buffer. Since the mi=
nimum IPv6
> > reassembly unit is only 1500 bytes, the source SHOULD NOT send fragment=
ed packets
> > larger than 1500 bytes unless there is some other means of determining =
whether the
> > destination's reassembly buffer can accommodate the larger size.
> >
> > How big do you need?
> >
> > Thanks - Fred
> >
> > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sg=
undave)
> > Sent: Thursday, September 18, 2014 1:04 PM
> > To: dmm@ietf.org
> > Subject: [DMM] Signaling Message Fragmentation
> >
> > [Discussion under the maintenance scope]
> >
> > With the standardization of all the new mobility options (ANI, QoS, IFO=
M, MNP..etc) =A0=A0and specially
> > with the NAI/Domain type fields in some of those options, we are almost=
 close to hitting the PBU/BU
> > fragmentation limit.
> >
> > Any thoughts on how to deal with this ? How is it solved in other messa=
ge based protocols ? I've
> seen
> > some work on IPSecme WG on IKEv2 message fragmentation for the same iss=
ue.
> >
> > Should we do some thing here ? Or, if any one has invested time on this=
 and has a proposal ?
> Comments
> > ?
> >
> >
> >
> > Regards
> > Sri
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Tue Sep 23 12:10:24 2014
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 478381A88FB for ; Tue, 23 Sep 2014 12:10:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 N936K3RIG7H6 for ; Tue, 23 Sep 2014 12:10:20 -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 28A001A88C2 for ; Tue, 23 Sep 2014 12:10:03 -0700 (PDT)
Received: from [107.1.141.74] (helo=[192.168.254.194]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XWVTO-00012j-9c for dmm@ietf.org; Tue, 23 Sep 2014 15:10:02 -0400
Message-ID: <5421C587.50809@computer.org>
Date: Tue, 23 Sep 2014 12:09:59 -0700
From: "Charles E. Perkins" 
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dmm@ietf.org" 
References: <20140923174312.6322.91357.idtracker@ietfa.amsl.com>
In-Reply-To: <20140923174312.6322.91357.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140923174312.6322.91357.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------000100060802070700010308"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac77f70b62d46f46f84d10b7b3bc0b4e186350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ddy8X51xM9Y1VQRVSNH5OIMVN2Y
Subject: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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, 23 Sep 2014 19:10:21 -0000

This is a multi-part message in MIME format.
--------------000100060802070700010308
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello folks,

We have published a ...-00 version of the MNIDs draft.  This is mainly for
reference purposes.  A new version should be out within a week or so,
incorporating the suggestions and comments from people who responded
to the earlier suggestion to revisit this work.

Regards,
Charlie P.



-------- Original Message --------
Subject: 	New Version Notification for draft-perkins-dmm-4283mnids-00.txt
Date: 	Tue, 23 Sep 2014 10:43:12 -0700
From: 	
To: 	Charles E. Perkins , Vijay Devarapalli 
, Charles E.Perkins 




A new version of I-D, draft-perkins-dmm-4283mnids-00.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:		draft-perkins-dmm-4283mnids
Revision:	00
Title:		MN Identifier Types for RFC 4283 Mobile Node Identifier Option
Document date:	2014-09-23
Group:		Individual Submission
Pages:		4
URL:            http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/
Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00


Abstract:
    Additional Identifier Types are proposed for use with the Mobile Node
    Identifier Option for MIPv6 (RFC 4283).

                                                                                   


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.

The IETF Secretariat





--------------000100060802070700010308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Hello folks,

    

    We have published a ...-00 version of the MNIDs draft.  This is
    mainly for

    reference purposes.  A new version should be out within a week or
    so,

    incorporating the suggestions and comments from people who responded

    to the earlier suggestion to revisit this work.

    

    Regards,

    Charlie P.

    

    


      

      -------- Original Message --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-perkins-dmm-4283mnids-00.txt
          

          

            Date: 
            Tue, 23 Sep 2014 10:43:12 -0700
          

          

            From: 
            <internet-drafts@ietf.org>
          

          

            To: 
            Charles E. Perkins <charliep@computer.org>, Vijay
              Devarapalli
              <unknown-email-Vijay-Devarapalli@ietfa.amsl.com>,
              Charles E.Perkins <charliep@computer.org>
          

        
      

      

      

      
A new version of I-D, draft-perkins-dmm-4283mnids-00.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:		draft-perkins-dmm-4283mnids
Revision:	00
Title:		MN Identifier Types for RFC 4283 Mobile Node Identifier Option
Document date:	2014-09-23
Group:		Individual Submission
Pages:		4
URL:            http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/
Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00


Abstract:
   Additional Identifier Types are proposed for use with the Mobile Node
   Identifier Option for MIPv6 (RFC 4283).

                                                                                  


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.

The IETF Secretariat




      

    

    

  


--------------000100060802070700010308--


From nobody Tue Sep 23 16:06:09 2014
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 440AE1A8963 for ; Tue, 23 Sep 2014 16:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 rjHiQGIlxwfN for ; Tue, 23 Sep 2014 16:06:05 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536841A895E for ; Tue, 23 Sep 2014 16:06:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5204; q=dns/txt; s=iport; t=1411513566; x=1412723166; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=9VzeKqLXyE4XCVY4HNK3M7YZNU10q7NHjgPh57X6AhM=; b=FPPrg0m3f+ZP8eVzNgDnS3bupBqhuMG/18uMtbKh+L7VXeA5OBQ+p+rd 1aCgBEF8o6xL+DiChSATg0gfLhqJ+7j9o39vQM9Mx5fJcCFnZeAS8xRCo NJDBYzevKPY/GXHRC7nAVWPNCPD2CL+hMCwnk74lhh5BMSz1pcRMClXG7 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgoFAPb7IVStJA2K/2dsb2JhbABggw6BKgTRLAGBDBYBeoQDAQEBBDpRAQgRBAEBHwk5FAkIAgQBEog+wlsBF48wLDIGhEUBBJFai0KVU4FpIIFZbAGBBkGBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,583,1406592000"; d="scan'208";a="357650706"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP; 23 Sep 2014 23:06:05 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8NN64q2018572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Sep 2014 23:06:04 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 23 Sep 2014 18:06:04 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP14LyY1bYElSz6ECZgbUOTv9FGw==
Date: Tue, 23 Sep 2014 23:06:03 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D25696@XCH-BLV-504.nw.nos.boeing.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.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4B1879886171DF44ACF0D0F34A047BDA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/rRVC3CNrIbCMLJ0J2p5f6vVMFw8
Subject: Re: [DMM] Signaling Message Fragmentation
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, 23 Sep 2014 23:06:07 -0000

Hi Fred,

Thanks for your response and also sorry for the delay in catching up on
this thread; Had to focus on some other business.

The issue that I raised is specifically in the context of control plane
messages. Some of the mobility options (Ex: Dynamic Mobile Network Prefix
option in RFC7148) can easily exceed the path MTU size. Each of these
options by itself may not be huge, but multiple instances of the option
can be included in the message. For Mobile Networks use-case, its possible
a mobile node is assigned a set of IPv6 prefixes and based on the count
exceed the MTU limits.  As such this should be OK; But ensuring
fragmentation in the MIP layer eliminates issues such as dropped fragments
by mid-level boxes and also fragmentation by on-path nodes. The question
is also not about requiring a huge buffer sizes, but more about handling
messages which are slightly beyond the MTU sizes.  I will look at the SEAL
proposal and understand how its handled there.

For user-plane we are covered, the tunnel entry and exit point perform
fragmentation prior to the encapsulation and so generally this should not
cause any issues. We always have the ability to advertise a lower MTU
value on the access link;  The MTU value that we advertise on the access
link should be the lower of the link MTU on the WLAN link and the Tunnel
MTU on the MAG-LMA path. This can be achieved by allowing the MAG to
include the adjusted MTU value in the DHCP OFFER and IPv6 Router
Advertisements. However, we realize not all mobile nodes honor the MTU
option in the DHCPOFFER; But, at least on the addressing plane we can
ensure we send the correct MTU values.
=20

=20
RFC 5844: (IPv4 Traffic from the Mobile Node)
"     The DHCPOFFER message [RFC2131] sent to the mobile node MUST
      include the Interface MTU option [RFC2132].  The DHCP servers in
      the Proxy Mobile IPv6 domain MUST be configured to include the
      Interface MTU option.  The MTU value SHOULD reflect the tunnel MTU
      for the bidirectional tunnel between the mobile access gateway and
      the local mobility anchor."

RFC 5213: (IPv6 Traffic from the Mobile Node)
=20
  3.  The mobile access gateway SHOULD add the MTU option, as specified
       in [RFC4861], to the Router Advertisement messages that it sends
       on the access link.  This will ensure the mobile node on the link
       uses the advertised MTU value.  The MTU value SHOULD reflect the
       tunnel MTU for the bi-directional tunnel between the mobile
       access gateway and the local mobility anchor.  Considerations
       from Section 6.9.5 SHOULD be applied for determining the tunnel
       MTU value.



Regards
Sri


On 9/23/14 8:50 AM, "Templin, Fred L"  wrote:

>Sri,
>
>> I've seen some work on IPSecme WG on IKEv2 message fragmentation
>> for the same issue.
>
>I looked at this, and the approach is roughly the same as what I have
>been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
>years. In other words, perform fragmentation and reassembly at a level
>above the encapsulating IP protocol headers and below the encapsulated
>IP protocol headers - a mid-layer fragmentation and reassembly.
>
>So, this brings up a few questions:
>
>  1) Does the concern apply only to large control messages, or also to
>     large data packets?
>  2) How big can the control messages get - not only for just today but
>     also going forward into the future?
>  3) Are we really so concerned about IP fragment dropping that we need
>     to bump this up to a mid-layer frag/reass?
>
>Thanks - Fred
>fred.l.templin@boeing.com
>
>---
>
>From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L
>Sent: Monday, September 22, 2014 4:45 PM
>To: Sri Gundavelli (sgundave); dmm@ietf.org
>Subject: Re: [DMM] Signaling Message Fragmentation
>
>Hi Sri,
>
>My understanding is that if a source sends fragmented messages it must
>have assurance
>that the destination has a large enough reassembly buffer. Since the
>minimum IPv6
>reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmented
>packets
>larger than 1500 bytes unless there is some other means of determining
>whether the
>destination's reassembly buffer can accommodate the larger size.
>
>How big do you need?
>
>Thanks - Fred
>
>From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
>(sgundave)
>Sent: Thursday, September 18, 2014 1:04 PM
>To: dmm@ietf.org
>Subject: [DMM] Signaling Message Fragmentation
>
>[Discussion under the maintenance scope]
>
>With the standardization of all the new mobility options (ANI, QoS, IFOM,
>MNP..etc)   and specially with the NAI/Domain type fields in some of
>those options, we are almost close to hitting the PBU/BU fragmentation
>limit.=20
>
>Any thoughts on how to deal with this ? How is it solved in other message
>based protocols ? I've seen some work on IPSecme WG on IKEv2 message
>fragmentation for the same issue.
>
>Should we do some thing here ? Or, if any one has invested time on this
>and has a proposal ? Comments ?
>
>
>
>Regards
>Sri


From nobody Tue Sep 23 16:14:18 2014
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 4821A1A024C for ; Tue, 23 Sep 2014 16:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 TbVCUjJ49UuM for ; Tue, 23 Sep 2014 16:14:09 -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 4CBCD1A1B43 for ; Tue, 23 Sep 2014 16:14:09 -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 s8NNE86s021558; Tue, 23 Sep 2014 18:14:08 -0500
Received: from XCH-BLV-501.nw.nos.boeing.com (xch-blv-501.nw.nos.boeing.com [130.247.25.190]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8NNE29H021361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Sep 2014 18:14:03 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.101]) with mapi id 14.03.0181.006; Tue, 23 Sep 2014 16:14:02 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1YkwgAEM+6CAAPHCgP//i1Og
Date: Tue, 23 Sep 2014 23:14:02 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D25D9A@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D25696@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/DmzSdHGtiv3YeVHk9iAuwIMaZOA
Subject: Re: [DMM] Signaling Message Fragmentation
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, 23 Sep 2014 23:14:11 -0000

Hi Sri,

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> Sent: Tuesday, September 23, 2014 4:06 PM
> To: Templin, Fred L; dmm@ietf.org
> Subject: Re: Signaling Message Fragmentation
>=20
> Hi Fred,
>=20
> Thanks for your response and also sorry for the delay in catching up on
> this thread; Had to focus on some other business.
>=20
> The issue that I raised is specifically in the context of control plane
> messages. Some of the mobility options (Ex: Dynamic Mobile Network Prefix
> option in RFC7148) can easily exceed the path MTU size. Each of these
> options by itself may not be huge, but multiple instances of the option
> can be included in the message. For Mobile Networks use-case, its possibl=
e
> a mobile node is assigned a set of IPv6 prefixes and based on the count
> exceed the MTU limits.  As such this should be OK; But ensuring
> fragmentation in the MIP layer eliminates issues such as dropped fragment=
s
> by mid-level boxes and also fragmentation by on-path nodes. The question
> is also not about requiring a huge buffer sizes, but more about handling
> messages which are slightly beyond the MTU sizes.  I will look at the SEA=
L
> proposal and understand how its handled there.

Probably better to look at the latest AERO spec (posted today).
I have it fixed there now.
=20
> For user-plane we are covered, the tunnel entry and exit point perform
> fragmentation prior to the encapsulation and so generally this should not
> cause any issues. We always have the ability to advertise a lower MTU
> value on the access link;  The MTU value that we advertise on the access
> link should be the lower of the link MTU on the WLAN link and the Tunnel
> MTU on the MAG-LMA path. This can be achieved by allowing the MAG to
> include the adjusted MTU value in the DHCP OFFER and IPv6 Router
> Advertisements. However, we realize not all mobile nodes honor the MTU
> option in the DHCPOFFER; But, at least on the addressing plane we can
> ensure we send the correct MTU values.

I'm not much of a fan of advertised MTU values in RAs and such. It
may be OK if your tunnel is point-to-point, but I want good MTU
solution for NBMA tunnels where the MTU between neighbors A and B
may be vastly different than the MTU between neighbors A and C.

I also want there to be a guaranteed minimum and an unlimited maximum.
With AERO, all paths are guaranteed to support a minimum MTU of 1500.
But, larger packets can also go through (unfragmented) if the path
MTU is sufficient.

Thanks - Fred
fred.l.templin@boeing.com

> RFC 5844: (IPv4 Traffic from the Mobile Node)
> "     The DHCPOFFER message [RFC2131] sent to the mobile node MUST
>       include the Interface MTU option [RFC2132].  The DHCP servers in
>       the Proxy Mobile IPv6 domain MUST be configured to include the
>       Interface MTU option.  The MTU value SHOULD reflect the tunnel MTU
>       for the bidirectional tunnel between the mobile access gateway and
>       the local mobility anchor."
>=20
> RFC 5213: (IPv6 Traffic from the Mobile Node)
>=20
>   3.  The mobile access gateway SHOULD add the MTU option, as specified
>        in [RFC4861], to the Router Advertisement messages that it sends
>        on the access link.  This will ensure the mobile node on the link
>        uses the advertised MTU value.  The MTU value SHOULD reflect the
>        tunnel MTU for the bi-directional tunnel between the mobile
>        access gateway and the local mobility anchor.  Considerations
>        from Section 6.9.5 SHOULD be applied for determining the tunnel
>        MTU value.
>=20
>=20
>=20
> Regards
> Sri
>=20
>=20
> On 9/23/14 8:50 AM, "Templin, Fred L"  wrote:
>=20
> >Sri,
> >
> >> I've seen some work on IPSecme WG on IKEv2 message fragmentation
> >> for the same issue.
> >
> >I looked at this, and the approach is roughly the same as what I have
> >been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
> >years. In other words, perform fragmentation and reassembly at a level
> >above the encapsulating IP protocol headers and below the encapsulated
> >IP protocol headers - a mid-layer fragmentation and reassembly.
> >
> >So, this brings up a few questions:
> >
> >  1) Does the concern apply only to large control messages, or also to
> >     large data packets?
> >  2) How big can the control messages get - not only for just today but
> >     also going forward into the future?
> >  3) Are we really so concerned about IP fragment dropping that we need
> >     to bump this up to a mid-layer frag/reass?
> >
> >Thanks - Fred
> >fred.l.templin@boeing.com
> >
> >---
> >
> >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L
> >Sent: Monday, September 22, 2014 4:45 PM
> >To: Sri Gundavelli (sgundave); dmm@ietf.org
> >Subject: Re: [DMM] Signaling Message Fragmentation
> >
> >Hi Sri,
> >
> >My understanding is that if a source sends fragmented messages it must
> >have assurance
> >that the destination has a large enough reassembly buffer. Since the
> >minimum IPv6
> >reassembly unit is only 1500 bytes, the source SHOULD NOT send fragmente=
d
> >packets
> >larger than 1500 bytes unless there is some other means of determining
> >whether the
> >destination's reassembly buffer can accommodate the larger size.
> >
> >How big do you need?
> >
> >Thanks - Fred
> >
> >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
> >(sgundave)
> >Sent: Thursday, September 18, 2014 1:04 PM
> >To: dmm@ietf.org
> >Subject: [DMM] Signaling Message Fragmentation
> >
> >[Discussion under the maintenance scope]
> >
> >With the standardization of all the new mobility options (ANI, QoS, IFOM=
,
> >MNP..etc)   and specially with the NAI/Domain type fields in some of
> >those options, we are almost close to hitting the PBU/BU fragmentation
> >limit.
> >
> >Any thoughts on how to deal with this ? How is it solved in other messag=
e
> >based protocols ? I've seen some work on IPSecme WG on IKEv2 message
> >fragmentation for the same issue.
> >
> >Should we do some thing here ? Or, if any one has invested time on this
> >and has a proposal ? Comments ?
> >
> >
> >
> >Regards
> >Sri


From nobody Tue Sep 23 16:19:34 2014
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 E56EA1A6F27 for ; Tue, 23 Sep 2014 16:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 ewlGKTHMrBFx for ; Tue, 23 Sep 2014 16:19:30 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64141A024C for ; Tue, 23 Sep 2014 16:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6752; q=dns/txt; s=iport; t=1411514369; x=1412723969; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Xg+UdtXBLxdn0YQKQCMXkV/pDM+g5VdkLqzfnILmM7A=; b=mxT7XKZ0GqE/7D3x8VzTWK/dz7HEJCSk43qTXvAtSqADWeIWozYiqc1y 9fGPtlfsTCgSMXO2LPXNTHFuNirTSK4q7/zc6U7rdBNsn6zfmpdIjyF1N +9qJ9R6XcY8KTdJoswMfTccLQIATCy5e9UYM5v+aIlQ+j0/rCGD2+Z1r9 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAHb/IVStJV2b/2dsb2JhbABggw6BKgTRLAGBBRYBeoQDAQEBAwE6SwYBCBEEAQEBHgk5FAkIAgQBEhuIGwjCVAEXjzAsMgaERQEEkVqLQpVTgWkggVlsAYEGQYECAQEB
X-IronPort-AV: E=Sophos;i="5.04,583,1406592000"; d="scan'208";a="80645380"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 23 Sep 2014 23:19:28 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8NNJSZ1021088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Sep 2014 23:19:28 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 23 Sep 2014 18:19:28 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP14TSmTUMO+WGoEG0jQDdR1zK2Q==
Date: Tue, 23 Sep 2014 23:19:27 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D25D9A@XCH-BLV-504.nw.nos.boeing.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.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/8l5pfxhrcekN7v5IfuWgctk-noY
Subject: Re: [DMM] Signaling Message Fragmentation
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, 23 Sep 2014 23:19:32 -0000

Hi Fred,

inline ..

On 9/23/14 4:14 PM, "Templin, Fred L"  wrote:

>Hi Sri,
>
>> -----Original Message-----
>> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>> Sent: Tuesday, September 23, 2014 4:06 PM
>> To: Templin, Fred L; dmm@ietf.org
>> Subject: Re: Signaling Message Fragmentation
>>=20
>> Hi Fred,
>>=20
>> Thanks for your response and also sorry for the delay in catching up on
>> this thread; Had to focus on some other business.
>>=20
>> The issue that I raised is specifically in the context of control plane
>> messages. Some of the mobility options (Ex: Dynamic Mobile Network
>>Prefix
>> option in RFC7148) can easily exceed the path MTU size. Each of these
>> options by itself may not be huge, but multiple instances of the option
>> can be included in the message. For Mobile Networks use-case, its
>>possible
>> a mobile node is assigned a set of IPv6 prefixes and based on the count
>> exceed the MTU limits.  As such this should be OK; But ensuring
>> fragmentation in the MIP layer eliminates issues such as dropped
>>fragments
>> by mid-level boxes and also fragmentation by on-path nodes. The question
>> is also not about requiring a huge buffer sizes, but more about handling
>> messages which are slightly beyond the MTU sizes.  I will look at the
>>SEAL
>> proposal and understand how its handled there.
>
>Probably better to look at the latest AERO spec (posted today).
>I have it fixed there now.

Ack. Will take a look

>=20
>> For user-plane we are covered, the tunnel entry and exit point perform
>> fragmentation prior to the encapsulation and so generally this should
>>not
>> cause any issues. We always have the ability to advertise a lower MTU
>> value on the access link;  The MTU value that we advertise on the access
>> link should be the lower of the link MTU on the WLAN link and the Tunnel
>> MTU on the MAG-LMA path. This can be achieved by allowing the MAG to
>> include the adjusted MTU value in the DHCP OFFER and IPv6 Router
>> Advertisements. However, we realize not all mobile nodes honor the MTU
>> option in the DHCPOFFER; But, at least on the addressing plane we can
>> ensure we send the correct MTU values.
>
>I'm not much of a fan of advertised MTU values in RAs and such. It
>may be OK if your tunnel is point-to-point, but I want good MTU
>solution for NBMA tunnels where the MTU between neighbors A and B
>may be vastly different than the MTU between neighbors A and C.


Its a P2P tunnel and so the NBMA considerations may not be needed.


>
>I also want there to be a guaranteed minimum and an unlimited maximum.
>With AERO, all paths are guaranteed to support a minimum MTU of 1500.
>But, larger packets can also go through (unfragmented) if the path
>MTU is sufficient.


Ok.

Regards
Sri




>
>Thanks - Fred
>fred.l.templin@boeing.com
>
>> RFC 5844: (IPv4 Traffic from the Mobile Node)
>> "     The DHCPOFFER message [RFC2131] sent to the mobile node MUST
>>       include the Interface MTU option [RFC2132].  The DHCP servers in
>>       the Proxy Mobile IPv6 domain MUST be configured to include the
>>       Interface MTU option.  The MTU value SHOULD reflect the tunnel MTU
>>       for the bidirectional tunnel between the mobile access gateway and
>>       the local mobility anchor."
>>=20
>> RFC 5213: (IPv6 Traffic from the Mobile Node)
>>=20
>>   3.  The mobile access gateway SHOULD add the MTU option, as specified
>>        in [RFC4861], to the Router Advertisement messages that it sends
>>        on the access link.  This will ensure the mobile node on the link
>>        uses the advertised MTU value.  The MTU value SHOULD reflect the
>>        tunnel MTU for the bi-directional tunnel between the mobile
>>        access gateway and the local mobility anchor.  Considerations
>>        from Section 6.9.5 SHOULD be applied for determining the tunnel
>>        MTU value.
>>=20
>>=20
>>=20
>> Regards
>> Sri
>>=20
>>=20
>> On 9/23/14 8:50 AM, "Templin, Fred L"  wrote:
>>=20
>> >Sri,
>> >
>> >> I've seen some work on IPSecme WG on IKEv2 message fragmentation
>> >> for the same issue.
>> >
>> >I looked at this, and the approach is roughly the same as what I have
>> >been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
>> >years. In other words, perform fragmentation and reassembly at a level
>> >above the encapsulating IP protocol headers and below the encapsulated
>> >IP protocol headers - a mid-layer fragmentation and reassembly.
>> >
>> >So, this brings up a few questions:
>> >
>> >  1) Does the concern apply only to large control messages, or also to
>> >     large data packets?
>> >  2) How big can the control messages get - not only for just today but
>> >     also going forward into the future?
>> >  3) Are we really so concerned about IP fragment dropping that we need
>> >     to bump this up to a mid-layer frag/reass?
>> >
>> >Thanks - Fred
>> >fred.l.templin@boeing.com
>> >
>> >---
>> >
>> >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L
>> >Sent: Monday, September 22, 2014 4:45 PM
>> >To: Sri Gundavelli (sgundave); dmm@ietf.org
>> >Subject: Re: [DMM] Signaling Message Fragmentation
>> >
>> >Hi Sri,
>> >
>> >My understanding is that if a source sends fragmented messages it must
>> >have assurance
>> >that the destination has a large enough reassembly buffer. Since the
>> >minimum IPv6
>> >reassembly unit is only 1500 bytes, the source SHOULD NOT send
>>fragmented
>> >packets
>> >larger than 1500 bytes unless there is some other means of determining
>> >whether the
>> >destination's reassembly buffer can accommodate the larger size.
>> >
>> >How big do you need?
>> >
>> >Thanks - Fred
>> >
>> >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
>> >(sgundave)
>> >Sent: Thursday, September 18, 2014 1:04 PM
>> >To: dmm@ietf.org
>> >Subject: [DMM] Signaling Message Fragmentation
>> >
>> >[Discussion under the maintenance scope]
>> >
>> >With the standardization of all the new mobility options (ANI, QoS,
>>IFOM,
>> >MNP..etc)   and specially with the NAI/Domain type fields in some of
>> >those options, we are almost close to hitting the PBU/BU fragmentation
>> >limit.
>> >
>> >Any thoughts on how to deal with this ? How is it solved in other
>>message
>> >based protocols ? I've seen some work on IPSecme WG on IKEv2 message
>> >fragmentation for the same issue.
>> >
>> >Should we do some thing here ? Or, if any one has invested time on this
>> >and has a proposal ? Comments ?
>> >
>> >
>> >
>> >Regards
>> >Sri
>


From nobody Tue Sep 23 17:00:38 2014
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 245BC1A8988 for ; Tue, 23 Sep 2014 17:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 JnDKfahv6WGk for ; Tue, 23 Sep 2014 17:00:33 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8CA1A896F for ; Tue, 23 Sep 2014 17:00:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s8O00Wt2028291; Tue, 23 Sep 2014 19:00:32 -0500
Received: from XCH-BLV-505.nw.nos.boeing.com (xch-blv-505.nw.nos.boeing.com [130.247.25.195]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8O00Q61028202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 23 Sep 2014 19:00:26 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.191]) with mapi id 14.03.0181.006; Tue, 23 Sep 2014 17:00:25 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1YkwgAEM+6CAAPHCgP//i1OggAB4a4D//5S3IA==
Date: Wed, 24 Sep 2014 00:00:24 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D25E30@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D25D9A@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/au4tNKxvD9En0ARbo_-NgIT_biQ
Subject: Re: [DMM] Signaling Message Fragmentation
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, 24 Sep 2014 00:00:36 -0000

Hi Sri,

> -----Original Message-----
> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> Sent: Tuesday, September 23, 2014 4:19 PM
> To: Templin, Fred L; dmm@ietf.org
> Subject: Re: Signaling Message Fragmentation
>=20
> Hi Fred,
>=20
> inline ..
>=20
> On 9/23/14 4:14 PM, "Templin, Fred L"  wrote:
>=20
> >Hi Sri,
> >
> >> -----Original Message-----
> >> From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
> >> Sent: Tuesday, September 23, 2014 4:06 PM
> >> To: Templin, Fred L; dmm@ietf.org
> >> Subject: Re: Signaling Message Fragmentation
> >>
> >> Hi Fred,
> >>
> >> Thanks for your response and also sorry for the delay in catching up o=
n
> >> this thread; Had to focus on some other business.
> >>
> >> The issue that I raised is specifically in the context of control plan=
e
> >> messages. Some of the mobility options (Ex: Dynamic Mobile Network
> >>Prefix
> >> option in RFC7148) can easily exceed the path MTU size. Each of these
> >> options by itself may not be huge, but multiple instances of the optio=
n
> >> can be included in the message. For Mobile Networks use-case, its
> >>possible
> >> a mobile node is assigned a set of IPv6 prefixes and based on the coun=
t
> >> exceed the MTU limits.  As such this should be OK; But ensuring
> >> fragmentation in the MIP layer eliminates issues such as dropped
> >>fragments
> >> by mid-level boxes and also fragmentation by on-path nodes. The questi=
on
> >> is also not about requiring a huge buffer sizes, but more about handli=
ng
> >> messages which are slightly beyond the MTU sizes.  I will look at the
> >>SEAL
> >> proposal and understand how its handled there.
> >
> >Probably better to look at the latest AERO spec (posted today).
> >I have it fixed there now.
>=20
> Ack. Will take a look

OK.

> >> For user-plane we are covered, the tunnel entry and exit point perform
> >> fragmentation prior to the encapsulation and so generally this should
> >>not
> >> cause any issues. We always have the ability to advertise a lower MTU
> >> value on the access link;  The MTU value that we advertise on the acce=
ss
> >> link should be the lower of the link MTU on the WLAN link and the Tunn=
el
> >> MTU on the MAG-LMA path. This can be achieved by allowing the MAG to
> >> include the adjusted MTU value in the DHCP OFFER and IPv6 Router
> >> Advertisements. However, we realize not all mobile nodes honor the MTU
> >> option in the DHCPOFFER; But, at least on the addressing plane we can
> >> ensure we send the correct MTU values.
> >
> >I'm not much of a fan of advertised MTU values in RAs and such. It
> >may be OK if your tunnel is point-to-point, but I want good MTU
> >solution for NBMA tunnels where the MTU between neighbors A and B
> >may be vastly different than the MTU between neighbors A and C.
>=20
>=20
> Its a P2P tunnel and so the NBMA considerations may not be needed.

What might be needed however is a solution that recurses for
deeply-nested tunnels-within-tunnels (remember "nested NEMO"?).
AERO tunnels can recurse indefinitely, with a minimum of 1500
seen at each level.

> >I also want there to be a guaranteed minimum and an unlimited maximum.
> >With AERO, all paths are guaranteed to support a minimum MTU of 1500.
> >But, larger packets can also go through (unfragmented) if the path
> >MTU is sufficient.
>=20
>=20
> Ok.

Good. We will need this if we want to push the Internet MTU up
to something more robust like 9KB or more.

Thanks - Fred
fred.l.templin@boeing.com

> Regards
> Sri
>=20
>=20
>=20
>=20
> >
> >Thanks - Fred
> >fred.l.templin@boeing.com
> >
> >> RFC 5844: (IPv4 Traffic from the Mobile Node)
> >> "     The DHCPOFFER message [RFC2131] sent to the mobile node MUST
> >>       include the Interface MTU option [RFC2132].  The DHCP servers in
> >>       the Proxy Mobile IPv6 domain MUST be configured to include the
> >>       Interface MTU option.  The MTU value SHOULD reflect the tunnel M=
TU
> >>       for the bidirectional tunnel between the mobile access gateway a=
nd
> >>       the local mobility anchor."
> >>
> >> RFC 5213: (IPv6 Traffic from the Mobile Node)
> >>
> >>   3.  The mobile access gateway SHOULD add the MTU option, as specifie=
d
> >>        in [RFC4861], to the Router Advertisement messages that it send=
s
> >>        on the access link.  This will ensure the mobile node on the li=
nk
> >>        uses the advertised MTU value.  The MTU value SHOULD reflect th=
e
> >>        tunnel MTU for the bi-directional tunnel between the mobile
> >>        access gateway and the local mobility anchor.  Considerations
> >>        from Section 6.9.5 SHOULD be applied for determining the tunnel
> >>        MTU value.
> >>
> >>
> >>
> >> Regards
> >> Sri
> >>
> >>
> >> On 9/23/14 8:50 AM, "Templin, Fred L"  wrot=
e:
> >>
> >> >Sri,
> >> >
> >> >> I've seen some work on IPSecme WG on IKEv2 message fragmentation
> >> >> for the same issue.
> >> >
> >> >I looked at this, and the approach is roughly the same as what I have
> >> >been talking about in SEAL [RFC5320][draft-templin-intarea-seal] for
> >> >years. In other words, perform fragmentation and reassembly at a leve=
l
> >> >above the encapsulating IP protocol headers and below the encapsulate=
d
> >> >IP protocol headers - a mid-layer fragmentation and reassembly.
> >> >
> >> >So, this brings up a few questions:
> >> >
> >> >  1) Does the concern apply only to large control messages, or also t=
o
> >> >     large data packets?
> >> >  2) How big can the control messages get - not only for just today b=
ut
> >> >     also going forward into the future?
> >> >  3) Are we really so concerned about IP fragment dropping that we ne=
ed
> >> >     to bump this up to a mid-layer frag/reass?
> >> >
> >> >Thanks - Fred
> >> >fred.l.templin@boeing.com
> >> >
> >> >---
> >> >
> >> >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Templin, Fred L
> >> >Sent: Monday, September 22, 2014 4:45 PM
> >> >To: Sri Gundavelli (sgundave); dmm@ietf.org
> >> >Subject: Re: [DMM] Signaling Message Fragmentation
> >> >
> >> >Hi Sri,
> >> >
> >> >My understanding is that if a source sends fragmented messages it mus=
t
> >> >have assurance
> >> >that the destination has a large enough reassembly buffer. Since the
> >> >minimum IPv6
> >> >reassembly unit is only 1500 bytes, the source SHOULD NOT send
> >>fragmented
> >> >packets
> >> >larger than 1500 bytes unless there is some other means of determinin=
g
> >> >whether the
> >> >destination's reassembly buffer can accommodate the larger size.
> >> >
> >> >How big do you need?
> >> >
> >> >Thanks - Fred
> >> >
> >> >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
> >> >(sgundave)
> >> >Sent: Thursday, September 18, 2014 1:04 PM
> >> >To: dmm@ietf.org
> >> >Subject: [DMM] Signaling Message Fragmentation
> >> >
> >> >[Discussion under the maintenance scope]
> >> >
> >> >With the standardization of all the new mobility options (ANI, QoS,
> >>IFOM,
> >> >MNP..etc)   and specially with the NAI/Domain type fields in some of
> >> >those options, we are almost close to hitting the PBU/BU fragmentatio=
n
> >> >limit.
> >> >
> >> >Any thoughts on how to deal with this ? How is it solved in other
> >>message
> >> >based protocols ? I've seen some work on IPSecme WG on IKEv2 message
> >> >fragmentation for the same issue.
> >> >
> >> >Should we do some thing here ? Or, if any one has invested time on th=
is
> >> >and has a proposal ? Comments ?
> >> >
> >> >
> >> >
> >> >Regards
> >> >Sri
> >


From nobody Wed Sep 24 08:56:15 2014
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 1C2C51A01DD for ; Wed, 24 Sep 2014 08:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hahic1wLxnWp for ; Wed, 24 Sep 2014 08:56:07 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6091A01D0 for ; Wed, 24 Sep 2014 08:56:07 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 662BEC0644; Wed, 24 Sep 2014 17:56:05 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 4A6B6180072; Wed, 24 Sep 2014 17:56:05 +0200 (CEST)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 17:56:04 +0200
From: 
To: "Charles E. Perkins" , "dmm@ietf.org" 
Thread-Topic: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt
Thread-Index: AQHP12IKOy+gCo85mU+dPO0qq3I6HJwQaRAA
Date: Wed, 24 Sep 2014 15:56:04 +0000
Message-ID: <13894_1411574165_5422E995_13894_4130_1_81C77F07008CA24F9783A98CFD706F71142A4CBB@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <20140923174312.6322.91357.idtracker@ietfa.amsl.com> <5421C587.50809@computer.org>
In-Reply-To: <5421C587.50809@computer.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.2]
Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71142A4CBBPEXCVZYM12corpo_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.24.114819
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/E5L9TkNcOwxZozdcV4xVP_y_qiY
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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: Wed, 24 Sep 2014 15:56:11 -0000

--_000_81C77F07008CA24F9783A98CFD706F71142A4CBBPEXCVZYM12corpo_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQ2hhcmxpZSwNCg0KVGhhbmtzIGZvciB0aGUgbGlzdOKApiBpdCBsb29rcyBnb29kLiBJ4oCZ
bSBqdXN0IHdvbmRlcmluZyBhYm91dCBzZWN1cml0eSBjb25zaWRlcmF0aW9uc+KApiBBY3R1YWxs
eSwgZnJvbSAzR1BQIHN0YW5kcG9pbnQsIHNlY3VyaXR5IGNvbnN0cmFpbnMgb24gSU1TSSBhbmQg
R1BSU1MvTFRFIHRlbXBvcmFyeSBpZGVudGlmaWVycyAoUC1UTVNJLCBHVVRJKS4gQUZBSUssIElN
U0kgaXMgdmVyeSByYXJlbHkgc2VudCBvbiB0aGUgYWlyIChtYXliZSBvbmx5IG9uZSB0aW1lIGF0
IHRoZSBiZWdpbm5pbmcgb2YgdGhlIDNHUFAgYXV0aGVudGljYXRpb24gcHJvY2VzcykgZm9yIHNl
Y3VyaXR5IHJlYXNvbnMuIFNvLCBJ4oCZbSB3b25kZXJpbmcgaWYgYWRkaW5nIElNU0kgdG8gdGhl
IGxpc3Qgb2YgSURzLCB3aXRob3V0IGFueSB3YXJuaW5ncywgaXMgc29tZWhvdyBpbnRyb2R1Y2lu
ZyBzZWN1cml0eSB3ZWFrbmVzcyB0byB0aGUgM0dQUCBzZWN1cml0eSBwcm9jZXNzLiAgIENvbnNl
cXVlbnRseSwgSeKAmW0gbm90IHN1cmUgYWJvdXQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQg4oCc
VGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IHNlY3VyaXR5IG1lY2hhbmlzbXMs
IGFuZCBkb2VzIG5vdCBoYXZlIGFueSBpbXBhY3Qgb24gZXhpc3Rpbmcgc2VjdXJpdHkgbWVjaGFu
aXNtcy7igJ0gSXTigJlzIG1heWJlIG5vdCBzbyB0cnVlIGZyb20gdGhlIDNHUFAgcG9pbnQgb2Yg
dmlld+KApg0KDQpNYXliZSB3ZSBzaG91bGQgc3RhdGUgdGhhdCB0aGUgSUQgb3B0aW9uIE1VU1Qg
YmUgdXNlZCBpbiBhIHdheSB0aGF0IGl0IGRvZXMgbm90IGhhcm0gZXhpc3Rpbmcgc2VjdXJpdHkg
bWVjaGFuaXNtcyAoaS5lLiB1c2UgdGhlIG9wdGlvbiB3aXRoIGNhdXRpb24g4pi6KS4gRm9yIGV4
YW1wbGUsIHRvIGFkZHJlc3MgdGhlIGlzc3VlIGFib3ZlIChtYXliZSB0aGVyZSBhcmUgb3RoZXIg
ZXhhbXBsZXPigKYgSSBkb27igJl0IGtub3figKYpLCB3ZSBjb3VsZCBzdGF0ZSB0aGF0IHRoZSBJ
TVNJIHNob3VsZCBiZSB0cmFuc21pdHRlZCBvbmx5IGR1cmluZyBmaXJzdCBiaW5kaW5nIHVwZGF0
ZSwgYW5kIG5vdCB0cmFuc21pdHRlZCBhbnltb3JlIGFzIGxvbmcgYXMgdGhlIGFzc29jaWF0aW9u
IElNU0kvSG9BL0hOUCBpcyBkb25l4oCmLiBPci4uLiBzaW1wbGVyIHdheSB0byBhZGRyZXNzIHRo
ZSBpc3N1ZTogIGlmIG5vYm9keSBoYXMgdXNlLWNhc2UgZm9yIHRyYW5zbWl0dGluZyB0aGUgSU1T
SSwgd2UgY2FuIHNpbXBseSByZW1vdmUgdGhlIElNU0kgZnJvbSB0aGUgbGlzdCDimLoNCg0KQlIs
DQpQaWVycmljaw0KDQoNCkRlIDogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIERl
IGxhIHBhcnQgZGUgQ2hhcmxlcyBFLiBQZXJraW5zDQpFbnZvecOpIDogbWFyZGkgMjMgc2VwdGVt
YnJlIDIwMTQgMjE6MTANCsOAIDogZG1tQGlldGYub3JnDQpPYmpldCA6IFtETU1dIEZ3ZDogTmV3
IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wZXJraW5zLWRtbS00MjgzbW5pZHMtMDAu
dHh0DQoNCkhlbGxvIGZvbGtzLA0KDQpXZSBoYXZlIHB1Ymxpc2hlZCBhIC4uLi0wMCB2ZXJzaW9u
IG9mIHRoZSBNTklEcyBkcmFmdC4gIFRoaXMgaXMgbWFpbmx5IGZvcg0KcmVmZXJlbmNlIHB1cnBv
c2VzLiAgQSBuZXcgdmVyc2lvbiBzaG91bGQgYmUgb3V0IHdpdGhpbiBhIHdlZWsgb3Igc28sDQpp
bmNvcnBvcmF0aW5nIHRoZSBzdWdnZXN0aW9ucyBhbmQgY29tbWVudHMgZnJvbSBwZW9wbGUgd2hv
IHJlc3BvbmRlZA0KdG8gdGhlIGVhcmxpZXIgc3VnZ2VzdGlvbiB0byByZXZpc2l0IHRoaXMgd29y
ay4NCg0KUmVnYXJkcywNCkNoYXJsaWUgUC4NCg0KDQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdl
IC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0
LXBlcmtpbnMtZG1tLTQyODNtbmlkcy0wMC50eHQNCg0KRGF0ZToNCg0KVHVlLCAyMyBTZXAgMjAx
NCAxMDo0MzoxMiAtMDcwMA0KDQpGcm9tOg0KDQo8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPjxt
YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KDQpUbzoNCg0KQ2hhcmxlcyBFLiBQZXJr
aW5zIDxjaGFybGllcEBjb21wdXRlci5vcmc+PG1haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmc+
LCBWaWpheSBEZXZhcmFwYWxsaSA8dW5rbm93bi1lbWFpbC1WaWpheS1EZXZhcmFwYWxsaUBpZXRm
YS5hbXNsLmNvbT48bWFpbHRvOnVua25vd24tZW1haWwtVmlqYXktRGV2YXJhcGFsbGlAaWV0ZmEu
YW1zbC5jb20+LCBDaGFybGVzIEUuUGVya2lucyA8Y2hhcmxpZXBAY29tcHV0ZXIub3JnPjxtYWls
dG86Y2hhcmxpZXBAY29tcHV0ZXIub3JnPg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy
YWZ0LXBlcmtpbnMtZG1tLTQyODNtbmlkcy0wMC50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5
IHN1Ym1pdHRlZCBieSBDaGFybGVzIEUuIFBlcmtpbnMgYW5kIHBvc3RlZCB0byB0aGUNCg0KSUVU
RiByZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAgICAgICBkcmFmdC1wZXJraW5zLWRtbS00Mjgz
bW5pZHMNCg0KUmV2aXNpb246ICAgICAwMA0KDQpUaXRsZTogICAgICAgIE1OIElkZW50aWZpZXIg
VHlwZXMgZm9yIFJGQyA0MjgzIE1vYmlsZSBOb2RlIElkZW50aWZpZXIgT3B0aW9uDQoNCkRvY3Vt
ZW50IGRhdGU6IDIwMTQtMDktMjMNCg0KR3JvdXA6ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Np
b24NCg0KUGFnZXM6ICAgICAgICA0DQoNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu
b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wZXJraW5zLWRtbS00MjgzbW5pZHMtMDAudHh0DQoN
ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1w
ZXJraW5zLWRtbS00MjgzbW5pZHMvDQoNCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5zLWRtbS00MjgzbW5pZHMtMDANCg0KDQoNCg0KDQpBYnN0
cmFjdDoNCg0KICAgQWRkaXRpb25hbCBJZGVudGlmaWVyIFR5cGVzIGFyZSBwcm9wb3NlZCBmb3Ig
dXNlIHdpdGggdGhlIE1vYmlsZSBOb2RlDQoNCiAgIElkZW50aWZpZXIgT3B0aW9uIGZvciBNSVB2
NiAoUkZDIDQyODMpLg0KDQoNCg0KDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg
dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KDQp1
bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz
LmlldGYub3JnLg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0KDQoNCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl
cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2
ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv
cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxs
ZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl
cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw
dGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg
c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoK
VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs
IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsK
dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1
dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs
ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl
IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp
ZWQuClRoYW5rIHlvdS4KCg==

--_000_81C77F07008CA24F9783A98CFD706F71142A4CBBPEXCVZYM12corpo_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z
b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0
aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn
aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46
MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxD
YXINCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9u
dC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBw
dCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48
L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5r
PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBDaGFybGll
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGxpc3TigKYgaXQgbG9va3Mg
Z29vZC4gSeKAmW0ganVzdCB3b25kZXJpbmcgYWJvdXQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnPi
gKYgQWN0dWFsbHksIGZyb20gM0dQUCBzdGFuZHBvaW50LCBzZWN1cml0eSBjb25zdHJhaW5zIG9u
IElNU0kNCiBhbmQgR1BSU1MvTFRFIHRlbXBvcmFyeSBpZGVudGlmaWVycyAoUC1UTVNJLCBHVVRJ
KS4gQUZBSUssIElNU0kgaXMgdmVyeSByYXJlbHkgc2VudCBvbiB0aGUgYWlyIChtYXliZSBvbmx5
IG9uZSB0aW1lIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIDNHUFAgYXV0aGVudGljYXRpb24gcHJv
Y2VzcykgZm9yIHNlY3VyaXR5IHJlYXNvbnMuIFNvLCBJ4oCZbSB3b25kZXJpbmcgaWYgYWRkaW5n
IElNU0kgdG8gdGhlIGxpc3Qgb2YgSURzLCB3aXRob3V0IGFueQ0KIHdhcm5pbmdzLCBpcyBzb21l
aG93IGludHJvZHVjaW5nIHNlY3VyaXR5IHdlYWtuZXNzIHRvIHRoZSAzR1BQIHNlY3VyaXR5IHBy
b2Nlc3MuICZuYnNwOyZuYnNwO0NvbnNlcXVlbnRseSwgSeKAmW0gbm90IHN1cmUgYWJvdXQgdGhl
IGZvbGxvd2luZyBzdGF0ZW1lbnQg4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv
cjp3aW5kb3d0ZXh0Ij5UaGlzIGRvY3VtZW50IGRvZXMgbm90DQogaW50cm9kdWNlIGFueSBzZWN1
cml0eSBtZWNoYW5pc21zLCBhbmQgZG9lcyBub3QgaGF2ZSBhbnkgaW1wYWN0IG9uIGV4aXN0aW5n
IHNlY3VyaXR5IG1lY2hhbmlzbXMu4oCdDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdOKAmXMgbWF5YmUgbm90IHNvIHRydWUg
ZnJvbSB0aGUgM0dQUCBwb2ludCBvZiB2aWV34oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPk1heWJlIHdlIHNob3VsZCBzdGF0ZSB0aGF0IHRoZSBJRCBvcHRpb24gTVVTVCBi
ZSB1c2VkIGluIGEgd2F5IHRoYXQgaXQgZG9lcyBub3QgaGFybSBleGlzdGluZyBzZWN1cml0eSBt
ZWNoYW5pc21zIChpLmUuIHVzZSB0aGUgb3B0aW9uIHdpdGggY2F1dGlvbg0KPC9zcGFuPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu
Z3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPikuIEZvciBleGFtcGxlLCB0byBhZGRyZXNzIHRoZSBp
c3N1ZSBhYm92ZSAobWF5YmUgdGhlcmUgYXJlIG90aGVyIGV4YW1wbGVz4oCmDQogSSBkb27igJl0
IGtub3figKYpLCB3ZSBjb3VsZCBzdGF0ZSB0aGF0IHRoZSBJTVNJIHNob3VsZCBiZSB0cmFuc21p
dHRlZCBvbmx5IGR1cmluZyBmaXJzdCBiaW5kaW5nIHVwZGF0ZSwgYW5kIG5vdCB0cmFuc21pdHRl
ZCBhbnltb3JlIGFzIGxvbmcgYXMgdGhlIGFzc29jaWF0aW9uIElNU0kvSG9BL0hOUCBpcyBkb25l
4oCmLiBPci4uLiBzaW1wbGVyIHdheSB0byBhZGRyZXNzIHRoZSBpc3N1ZTogJm5ic3A7aWYgbm9i
b2R5IGhhcyB1c2UtY2FzZSBmb3IgdHJhbnNtaXR0aW5nDQogdGhlIElNU0ksIHdlIGNhbiBzaW1w
bHkgcmVtb3ZlIHRoZSBJTVNJIGZyb20gdGhlIGxpc3QgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFG
NDk3RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUiw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBpZXJyaWNrPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk
ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmdd
DQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBDaGFybGVzIEUuIFBlcmtpbnM8YnI+DQo8Yj5FbnZvecOp
Jm5ic3A7OjwvYj4gbWFyZGkgMjMgc2VwdGVtYnJlIDIwMTQgMjE6MTA8YnI+DQo8Yj7DgCZuYnNw
Ozo8L2I+IGRtbUBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0RNTV0gRndkOiBO
ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXBlcmtpbnMtZG1tLTQyODNtbmlkcy0w
MC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhlbGxvIGZvbGtzLDxicj4NCjxicj4NCldlIGhhdmUg
cHVibGlzaGVkIGEgLi4uLTAwIHZlcnNpb24gb2YgdGhlIE1OSURzIGRyYWZ0LiZuYnNwOyBUaGlz
IGlzIG1haW5seSBmb3I8YnI+DQpyZWZlcmVuY2UgcHVycG9zZXMuJm5ic3A7IEEgbmV3IHZlcnNp
b24gc2hvdWxkIGJlIG91dCB3aXRoaW4gYSB3ZWVrIG9yIHNvLDxicj4NCmluY29ycG9yYXRpbmcg
dGhlIHN1Z2dlc3Rpb25zIGFuZCBjb21tZW50cyBmcm9tIHBlb3BsZSB3aG8gcmVzcG9uZGVkPGJy
Pg0KdG8gdGhlIGVhcmxpZXIgc3VnZ2VzdGlvbiB0byByZXZpc2l0IHRoaXMgd29yay48YnI+DQo8
YnI+DQpSZWdhcmRzLDxicj4NCkNoYXJsaWUgUC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t
LS0tLS0tIDxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y
ZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0K
PHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNt
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246
cmlnaHQiPjxiPlN1YmplY3Q6IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9
InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5ldyBWZXJz
aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcGVya2lucy1kbW0tNDI4M21uaWRzLTAwLnR4dDxv
OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0i
dG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RGF0ZTogPG86cD48
L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHVlLCAyMyBTZXAgMjAxNCAxMDo0MzoxMiAtMDcwMDxv
OnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0i
dG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RnJvbTogPG86cD48
L286cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp
ZXRmLm9yZyI+Jmx0O2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48
L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxl
PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i
cmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5UbzogPG86cD48L286cD48L2I+PC9w
Pg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Q2hhcmxlcyBFLiBQZXJraW5zIDxhIGhyZWY9Im1haWx0bzpjaGFybGllcEBj
b21wdXRlci5vcmciPiZsdDtjaGFybGllcEBjb21wdXRlci5vcmcmZ3Q7PC9hPiwgVmlqYXkgRGV2
YXJhcGFsbGkNCjxhIGhyZWY9Im1haWx0bzp1bmtub3duLWVtYWlsLVZpamF5LURldmFyYXBhbGxp
QGlldGZhLmFtc2wuY29tIj4mbHQ7dW5rbm93bi1lbWFpbC1WaWpheS1EZXZhcmFwYWxsaUBpZXRm
YS5hbXNsLmNvbSZndDs8L2E+LCBDaGFybGVzIEUuUGVya2lucw0KPGEgaHJlZj0ibWFpbHRvOmNo
YXJsaWVwQGNvbXB1dGVyLm9yZyI+Jmx0O2NoYXJsaWVwQGNvbXB1dGVyLm9yZyZndDs8L2E+PG86
cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwcmU+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXBlcmtpbnMtZG1tLTQyODNt
bmlkcy0wMC50eHQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5oYXMgYmVlbiBzdWNjZXNzZnVsbHkg
c3VibWl0dGVkIGJ5IENoYXJsZXMgRS4gUGVya2lucyBhbmQgcG9zdGVkIHRvIHRoZTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPklFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5OYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1wZXJraW5zLWRtbS00MjgzbW5pZHM8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5SZXZpc2lvbjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDA8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgTU4gSWRlbnRpZmllciBUeXBlcyBmb3IgUkZDIDQyODMgTW9iaWxlIE5v
ZGUgSWRlbnRpZmllciBPcHRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Eb2N1bWVudCBkYXRl
OiAyMDE0LTA5LTIzPG86cD48L286cD48L3ByZT4NCjxwcmU+R3JvdXA6Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPlBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyA0PG86cD48L286cD48L3ByZT4NCjxwcmU+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJo
dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wZXJraW5zLWRtbS00Mjgz
bW5pZHMtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1w
ZXJraW5zLWRtbS00MjgzbW5pZHMtMDAudHh0PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN0
YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEg
aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVya2lucy1kbW0t
NDI4M21uaWRzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVya2lu
cy1kbW0tNDI4M21uaWRzLzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5IdG1saXplZDombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtcGVya2lucy1kbW0tNDI4M21uaWRzLTAwIj5odHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1wZXJraW5zLWRtbS00MjgzbW5pZHMtMDA8L2E+PG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+QWJzdHJhY3Q6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7IEFkZGl0aW9uYWwgSWRlbnRpZmllciBUeXBlcyBhcmUgcHJvcG9zZWQgZm9yIHVzZSB3
aXRoIHRoZSBNb2JpbGUgTm9kZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBJ
ZGVudGlmaWVyIE9wdGlvbiBmb3IgTUlQdjYgKFJGQyA0MjgzKS48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UGxlYXNlIG5vdGUgdGhhdCBpdCBt
YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm
IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50
ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw
cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0
ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz
YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxl
IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj
dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5l
IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l
IG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1h
eSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5
IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl
ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0
aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0
aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk
LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp
ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_81C77F07008CA24F9783A98CFD706F71142A4CBBPEXCVZYM12corpo_--


From nobody Wed Sep 24 10:47:37 2014
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 B97FE1A02D9 for ; Wed, 24 Sep 2014 10:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Level: 
X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 3m-eXp2yzZmO for ; Wed, 24 Sep 2014 10:47:34 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719561A02D6 for ; Wed, 24 Sep 2014 10:47:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1335; q=dns/txt; s=iport; t=1411580855; x=1412790455; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=kRz+h1G5QfWQpdpj9o0sF4c9Gq68xvhpLu9sNtyKsqE=; b=A6e1OyXzu2sa2Hqd45k6/lhWiD/8ODWs7k/zNuQqxvBcwVPNxvaTzEco ottnZ8cR3iT2l68I5xbaduAZjwbpr6aHqxuZgUFWgQ5iJYD4eEtS4c6mg fpKjMwHWYb4hAFPGR5w+oBJDgYEig+vlWbKlx3KK1BcIXOXNrCSf6KEdL Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAGIDI1StJA2M/2dsb2JhbABggw6BLtIRAYEIFgF6hAQCBDpRAQg2QiUCBAESG4gjxBQBF49zMoRLAQSRXotDlVSDYmwBgUeBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,590,1406592000"; d="scan'208";a="80912695"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 24 Sep 2014 17:47:13 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s8OHlCNQ021964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 17:47:12 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 12:47:12 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP2B+SLHUp87997Eiiwqu0LbYHLw==
Date: Wed, 24 Sep 2014 17:47:12 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D25E30@XCH-BLV-504.nw.nos.boeing.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.217]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/YKo2fqgsODgzawsy9s1EBe5fwXc
Subject: Re: [DMM] Signaling Message Fragmentation
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, 24 Sep 2014 17:47:35 -0000

Hi Fred,



On 9/23/14 5:00 PM, "Templin, Fred L"  wrote:

>Hi Sri,
>
>> >
>> >I'm not much of a fan of advertised MTU values in RAs and such. It
>> >may be OK if your tunnel is point-to-point, but I want good MTU
>> >solution for NBMA tunnels where the MTU between neighbors A and B
>> >may be vastly different than the MTU between neighbors A and C.
>>=20
>>=20
>> Its a P2P tunnel and so the NBMA considerations may not be needed.
>
>What might be needed however is a solution that recurses for
>deeply-nested tunnels-within-tunnels (remember "nested NEMO"?).
>AERO tunnels can recurse indefinitely, with a minimum of 1500
>seen at each level.

Ok.=20

I remember the nested NEMO discussions, but at least for mobile network
use-cases I have not seen any real deployment use-cases for that
requirement. But, it will be good to have some discussions on that topic.



>
>> >I also want there to be a guaranteed minimum and an unlimited maximum.
>> >With AERO, all paths are guaranteed to support a minimum MTU of 1500.
>> >But, larger packets can also go through (unfragmented) if the path
>> >MTU is sufficient.
>>=20
>>=20
>> Ok.
>
>Good. We will need this if we want to push the Internet MTU up
>to something more robust like 9KB or more.

OK.

Regards
Sri


From nobody Wed Sep 24 10:48:08 2014
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 6706C1A02D6 for ; Wed, 24 Sep 2014 10:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 6fy3PYv-RKri for ; Wed, 24 Sep 2014 10:48:05 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59A31A02A6 for ; Wed, 24 Sep 2014 10:48:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20421; q=dns/txt; s=iport; t=1411580885; x=1412790485; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=7P6bMgfuSXmGrr8bZrHFF4GHfCZxOHU3FV1q523v0I0=; b=jFVTyeZyB7zf+fwe08fWbmQveIWnJQZwpP0YCBqqJvOcvknKaMh7zyQQ WXoYWH2snoeIj+DHHqHcGalEhpqfNOglAGxCUQQp//nPg4DwwZGmp5Lig AoSZ+cgEIfL0lsgzTbnMtNKFTKo3u5fyKpW/THcrFsTMEEK12btzfayBJ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFALACI1StJV2R/2dsb2JhbABggkhGU1vIV4Fvh0sBgQgWAXqEAwEBAQQtSg4GAQgRAwECKDkUCQgCBAESCYg1DcQIARePPBEBPwwBCgEGhEUFj0aCGIQ6hwmBYZNzg2JsAYEFCRcEHoECAQEB
X-IronPort-AV: E=Sophos; i="5.04,590,1406592000"; d="scan'208,217"; a="80907057"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 24 Sep 2014 17:48:04 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8OHm3oS006116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 17:48:03 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 12:48:03 -0500
From: "Sri Gundavelli (sgundave)" 
To: "pierrick.seite@orange.com" , "Charles E. Perkins" , "dmm@ietf.org" 
Thread-Topic: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt
Thread-Index: AQHP2B+vbWAmSJ+ZZk+IjZ2MCbQbOg==
Date: Wed, 24 Sep 2014 17:48:02 +0000
Message-ID: 
In-Reply-To: <13894_1411574165_5422E995_13894_4130_1_81C77F07008CA24F9783A98CFD706F71142A4CBB@PEXCVZYM12.corporate.adroot.infra.ftgroup>
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.217]
Content-Type: multipart/alternative; boundary="_000_D04850541666A2sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/K98Pv-io_265l8hmJTCozySnaQE
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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: Wed, 24 Sep 2014 17:48:07 -0000

--_000_D04850541666A2sgundaveciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Pierrick,

The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP TS 2=
3.003. It is sent in PBU/PBA messages. Not sure, if IMSI information is see=
n as a confidential IE. But, I agree on the need to include some text on ho=
w the signaling message can be protected with privacy / confidentiality ser=
vice set, when the identifier is based on some confidential data.


Regards
Sri

From: "pierrick.seite@orange.com" >
Date: Wednesday, September 24, 2014 8:56 AM
To: "Charles E. Perkins" >, "dmm@ietf.org" =
>
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283=
mnids-00.txt

Hi Charlie,

Thanks for the list=85 it looks good. I=92m just wondering about security c=
onsiderations=85 Actually, from 3GPP standpoint, security constrains on IMS=
I and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI is very r=
arely sent on the air (maybe only one time at the beginning of the 3GPP aut=
hentication process) for security reasons. So, I=92m wondering if adding IM=
SI to the list of IDs, without any warnings, is somehow introducing securit=
y weakness to the 3GPP security process.   Consequently, I=92m not sure abo=
ut the following statement =93This document does not introduce any security=
 mechanisms, and does not have any impact on existing security mechanisms.=
=94 It=92s maybe not so true from the 3GPP point of view=85

Maybe we should state that the ID option MUST be used in a way that it does=
 not harm existing security mechanisms (i.e. use the option with caution :)=
). For example, to address the issue above (maybe there are other examples=
=85 I don=92t know=85), we could state that the IMSI should be transmitted =
only during first binding update, and not transmitted anymore as long as th=
e association IMSI/HoA/HNP is done=85. Or... simpler way to address the iss=
ue:  if nobody has use-case for transmitting the IMSI, we can simply remove=
 the IMSI from the list :)

BR,
Pierrick


De : dmm [mailto:dmm-bounces@ietf.org] De la part de Charles E. Perkins
Envoy=E9 : mardi 23 septembre 2014 21:10
=C0 : dmm@ietf.org
Objet : [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids=
-00.txt

Hello folks,

We have published a ...-00 version of the MNIDs draft.  This is mainly for
reference purposes.  A new version should be out within a week or so,
incorporating the suggestions and comments from people who responded
to the earlier suggestion to revisit this work.

Regards,
Charlie P.


-------- Original Message --------
Subject:

New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Date:

Tue, 23 Sep 2014 10:43:12 -0700

From:



To:

Charles E. Perkins , V=
ijay Devarapalli , Charles E.Perkins 



A new version of I-D, draft-perkins-dmm-4283mnids-00.txt

has been successfully submitted by Charles E. Perkins and posted to the

IETF repository.



Name:         draft-perkins-dmm-4283mnids

Revision:     00

Title:        MN Identifier Types for RFC 4283 Mobile Node Identifier Optio=
n

Document date: 2014-09-23

Group:        Individual Submission

Pages:        4

URL:            http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283m=
nids-00.txt

Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnid=
s/

Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00





Abstract:

   Additional Identifier Types are proposed for use with the Mobile Node

   Identifier Option for MIPv6 (RFC 4283).









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat







___________________________________________________________________________=
______________________________________________

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.


--_000_D04850541666A2sgundaveciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi Pierrick,







The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP=
 TS 23.003. It is sent in PBU/PBA messages. Not sure, if IMSI information i=
s seen as a confidential IE. But, I agree on the need to include some text =
on how the signaling message can
 be protected with privacy / confidentiality service set, when the identifi=
er is based on some confidential data.












Regards


Sri









From: "pierrick.seite@orange.com" <pierrick.seite@orange.com>

Date: Wednesday, September 24, 2014=
 8:56 AM

To: "Charles E. Perkins" =
<charliep@computer.org>,=
 "dmm@ietf.org" <dmm@ietf.org>

Subject: Re: [DMM] Fwd: New Version=
 Notification for draft-perkins-dmm-4283mnids-00.txt

















Hi Charlie,


 


Thanks for the list=
=85 it looks good. I=92m just wondering about security considerations=85 Ac=
tually, from 3GPP standpoint, security constrains
 on IMSI and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI is=
 very rarely sent on the air (maybe only one time at the beginning of the 3=
GPP authentication process) for security reasons. So, I=92m wondering if ad=
ding IMSI to the list of IDs, without
 any warnings, is somehow introducing security weakness to the 3GPP securit=
y process.   Consequently, I=92m not sure about the following sta=
tement =93This document
 does not introduce any security mechanisms, and does not have any impact o=
n existing security mechanisms.=94
It=92s maybe not so true from the 3=
GPP point of view=85


 


Maybe we should sta=
te that the ID option MUST be used in a way that it does not harm existing =
security mechanisms (i.e. use the option
 with caution J). F=
or example, to address the issue above (maybe
 there are other examples=85 I don=92t know=85), we could state that the IM=
SI should be transmitted only during first binding update, and not transmit=
ted anymore as long as the association IMSI/HoA/HNP is done=85. Or... simpl=
er way to address the issue:  if nobody
 has use-case for transmitting the IMSI, we can simply remove the IMSI from=
 the list
J=



 


BR,


Pierrick=



 


 








De : dmm [<=
a href=3D"mailto:dmm-bounces@ietf.org">mailto:dmm-bounces@ietf.org]
De la part de Charles E. Perkins

Envoy=E9 : mardi 23 septembre 2014 21:10

=C0 : dmm@ietf.org

Objet : [DMM] Fwd: New Version Notification for draft-perkins-d=
mm-4283mnids-00.txt






 


Hello folks,



We have published a ...-00 version of the MNIDs draft.  This is mainly=
 for

reference purposes.  A new version should be out within a week or so,<=
br>
incorporating the suggestions and comments from people who responded

to the earlier suggestion to revisit this work.



Regards,

Charlie P.








-------- Original Message -------- 








Subjec=
t: 




New Version Notification for draft-perkins-dmm-4283m=
nids-00.txt








Date: =





Tue, 23 Sep 2014 10:43:12 -0700








From: =





<inte=
rnet-drafts@ietf.org>








To: 




Charles E. Perkins <charliep@computer.org>, Vijay Devarapalli
<unkno=
wn-email-Vijay-Devarapalli@ietfa.amsl.com>, Charles E.Perkins
<charliep@computer.org><=
o:p>








 


A new version of I-D, draft-perkins-dmm-4283mnids-00.txt

has been successfully submitted by Charles E. Perkins and posted to th=
e


IETF repository.


 


Name:         draft-perkins-dm=
m-4283mnids


Revision:     00


Title:        MN Identifier Types f=
or RFC 4283 Mobile Node Identifier Option


Document date: 2014-09-23


Group:        Individual Submission=



Pages:        4


URL:           =
 http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00=
.txt


Status:         https://datatra=
cker.ietf.org/doc/draft-perkins-dmm-4283mnids/


Htmlized:       http://tools.ietf.org/html/dr=
aft-perkins-dmm-4283mnids-00


 


 


Abstract:


   Additional Identifier Types are proposed for use with the=
 Mobile Node


   Identifier Option for MIPv6 (RFC 4283).


 


            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       


 


 


Please note that it may take a couple of minutes from the time of subm=
ission


until the htmlized version and diff are available at tools.ietf.org.


 


The IETF Secretariat


 


 


 




 






______________________________________________________________________=
___________________________________________________

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.










--_000_D04850541666A2sgundaveciscocom_--


From nobody Wed Sep 24 13:51:30 2014
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 C1FBC1A19EC for ; Wed, 24 Sep 2014 13:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 1JOIUWiiJsne for ; Wed, 24 Sep 2014 13:51:13 -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 2D0991A03D0 for ; Wed, 24 Sep 2014 13:51:12 -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 s8OKpCr3003449; Wed, 24 Sep 2014 13:51:12 -0700
Received: from XCH-BLV-402.nw.nos.boeing.com (xch-blv-402.nw.nos.boeing.com [130.247.25.31]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8OKp8HQ003296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 24 Sep 2014 13:51:11 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-402.nw.nos.boeing.com ([169.254.2.160]) with mapi id 14.03.0181.006; Wed, 24 Sep 2014 13:50:34 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1YkwgAEM+6CAAPHCgP//i1OggAB4a4D//5S3IIABoMoA//+6RxA=
Date: Wed, 24 Sep 2014 20:50:33 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D26B25@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D25E30@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/4SDVX8aD-DMa_yteH0bvnPpSZ44
Subject: Re: [DMM] Signaling Message Fragmentation
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, 24 Sep 2014 20:51:17 -0000

Hi Sri,

> I remember the nested NEMO discussions, but at least for mobile network
> use-cases I have not seen any real deployment use-cases for that
> requirement. But, it will be good to have some discussions on that topic.

I am thinking about the case when a mobile router A provides an access
link for a mobile router B, which provides an access link for a mobile
router C, which provides an access link for a mobile router D, etc.
Each mobile router would coordinate with their home networks so that
there would be tunnels-within-tunnels-within-tunnels-etc.

I can think of use cases related to my industry, for example when a
first airplane provides an access link to a second airplane, the second
airplane provides an access link to a third airplane, etc. I think this
might come up also for certain mobile ad-hoc scenarios.

In any case, however, whenever there is a fixed or mobile node connected
to an access link provided by a mobility anchor there is nothing stopping
the node from setting up a tunnel. Then, there will be at least one
tunnel-within-tunnel nesting.

Thanks - Fred
fred.l.templin@boeing.com


From nobody Wed Sep 24 13:58:55 2014
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 05E021A036D for ; Wed, 24 Sep 2014 13:58: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 kesh8JG6UUUz for ; Wed, 24 Sep 2014 13:58:47 -0700 (PDT)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6251A19EF for ; Wed, 24 Sep 2014 13:58:46 -0700 (PDT)
Received: by mail-la0-f46.google.com with SMTP id gi9so1135516lab.33 for ; Wed, 24 Sep 2014 13:58:44 -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=WwRWtTlgpCGkaq5WBJpJE2DCqg9vup0u/4ruUyBXLW4=; b=MMwdpi8Q9GexPdTppxw1VgFOYT27UxwFjjjeSJhEHetm5tLnVt7rwvJGZ1JUq9TWhm 2Led5l5bFLpQeFzMh1Dm/QqwI2o6ymGW9jbPLJwWCSF+zwefJoLR3/vgfpc8QtatgHeF ZkxuLgfYtp7YN54TtfTlO0HxhAlUT27b+4vNdjovuPeUjvR7DGHZo6FMAAv3jzzjoeEX uGqMYYNB0uHVVQgefM8FHAYgTEuG2+0GOCyur2JY+/swd3fR4zSN08oxU6a1aXsby7TB jO9m9RYW8003sSwiiE9mTT+/nPesXsfUZvQqtCksVNfwxRA+2KwO1laIehw4Gzeddj76 dXFg==
X-Received: by 10.152.19.166 with SMTP id g6mr8649574lae.37.1411592324705; Wed, 24 Sep 2014 13:58:44 -0700 (PDT)
Received: from [10.17.0.20] ([83.150.126.201]) by mx.google.com with ESMTPSA id kw10sm136453lbc.17.2014.09.24.13.58.42 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 13:58:43 -0700 (PDT)
Message-ID: <54233082.80305@gmail.com>
Date: Wed, 24 Sep 2014 23:58:42 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Sri Gundavelli (sgundave)" ,  "pierrick.seite@orange.com" , "Charles E. Perkins" ,  "dmm@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/j_QO_v21CFzMBr5L0rRf97zTUdM
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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: Wed, 24 Sep 2014 20:58:52 -0000

And yes we tried to get folks into senses here and allow temporary 
identities.. but no. Our dear telco vendors insisted having IMSI in the 
NAI in the MN-ID.. ;-)

- Jouni (with a flashback to 2008)

9/24/2014 8:48 PM, Sri Gundavelli (sgundave) kirjoitti:
> Hi Pierrick,
>
> The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP
> TS 23.003. It is sent in PBU/PBA messages. Not sure, if IMSI information
> is seen as a confidential IE. But, I agree on the need to include some
> text on how the signaling message can be protected with privacy /
> confidentiality service set, when the identifier is based on some
> confidential data.
>
>
> Regards
> Sri
>
> From: "pierrick.seite@orange.com "
> >
> Date: Wednesday, September 24, 2014 8:56 AM
> To: "Charles E. Perkins"  >, "dmm@ietf.org "
> >
> Subject: Re: [DMM] Fwd: New Version Notification for
> draft-perkins-dmm-4283mnids-00.txt
>
> Hi Charlie,
>
> Thanks for the list… it looks good. I’m just wondering about security
> considerations… Actually, from 3GPP standpoint, security constrains on
> IMSI and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI is
> very rarely sent on the air (maybe only one time at the beginning of the
> 3GPP authentication process) for security reasons. So, I’m wondering if
> adding IMSI to the list of IDs, without any warnings, is somehow
> introducing security weakness to the 3GPP security process.
>    Consequently, I’m not sure about the following statement “This
> document does not introduce any security mechanisms, and does not have
> any impact on existing security mechanisms.” It’s maybe not so true from
> the 3GPP point of view…
>
> Maybe we should state that the ID option MUST be used in a way that it
> does not harm existing security mechanisms (i.e. use the option with
> caution J). For example, to address the issue above (maybe there are
> other examples… I don’t know…), we could state that the IMSI should be
> transmitted only during first binding update, and not transmitted
> anymore as long as the association IMSI/HoA/HNP is done…. Or... simpler
> way to address the issue:  if nobody has use-case for transmitting the
> IMSI, we can simply remove the IMSI from the list J
>
> BR,
>
> Pierrick
>
> *De :*dmm [mailto:dmm-bounces@ietf.org] *De la part de* Charles E. Perkins
> *Envoyé :* mardi 23 septembre 2014 21:10
> *À :* dmm@ietf.org 
> *Objet :* [DMM] Fwd: New Version Notification for
> draft-perkins-dmm-4283mnids-00.txt
>
> Hello folks,
>
> We have published a ...-00 version of the MNIDs draft.  This is mainly for
> reference purposes.  A new version should be out within a week or so,
> incorporating the suggestions and comments from people who responded
> to the earlier suggestion to revisit this work.
>
> Regards,
> Charlie P.
>
>
>
> -------- Original Message --------
>
> *Subject: *
>
> 	
>
> New Version Notification for draft-perkins-dmm-4283mnids-00.txt
>
> *Date: *
>
> 	
>
> Tue, 23 Sep 2014 10:43:12 -0700
>
> *From: *
>
> 	
>
>  
>
> *To: *
>
> 	
>
> Charles E. Perkins 
> , Vijay Devarapalli
> 
> , Charles
> E.Perkins  
>
> A new version of I-D, draft-perkins-dmm-4283mnids-00.txt
>
> has been successfully submitted by Charles E. Perkins and posted to the
>
> IETF repository.
>
>
>
> Name:         draft-perkins-dmm-4283mnids
>
> Revision:     00
>
> Title:        MN Identifier Types for RFC 4283 Mobile Node Identifier Option
>
> Document date: 2014-09-23
>
> Group:        Individual Submission
>
> Pages:        4
>
> URL:http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt
>
> Status:https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/
>
> Htmlized:http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00
>
>
>
>
>
> Abstract:
>
>     Additional Identifier Types are proposed for use with the Mobile Node
>
>     Identifier Option for MIPv6 (RFC 4283).
>
>
>
>
>
>
>
>
>
> 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.
>
>
>
> The IETF Secretariat
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> 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.
>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>


From nobody Wed Sep 24 15:26:41 2014
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 68E911A1AC8 for ; Wed, 24 Sep 2014 15:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 zAaSIsrp4P1x for ; Wed, 24 Sep 2014 15:26:13 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639D11A1ADC for ; Wed, 24 Sep 2014 15:26:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44286; q=dns/txt; s=iport; t=1411597573; x=1412807173; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ObMZ35szlpfRHaphTEpi7natxrKbkDOILsn3iWgE69M=; b=Pj8bdqpFt/4L9ziU8K+PTAU1dNF+hp2RNpovkUo8G8n2IHpwJ02mHzV1 8RW8iTtOsu1FY4hpwNyJ6pkARSPyWpOi4s151aFlHxmZ4rE3aR4x52cHH y/1YV5WyzU80q6CpQ0wQsJhd6zNpanYE5YKdxbgyLiWgWqt6ysIfYfQlx s=;
X-Files: CF1352BB-928A-4DEE-8733-2DD79320CEB2.jpg : 27527
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0JAExEI1StJA2E/2dsb2JhbABggkhGgS7KdoEihXkBgQwWAXqEBAEBAwEFeQ0BCB0BAQEKFQkFEAEODBQRAgQBEQEGCIgoCMQ+ARePczIEhEcBBJFeg1aHbZVUg2JsAYFHgQIBAQE
X-IronPort-AV: E=Sophos;i="5.04,591,1406592000";  d="jpg'145?scan'145,208,217,145";a="80983291"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 24 Sep 2014 22:26:10 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8OMQALg014796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 22:26:10 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 17:26:10 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP2EaKWXYSGPcuIE+3vNRC+dMJtQ==
Date: Wed, 24 Sep 2014 22:26:10 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D26B25@XCH-BLV-504.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.217]
Content-Type: multipart/related; boundary="_004_D0488F8F16683Bsgundaveciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/CpEk8J0QUyJWwbeVL19AVANnwpk
Subject: Re: [DMM] Signaling Message Fragmentation
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, 24 Sep 2014 22:26:20 -0000

--_004_D0488F8F16683Bsgundaveciscocom_
Content-Type: multipart/alternative;
	boundary="_000_D0488F8F16683Bsgundaveciscocom_"

--_000_D0488F8F16683Bsgundaveciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Fred,


> I can think of use cases related to my industry, for example when a first=
 airplane provides an access link to a second airplane, the second airplane=
 provides an access link to a third airplane, etc.

Seems to match the below use-case. I do not know the Boeing's or the broade=
r Airline industry requirement, but personally I've not seen much interest =
for this.



[cid:CF1352BB-928A-4DEE-8733-2DD79320CEB2]



> In any case, however, whenever there is a fixed or mobile node connected =
to an access link provided by a mobility anchor there is nothing stopping t=
he node from setting up a tunnel.

Agree. That's there today; A MR on cellular access link, brings up a tunnel=
, which is on a transport tunnel.

Regards
Sri




On 9/24/14 1:50 PM, "Templin, Fred L" > wrote:

Hi Sri,

I remember the nested NEMO discussions, but at least for mobile network
use-cases I have not seen any real deployment use-cases for that
requirement. But, it will be good to have some discussions on that topic.

I am thinking about the case when a mobile router A provides an access
link for a mobile router B, which provides an access link for a mobile
router C, which provides an access link for a mobile router D, etc.
Each mobile router would coordinate with their home networks so that
there would be tunnels-within-tunnels-within-tunnels-etc.

I can think of use cases related to my industry, for example when a
first airplane provides an access link to a second airplane, the second
airplane provides an access link to a third airplane, etc. I think this
might come up also for certain mobile ad-hoc scenarios.

In any case, however, whenever there is a fixed or mobile node connected
to an access link provided by a mobility anchor there is nothing stopping
the node from setting up a tunnel. Then, there will be at least one
tunnel-within-tunnel nesting.

Thanks - Fred
fred.l.templin@boeing.com


--_000_D0488F8F16683Bsgundaveciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <1630F45F4DE79D4DAC0611F62BB83994@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi Fred,












> I can think of use cases related to my industry, for example when=
 a first airplane provides an access link to a second airplane, the se=
cond airplane provides an access link to a third airplane, etc.







Seems to match the below use-case. I do not know the Boeing's or the b=
roader Airline industry requirement, but personally I've not seen much inte=
rest for this.  






































> In any case, however, whenever there is a fixed or mobile node co=
nnected to an access link provided by a mobility anchor there is nothi=
ng stopping the node from setting up a tunnel. 











Agree. That's there today; A MR on cellular access link, brings up a t=
unnel, which is on a transport tunnel.







Regards


Sri






















On 9/24/14 1:50 PM, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:









Hi Sri,









I remember the nested NEMO discussions, but at least for mobile networ=
k


use-cases I have not seen any real deployment use-cases for that


requirement. But, it will be good to have some discussions on that top=
ic.









I am thinking about the case when a mobile router A provides an access=



link for a mobile router B, which provides an access link for a mobile=



router C, which provides an access link for a mobile router D, etc.

Each mobile router would coordinate with their home networks so that

there would be tunnels-within-tunnels-within-tunnels-etc.







I can think of use cases related to my industry, for example when a

first airplane provides an access link to a second airplane, the secon=
d


airplane provides an access link to a third airplane, etc. I think thi=
s


might come up also for certain mobile ad-hoc scenarios.







In any case, however, whenever there is a fixed or mobile node connect=
ed


to an access link provided by a mobility anchor there is nothing stopp=
ing


the node from setting up a tunnel. Then, there will be at least one

tunnel-within-tunnel nesting.







Thanks - Fred












--_000_D0488F8F16683Bsgundaveciscocom_--

--_004_D0488F8F16683Bsgundaveciscocom_
Content-Type: image/jpeg; name="CF1352BB-928A-4DEE-8733-2DD79320CEB2.jpg"
Content-Description: CF1352BB-928A-4DEE-8733-2DD79320CEB2.jpg
Content-Disposition: inline;
	filename="CF1352BB-928A-4DEE-8733-2DD79320CEB2.jpg"; size=27527;
	creation-date="Wed, 24 Sep 2014 22:26:10 GMT";
	modification-date="Wed, 24 Sep 2014 22:26:10 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQAAAQABAAD/4hrESUNDX1BST0ZJTEUAAQEAABq0YXBwbAIQAABtbnRyUkdC
IFhZWiAH3gAHABIABgAXACVhY3NwQVBQTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAA
AADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFk
ZXNjAAABUAAAAGJkc2NtAAABtAAAA7hjcHJ0AAAFbAAAACR3dHB0AAAFkAAAABRyWFlaAAAFpAAA
ABRnWFlaAAAFuAAAABRiWFlaAAAFzAAAABRyVFJDAAAF4AAACAxhYXJnAAAN7AAAACB2Y2d0AAAO
DAAABhJuZGluAAAUIAAABj5jaGFkAAAaYAAAACxtbW9kAAAajAAAAChiVFJDAAAF4AAACAxnVFJD
AAAF4AAACAxhYWJnAAAN7AAAACBhYWdnAAAN7AAAACBkZXNjAAAAAAAAAAhEaXNwbGF5AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAbWx1YwAAAAAAAAAeAAAADHNrU0sAAAAWAAABeGNhRVMAAAAYAAAB
jmhlSUwAAAAWAAABpnB0QlIAAAAYAAABvGl0SVQAAAAUAAAB1Gh1SFUAAAAUAAAB6HVrVUEAAAAc
AAAB/GtvS1IAAAAMAAACGG5iTk8AAAASAAACJGNzQ1oAAAAWAAACNnpoVFcAAAAMAAACTGRlREUA
AAAQAAACWHJvUk8AAAASAAACaHN2U0UAAAAQAAACenpoQ04AAAAMAAACTGphSlAAAAAOAAACimFy
AAAAAAAUAAACmGVsR1IAAAAiAAACrHB0UFQAAAAWAAACzm5sTkwAAAAWAAAC5GZyRlIAAAAWAAAC
+mVzRVMAAAASAAACaHRoVEgAAAAMAAADEHRyVFIAAAAUAAADHGZpRkkAAAAQAAADMGhySFIAAAAU
AAADQHBsUEwAAAASAAADVHJ1UlUAAAAkAAADZmVuVVMAAAASAAADimRhREsAAAAcAAADnABGAGEA
cgBlAGIAbgD9ACAATABDAEQATABDAEQAIABlAG4AIABjAG8AbABvAHIgDwBMAEMARAAgBeYF0QXi
BdUF4AXZAEwAQwBEACAAQwBvAGwAbwByAGkAZABvAEwAQwBEACAAYwBvAGwAbwByAGkAUwB6AO0A
bgBlAHMAIABMAEMARAQaBD4EOwRMBD4EQAQ+BDIEOAQ5ACAATABDAETO7LfsACAATABDAEQARgBh
AHIAZwBlAC0ATABDAEQAQgBhAHIAZQB2AG4A/QAgAEwAQwBEX2mCcgAgAEwAQwBEAEYAYQByAGIA
LQBMAEMARABMAEMARAAgAGMAbwBsAG8AcgBGAOQAcgBnAC0ATABDAEQwqzDpMPwAIABMAEMARCAP
AEwAQwBEACAGRQZEBkgGRgYpA4gDswPHA8EDyQO8A7cAIAO/A7gDzAO9A7cAIABMAEMARABMAEMA
RAAgAGEAIABDAG8AcgBlAHMASwBsAGUAdQByAGUAbgAtAEwAQwBEAEwAQwBEACAAYwBvAHUAbABl
AHUAcgBMAEMARAAgDioONQBSAGUAbgBrAGwAaQAgAEwAQwBEAFYA5AByAGkALQBMAEMARABMAEMA
RAAgAHUAIABiAG8AagBpAEsAbwBsAG8AcgAgAEwAQwBEBCYEMgQ1BEIEPQQ+BDkAIAQWBBoALQQ0
BDgEQQQ/BDsENQQ5AEMAbwBsAG8AcgAgAEwAQwBEAEwAQwBEAC0AZgBhAHIAdgBlAHMAawDmAHIA
bXRleHQAAAAAQ29weXJpZ2h0IEFwcGxlLCBJbmMuLCAyMDE0AFhZWiAAAAAAAADzUgABAAAAARbP
WFlaIAAAAAAAAGcyAAA18QAAAidYWVogAAAAAAAAaZcAALtOAAAHcVhZWiAAAAAAAAAmDAAADsEA
AMmUY3VydgAAAAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA2ADsAQABFAEoATwBUAFkAXgBj
AGgAbQByAHcAfACBAIYAiwCQAJUAmgCfAKMAqACtALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA
9gD7AQEBBwENARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGx
AbkBwQHJAdEB2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwC
tgLBAssC1QLgAusC9QMAAwsDFgMhAy0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5
BAYEEwQgBC0EOwRIBFUEYwRxBH4EjASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYF
lgWmBbUFxQXVBeUF9gYGBhYGJwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0
B4YHmQesB78H0gflB/gICwgfCDIIRghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJ
ugnPCeUJ+woRCicKPQpUCmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxD
DFwMdQyODKcMwAzZDPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUP
QQ9eD3oPlg+zD88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKE
EqMSwxLjEwMTIxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYW
SRZsFo8WshbWFvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpR
GncanhrFGuwbFBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e
6R8THz4faR+UH78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPC
I/AkHyRNJHwkqyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYp
OClrKZ0p0CoCKjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7u
LyQvWi+RL8cv/jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1
TTWHNcI1/TY3NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvo
PCc8ZTykPOM9Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdD
OkN9Q8BEA0RHRIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrE
SwxLU0uaS+JMKkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdT
E1NfU6pT9lRCVI9U21UoVXVVwlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuV
W+VcNVyGXNZdJ114XcleGl5sXr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk
6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5r
bsRvHm94b9FwK3CGcOBxOnGVcfByS3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54
zHkqeYl553pGeqV7BHtje8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INX
g7qEHYSAhOOFR4Wrhg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaO
zo82j56QBpBukNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/Jpo
mtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum
/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOu
tCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzB
Z8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83
z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3Zbe
HN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R
7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9
Kf26/kv+3P9t//9wYXJhAAAAAAADAAAAAmZmAADypwAADVkAABPQAAAKDnZjZ3QAAAAAAAAAAAAD
AQAAAgAAAFYBiQJxAzgEFgTlBcgGpwePCHkJZQpbC1UMUQ1WDlIPWhBgEWgSbhOGFMUWERdbGKYZ
8Rs8HIcd2R8wIH4h1CMrJIMl3Sc6KJgp9itULLQuFS95MOEyTDOyNRw2hjfvOVQ6vDwiPYg+7kBS
QbVDGER4RdlHOEiXSfVLVEyrTeNPE1BBUW1Sl1PBVOZWClcpWEZZXlpyW4NckF2bXqFfpmCoYadi
p2OjZJ5lkGZ/Z25oXmlOajxrK2wbbQtt+m7pb9hwx3G3cqdzlnSFdXR2Y3dSeEF5LHoXewF77HzX
fcF+rH+XgIGBbYJYg0OELoUahgWG8YfciMiJtIqgi4yMjY2Pjo6PjpCOkY2Si5OIlIKVfZZ0l2yY
YplWmkmbO5wsnRyeC576n+agzqGzopijfKRipUimLqcUp/uo4qnKqrGrmqyCrWyuVa8/sCmxE7H+
suiz07S4tZy2gLdjuEW5J7oIuui7x7ylvYG+XL83wBDA6cHBwpjDbsRDxRnF8cbQx7PIlsl6yl7L
QswozQ7N9c7cz8TQrNGV0n7TZ9RQ1TrWI9cN1/fY4dnS2sLbstyi3ZHegN9v4F3hSuI14yDkCuTy
5dnmv+ek6Ifpa+pN6y7sDOzX7aDua+838AXw1/Gs8oTzYPRB9SX2D/b99/D46Pni+uL74/zm/e3+
9P//AAAAVgFFAkEDLwPuBMEFhwZTBy4IFQjnCcYKpguMDHYNXw5IDzcQHRELEf4TLxReFZQWzBgD
GTcaaBuhHN0eGh9RII4hzCMKJEclhSbJKAgpSiqOK9QtHy5oL7UxAzJPM5k04zYtN3c4wjoLO1M8
mz3hPylAbUGyQvlEPkWDRrxH2EjpSfhLBkwRTR5OJ08vUDNRNlI2UzNULVUlVhtXD1gAWO9Z3lrN
W7pcoV2AXltfNWAPYOlhxGKgY3tkVWUvZgpm5WfAaJtpd2pRayxsB2zibb1umW9ycExxJnIActpz
s3SNdWd2QXcbd/R4znmneoJ7W3w0fQx95n6/f5iAc4FYgj6DI4QIhO6F1Ia6h6CIhYlrilCLNYwZ
jP+N5I7Ij66QkpF2kluTP5QglQCV35a/l6CYgZlhmkKbI5wEnOWdx56pn4ugbqFQojOjFaP4pNul
vqaip4KoYqlCqiKrA6vjrMOtpK6Dr2SwRLEksgSy5LPFtKW1hLZkt0S4JLkGuey61bu+vKm9k75+
v2vAWcFHwjfDKMQaxQ7GAsb4x+7I5cndytbLz8zJzczOz8/R0NPR1tLY09rU3NXe1uDX4tjk2eba
59vq3Ozd8N7z3/bg+eIB4yXkTuV55qfn2ekR6k7rkezZ7irvg/Dj8kzzu/Uz9q/4M/m7+0b81/5p
//8AAABWAS4B6wKdA1MECAS5BXYGNgbxB7gIfglIChwK8AvEDJYNag5FDyEP/hEGEhYTKhQ5FUUW
VhdqGIAZlRqtG8Uc3h36HxQgMCFOIm8jjiStJc8m8ygYKT8qZyuMLLAt1y79MCExRjJoM4o0rDXN
Nuw4DDkoOkg7ZDx/PZw+rj+rQJ5Bj0J+Q2tEWEVARiZHCUfoSMVJnkp0S0ZMFEzgTapOck82T/pQ
vVF+UjpS9VOwVGtVJVXfVppXVFgOWMdZgVo6WvNbrFxnXR9d116QX0lgAWC8YXpiOWL3Y7ZkdGUy
ZfFmr2dtaCpo6GmmamRrIGvdbJptVm4Tbs9vi3BIcQVxw3KBcz5z/HS5dXh2NXbxd654a3kneeN6
n3tbfBZ80n2Ofkh/A3/DgIyBWIIlgvGDvYSKhVaGI4bvh7uIh4lSih6K6ou1jICNS44WjuGPrJB2
kUKSD5Lck6mUdpVDlhGW3permHmZRpoUmuGbr5x9nUyeGp7on7aghKFToiWi+6PWpLCliqZkpz+o
G6j2qdKqr6uMrGmtR64mrwSv5LDDsaOyg7NktEq1OrYwtye4H7kYuhS7EbwRvRS+G78lwDLBRMJZ
w3PEj8WvxtLH+ckgyl3L4c2IzzTQ5dKg1GfWPtgq2i3cTd6P4PLjfeYt6QDr8+8K8kH1j/jz/G//
/wAAbmRpbgAAAAAAAAY2AACkEgAAVtUAAFVzAACkEgAAJT8AAA3MAABQDQAAVDkAAoUeAAIXCgAB
jMwAAwEAAAIAAAABAAIABgALABIAGgAkAC8APABKAFkAagB7AI8AowC5ANAA6QEDARsBMgFKAWMB
fQGYAbQB0QHvAg4CLQJNAm8CkQK0AtgC/QMiA0kDcAOYA8ED6wQWBEIEbgScBMoE+QUoBVgFigW8
Be8GIwZYBo4Gxgb+BzcHcgetB+oIJwhmCKYI5wkpCW0JsQn3Cj4KhgrPCxoLZQuxDAYMYQy9DRwN
fA3fDkMOqQ8TD34P7RBeENMRSxHGEkUSxhNME9UUYRTxFYMWGRaxF1IX+BigGUoZ9xqnG1kcDRzE
HX4eOh75H7ogfSFDIgwi2COmJHclSiYkJwEn4CjCKacqjit4LGUtUy5FLzowMTEqMiYzJTQnNSs2
Mjc7ODE5KTolOyM8JD0oPi8/OkBKQVxCdEOPRK5F0kb6SCZJVkqKS8JM/U5ET5JQ41I4U41U5lZB
V59Y/1phW8ZdLV6WYAFhb2LfZFJlx2dAaLlqQWvMbVxu8HCJciZzyXVxdx941HqOfE9+FH/fgbCD
h4Vih0CJDYrXjKKOb5BAkhGT5JW5l4+ZaJtDnSCe/6DhosWkrqaYqIWqdaxarkOwL7IftBK2CrgF
uga8Db4ZwCvCQ8RhxobIssrizRnPVdGW1BrWp9kz27veOuCz4yLlh+fi6jPseu648O7zIPVK93P5
mfu7/eD//wAAAAEAAwAGAAwAEwAdACgANABDAFMAZQB4AI0ApAC8ANcA8wEQASgBQgFcAXgBlAGy
AdEB8gITAjUCWAJ8AqICyALwAxgDQgNtA5kDxgPzBCMEUwSEBLYE6QUcBVEFhgW9BfQGLQZnBqMG
3wcdB1wHnAfdCCAIZAipCPAJOAmBCcwKGAplCrMLAwtUC6YMAgxnDM4NOA2kDhMOgw73D20P5xBj
EOMRZxHuEnkTBxOZFC8UyBVkFgMWphdVGAoYwxl/Gj0a/hvCHIodVB4hHvEfxSCaIXQiUCMvJBIk
9iXgJs0nvCivKaYqnyucLJstni6kL64wujHKMt4z9TUPNiw3SzheOXU6jzurPMo97D8RQDpBZUKU
Q8ZE+0YyR25Iq0ntSzJMeE3FTxlQcVHMUylUiFXsV1FYulomW5RdBV54X+5haGLjZGNl5GdqaPBq
gWwUbatvRHDhcoF0JHXMd3V5I3rUfIh+P3/5gbiDeYU/hwaIxoqEjEOOA4/HkYqTTpUTltmYn5pm
nC2d9Z+9oYejUqUfpuyou6qLrE6uE6/dsamzd7VItxu48brLvKa+hcBlwknEL8YWyAHJ7MvazcvP
vdGx03LVLdbn2KDaV9wK3bffY+EJ4qrkSOXe527o+uqC7APtgO778HDx4/NU9MD2K/eW+QD6Z/vN
/TX+m///AAAAAQAEAAkAEQAbACcANgBGAFkAbQCDAJsAtgDSAPABEAEsAUkBZwGHAakBzAHwAhUC
PAJkAo0CuALkAxEDQANwA6ED0wQHBDwEcwSqBOMFHQVYBZQF0gYSBlMGlQbZBx8HZgevB/oIRgiU
COQJNgmJCd8KNQqOCukLRQujDAsMfQzyDWoN5g5kDugPbw/7EIwRIxG/EmITCxO6FG8VKxXrFrEX
gRhWGTAaDhrwG9ccwh2yHqYfnyCbIZ0ioyOuJLwlySbXJ+kpASocKzssXy2ILrUv5jEcMlczlzTb
NiQ3cDi+OhE7aTzFPiQ/iUDzQmJD1kVPRsxIT0nWS2NM805uT+VRX1LeVF9V5ldvWP5akFwnXcFf
YGEEYqtkV2YGZ7tpcGsnbOFuoHBhcidz8XW+d495Y3s8fRZ+9YDYgr6EqYaWiHqKVYwyjhOP+JHe
k8eVspegmZCbgp12n2yhZaNgpV+nXqlhq1OtMa8PsO2yzLSqtoe4Yro6vA+94L+uwXjDPcUAxr/I
e8o1y+3Nos9Z0Q7SidPL1QHWN9ds2KDZ0tsA3C3dVN5335bgruHB4s3j1uTV5dHmxOey6Jzpfepf
6zXsDOzd7afucu827/jwufF08i7y6fOc9E/1AvWw9l33Cve0+F35Bvmt+lL6+Pud/D/84f2D/iP+
wv9g//8AAHNmMzIAAAAAAAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBsbW1vZAAA
AAAAAAYQAACctwAAAADGQ4SAAAAAAAAAAAAAAAAAAAAAAP/bAEMAAgICAgIBAgICAgICAgMDBgQD
AwMDBwUFBAYIBwgICAcICAkKDQsJCQwKCAgLDwsMDQ4ODg4JCxARDw4RDQ4ODv/bAEMBAgICAwMD
BgQEBg4JCAkODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O
Dv/AABEIANkBNQMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1
EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoW
FxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImK
kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy
8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUE
BAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkq
NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqi
o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAM
AwEAAhEDEQA/AP38ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKa7rHC8jsERQSzE4AA70AOprMFQkkAe5r4y8Y/tv/AAx0Pxxc+HfCGjeKfiVqFuSJ
59Ct1a2GDhtrk5fB/iVSp7Ma4G//AOChfwpS2/4mPhzxjpYi/wBfDd26A+ZkjYShbAGO+M5Ax1ry
qOeZfVrexhVTl67+j2fyZ99jfC3izB5c8wr4CpGkldtrVJ9ZR+KK82kj9BYJnmDOU2xk/Ie5HrVi
vgrwl+3p4C8ba82leGfD2palequ9oo7lcoucbmBXge9e4WH7Q/h+aIyaloHiXTYlj8xpBbCVAm4L
vGDllBIBIBAyM9RXurC1Wr8uh8C2luz6FornfDfizw94v0Maj4d1S11S1zh2iblD6MOoP1roqwlF
p2YJ3CiiikAUUUUAFFFFABRRXxr+3X4gvdG/YXfTrWK1kg17xBaafeNKpLJGokuwUwQA2+2jGSCN
pYYyQRx4/FrC4adZq/Kr2OvA4V4nEQop25nY+vNP1PTdWsJLrStQsdTtUuZrZ5rSdZUWaCV4ZoiV
JAeOWN43XqroykAgir1fkn+wbdX2gfFjxVrmpeMdL0LwNe6emnXOmXiRRi91N7yzhsX898MjhrqS
COJT++e7AI3JGD+qd7q1za6sbS30DWtT2wrI01t5KxjcWG3dJImWG3JAzgFc9RWeV454zCwruPLz
dL36/L1NMzwSwmJnRUubl67dPmbNFch4S8baL41j159Efzk0fVZdKv3W4gmSO7hwJ4N0MjrviY7H
XOUcMhwysB19egcAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUVHNKkFrJNI
wSNF3Mx6AUAPJAUkkADua+AP2ufjHc6tY6B8CvhrqMdz4l8Y6jHp+oXVtLlYYXdU8jcOhdnUN6IG
B+9X094l8dXstjLBoywRWzIRLeTsFxnsuc849jX5zP4d8L+CP+CmXwHXTJJTpd5rLvK09wZt15LK
Ru3EAkl3i+nGMV5HESnHLpW05nGN+ylJJv7mfqXg3hqFTiinVqwU/Ywq1YxeqlKlSlOC8/einbyP
0t+E3wm8JfB74S2HhbwtYQRskanUNQMQE+oTY+aWVupJOcDOFGAOBXzH+218AvD3jn9nfXfiJpml
Wtv4y0C1NzeTxRhTqFmo/fJLj7xRMurHJAQr0PH3VX57ftJ/tneGPh/8VPFvwVn8FaprYfSHs9X1
UXqxLbPdWoZBHEUPmqFlQsSyYyQAcc8udU8BRy/2FW0YvSOmztpa21u56PhZPi7OuMo4zLVLEYhN
1Kt2vep3SqKfM0nGSfLy9bpJXsfDf7KumeEvg78MdS8YeKdSsVvtZvZJIWnfLLbQyPHEuOpJZXbA
6nHXFfcs3xX0WXxb4S1GK/tGLefCGR+fKkgMoI9i0Mf51+ZHhD4UeIvHcukTWfiWC3m1CeLStH0e
4XKM5lkeS4JwWCInms23GQp4JxX2V4p/Zd0X4Y+CNP8AHdj4n8T+I18PKLjXbW9dAj26ptmmt1QL
5ZjUs/luzgqpXIPzVzUuMo4bE4ShjrRjUp02mtdZLVvsm7/1t8h4sYHhfI8xxWFwdWpKvTxFaMoc
q9nTpRk1D3r3crbpJ7O6Vlz9fB+0R4P8H/tP6X4n0bUUktdSkgs9dtIDlLmJ38vzcDjzI2aJt3dd
wOeMfqDBPFc2UNzA6yQSoHjdTwykZB/Kvw5j0P4J6U4urHw5rV9cQHzYnlnXeWByAOD3AxX6hfs8
fFLSfHfw2GhWkF3a3ehWsMRW5cM8sRGFbIA5GMEYr9Fx+VV6NFVJ6+nY+GpKysfRNFFFeIahRRRQ
AUUUUAFfBH7eWmaHr3wo8HaFd6VDb+Ibqe5bTPFNukR1DR40a3aeK3Mkbrtn/dK6uGQiNTs3rHJH
971+MH/BRP8Ad/t1eDLyP93d2vgu3ktp14eFjdaghZG6qSruuR2YjoTW9DAxxknSlazXVXR87xPx
R/q/gvrvK5WaWjs9eqZY+Efi3wr8KfA2l+GrHwNrXijX/EWrwaX4p8VX3iaK1+y6S8conuViWDy/
MjKxbIlT95JM5aWGNQB9seEv2lYNRm8aXR8PeEriK38RTRJcaJ4ra98yERxG3a5U24FtdGAwl4FM
ijKsrsHr8pPhVo/j3x14e8T2uj2HjnXPKlt7Vb7StKlvpLKW4hu3Vw3lSIMC1c5cGNW8pWAM8ayf
tV8JD8PPij8FPAHxfttM8G+KfEOq6Ra3M3iRNKg+1m7jiWKYM+wPFNFIjxPGdrRPG0ZVShUYPL6e
Ck6NNJJdtu56GTcRSzzA08dJNc99Jb6O34208rG18GdJ0C1+B9t4l0GfTdRXxpdzeLLzVbM+YNRk
1BvtCSGUu5lVIWggjYuQIYIUTbGiIvq1FFB6QUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAV8Z/tq/F/W/hh+ztp9h4VmSPxRr959ntc7c7EUu+ASAc4C/8Cr7Mr8if+Csmha23wa+
GXi/S2Y2+m6pPb3EeeCZY8g/+OY/Gu/LKVOpiYRm9GJ36HlPg39qLWda0q6h8c6JfaNcadgzeazR
JJGASXUSqpPToMjn71eN/EP9prwT4/m0W18NaT4g0/XtN1NLjS9UM1uCrAjJ2CQuOQrcAnKjivjm
0+K1hHbRbpr7TpIYUEYeGX74GHIZSeCfYV1WmftPNpvjQWMEWp6jYo6BZw6kkcZPzc/nXp4zA0Mx
w08HNuKkrNtb66NWejW/yPa4az/GZFm9DMsKlz0pXXZrZprqpJuL8mz+gr4N/tifDHxx8NrNPHPi
LSvAnja1iEeq2mqyi2glkUYMkMjYUqx52EhlORggBj+WX7YOseCPG/8AwUL1XXvAuv2ut6Vq1vZr
eX0YYQLcJGsD7WYDcoSOM7l45OCea8X8a/ETTvF2o6dcaZDctcMwN5c3SIZWGMAbhyR9a86+EEEn
i34geLfEl3qT3cUd81ra6VKhdY441ZUaMdNxJcnByCqnmvgM44RzKp7ChiqsJQ54q6upNN8uq2Wj
u9Xqf0P4c+KPBvDWaYzOMpw9enXlQrfu24Soxag6iiml7SSc4RjFOKtfVux9DfB/4vaNpnjv4d+P
7Dzr/QNMuFkeJExKIWjlgmwveRVkc7e7DGec19QftJ/tW2EMun+BfAXiDwT4p8OeOPAmq+aYYJJb
6xnxBEglxOvkgx3Uj7JIg4MBX+LKfk74Tn/4Q9vE/hxEZray1y4jtTNJjCA45/EGrgvrPVviPp2p
taSXWoQRPbobSebcsTkb8BW254BzjPA5ru4t4CoZnCnmFJqM6dOyh0lZPlt2s9vkfzBlmEwma8S0
p5vVfsa1SPtn1tKS55X6O17uz7pHZeGPj1qY8H2WueL9Lkg0O5hsfL1KxtXiiilnBDowlclkQhR5
qnB3gYyK+tv+CeP7Q/i+b/gp1qHgPxxqGmaNofirSmXw9atpzys84hS8S0EyOFjk+z7pGaQMNyFB
gsK/Or4zWieDfgnptnpFnO3hvzY7Ka0ad5EhTJcE7iWOdpXJPHHtX7EfsC+FfhN4z/ajvPiQunW1
94z0zw7a3GmTXVwXlieSFoTcBVby2l8h2iMgUNhtvpj2MPxPDNMJTqU5Pld7rqntZ+m68rep9Xxz
wTmPCmb1srxjTnCzTV3GSaTUk7JtPbpqmtD9kaKKK5j5MKKKKACiiigAr8kv+CgulR2/7WngDxD4
h3ap4U/4Vzq1za6VZxRRXT31lqOnxhjMqxySK8eqlFilnaBX+fZGwMjfrbXx3+1x4P8ADfiLRPAk
2t/ESXwDf6jJqXhbTBJ4efVre9e/snuG3RxvE6PCNN88OZQjRRzxbGklheO6cnGV07HJjsPCvRlC
dNTT6StZ/emtj8TdW8arbfDm80nwk/irw74a1QfbfEmiyXM8xu5I1hMKmKKeSNxH5bHywj/vMMhB
Ll/3H/Yu8AeKvh9+wtodn4r1a7vJ9YuW1mx0u5s57aTQre4iiIsnSc7lkDrJK67I9kkzoVJUyP8A
BmhfCT4YfC/9sDw7pPgnwuvxqu7rVtTim8M6xfWbWdnbBlFpfSFYlRXu5pZ41MyyrK0TtHGnkzzR
/ffgn47yaz+33dfBWCxtH8PReCl12x1gW86G9leWIgQyMBFPD5cu7zYd67lZN25HVYxNaEakVdu/
V99P61OjhnKMficNW/cwpxpK6jF3tBXvfSK7WjG9lfVn1PRRRQWFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFeTfG7w94R8Sfs1+J7Txp4Zi8WaNFZvMbEx7nLKDhkPVWHYivWajl
ijntnhmRJYnGGRhkEehpptO6A/jq8QXl/wCGfjlcNrfh+6ufB1vfSEaf5SpcPFuO1DL/AHsYycV5
74v+JXg9vEMtz4d8AalokOePtEiTMfqdor+rv4hfshfBT4i3E9zqnhmCzvJSS01qNmSe+K+Xdb/4
JafB7VJ5Wtdc1KyRzyptlfH45FdkMwxEdpsbUX0P50tK+NmqRXu2DQ3niddn09/wr2T4Ra/p09nY
6DeagNE1ZLsvbmQMWuGklLgRlRjflsAMV5xz1I/bnTP+CUnwctJFN54i1i6QHJWOBY8/rXuvgz/g
nz+zT4Qkgm/4Q5tbu4mDLLf3DPyDnOBXBmVGnmKhDFtyjGSdlp/V0fZ8Ccf5xwZjauOyeUY1p05U
7zjzK0rPa62aT36WejZ/PDqfwv8AGWq6nd6tatLd65qeoNLc6Jp8JlksvN3SKpYcEjBBwBjjrnNe
o+Bv2MPj14wuEmsPB2swI3Hn3pMYA/Gv6KdP8BeAvCH7RPg+y8OeF9I06JdA1d5Y7S3QbcXWnKrv
nqBubnk8nHevfY4ool2xxoi+irivXzP2HNCVGDjFrRN32bW77pXfS+ysfmeS1sW41Y4qopzUtWoq
K1jGVklsk20t3ZK7b1P5qvil+zZ4v+F/gDw/4U+LNikuna1asIpraQOWWJ13KCekiBoz+K+9fr7+
yR+yB8Lv2fdDj8X+C9Svdfv9b0qPy9Smk+R7eQLIpRegDDaa6j9tH4cDx9+xJrd9awCXWfC7/wBs
WhA+YxxqRcLn08os+O5jWuf/AGFPiI/jL9jdPDd7MZdV8JXhsDuOWa2fMkBPsAXjHtEK/Oct/wBg
zmthfsVVzx9ftL9fRI/qbjKf+tfhzgM83xGBl9Xqvq4PWlJ+l1G/WUpH2pRRRX2J/OIUUUUAFFFF
ABXzt8YdE+JWv+FvGz2/xM0D4LeEdIt7S/tPEVw0lxB5Vs63VzcXhjnspbZE8pkeMXJheIBpGZXl
gH0TWfq2mwaz4V1PSLp5Y7a+tJLaVoiA4WRSpKkgjODxkGgD4r+Emk6joXgPw74i8Y+CYvGXhfU7
T7TrmrTeH/s39jXmm38ZhuI7S5dpzC80aXcMkSygLbrKJfkhebze6+FXhz4Mf8FX/wBmPWvDHiPx
RqXhrxJYapp8Ed3qazW8Aj0/5EiMaLuilmna5KuWXzpXZNqhET73/wCEQmn/AGdP+ECvNcu7a4k8
N/2RPrOl28cU0bG38lriGOYTIjA5dVkEqg4DBxnPyx+1nZWvhJ/2YfFljF9nsfDHxP0yyKhi3lWk
qlXG4knG2FVySeormxX8O/Zp/ifYcDe/mvsP+fsKsP8AwKnJL/yazPtyiiiuk+PCiiigAooooAKK
K/M39oX9sPU/BH7bfh3QPBsv2/w14UuWXxPbRyALqczjbLBu7eUpOD2lzkHaK8zNc3w+X0lUrPRt
L7/8lqfbcB+H+b8X5hPBZbC8owlNt6JKK0TfeTtFeb10Ta/TKvm/4m/tXfBb4XTT2Wp+JR4h12Il
X0nQFW7nRh1V23COMjuHcN7V8A6v8V/2l/2uPFl54b+HemXnhnwTv8u5h0+cw20aH/n7vCAXOD/q
1wGHSM4zX0d8LP2AvAHhyC11H4l6lc+OtZXDPY27tbadGfTjEkuD3LKD3SvAefY7Hvly6l7v889F
8lu/6uj9YXhVwxwnTVXjHH/vrX+rULSqek5fDH00T6TZ5Rr3/BRDxZqetPZ/D34YacueIDqlxLdy
ye5ih2Y+gY/WsR/22f2mdGjF9r3wv8PxaXH80z3Hhy/txt/66GbC/Ug1+qHhvwj4V8HaKNO8KeG9
D8N2OBmHTbKO3VsdzsAyfc810RAIIIyD1FX/AGFm0/eqY5p+UVb89TmfijwDhn7LC8MQlTXWdWTm
/O9nyv0bPgL4Zft//DzxPfxab8QdFvfh/euQqXqSm8sWP+0yqHjyfVWUd2FfeOn6jYatolrqelX1
pqWnXMYltrq1mWWKZD0ZWUkMD6ivnP4u/sofCb4s6dd3MuiweE/FUikxa5o8KxOX9ZYxhJh0zuG7
HAZa/PvTNe+N37Dvxrj0bXIpPEvw4v5iyQrI32C/TPzSQMc+RcAfeXHpkMNrVk81zHKpJY9c9N/b
itV/iX+X4s7o8CcHcdUZT4Uk8LjYpv6tVleM7av2VRu7flJ+qitT9nKK4X4dfEbwn8U/hXYeL/B2
orf6XcjDo2BNaygDdDKufldc8jvkEEggnuq+wpVYVYKcHdPZn87Y7A4jB4ieHxEHCpBtSi1ZprdN
dwopu5f7y/nS5HqPzrQ5RaKKKACiiigAooooAKKKKAPGfEuuaD4c/aKvda16+t9LsrDwNcXElxK2
FVGuohIcAcnKQqMcn5QAeK9G8K+KtA8beAtP8T+F9RTVdCvlY2t0sboH2uyN8rgMCGVhggHiuO+I
Hwm8JfETxb4U1nxNHe3B0OdjHZxyhbe9V3iby7hSp8yMPEjBcgZHOQcU/wCFtnDYeH/FtvaQpbWH
/CXam1tCi7VRTcNuAHYeYJOnFe5iFhKuBhOLftI2T25UtdF1be/Zbany2DlmFDNalOcY+xndp68z
do6voktY21bdndLR+i3tnbahpF3YXsKXFncwtDPE4+V0YFWU+xBIr8k/2Rbq6+EX/BTnxx8IdRlk
+z6h9r01N3HmzWjNLBL9GiWXH/XQV+utfkP+0zn4Uf8ABYbwX8RU/cWN/Jpuq3LrwpWN/s1wv1Mc
WT/v5r8z4rXsJYbGL/l3NX/wy0f9eZ/WHgK/7UpZzw5LVYvDycV/09paw/Nv5I/XiiiivsD+eAoo
ooAKKKKACiiigAr5D/bo0qa//wCCbHjS/tci+0W7sNStmA5Vo7uJWb8Edz+FfTHiTxXovhXTUn1a
5ZZJc+RbRLvlmI67V9ORljhRkZIyK+aPjj8RNH8Z/sffE/wxDomreZqHhm8jtvM8vcJfJZoyVDH+
MKeCaivSlOlJJdGe3wtmdPBZ5g60n8NSDfpzK/4H1NoOqw674H0bW7fHkahYw3ceDkbZEDj9DWrX
z7+y/wCLbXxP+w38MYzM66xp3hqzstQtpkKTRvDEIdxVgDhvLyG6HnuCK+gqcHeKZxZnhVhsZWoJ
/BKUfubQUUUVRwhUUkyRTQI2d00mxMDvtZv5Kalr44/aF+Ptz8Mfjf4Z0my02zvpbKxbUis8UrGV
5VmgRQUwAoG8nJySR0xz6uT5RiMyxHsKCvKzf3L+keDxJxHg8kwf1vFO0LxW193b8Fd/I9Q/aG+L
Fn8KfgBfXUOv+HtE8W6qj2nh/wDtW7ES+aQN02MEssStuOFI3FFONwr8UbP4a+HtTvZLrW/j18I9
OmmcvM1xeX88zljksdtqQSc5yW5zWr8T7i9+L3xev/GfjbxD4gvtTuDtihjtgsFpECdsMKEHYi5P
HJJJJJJJPjMHh/T7rxZe3UcVyNMtZzbQQ3DBnlMX7su2ABjKnj2/A/CeIPA+d4Wl9bxtBKEWoxjz
q7vdvRNauyVr3d0lc/pP6O/jpw5TqPKcixj9tVTnVqexdo8riopuSdoR5pPmasvecmlY/b79jjwx
c+Ff2abmysviJoXxF8ISX7yaRcadZzQrauf9dGGlwWQthh8owS3Jzx9cV8K/sZeL2sP2btC8OXOh
ahFYXuuXltZatvj8mW6EfnmDbncP3SuwfGCUZeoGfpvQPiZHrvxBm0keH9RstLniuZNF1aS4haPU
xayiG52oG3JtZlKbv9YpLDAFe3w/luIWV0Zez5VyKVr3snrbV30103ST0smflviRxLh8VxXjpTrK
cnVlFyUeXmcWle0YqKvp71rSclq3JX9PoryfQfizpmq2WpXmp6RqPh2wh0f+3LK4u5I2W90z5v8A
SlCMSuAAzIfmVZIz1bAdbfFS2j8G+JdS1/w1r/hy+0W3huZ9LuRG080U4P2bytrbWaRw0QXIIlRl
PQMfblleKTa5NVbt1/PVpabN2Z8JDP8AASipKpo03s9km3fTTRNq+6TaukerVx3j3wV4U+IXwt1T
wr4z0631LQruM+ash2tEwHEqN1R16hh0+mRXF678adC8L/BTXPF/ibTb/QZdHvl0/UdNu5oVkhum
2FEMm7YUKSRy+YCR5bbuoIHFa78TI/GXgtJreG70XQbVmGsCV13TzozL9kR1JV4wV3M6nDKUA+82
OfE5dUVJ+1j7rdns76firddmejlmfxp4uE8LVcakbTTV01Z6O+lmn00afQ+DPgr4N8eeBf24fFnh
H4SfFOzPggWRm1HXLSGK7Etv5m2OPyXBjW7Db1DspVQrthlOxvrrXvin8S/hRrGmWOs65b+PPDmt
TvBp+qapYxQ39lcrE0vkSfZljiljdI5GVhGrKUIYvuBHzfpf7QHg7wx+3DdyeK9UtNJ0rXtLj01b
6TiO3nimZofMI+7GwmkBc8KQpOFyw+UP2rP2x/EsHizxx4f8I3vw68RWHgfxhptzpGo2tnJcwXMF
xZKrLK63DLIwa9kXMYXBgPQtgfkGFeOyziOGHpNrDpp2eqcZNJ287ysv+HOzi7ijiLjbiCpi6z5s
SoxuoK16dOPvTcVo/dUpzk07apWUUo/orf8A7QHjS4bcl/DaqDnEECL/ADB4/Gq0P7UPiLSLhBqF
9ol4AeY5ogHb/vjBr8WfEv7YPi2f4UeGrnUvBdhoXinV4pZoFtXkWznhWTyxL5byGRWJ5CFsY5ye
g+a7342/ETxe10LrxNqFjDINy2dj/oymPcyhiUxuB2ngk47k1+51cXhErKB87Tw2Mvd1LH9Ky/t4
fDTR5I4/GkI0NCQJLkXkSqo/vbJWVsfTNfbWlapYa34bsNX0u5ivNOvIEntp42ysiMMqwPoQa/it
wZtPjuJlEsrvgs3Jbsa/p1/4J1fEKXx1/wAEzvClrfXBm1Pw5LLo8+5sttibEef+AFa8mrKE3eMb
HqUOdaTlc+7aKKKxOkKKKKACiiigCOWPzbdo97xk9HXGVPUEZ44PrxXnfwzjjHgm7nUmSWXxBrZe
ZwN8oGq3IUsQBnjAHoOBxXpFfEnjH4cfEaxsPF3i3XvFv9k6J4M1G71nwVY6TM2bgy30l20l3n7z
bHMATpjPTkv7mUYWnioSozqKF3HfW+6skt9Wr9ld9D5biHHVsDUp4mnQdS0ZXs0kvhk229vdjK3d
2XU+26/MD/gpDom7TfhV4jRPuS31lO+Ou4QyRj/x2T86/T+vgr/gofaCb9jLw1dhQXt/GEGTjorW
t0D+oWvz/i6kqmUVl2Sf3NM/o36PuPlhPEHLZrrKUf8AwKEo/qfYPw41v/hJf2e/AviLf5jan4fs
7tmz3kgRz+OSa7SvBP2Xbs3v/BP34VzE7tuiLFn/AK5u8f8A7LXvdezgKrq4WnN9Yp/ej864rwMc
FneMw0dqdScf/AZNfoFFFFdZ4AUUUUAYPibX7fwz4LvdYuUM3kqBFCGwZXY4VQe2SeTg4GTjivlf
UPHvi/UtTN1Lrt7a/NlIbJzDFGPQBeWH++WPvXoPxd8V6bqEUPhmxaa4u7O+Et3MoHlIRHIpjznJ
cF1zgYGCCcgivEK6qULK7PIxddudk9EX9T1XUta1h9Q1e9lv71kVDK6quFUcABQAB1OAOpJ7mqFF
FbHG23qy9p2p6lo+rpqGk3s2n3qKVWaNVY7W6ghgQQfQg8gHqAa9W8IfFXWovEdtZeJriPUrC4kE
ZuzEkcsBY4DHYApQHrwCAScnGD43TkEZnjE7SLAXUStGu5lUn5iBxkgZIGeamUU9y6dWcHoz7yoq
tZ3ltqGk219ZzLcWlxEssMi9HVhkH8qs1wn0F7hX85Pxf8SeJvFn7THjbWdd8Rate3r6vcRJm4YL
FEkjKkaKDhUVQAAP5k1/RtX82Xjv/kt3jD/sN3X/AKOevzjxCzLF4ONCWHqyg25axbXbsf0N4A5D
luaVsdDHYeFVJQspxUktZdGn2RiaTb3El1JLNqWpSiLBCNcNgk+vNdHgZ/HNfcPjj4eeDv8AhkLX
fEPw60Pwfe6Zp2iWMGqWcti1r4k8N3yzwmd7red0gcLMrBwCuQY8puNfD9fmfE2KzbDYuFOvipTc
bSi+aTS1aTi2/K6a/B3S/pnw9wHC+OwFapgsup0k26c4+zgm1ZNxmktrOzi9Hurxab/XD9kjwzov
ij9gCx0/Wraa4txr888bQ3ctvLDJHKjpJHJEyvG4IHzKQcZGcEivpnV/hp4L1vwNpXhu/wBJnXRt
NjEdhDaajcWrQJ5LQFFkikV9rRuyMu7DA/MDXgv7FP8AyY3Yf9hi7/8AQhX1rX9A8L5ji3lWGm6s
r8qd7u92tX6vq9z+B/EvJMuhxRmFKOHgoqcopcqtyp6Rta3Kui2XQ4vWvh54O8QppKatoyzw6aNl
pDHcywxLHujYwskbKrwkxRkxMDGdi5Xinav4H8Jar4qsNd1Wwkl1Cy2GOX7dPGjiNxJH5qK4SUI4
3oJAwRuVweau+J/FOleFtIiudRuY45p38u0tvMVZLqTBOxATycAn6CvjH4ifEPxp4iuZ4ZvP0vSh
kJZQkqpHq5HLn26e1fTYSWKq2tUaSv1el97evU+DxWEwUeZujFuVr+6tbbX06dO3Qv8A7T7fCHUf
hrrTS6DqvjfxJOYFlsdC1iSKQ+WxAnCtKtvJPGjybTJliDtzjivgT4gftj+DIfBtr4H0zwX42+G2
n6fara6db63ZCJCqrgAOrMC3cknJOTXqHiu71ex8K3t3p+jXXiDUIlBjsIZ44nm55CtIQoOMnkjp
Xj8+q+G/F/gme31/wfrlvKkxjn0jxHpCZBxkFSSUZefvqxFdOIw3PaPtG7Kyvrp2XZeRx4bEQpOT
jSUbu7srNvu+782fmZ8VvGOp+JPGE/nvMYFcnkHFfcn7Mf7OfwV8Z/A2e+8ZeFbPxJY3lpa6jr+s
XHiaaym0uZN8kRSJXYOpI8sqLeUsMYABZqvat8CPAus6NNd6dpWp+Ap5E5vdMvPIjT/tkwKuPbH4
1DpnwM8Qf2bY2nhrU21iG3gEf2y9g+xmQqMAjBYHIHXgV7PC2EwqrVYYrl95LlbV7O6d1tZ6aN6d
09n8nx5jMyVChVy7nbhJuUYuzknFpKWjvG71Ss30aeq9L+K3wR+COq/s46JqreFfCzSRoI5PEFvr
Mv8AaWjymL5LcWyLDEsYXdgeVKrPuAfotfj3ZafaxvDDZWzm6mO1VjDSMfmJ2qvJ6sTgDvX6t6f8
BvETazA/inV9NsbIMDMsE5nuCP7qjG0Z6ZLcdcHpXTeF/Cvh/wCG/jjVIfD/AMOvDdj4dt4UGn6m
j/adUuZD97O7hVHqSK9Li/C4HEVaUMK1e8rtbu7Vk3eztra1kl0PB8O62bYWhiKmYqShywUYuyS5
VLmcYpXV/dbvzNu7ufNnwd/ZHvNZ8Pxa/wDEy6v/AA/p0uHttJgYJdOp5zKxB8vP90Dd6kdK/Vb9
jbwVZ+B/2h9f0rwTp9zpfgJPDcXnw/aGdJL03EhMjbmJLlMDd6ADtXyL41/aA8I/Dzw619rfnPrL
SMEspnVDEo/iYgnCnPG3JPPpXt37Bf7VPgn4mftEax4UstPubTWtY037RA6FTFmBiJFxww++CDjm
vk8bQp4em6aXvfj9/wDkfp+WV6mIkq8XeDvbt223089bn670UUV4Z7gUUUUAFFFFABXmnxUFw/wu
ezhG2PUtU0ywlmypESzahbwk7T97IlPHtXpdeV/GjU/7D/Z/vNfa2vby20jV9K1K7is4vMlNvb6l
azTFV74jjc8kDAOSBXflSbxtJJauUfzR5OfSjHLcRKTslCT/APJWem2/mC0AkkMrqSpcgAtgkAnA
Az9BXxb+32EP7BgLDLDxJaFPY7Zf6Zr1T4XfEvx74t+K0tv4k8KWmgeDtb0ifWPCMrBlvWgiuI4m
W5UsQHZZ4ZAAAAHHLdvIf+CgcyxfsMaejHBm8V2qKPU+Tct/JTXg8a4KphMBiIVLX5Xs01+HVPR+
aP1L6P8AmVHMeMsqq0b29tHdNPTW9nrZqzXdNM9N/Y9Ln/gnB8Mt5y32a6x9Pttxj9MV9LV85/sk
wtB/wTr+F6MCpNhM+PZrmZh/OvoyoyZWy+h/gj+SOfxIkpcW5o11r1v/AE5IKKKK9I+LCiiigD4L
82acme4ZnuZSXmZjks55Yn3JJNFekfFHw5BoPxEFxZq8dlqaNcBD0WXd+9C+3zK2OxY44wB5vXfF
3Vz56cHGTiwooopkBRRUNzGJtPnhaWSEPGymRGwyZGMg9iKBqzep9f8Awzt7i2+B+hR3KskjLLKo
brseZ3Q/irKa7uviHS/2Nw/hrTnn/aJ/actp2tozJDH4z2rG20ZUDyuADxir/wDwxrD/ANHIftQ/
+FqP/jVeRKrVb+D8T9Pp5LkMYJf2j/5Sl/mfZ9fzZeO/+S3eMP8AsN3X/o56/X7/AIY1h/6OQ/ah
/wDC1H/xqvyo0iHQNL/bR0238VTfbPDFp4yjTVpb8+Z5tsl2BK0vHzZQMW455r828QKcsRPCU5e7
zSau3or8qu/Q/oLwKo4DAvMKuFruu1GLaUHF6czSV92zvNY+JPxi8Q/DjWL3xLp32TRfECwR3utQ
+FoLJtVSIgwxvdRwqZVXYuBuOQoznAx5LX6bwnXrL9tP9ojxB8QjeD4JXHhDZbXV28jaRdQskH2V
LUk+XI5BkCiPJDs4GGNfmRX5lxRg6lGtCdSpKTlf4t1yya7vRu79W993+9eGmdUMZhalOhh4UoxV
OXufC3ON+XZe9BJRfly7LRfsf+xT/wAmN2H/AGGLv/0IV9a18lfsU/8AJjdh/wBhi7/9CFfWp5Br
9/4W/wCRRhv8EfyP4R8Tv+StzH/r7P8ANn5Uftu/FiK7/aT8C/Dmwsxd2OnXSprMtw3lJFLcPBte
J/78ce8nPH7wdcGt+5+LGt+DfF3wq8E+P/BWqXGseJtFtzM1uiXEaXslzLbmIRlhIFAjRtyu4Acn
bivGf+CiejWPg39qT4W+ILmLU7Lwr401qysvEV3ZwCc5SZVkIVgcEw7RgDOASORXullpPibw78Jr
3xZ8J/ih4P8AjF8PtKsprmLT/EKia/02FY2LpFOD5qEJuGMluwAr6ONVx2Z8M6cTO8UeNvgnPqmp
2dp4x0mK+stSOnXsloz3VvbzYJO5ggYD5TzjHGM15l4guvBmj6pYW+n61pPiLWtQP+hBLpXZv90Z
+X8ga8Vg0vxdrngjwz8TfhV8F7GP4aaijX8UOjPJqC3UpbDvOj4kUgoV2soxj3zXzx8VP2sZfCHx
Yha2+H2iw61bTEzWxi+yxx7SCgZSN2QVU9scjvXbQxsrpSOLEYHmi3Fan2jfnR9CtV1rxpq1haQb
8K13KFhU/wB1R1dvwr5S+JHxq8ZaQnxTk8D+PmvdCfw9c6j4fvYLG2dNDubNgLi2k3JuJlV4DGH3
HMknZBXxB8RPjT8QfjB8QzrOqata6ZHAgitY7QlLezU/woCfvHu/U/Stn9n74g+J/Avx81zSdV1K
4nt7yxYszyllYrhlfP8AnrVYrHKSajdKz/r5bmWEymSabacm1va346ffofQfxA/aJ8UWuueM7LQr
m7s5bXRfLgv3lR5fNgginNx5ZjZPLZpWTfzk5G3gYt+LfjnczS2MkWqXuk6h5qo0VvewSWE6Ra5b
2croGhEjrJCXKvuUbXb5cqrVUg1iz1e/vJLe6S7nV905Gc5bJzz6818xeMvjdNe21xb+G9N1CMRR
sjtdttUY7hV59e4r894X4jxeJx1WlUoyik3J3ezldpWdrJ7pL7tbn9U+N3hRkmUcP5fmGEx9OpJx
VOKhFWqRp2i2pwcoylB2Tbs2r6tqxS+Kvia4+L3jLxV4htdLez0fTNMMyR27bzbDa0gEoHCsrMUZ
TnBBGSRX2N/wTsvdB+CmoePvi/qmnaRrPi/T9Rj0PTtP1nV20yHSbSXT7rUJb+7mEUvlQzLZCCBg
jb53RCVDA1wX7Jmu6lqvwR1DVL291C5j0bUzJLczyBltLaNEbapY5wMsTjoMe1fs5/wT28Q+CD8F
fEPhPRTdy+KotQWbxEJojs80RCOIoehUJCoIPIYGv0nH04V6Eq8ZPmvFapebskntaNk/y0P5Dy+r
WwuJhg5QSjabVm27JxV22lq3K7Xfq1cZ47/br1K28P8Axe0Dwt4FstC8c+HPAWt+INPi17WMXEBs
tG0rU4muLIQ7xuXVGUpvxvspF34JdOzvP20pf+En8X6Po3gLwvq97ofibQvDwLePoIVmuNVutOt4
pmT7O062kg1Dz7e5WJ454baZiYWAjP3ZgZzgZpa8ebTtZWPooppWbuZ+kS6rP4U0ybXbLT9N1yS0
jbUbSxvWure3nKAyRxTNHE0qK2QrtHGWABKKTtGhRRUFBRRRQAUUUUAeWtqH2j9qPRbeFRKmneFr
pLnbjMTz3dqoBPT/AJdjwDnv6V8i/wDBRe+8v9mfwLpu7/X+J/Px6+XbSr/7Vr6c8V+O/CvgH4xe
Ntc8T6jFZQ2vhTSZY4sgzXH+maiNkSZ+dy2wYHquSByPz+/bw+Iej+PPh98DtR8OzTSaTqFrqF+F
mTZIp3QRBXXsyskqnkjIOCRzXn8f0qtPIp1eRqFoxv0blaVr/Nn6X9GGVDF+JeCw3tE6ilUqON9V
GEJRTtva8UvVn6G/s82P9n/sL/CW327d3hWymI/66wrJ/wCz17JXM+CtJ/sH4N+EtD27P7O0a1tN
vp5cKJj9K6at8HS9nh4Q7JL7kfG8RY1YzNcViF9upOX3ybCiiiuk8YKKKKAOd8TeGNM8V+HTp+pL
Im1t8E8RAkhfplSQR04IIINeLH4J6t/aHljxDp/2X/nubR949vL3Y/HfX0XRVxnJbGNTD05u8kfD
eraVf6H4huNK1OIw3kJ54+WRezr6qccH8DgggZ9fbusaBo2v2K22sadbX8a58syL88ZPUow+ZT7g
iuQ/4VP4Dxj+x7nHp/adz/PzM1sq6tqcE8BO/uvQ+VI4pp5HSCCe4dEMkgiiZyiA4LtgcLkgZPHI
ru/A3gm/8SeJraa5tJ4dChkD3M8sZVZgD/q0z97JGCRwBnnOAfqDSNC0fQNONro+nW1hCxBfyl+a
Qju7Hlj7sSa1qmVfsaU8Ak05MKKKKwPRCv5svHf/ACW7xh/2G7r/ANHPX9JtfzZeO/8Akt3jD/sN
3X/o56/LPE/+Hh/WX6H9O/Rr/wB4x/pD85HrF98HvHHhj4aaje67q+gx/wBm6ba6nd+H/wC1S17Y
wXMsaRSGHG35jMhOwnbn5tpIB8wr7Z8efFTwF4g/Zd8UeE9U8W+HPiNPp9ra2vgbV4bK5g12NBJG
ZIr1mgSNkTYPmU4l2KxUv8y+TfAX4A+IfjX44YoZtI8GWEqjVtXKd+D5EORhpiDn0QEM3VVb87zr
J6dTM44bAe/zJW1Te73torJK+rVveTs7L+huFuLquHyGvj87XsY05PVxcU01FrlTtJ3bas0pX93V
q7/Q/wDYp/5MbsP+wxd/+hCvrWuc8JeEvD/gb4f6d4X8L6dDpei2MeyCBCSeTlmZjyzEkkseSTXR
1/QuTYKeDwNGhN3cIpO3kj/P/i/OaWbZ3i8dSi1GrOUknvZu6v5nGeOfAXhn4heDW0bxNpdrqMKS
CezlkjBks51HyTRN1SRT0Ir+bb4jfG/wz4L/AGuPGngfxF4c1qxsrO/m09vEvgqVrG6XaTFKtzAM
LLlgxz3VhX9Plfnn+0l/wT+8B/Gnxtqnjnw3e/8ACH+Obwb7uRYd9teyAY3OuRhj3YV6XU+eTPzN
+DPx58NeDfj/AOBvBuh/EfXb34d6hOLR7mGZ7Ke0eYOkXmIxwNsmwk9MGvPf2j/hB8LdN/aE8aeL
PEXiLXvExaJ7xmu9QVvNfk43KTu5wK4b4zfsffFn4Wa9dR+IPCeoy2ETHZqunxNLbuOzbl5H415V
8LNB0i3+OljH47ifW9BuIpbWSG/mZo4mcfI5BPZsUW5VdFyu1ZMn+CngOxvbWPxFq+i/b9PguXlt
re5jDWkyIuZFYHqAXXntivEfiLaX2ifG7WdM0OSWw+zzPCPs7EeXG21/LDdcDcQPYV9HeAPjFpXw
3u9Z8IazpV7qusaRrd3DpujRQ747tJMhY0IOVy2xicNlRXtPwe/Ya+OPxq8RyeIdS0JvD1vqFy1z
e6jqqGNQXJbCKeWABAH0rok4+zjbchXvrsfKfwItb3TPFWsJdSSuL+2V2Z2JLPG3GSfZ2rtrX4Qa
t4j+J+q6f4e8Oajrct1cs6Q2lsz8SHdjIGB97Ffs7oP/AATQ8JeEvg74hupfEmpeIvHCaTO2lGKI
QwLciNjGMZJILYBz2NbH/BOvxLpU+l+PfBF5a2S63azx6pZyvEvnPC4EUq567UZYjj1lNfE1JfVO
IlJ7VoW/7ej/AMD8z+icP/wveEVSnHWpltdSt2pVf/t22/KJ8H/AP/gl78cbmK7t/Ffi6TwF4E1C
YSXenLzczx8ZQgfd3AKD6gDNfrt4O/ZB+EvgnTJrS/PiPxHY3Y827t7q9aG3eYYxIUtxGXbG4AyF
8c4xX1zVLUrNdR8PX+ntLJAt1bvCZI/vIGUrke4zX3uDzHEYdtUpuN7Xt+fqrvbuz+YczynCY1J1
6Sm43smrrW101s07LfTRPoeYfA5pk/Zh8HxTNfSwy2stxp0l1MZW+xvM72ylmO47YHhX5gOBXrlf
OXh/wN8YNP8ABmnaHq/xQ8P+EdK8PaOlnYy+HNESWS4jjjCRzXL3m9VwIgWSNADk/OK9U+Gev3/i
f9n7wVruryQvrN/odrdXxj2jMkkSsW2rwu4knb2zjtXZm+GjKpUxEKkZJye19Oa7W6S2XRs8rh3G
zjQo4OrSlCUYK3Ny68qintJtavqlfpc7miiivEPqAooooAKKKKAOF8SfDrwT4n+IHh3xZr/h6y1P
xDocgOl3kpbMOXB5UEK+CMruB2nJXBJr8hP2gBH4w/bu8B+BLQJJGuvXlgYk6CS68R6gcY90eKv2
wmiE9s0ZZ0zghkOCpByCPxr8TPhTHF46/wCCxng6VJftNsmoi/DM2cNBZtct1/6aqT9TXh8ZV6lf
KaeGlJvmq04pdEvfenbX8z9p+jnhKOA4sx2bxgo/V8Hiajkkk3Jeyir93y31fRWP24ooor3D8WCi
iigAooooAKKKKACiiigAooooAKK8t+N3j/UPhR+yH8SPidpulWeu3XhPw9daydNurlrdLtLaJpnj
8xVcozKjAHaRnGRjmvKtA/aa8Ow/s9a78YfHms+BtO+EuladYtf+JPD+oXGpx2eoSsi3FnIkcBLL
E89unmxlsuZVdIjEQQD6nr8qPEX7APxA1rx9resReOPB0MV9fzXKRvHcEoHcsAfk6jNfZvh79rD4
CeKfiho/gzR/G123iXUtdn0K2s7zw3qVns1CKA3Btpnnt0SCR4lZ4hKU84KfK34NNl/a1/Z7g8F6
r4lufiJDZ+GtOvbK2u9YudHvorJUvZpYLS8WdoBG+nzSwTRpfoxtWZGAmyK8fN8iweZKKxEb8t7a
tb+h9bwrxvm3Dsqksvmoupa90nte2/qfIHhX/gn34ns/F9ofEvjnQJNBaVTejTYpftDIDkqm9QoJ
6ZPTOcHGD+lnhfwvoPgzwHpvhnwzptvpOiWEXl21tCOAOpJJ5ZiSWZiSWJJJJJrwCD9sn9nO60zR
7yz8eahfWupJA0Elr4U1aYQm4u5rO3S422p+zSTXFvNHFHNseUodgYEE7GvftW/AHwxbeN7jXviB
Hptr4SjaXWbmTR74w+Wl4thNJbSCEreJDdulvM1sZVglYJKY2OKzyjh3AZbKUsPCzlu936a9Dfiv
xBz3iKFOnmFbmjDaKSirvrZWu+l3stt2fQ1FfPUv7VXwJh+DOtePZfGV8nh/Sden0K/Q+GtS+3xX
9vb/AGqeAWP2f7UxjtwbhisRVYVaUkIrMNDw9+0t8FPFniDW9M8MeMpNfvNIl0OO/Fhol9MkY1sK
dLkDrCVeKdWVhKpMaqwZ2VTmvcPiz3WiiigCrdWVpfWb295bQ3UDjDRyoGUj3Br5W+In7FXwC+I2
uNqmo+EYdI1FzmWbS2MG/wCoXivrOii47nyr8O/2MP2e/ht4qt/EGkeA9N1LxFAcxanqiC4njPba
zdK+po4Y4YwkSLGgGAqjAFSUUBcK/HPx+sv7K/8AwV6tfGNvBPB4K1i6N+yxIdr2d0St1GAOCY5C
7KnbbH0yK/Yyvmb9qn4IH41/s3zWekwwt400ZzeaE7kL5jYxJblj0EigYzgb1QkgA187xNl1TE4V
VKP8Sm+aPqunz/Ox+w+CnGGCybO54TMv9zxkHRq32Slopf8Abr69IuTPpGzu7XUNJtb+xuIruyuY
Vmt54mDJKjAMrKR1BBBBqxX5o/sX/tEm3ig+A3xGlbStZ06Rrbw9cXuY2baxBsZN3KyIchAeoGzg
qob9Lq7sozWlmGGjWp/Ndn1R8p4hcC4/hLOquX4pXS1hLpOD+GS9Vv2d10OL+I2iXniL4DeNdG0u
3hn1m+0C9tdPDsF/fSQOiDcfu/MV57V5Be/EH4m2Pw6m1Tw38IYPDOk+H9H826g8UaukLyLEvzQW
yQCUtgJhZJCin05r6TryD47/AGmH9k3x/PZi7eSTSGgnSBN58l2CSPjBPyo7tx6e1fX5RiYynTw8
6aknJWvfS9k9mvx2PyHiDBTjTq4ynVlBxg78vLry3a+KLa17Wv8AI7PRfFtrrfg3SdZhs7q3iv7K
K6SKXG9BIgcK2O4zg1p/21D/AM8ZfzFfMqfHH4eafYmTQovEuveGbSONLzVNJ0ieaw0xBxullYAB
QpUkJuIAORXV/E74k2Xw48Gw3bWb6trN5cJbabp6SBDPK7YGW7KOpODwPXFY4zLa1Ca56bipPRPf
0/FfmetlubYHE0m4VozcEuZxd11106Np7dmujPb/AO2of+eMv5ij+2of+eMv5ivgG++Inxh1n4kQ
6ZaeI9F0mEWclzcR2mlFljGQsaZd8tuYtzxwh6V8SfH79qr9pX4dfGbT/C3hjQX8RSXOly3My26S
zPFJDL5cu1QwJQh4XXJJxKAc4yeavhKlFrmW/mVTzjB1L8r21+Xc/dn+2of+eMv5ij+2of8AnjL+
Yr+VfVf+CmX7QcOpNYWgsbPVY5/KlgvbWVdjA4KlfMBUg8c16X4D/wCChH7UuoeLtTtdSTwu9jpN
kb7UXt4pXPlLIqSKpEpG8bicHqFJ+uKpSey/E1q5hh6cOaeiP6Wn123jiaR43RFBLMSAAB3r8Sf2
YtHt9b/av1XxjGLrydG1XTrmykRyrK9xrNnFhsdQYGuFIPHze1emaZ+0z8X/ABR8DbC98O2eneNH
8U6PObSw0+1mubuJMGKSTbGS8bRs3UqULAKSNwI6P9ifwJeXfwy+INzdIdLvF8VaZDdw3UbJc27a
fMl2YmiIDIWLbTuxjB4OOPl8RXjU4gwNFPSEnKXlba/4/efsnA+d5RDw94mdOtB4qtCFKEOZKbjK
XvtRvfl1jd2smldn6lf21D/zxl/MUf21D/zxl/MVzlFfUciPy72cTo/7ah/54y/mK2a4Ou8qJpIy
qRS2CiiioMwooooAKKKKACiiigDyz43fDzUPi3+yP8RPhfpviCy8LT+K9BudHk1W60tr9bWK4jMU
rCFZoSz7Gbb+8ADYJDAFT8seN/2O/iD8Qf2KfFXwU1z42+F9P0fWPDdnpjXGifDt7VJrqCbTmfUb
qFtRcSzNFpyxIsRgRPPlYrISAPvqvkb9u3x/4z+Fn/BKf4sfEL4eeIbvwt4y0O3sp9M1O3iilaFm
v7aJwUlR0YNHI6kMp+9kYIBABy7/ALIviW4+Na+LLz4p6DNat8bE+JVxYJ4OmRnYaUNLaxWT+0Dt
Bhywm2nD4OwqNtcT4W/YO1Dwd+x0Pg9ovxC+HBsrTXdLu7DW5/hZGL+7stP1dtWhtNSkhvozet5p
WPzAYVEbTExmSXzF5yf9pLxp4J/4KbeJLHxmPiTpHwm8I/svz/EDUPDGqDTZr6/vba/8l7pXglcF
nhDIImmRPMBYovDGHxj+3R8RTpWi+E/Dvwx8NaB8Wz8TPBGg6np914re60wWXiKIXtuyXgsg2544
Z7WU/ZyYGPmJ54ChgA/aK+Fvx41L/gpDqnxA+HHwz8HeL/DI0vwrKNK1y91OzXxDfaVqN9eKwmsZ
1t0eAzQkNqS+WTHFsjfYQ2xrn/BPWPVf2cvjT8NrT4h+DdOs/Gc10ui6/wD8K1gfW9ItLrWYdWls
7i9F0sl7CskREaAwKpkZnEu2NUr+Hvjt8T/CX/BQ7Ufhz8Y4vH+gXWreNdYn+H2uQGC68IeL9MEN
6tjojTxxf6BeQFY3YhWmd4HEpKvGho6b/wAFJbey+C1742+IPwW1LwnZXnwxj8d+E4NO8Tx6i+pw
Pqsekpa3BMEK2szXFxbOu0zDyZSz7HXyiAeo3f7Ifjs+Pr3xzpHxq0PR/H8fxem+IGkX6+BXlsoB
caXHpVzptxbNqG6eGS2iVTIksTqWcrjK7et0T4RT6z/wVKs/izf6J4w0KbwZ4KHhu91OWeO00vxf
cMsMtpeQW0EzBhbLcarE4njXa08XllvLJXzy7/a1+Jeq/tA/C/4b+Hvht4R03xPP8WdS8F+Oobzx
VLLaQ/Y9J/tJWsbgWQaVJIZY5N8kEbK8LQ+XiUXEf6B0AFFFFABRRRQAUUUUAFFFFAHwl+1F+yJb
/E67vPiD8OzDpfxDVA93ZMwjg1YqODu/5Zz4AAY/K2AGx96vBfhX+2j45+FeoQ/Dz48+Gdd1FdPI
gbUJYzFqtso4HmpJgTgDo2VYjnL1+s9ee/EL4U/D74qeGxpfjvwxp2uxICIJ3UpcW+e8cykOn0Bw
e4NfK47h+rGu8VgKns6j3X2Zeq6ev66n7twt4uYKrlUMj4qwn1vCQ+CSdq1Lp7ktLpdItrs24pRM
zwJ8cPhP8So4R4O8daDql5IMrYPP5F3/AN+JNsn4hce9ejan/wAgOf8A4D/6EK/OPxx/wTq0G5mk
u/hz481HR3zuWx1yAXEefQTR7WUD3Vj715fP+zl+2f8ADq1YeE/HF3q9gmMQaT4tkSIjPGYrny0z
+BrKOd5th3bE4Ny84O/4av8AE9J+GfAObP2mT8QxpX+xiYuDXrPSL+St5n3b8XILuf4Ga3pdtcxW
ya3dWekySsDmNLy6gtH/AA2Sk/8A6+PhD9of4swQ/tq6Va3BurvRfDtmZTIsXy+Y+7jOAufliYex
/GuC8dXX7Zlt8OL3SPHdvr954auCq3Mc1rZXCsVO9f3kYLDBUNkMOQDXhp8a+P4PCD6JdeHdEuLG
SZZna58OQPNIwcN80pTewOMHLHKkg8Gvo8Dx3gY0Yxr4aupRbelNdVFXvzX0ttbXuj5HPPo059iM
RUlgM4wEoTjFXeJlf3XN2UVTtrzL3ubT+Vn1t8J/idpOv67r+vTTRIbq7S1to3kAby4kBGM9fmkf
pXyn+1b4tufDt2vxq0uzfWv7A1qeOW0WTYDaTxNYEEgHC+fbQuT714NqXgYaz47/AOEiS11jSboy
LJDHp97La20W0ggIgYKBkZxXpPh3TvHfxE0Pxf4H0Sxu/FtpHbGz8Q6fJbRSlI5pTLhy4yNzqWDA
54OCK5MZx5hq1KUfqtX/AMA/4PYywf0Vs0pVf32b4FRa5Xeu1pbygfk38VPH4+JvxjvfGLaFY+H7
q7hjW5gtHZlkdF2+YSf4iAufpXqHwk+Kl74cuJjqMU2rabPZvBqNvLIsaSJ5YiXGcZYIoGByccnm
vr25/Zf0DRNe/sy++HFrZ34/5Y3VyST/AN9SEGur8N/s8+Apdfih8Q+AvDn9m4O5UCLJv6KMod3U
4xmufKuIa2IrwpU8JUSk0ruNkvNvUXFvgVlmXZLWqVs9wcnRi2oQrc03ZfDFaO76edj73/4Juaf4
b07/AIJ932u2d1BNcS61PHf38zKGSOJEdY2bsiGWVhnoZGNcv+0J8f8ARvhP+2F4N+LPwk8b+DNa
utT0AprmmQa1A1j4ktoZ3QRvIrFfPUbxHLyUaML90up8r8P+Ita/Z416zh+C9rZadoWowmO50CSF
ri0mmDHD7NwZX/eDBVlz3zXj/hT4A33jbQPg1oXj3w3rsE6XGvp4tvft2myjTra5WcWsdurySqql
pN/7pGZXdmyDgj5nBcL4/D8T4jE1U1yyvqmrqSfdLy2/4B+P0eE5UsLhsw9rCVGtzypyp1ISbaun
FxTcouMmlJTUVJX5ZPc/c/4N/GrwB8dvgzYeNvh/q66hYTRr9qtZBsuLCYj5oJk/hkU5BHTjgkc1
6JpGuaL4g0t77QtX0zWrJZnha4sLpJ4xIh2um5CRuU5BHUEYNfjp/wAKF8VeC/CPx38H/BuU+GPC
mu+E1bwylnrEltNLqElpJZy2krh8vEETzQ0oOJLoEMPL+X75/Zm1nxLpXwiufCnjt7ixe31m6Xwl
ZXYt2mstGUqtpbSvb5j3RqCo5J2eWGYsGNfpFKrGba8rr77W9f0u9NL+pJzgo8y3dvwun6Pbyene
31NXeVwdd5TqE1egUUUVmYhRRRQAUUUUAFFFFABXnvxT+FfgX40/BLVvhz8SdHuPEHgzU2iOoadF
qdzZC48uRZEDSW0kchUOitt3YOBkGvQqKAPCJ/2afgzefF5/Hep+GNU1vxRL4LbwZdXOreJtSvo7
zRHBD2NxDNcNFPExYs3mIxZzvJL/ADVz6/sgfs8jwJf+H38C3s8V5rem61Nqc/ifU5NXF7psKW+n
zJqTXJu4zbxIEiCTAIGfAG9930vRQB4dD+z78NdK1ttc0bRdUk1e21zU/EWlWupeKNSudNs9W1AX
BubqK0lneCFna6uDmOIBPPlKBS7Z8M+Cn7Cnwj8BfslweAviJ4esPiJ4ivPBjeEfEOrXep6hPHd6
b9qe5ENtHPO32BDKyzbbby9sqq6nciMPuSigDwiH9mn4MQW3h8J4W1A3ujeLpPFlnqj+I9RbUX1W
SIwy3E94bjz7gPCRC8U0jxtEqRshRFUe70UUAFFFFABRRRQAUUUUAFFFFABRRRQAVQ1P/kBz/wDA
f/QhV+qGp/8AIDn/AOA/+hCmtyo7o/OH/goAvxJvv2afh/4a+GOtDQda8Q+O7PTprxnZVij8uacs
5UE7MQEMo+8CR3r8908UW3/CG6bPrRl0xpIVUSTA7A54KE9iDkYNfr58f3eLw58PJ44ppHTxhEFa
GJHaMvaXcYbD/LjL8+gJxzX85Vh+1Bo3h/x94u8DeJ7G9u9Istf1CCw1Z4t7zQG6lKefEeQwBGdu
f92vXy/ExpSfM9zzMzpSnP3eh9Wa7Kz27mFhLC38SNkVU0Tx54K+F/2Q6v461nwn4u8QK76Na6c5
US7Tt3znOArMNqjuQa8z0vxF4Rl1ay8SeHrqG90zfulsoLsmzuB3RlB+Q/7u0g18+eIPhjrX7QH7
S/j6Wz8QaZ4bsPCPheNrWW9V2jmlS2e5jtQV+4X23DbzkAITgniu/G4i1NWVzxcFFSrO7tY+uvEf
xk1nxI8Z14W+qzJxFeRgRSkepIGCfwr3XwP8W/h5H4r+H15o+q6r8PZbTw5ZnWPEUWmvdvJqPkMb
gsquryqS/lnnBzIuAMmvzP8ACOpXWsfCDRdYbUJEkmixL5gz+8QlHPqMspP412Pw0u9XvfjBJ4UX
UfDn2KaGWYpe3zQu0rMzJ5RIIXjaGUhsgZGDT4dzHDYPHOdR2i4yV7J25lbZprbyPC4tyzGZll7o
U7OopRkk5Sjdxle14tPfzW25+q178dvhv/Y/ji30PWNQ8GXGpMWsp9K0y2SO6hSJF+yziC3jdEkZ
GY7Ts+dVdGwXPH+CNNj8b6FDrFj488F6TdSl2bSrrWY1vrdVkZA0kQJZN20Nz/eGCc14no37PvxL
8QaIZ7bWPhzpkoUbZG1R7yNmy3BCrGR8uw9epPpkz/DP9mL43fB/9pG0+Lel/Ej4farfTxSW2p26
zmIXltIoHl5J2/KY42Hp5YFenxZxVldbBKhgJq/Mnqu0eW13713pu2tDy/D3gnPcJmc8ZmsNOSUU
lL+aanfli+RJa7JPXW59qaJ4b1GSdrQfELw1cXkSBngtZXuJtp4DbEBbB9cYNec6h+0d8NfAvxPj
0eL4ga74g8T2GpC1nstL8N3REUyvsdJHkVVAByG54GafoFl8UYv2x7Xxy9v4etba5u/tGoammpQF
jbnTxataELmR0MkFrKo+6DvOMgE0Lv4CfDrUPip4j8a+JfiAb281HU5r6azsplijhMjlwu7g9+pP
NfnOGmpS/ez0av7qv8tj9nrS5Yvkj5av8dz9Gvg/4k13xL8IXufE0tjLrlrqt5bTG0ZdnlrO5gyF
J2t5DREg85NfR9fnT+y1daPoHj/xN4J8PamNS0eeA6giCTcIHV1Q7QoEaghgML/dFfotXo1rX02O
KnNypq7u0FFFFYlBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABVDU/+QHP/wAB/wDQhV+qGp/8gOf/AID/AOhCmtyo7o+cvjt8OdY+KX7M+u+FfDOvReGPFm+G
90LVZYvMjtbuCVZYy6942KlHHPyu1fzjeP8A/glx+1x4cGp61Jp/hHxs7SvNNJo2stJLMxJYttlj
jOSefxr+pmjqK3sr6mtSlzap2Z/D/rfh74kfCXxrJp2v6T4i8F6whw8N1C0W/H1+Vx+Yr9M/+CeW
rQeKrb4sR67N4SubjUtQ01NSsNTfZNfxrbXcSC3A5Lrl2ccDYWr95fiz8Afhh8ZvBd1o3jbwvpep
JKhAmeBd6H1B6g1+Pmq/BbSv2E/2l723fUNOsvh747gDaRr+s3Bjj0i7tWPnReb0Dy2NzeomSCW4
ByRXRTUVa0tOz/r/ACPKxFGavzR17o/OH/hJ7zRviD8SPD3i2ztvDXiKDxlfvc6OXVRZyPKfMhQd
1R1YDHHT1rK1y1srHWNF8VXes3PhpLi4jjS+SCR0ZM4mXMeWDBCrqCMMVxnrj548S6rda58Q9c1i
91W8126vL6WaTUbsYmuyzk+a/wDtN1PuayvtNwbD7KZ5vsu/f5O87N3Izjpnk8+5rz6zlJrldhww
UOdylrfofUvhX4mw+B9N0rQLXxrr+i2llqE63Onm1dfIH28bvMGN2TbmQgL8wkGGwK7H4efHLwrp
V94N8PeI/Eur6h4O029hlNrfaekkVl8t4JmiA5AAkg2EfPkyDOOvxK7vLM8kjtJI7FndjksT1JPc
02o5ZO3NNu39W9DpdKn71opc1/xvr66n6XfCf9qrwd4Q0nw9onizxJNLoWleHrS0traw8MJcgMLK
BXDO8kbefHMk68homSRWDBl58O1b9pi20rxBYXngbQLHzbBddjsru70xLWYDUdTkukaby5HFwEj8
nYh2LGxkGJBg18uaH4e1nxHrUWn6NYy3lzI2FC8AfUngV+137Bf/AAT28FavfXnjv9oGy0/xfug2
aN4WV5PskZJBM9w6spkfA2rH9wAsTuONvbVpVpx9q42WuvqZU/ZKfs09dNPT+upS/YP8Yfta+Pry
58c+FtIu9V8Jf2lp2k32p2VjpVskSx6rZTX6ubp0eUNp7XC5hVmDbcbWwT+kXgHw1+2n4LstP8M3
Fz4ov9FiXxNey6m76Df3N7fzanq88AuWlmiMcMsM2nSWzQIfLmEyXEKQ7Fj+wfCnhDwr4F8C2Xhj
wV4b0Twn4cswRa6ZpNkltbxZOTtRAACSSSepJya9erOpL3VHtf8AG3+Wnqzp9lyddzyv4Kad8RdO
/Ze8F/8AC2te1fXviVdaRbXXiU38NhGbK+kgja4tYxYxpCYo5fMVCDISBzJJw1FeqUViAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVQ1P/kBz/8AAf8A0IVf
qjqX/IFm/D/0IU1uVHdHI0VJRW51Edee/E74UfDv4zfCq68E/E7wppni7w1O4kNrdhgY5BnEkciE
PG4ycMjA8nnmvRqKBNXPzC1j/gkt+yffvI+l2fjrQyxJVIteeZV9h5gJ/MmuCuf+CPvwMM7G08U+
LY4z0WWYMR+Vfr1RWsa0o7Jfcv8AI554SnLv97/zPyEt/wDgkF8F4jmTxLr03PRnP+NdrpP/AASj
/Z5sJ0ku21W+x1Vm4P5mv1GorRYyqtnb5IzeX0Xum/mz5D8C/sRfs+eAXSTSfCEU8y/8tJ2zX09o
/h3RPD9glto2mWunwoMKsSYreoqKuIqVPjk2bUsLRpfBFIjrvK4eu4rlqDq9AooorMxP/9k=

--_004_D0488F8F16683Bsgundaveciscocom_--


From nobody Wed Sep 24 15:59:47 2014
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 D35591A1AD7 for ; Wed, 24 Sep 2014 15:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 qf7iSZqeK6Ty for ; Wed, 24 Sep 2014 15:59:33 -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 50E001A01AE for ; Wed, 24 Sep 2014 15:59:33 -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 s8OMxX3k007259; Wed, 24 Sep 2014 15:59:33 -0700
Received: from XCH-BLV-102.nw.nos.boeing.com (xch-blv-102.nw.nos.boeing.com [130.247.25.117]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8OMxQeb006744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 24 Sep 2014 15:59:26 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-102.nw.nos.boeing.com ([169.254.2.177]) with mapi id 14.03.0181.006; Wed, 24 Sep 2014 15:59:25 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1YkwgAEM+6CAAPHCgP//i1OggAB4a4D//5S3IIABoMoA//+6RxAAEnVNAAAOGsXg
Date: Wed, 24 Sep 2014 22:59:24 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D26DF1@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D26B25@XCH-BLV-504.nw.nos.boeing.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: multipart/related; boundary="_004_2134F8430051B64F815C691A62D9831832D26DF1XCHBLV504nwnosb_"; type="multipart/alternative"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/sLKxl83pv1anrdCiaL2oJ4-s73s
Subject: Re: [DMM] Signaling Message Fragmentation
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, 24 Sep 2014 22:59:40 -0000

--_004_2134F8430051B64F815C691A62D9831832D26DF1XCHBLV504nwnosb_
Content-Type: multipart/alternative;
	boundary="_000_2134F8430051B64F815C691A62D9831832D26DF1XCHBLV504nwnosb_"

--_000_2134F8430051B64F815C691A62D9831832D26DF1XCHBLV504nwnosb_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Sri,

Sure, that diagram could be redrawn with airplanes instead of automobiles. =
But,
consider also the case where the airplane is a mobile router that connects =
into a
home network provided by an aeronautical Internet service provider. Then, t=
he
passenger devices are also mobile routers with their own home networks. Tha=
t
would represent a single mobile-router-within-mobile-router nesting, but a
"nested NEMO" case nonetheless.

We also care about use cases outside of just commercial aviation. Unmanned =
Air
Systems, Unmanned Underwater Vehicles, MANETs, disaster relief networks,
search and rescue networks, space-based systems etc.

About tunnels within tunnels, we should be able to nest them to infinite le=
vels
of recursion where each level sees at least a 1500 MTU. None of this 1460
reduced to 1420 reduced to 1380, etc. until we run out of space - there sho=
uld
be a solid 1500 at every level with the ability to go bigger if the path MT=
U can
support it.

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, September 24, 2014 3:26 PM
To: Templin, Fred L; dmm@ietf.org
Subject: Re: Signaling Message Fragmentation

Hi Fred,


> I can think of use cases related to my industry, for example when a first=
 airplane provides an access link to a second airplane, the second airplane=
 provides an access link to a third airplane, etc.

Seems to match the below use-case. I do not know the Boeing's or the broade=
r Airline industry requirement, but personally I've not seen much interest =
for this.



[cid:image001.jpg@01CFD80E.903CD000]



> In any case, however, whenever there is a fixed or mobile node connected =
to an access link provided by a mobility anchor there is nothing stopping t=
he node from setting up a tunnel.

Agree. That's there today; A MR on cellular access link, brings up a tunnel=
, which is on a transport tunnel.

Regards
Sri




On 9/24/14 1:50 PM, "Templin, Fred L" > wrote:

Hi Sri,

I remember the nested NEMO discussions, but at least for mobile network
use-cases I have not seen any real deployment use-cases for that
requirement. But, it will be good to have some discussions on that topic.

I am thinking about the case when a mobile router A provides an access
link for a mobile router B, which provides an access link for a mobile
router C, which provides an access link for a mobile router D, etc.
Each mobile router would coordinate with their home networks so that
there would be tunnels-within-tunnels-within-tunnels-etc.

I can think of use cases related to my industry, for example when a
first airplane provides an access link to a second airplane, the second
airplane provides an access link to a third airplane, etc. I think this
might come up also for certain mobile ad-hoc scenarios.

In any case, however, whenever there is a fixed or mobile node connected
to an access link provided by a mobility anchor there is nothing stopping
the node from setting up a tunnel. Then, there will be at least one
tunnel-within-tunnel nesting.

Thanks - Fred
fred.l.templin@boeing.com


--_000_2134F8430051B64F815C691A62D9831832D26DF1XCHBLV504nwnosb_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Sri,=



 <=
/p>

Sure, that diagram could =
be redrawn with airplanes instead of automobiles. But,

consider also the case wh=
ere the airplane is a mobile router that connects into a<=
/p>

home network provided by =
an aeronautical Internet service provider. Then, the


passenger devices are als=
o mobile routers with their own home networks. That


would represent a single =
mobile-router-within-mobile-router nesting, but a


“nested NEMO”=
 case nonetheless.


 <=
/p>

We also care about use ca=
ses outside of just commercial aviation. Unmanned Air


Systems, Unmanned Underwa=
ter Vehicles, MANETs, disaster relief networks,


search and rescue network=
s, space-based systems etc.


 <=
/p>

About tunnels within tunn=
els, we should be able to nest them to infinite levels

of recursion where each l=
evel sees at least a 1500 MTU. None of this 1460


reduced to 1420 reduced t=
o 1380, etc. until we run out of space - there should


be a solid 1500 at every =
level with the ability to go bigger if the path MTU can

support it.


 <=
/p>

Thanks - Fred<=
/span>


 <=
/p>







From: Sri Gund=
avelli (sgundave) [mailto:sgundave@cisco.com]


Sent: Wednesday, September 24, 2014 3:26 PM

To: Templin, Fred L; dmm@ietf.org

Subject: Re: Signaling Message Fragmentation






 




Hi Fred,<=
/p>





 





 





> I can think of use cas=
es related to my industry, for example when a first airplane provides =
an access link to a second airplane, the second airplane provides
 an access link to a third airplane, etc.






 





Seems to match the below us=
e-case. I do not know the Boeing's or the broader Airline industry requirem=
ent, but personally I've not seen much interest for this.
  






 





 





 











 





 





 









> In any case, however, =
whenever there is a fixed or mobile node connected to an access link p=
rovided by a mobility anchor there is nothing stopping the node
 from setting up a tunnel. 










 





Agree. That's there today; =
A MR on cellular access link, brings up a tunnel, which is on a transport t=
unnel.






 





Regards





Sri






 





 





 





 





On 9/24/14 1:50 PM, "T=
emplin, Fred L" <Fred.=
L.Templin@boeing.com> wrote:






 







Hi Sri,





 







I remember the nested NEMO =
discussions, but at least for mobile network






use-cases I have not seen a=
ny real deployment use-cases for that






requirement. But, it will b=
e good to have some discussions on that topic.








 





I am thinking about the cas=
e when a mobile router A provides an access






link for a mobile router B,=
 which provides an access link for a mobile






router C, which provides an=
 access link for a mobile router D, etc.






Each mobile router would co=
ordinate with their home networks so that






there would be tunnels-with=
in-tunnels-within-tunnels-etc.






 





I can think of use cases re=
lated to my industry, for example when a






first airplane provides an =
access link to a second airplane, the second






airplane provides an access=
 link to a third airplane, etc. I think this






might come up also for cert=
ain mobile ad-hoc scenarios.






 





In any case, however, whene=
ver there is a fixed or mobile node connected






to an access link provided =
by a mobility anchor there is nothing stopping






the node from setting up a =
tunnel. Then, there will be at least one






tunnel-within-tunnel nestin=
g.






 





Thanks - Fred







 











--_000_2134F8430051B64F815C691A62D9831832D26DF1XCHBLV504nwnosb_--

--_004_2134F8430051B64F815C691A62D9831832D26DF1XCHBLV504nwnosb_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=27527;
	creation-date="Wed, 24 Sep 2014 22:59:24 GMT";
	modification-date="Wed, 24 Sep 2014 22:59:24 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAQAAAQABAAD/4hrESUNDX1BST0ZJTEUAAQEAABq0YXBwbAIQAABtbnRyUkdC
IFhZWiAH3gAHABIABgAXACVhY3NwQVBQTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAA
AADTLWFwcGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFk
ZXNjAAABUAAAAGJkc2NtAAABtAAAA7hjcHJ0AAAFbAAAACR3dHB0AAAFkAAAABRyWFlaAAAFpAAA
ABRnWFlaAAAFuAAAABRiWFlaAAAFzAAAABRyVFJDAAAF4AAACAxhYXJnAAAN7AAAACB2Y2d0AAAO
DAAABhJuZGluAAAUIAAABj5jaGFkAAAaYAAAACxtbW9kAAAajAAAAChiVFJDAAAF4AAACAxnVFJD
AAAF4AAACAxhYWJnAAAN7AAAACBhYWdnAAAN7AAAACBkZXNjAAAAAAAAAAhEaXNwbGF5AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAbWx1YwAAAAAAAAAeAAAADHNrU0sAAAAWAAABeGNhRVMAAAAYAAAB
jmhlSUwAAAAWAAABpnB0QlIAAAAYAAABvGl0SVQAAAAUAAAB1Gh1SFUAAAAUAAAB6HVrVUEAAAAc
AAAB/GtvS1IAAAAMAAACGG5iTk8AAAASAAACJGNzQ1oAAAAWAAACNnpoVFcAAAAMAAACTGRlREUA
AAAQAAACWHJvUk8AAAASAAACaHN2U0UAAAAQAAACenpoQ04AAAAMAAACTGphSlAAAAAOAAACimFy
AAAAAAAUAAACmGVsR1IAAAAiAAACrHB0UFQAAAAWAAACzm5sTkwAAAAWAAAC5GZyRlIAAAAWAAAC
+mVzRVMAAAASAAACaHRoVEgAAAAMAAADEHRyVFIAAAAUAAADHGZpRkkAAAAQAAADMGhySFIAAAAU
AAADQHBsUEwAAAASAAADVHJ1UlUAAAAkAAADZmVuVVMAAAASAAADimRhREsAAAAcAAADnABGAGEA
cgBlAGIAbgD9ACAATABDAEQATABDAEQAIABlAG4AIABjAG8AbABvAHIgDwBMAEMARAAgBeYF0QXi
BdUF4AXZAEwAQwBEACAAQwBvAGwAbwByAGkAZABvAEwAQwBEACAAYwBvAGwAbwByAGkAUwB6AO0A
bgBlAHMAIABMAEMARAQaBD4EOwRMBD4EQAQ+BDIEOAQ5ACAATABDAETO7LfsACAATABDAEQARgBh
AHIAZwBlAC0ATABDAEQAQgBhAHIAZQB2AG4A/QAgAEwAQwBEX2mCcgAgAEwAQwBEAEYAYQByAGIA
LQBMAEMARABMAEMARAAgAGMAbwBsAG8AcgBGAOQAcgBnAC0ATABDAEQwqzDpMPwAIABMAEMARCAP
AEwAQwBEACAGRQZEBkgGRgYpA4gDswPHA8EDyQO8A7cAIAO/A7gDzAO9A7cAIABMAEMARABMAEMA
RAAgAGEAIABDAG8AcgBlAHMASwBsAGUAdQByAGUAbgAtAEwAQwBEAEwAQwBEACAAYwBvAHUAbABl
AHUAcgBMAEMARAAgDioONQBSAGUAbgBrAGwAaQAgAEwAQwBEAFYA5AByAGkALQBMAEMARABMAEMA
RAAgAHUAIABiAG8AagBpAEsAbwBsAG8AcgAgAEwAQwBEBCYEMgQ1BEIEPQQ+BDkAIAQWBBoALQQ0
BDgEQQQ/BDsENQQ5AEMAbwBsAG8AcgAgAEwAQwBEAEwAQwBEAC0AZgBhAHIAdgBlAHMAawDmAHIA
bXRleHQAAAAAQ29weXJpZ2h0IEFwcGxlLCBJbmMuLCAyMDE0AFhZWiAAAAAAAADzUgABAAAAARbP
WFlaIAAAAAAAAGcyAAA18QAAAidYWVogAAAAAAAAaZcAALtOAAAHcVhZWiAAAAAAAAAmDAAADsEA
AMmUY3VydgAAAAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA2ADsAQABFAEoATwBUAFkAXgBj
AGgAbQByAHcAfACBAIYAiwCQAJUAmgCfAKMAqACtALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA
9gD7AQEBBwENARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGx
AbkBwQHJAdEB2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwC
tgLBAssC1QLgAusC9QMAAwsDFgMhAy0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5
BAYEEwQgBC0EOwRIBFUEYwRxBH4EjASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYF
lgWmBbUFxQXVBeUF9gYGBhYGJwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0
B4YHmQesB78H0gflB/gICwgfCDIIRghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJ
ugnPCeUJ+woRCicKPQpUCmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxD
DFwMdQyODKcMwAzZDPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUP
QQ9eD3oPlg+zD88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKE
EqMSwxLjEwMTIxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYW
SRZsFo8WshbWFvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpR
GncanhrFGuwbFBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e
6R8THz4faR+UH78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPC
I/AkHyRNJHwkqyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYp
OClrKZ0p0CoCKjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7u
LyQvWi+RL8cv/jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1
TTWHNcI1/TY3NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvo
PCc8ZTykPOM9Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdD
OkN9Q8BEA0RHRIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrE
SwxLU0uaS+JMKkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdT
E1NfU6pT9lRCVI9U21UoVXVVwlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuV
W+VcNVyGXNZdJ114XcleGl5sXr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk
6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5r
bsRvHm94b9FwK3CGcOBxOnGVcfByS3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54
zHkqeYl553pGeqV7BHtje8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INX
g7qEHYSAhOOFR4Wrhg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaO
zo82j56QBpBukNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/Jpo
mtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum
/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOu
tCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzB
Z8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83
z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3Zbe
HN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R
7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9
Kf26/kv+3P9t//9wYXJhAAAAAAADAAAAAmZmAADypwAADVkAABPQAAAKDnZjZ3QAAAAAAAAAAAAD
AQAAAgAAAFYBiQJxAzgEFgTlBcgGpwePCHkJZQpbC1UMUQ1WDlIPWhBgEWgSbhOGFMUWERdbGKYZ
8Rs8HIcd2R8wIH4h1CMrJIMl3Sc6KJgp9itULLQuFS95MOEyTDOyNRw2hjfvOVQ6vDwiPYg+7kBS
QbVDGER4RdlHOEiXSfVLVEyrTeNPE1BBUW1Sl1PBVOZWClcpWEZZXlpyW4NckF2bXqFfpmCoYadi
p2OjZJ5lkGZ/Z25oXmlOajxrK2wbbQtt+m7pb9hwx3G3cqdzlnSFdXR2Y3dSeEF5LHoXewF77HzX
fcF+rH+XgIGBbYJYg0OELoUahgWG8YfciMiJtIqgi4yMjY2Pjo6PjpCOkY2Si5OIlIKVfZZ0l2yY
YplWmkmbO5wsnRyeC576n+agzqGzopijfKRipUimLqcUp/uo4qnKqrGrmqyCrWyuVa8/sCmxE7H+
suiz07S4tZy2gLdjuEW5J7oIuui7x7ylvYG+XL83wBDA6cHBwpjDbsRDxRnF8cbQx7PIlsl6yl7L
QswozQ7N9c7cz8TQrNGV0n7TZ9RQ1TrWI9cN1/fY4dnS2sLbstyi3ZHegN9v4F3hSuI14yDkCuTy
5dnmv+ek6Ifpa+pN6y7sDOzX7aDua+838AXw1/Gs8oTzYPRB9SX2D/b99/D46Pni+uL74/zm/e3+
9P//AAAAVgFFAkEDLwPuBMEFhwZTBy4IFQjnCcYKpguMDHYNXw5IDzcQHRELEf4TLxReFZQWzBgD
GTcaaBuhHN0eGh9RII4hzCMKJEclhSbJKAgpSiqOK9QtHy5oL7UxAzJPM5k04zYtN3c4wjoLO1M8
mz3hPylAbUGyQvlEPkWDRrxH2EjpSfhLBkwRTR5OJ08vUDNRNlI2UzNULVUlVhtXD1gAWO9Z3lrN
W7pcoV2AXltfNWAPYOlhxGKgY3tkVWUvZgpm5WfAaJtpd2pRayxsB2zibb1umW9ycExxJnIActpz
s3SNdWd2QXcbd/R4znmneoJ7W3w0fQx95n6/f5iAc4FYgj6DI4QIhO6F1Ia6h6CIhYlrilCLNYwZ
jP+N5I7Ij66QkpF2kluTP5QglQCV35a/l6CYgZlhmkKbI5wEnOWdx56pn4ugbqFQojOjFaP4pNul
vqaip4KoYqlCqiKrA6vjrMOtpK6Dr2SwRLEksgSy5LPFtKW1hLZkt0S4JLkGuey61bu+vKm9k75+
v2vAWcFHwjfDKMQaxQ7GAsb4x+7I5cndytbLz8zJzczOz8/R0NPR1tLY09rU3NXe1uDX4tjk2eba
59vq3Ozd8N7z3/bg+eIB4yXkTuV55qfn2ekR6k7rkezZ7irvg/Dj8kzzu/Uz9q/4M/m7+0b81/5p
//8AAABWAS4B6wKdA1MECAS5BXYGNgbxB7gIfglIChwK8AvEDJYNag5FDyEP/hEGEhYTKhQ5FUUW
VhdqGIAZlRqtG8Uc3h36HxQgMCFOIm8jjiStJc8m8ygYKT8qZyuMLLAt1y79MCExRjJoM4o0rDXN
Nuw4DDkoOkg7ZDx/PZw+rj+rQJ5Bj0J+Q2tEWEVARiZHCUfoSMVJnkp0S0ZMFEzgTapOck82T/pQ
vVF+UjpS9VOwVGtVJVXfVppXVFgOWMdZgVo6WvNbrFxnXR9d116QX0lgAWC8YXpiOWL3Y7ZkdGUy
ZfFmr2dtaCpo6GmmamRrIGvdbJptVm4Tbs9vi3BIcQVxw3KBcz5z/HS5dXh2NXbxd654a3kneeN6
n3tbfBZ80n2Ofkh/A3/DgIyBWIIlgvGDvYSKhVaGI4bvh7uIh4lSih6K6ou1jICNS44WjuGPrJB2
kUKSD5Lck6mUdpVDlhGW3permHmZRpoUmuGbr5x9nUyeGp7on7aghKFToiWi+6PWpLCliqZkpz+o
G6j2qdKqr6uMrGmtR64mrwSv5LDDsaOyg7NktEq1OrYwtye4H7kYuhS7EbwRvRS+G78lwDLBRMJZ
w3PEj8WvxtLH+ckgyl3L4c2IzzTQ5dKg1GfWPtgq2i3cTd6P4PLjfeYt6QDr8+8K8kH1j/jz/G//
/wAAbmRpbgAAAAAAAAY2AACkEgAAVtUAAFVzAACkEgAAJT8AAA3MAABQDQAAVDkAAoUeAAIXCgAB
jMwAAwEAAAIAAAABAAIABgALABIAGgAkAC8APABKAFkAagB7AI8AowC5ANAA6QEDARsBMgFKAWMB
fQGYAbQB0QHvAg4CLQJNAm8CkQK0AtgC/QMiA0kDcAOYA8ED6wQWBEIEbgScBMoE+QUoBVgFigW8
Be8GIwZYBo4Gxgb+BzcHcgetB+oIJwhmCKYI5wkpCW0JsQn3Cj4KhgrPCxoLZQuxDAYMYQy9DRwN
fA3fDkMOqQ8TD34P7RBeENMRSxHGEkUSxhNME9UUYRTxFYMWGRaxF1IX+BigGUoZ9xqnG1kcDRzE
HX4eOh75H7ogfSFDIgwi2COmJHclSiYkJwEn4CjCKacqjit4LGUtUy5FLzowMTEqMiYzJTQnNSs2
Mjc7ODE5KTolOyM8JD0oPi8/OkBKQVxCdEOPRK5F0kb6SCZJVkqKS8JM/U5ET5JQ41I4U41U5lZB
V59Y/1phW8ZdLV6WYAFhb2LfZFJlx2dAaLlqQWvMbVxu8HCJciZzyXVxdx941HqOfE9+FH/fgbCD
h4Vih0CJDYrXjKKOb5BAkhGT5JW5l4+ZaJtDnSCe/6DhosWkrqaYqIWqdaxarkOwL7IftBK2CrgF
uga8Db4ZwCvCQ8RhxobIssrizRnPVdGW1BrWp9kz27veOuCz4yLlh+fi6jPseu648O7zIPVK93P5
mfu7/eD//wAAAAEAAwAGAAwAEwAdACgANABDAFMAZQB4AI0ApAC8ANcA8wEQASgBQgFcAXgBlAGy
AdEB8gITAjUCWAJ8AqICyALwAxgDQgNtA5kDxgPzBCMEUwSEBLYE6QUcBVEFhgW9BfQGLQZnBqMG
3wcdB1wHnAfdCCAIZAipCPAJOAmBCcwKGAplCrMLAwtUC6YMAgxnDM4NOA2kDhMOgw73D20P5xBj
EOMRZxHuEnkTBxOZFC8UyBVkFgMWphdVGAoYwxl/Gj0a/hvCHIodVB4hHvEfxSCaIXQiUCMvJBIk
9iXgJs0nvCivKaYqnyucLJstni6kL64wujHKMt4z9TUPNiw3SzheOXU6jzurPMo97D8RQDpBZUKU
Q8ZE+0YyR25Iq0ntSzJMeE3FTxlQcVHMUylUiFXsV1FYulomW5RdBV54X+5haGLjZGNl5GdqaPBq
gWwUbatvRHDhcoF0JHXMd3V5I3rUfIh+P3/5gbiDeYU/hwaIxoqEjEOOA4/HkYqTTpUTltmYn5pm
nC2d9Z+9oYejUqUfpuyou6qLrE6uE6/dsamzd7VItxu48brLvKa+hcBlwknEL8YWyAHJ7MvazcvP
vdGx03LVLdbn2KDaV9wK3bffY+EJ4qrkSOXe527o+uqC7APtgO778HDx4/NU9MD2K/eW+QD6Z/vN
/TX+m///AAAAAQAEAAkAEQAbACcANgBGAFkAbQCDAJsAtgDSAPABEAEsAUkBZwGHAakBzAHwAhUC
PAJkAo0CuALkAxEDQANwA6ED0wQHBDwEcwSqBOMFHQVYBZQF0gYSBlMGlQbZBx8HZgevB/oIRgiU
COQJNgmJCd8KNQqOCukLRQujDAsMfQzyDWoN5g5kDugPbw/7EIwRIxG/EmITCxO6FG8VKxXrFrEX
gRhWGTAaDhrwG9ccwh2yHqYfnyCbIZ0ioyOuJLwlySbXJ+kpASocKzssXy2ILrUv5jEcMlczlzTb
NiQ3cDi+OhE7aTzFPiQ/iUDzQmJD1kVPRsxIT0nWS2NM805uT+VRX1LeVF9V5ldvWP5akFwnXcFf
YGEEYqtkV2YGZ7tpcGsnbOFuoHBhcidz8XW+d495Y3s8fRZ+9YDYgr6EqYaWiHqKVYwyjhOP+JHe
k8eVspegmZCbgp12n2yhZaNgpV+nXqlhq1OtMa8PsO2yzLSqtoe4Yro6vA+94L+uwXjDPcUAxr/I
e8o1y+3Nos9Z0Q7SidPL1QHWN9ds2KDZ0tsA3C3dVN5335bgruHB4s3j1uTV5dHmxOey6Jzpfepf
6zXsDOzd7afucu827/jwufF08i7y6fOc9E/1AvWw9l33Cve0+F35Bvmt+lL6+Pud/D/84f2D/iP+
wv9g//8AAHNmMzIAAAAAAAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBsbW1vZAAA
AAAAAAYQAACctwAAAADGQ4SAAAAAAAAAAAAAAAAAAAAAAP/bAEMAAgICAgIBAgICAgICAgMDBgQD
AwMDBwUFBAYIBwgICAcICAkKDQsJCQwKCAgLDwsMDQ4ODg4JCxARDw4RDQ4ODv/bAEMBAgICAwMD
BgQEBg4JCAkODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O
Dv/AABEIANkBNQMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1
EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoW
FxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImK
kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy
8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUE
BAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkq
NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqi
o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAM
AwEAAhEDEQA/AP38ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi
iigAooooAKKKa7rHC8jsERQSzE4AA70AOprMFQkkAe5r4y8Y/tv/AAx0Pxxc+HfCGjeKfiVqFuSJ
59Ct1a2GDhtrk5fB/iVSp7Ma4G//AOChfwpS2/4mPhzxjpYi/wBfDd26A+ZkjYShbAGO+M5Ax1ry
qOeZfVrexhVTl67+j2fyZ99jfC3izB5c8wr4CpGkldtrVJ9ZR+KK82kj9BYJnmDOU2xk/Ie5HrVi
vgrwl+3p4C8ba82leGfD2palequ9oo7lcoucbmBXge9e4WH7Q/h+aIyaloHiXTYlj8xpBbCVAm4L
vGDllBIBIBAyM9RXurC1Wr8uh8C2luz6FornfDfizw94v0Maj4d1S11S1zh2iblD6MOoP1roqwlF
p2YJ3CiiikAUUUUAFFFFABRRXxr+3X4gvdG/YXfTrWK1kg17xBaafeNKpLJGokuwUwQA2+2jGSCN
pYYyQRx4/FrC4adZq/Kr2OvA4V4nEQop25nY+vNP1PTdWsJLrStQsdTtUuZrZ5rSdZUWaCV4ZoiV
JAeOWN43XqroykAgir1fkn+wbdX2gfFjxVrmpeMdL0LwNe6emnXOmXiRRi91N7yzhsX898MjhrqS
COJT++e7AI3JGD+qd7q1za6sbS30DWtT2wrI01t5KxjcWG3dJImWG3JAzgFc9RWeV454zCwruPLz
dL36/L1NMzwSwmJnRUubl67dPmbNFch4S8baL41j159Efzk0fVZdKv3W4gmSO7hwJ4N0MjrviY7H
XOUcMhwysB19egcAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUVHNKkFrJNI
wSNF3Mx6AUAPJAUkkADua+AP2ufjHc6tY6B8CvhrqMdz4l8Y6jHp+oXVtLlYYXdU8jcOhdnUN6IG
B+9X094l8dXstjLBoywRWzIRLeTsFxnsuc849jX5zP4d8L+CP+CmXwHXTJJTpd5rLvK09wZt15LK
Ru3EAkl3i+nGMV5HESnHLpW05nGN+ylJJv7mfqXg3hqFTiinVqwU/Ywq1YxeqlKlSlOC8/einbyP
0t+E3wm8JfB74S2HhbwtYQRskanUNQMQE+oTY+aWVupJOcDOFGAOBXzH+218AvD3jn9nfXfiJpml
Wtv4y0C1NzeTxRhTqFmo/fJLj7xRMurHJAQr0PH3VX57ftJ/tneGPh/8VPFvwVn8FaprYfSHs9X1
UXqxLbPdWoZBHEUPmqFlQsSyYyQAcc8udU8BRy/2FW0YvSOmztpa21u56PhZPi7OuMo4zLVLEYhN
1Kt2vep3SqKfM0nGSfLy9bpJXsfDf7KumeEvg78MdS8YeKdSsVvtZvZJIWnfLLbQyPHEuOpJZXbA
6nHXFfcs3xX0WXxb4S1GK/tGLefCGR+fKkgMoI9i0Mf51+ZHhD4UeIvHcukTWfiWC3m1CeLStH0e
4XKM5lkeS4JwWCInms23GQp4JxX2V4p/Zd0X4Y+CNP8AHdj4n8T+I18PKLjXbW9dAj26ptmmt1QL
5ZjUs/luzgqpXIPzVzUuMo4bE4ShjrRjUp02mtdZLVvsm7/1t8h4sYHhfI8xxWFwdWpKvTxFaMoc
q9nTpRk1D3r3crbpJ7O6Vlz9fB+0R4P8H/tP6X4n0bUUktdSkgs9dtIDlLmJ38vzcDjzI2aJt3dd
wOeMfqDBPFc2UNzA6yQSoHjdTwykZB/Kvw5j0P4J6U4urHw5rV9cQHzYnlnXeWByAOD3AxX6hfs8
fFLSfHfw2GhWkF3a3ehWsMRW5cM8sRGFbIA5GMEYr9Fx+VV6NFVJ6+nY+GpKysfRNFFFeIahRRRQ
AUUUUAFfBH7eWmaHr3wo8HaFd6VDb+Ibqe5bTPFNukR1DR40a3aeK3Mkbrtn/dK6uGQiNTs3rHJH
971+MH/BRP8Ad/t1eDLyP93d2vgu3ktp14eFjdaghZG6qSruuR2YjoTW9DAxxknSlazXVXR87xPx
R/q/gvrvK5WaWjs9eqZY+Efi3wr8KfA2l+GrHwNrXijX/EWrwaX4p8VX3iaK1+y6S8conuViWDy/
MjKxbIlT95JM5aWGNQB9seEv2lYNRm8aXR8PeEriK38RTRJcaJ4ra98yERxG3a5U24FtdGAwl4FM
ijKsrsHr8pPhVo/j3x14e8T2uj2HjnXPKlt7Vb7StKlvpLKW4hu3Vw3lSIMC1c5cGNW8pWAM8ayf
tV8JD8PPij8FPAHxfttM8G+KfEOq6Ra3M3iRNKg+1m7jiWKYM+wPFNFIjxPGdrRPG0ZVShUYPL6e
Ck6NNJJdtu56GTcRSzzA08dJNc99Jb6O34208rG18GdJ0C1+B9t4l0GfTdRXxpdzeLLzVbM+YNRk
1BvtCSGUu5lVIWggjYuQIYIUTbGiIvq1FFB6QUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABRRRQAV8Z/tq/F/W/hh+ztp9h4VmSPxRr959ntc7c7EUu+ASAc4C/8Cr7Mr8if+Csmha23wa+
GXi/S2Y2+m6pPb3EeeCZY8g/+OY/Gu/LKVOpiYRm9GJ36HlPg39qLWda0q6h8c6JfaNcadgzeazR
JJGASXUSqpPToMjn71eN/EP9prwT4/m0W18NaT4g0/XtN1NLjS9UM1uCrAjJ2CQuOQrcAnKjivjm
0+K1hHbRbpr7TpIYUEYeGX74GHIZSeCfYV1WmftPNpvjQWMEWp6jYo6BZw6kkcZPzc/nXp4zA0Mx
w08HNuKkrNtb66NWejW/yPa4az/GZFm9DMsKlz0pXXZrZprqpJuL8mz+gr4N/tifDHxx8NrNPHPi
LSvAnja1iEeq2mqyi2glkUYMkMjYUqx52EhlORggBj+WX7YOseCPG/8AwUL1XXvAuv2ut6Vq1vZr
eX0YYQLcJGsD7WYDcoSOM7l45OCea8X8a/ETTvF2o6dcaZDctcMwN5c3SIZWGMAbhyR9a86+EEEn
i34geLfEl3qT3cUd81ra6VKhdY441ZUaMdNxJcnByCqnmvgM44RzKp7ChiqsJQ54q6upNN8uq2Wj
u9Xqf0P4c+KPBvDWaYzOMpw9enXlQrfu24Soxag6iiml7SSc4RjFOKtfVux9DfB/4vaNpnjv4d+P
7Dzr/QNMuFkeJExKIWjlgmwveRVkc7e7DGec19QftJ/tW2EMun+BfAXiDwT4p8OeOPAmq+aYYJJb
6xnxBEglxOvkgx3Uj7JIg4MBX+LKfk74Tn/4Q9vE/hxEZray1y4jtTNJjCA45/EGrgvrPVviPp2p
taSXWoQRPbobSebcsTkb8BW254BzjPA5ru4t4CoZnCnmFJqM6dOyh0lZPlt2s9vkfzBlmEwma8S0
p5vVfsa1SPtn1tKS55X6O17uz7pHZeGPj1qY8H2WueL9Lkg0O5hsfL1KxtXiiilnBDowlclkQhR5
qnB3gYyK+tv+CeP7Q/i+b/gp1qHgPxxqGmaNofirSmXw9atpzys84hS8S0EyOFjk+z7pGaQMNyFB
gsK/Or4zWieDfgnptnpFnO3hvzY7Ka0ad5EhTJcE7iWOdpXJPHHtX7EfsC+FfhN4z/ajvPiQunW1
94z0zw7a3GmTXVwXlieSFoTcBVby2l8h2iMgUNhtvpj2MPxPDNMJTqU5Pld7rqntZ+m68rep9Xxz
wTmPCmb1srxjTnCzTV3GSaTUk7JtPbpqmtD9kaKKK5j5MKKKKACiiigAr8kv+CgulR2/7WngDxD4
h3ap4U/4Vzq1za6VZxRRXT31lqOnxhjMqxySK8eqlFilnaBX+fZGwMjfrbXx3+1x4P8ADfiLRPAk
2t/ESXwDf6jJqXhbTBJ4efVre9e/snuG3RxvE6PCNN88OZQjRRzxbGklheO6cnGV07HJjsPCvRlC
dNTT6StZ/emtj8TdW8arbfDm80nwk/irw74a1QfbfEmiyXM8xu5I1hMKmKKeSNxH5bHywj/vMMhB
Ll/3H/Yu8AeKvh9+wtodn4r1a7vJ9YuW1mx0u5s57aTQre4iiIsnSc7lkDrJK67I9kkzoVJUyP8A
BmhfCT4YfC/9sDw7pPgnwuvxqu7rVtTim8M6xfWbWdnbBlFpfSFYlRXu5pZ41MyyrK0TtHGnkzzR
/ffgn47yaz+33dfBWCxtH8PReCl12x1gW86G9leWIgQyMBFPD5cu7zYd67lZN25HVYxNaEakVdu/
V99P61OjhnKMficNW/cwpxpK6jF3tBXvfSK7WjG9lfVn1PRRRQWFFFFABRRRQAUUUUAFFFFABRRR
QAUUUUAFFFFABRRRQAUUUUAFeTfG7w94R8Sfs1+J7Txp4Zi8WaNFZvMbEx7nLKDhkPVWHYivWajl
ijntnhmRJYnGGRhkEehpptO6A/jq8QXl/wCGfjlcNrfh+6ufB1vfSEaf5SpcPFuO1DL/AHsYycV5
74v+JXg9vEMtz4d8AalokOePtEiTMfqdor+rv4hfshfBT4i3E9zqnhmCzvJSS01qNmSe+K+Xdb/4
JafB7VJ5Wtdc1KyRzyptlfH45FdkMwxEdpsbUX0P50tK+NmqRXu2DQ3niddn09/wr2T4Ra/p09nY
6DeagNE1ZLsvbmQMWuGklLgRlRjflsAMV5xz1I/bnTP+CUnwctJFN54i1i6QHJWOBY8/rXuvgz/g
nz+zT4Qkgm/4Q5tbu4mDLLf3DPyDnOBXBmVGnmKhDFtyjGSdlp/V0fZ8Ccf5xwZjauOyeUY1p05U
7zjzK0rPa62aT36WejZ/PDqfwv8AGWq6nd6tatLd65qeoNLc6Jp8JlksvN3SKpYcEjBBwBjjrnNe
o+Bv2MPj14wuEmsPB2swI3Hn3pMYA/Gv6KdP8BeAvCH7RPg+y8OeF9I06JdA1d5Y7S3QbcXWnKrv
nqBubnk8nHevfY4ool2xxoi+irivXzP2HNCVGDjFrRN32bW77pXfS+ysfmeS1sW41Y4qopzUtWoq
K1jGVklsk20t3ZK7b1P5qvil+zZ4v+F/gDw/4U+LNikuna1asIpraQOWWJ13KCekiBoz+K+9fr7+
yR+yB8Lv2fdDj8X+C9Svdfv9b0qPy9Smk+R7eQLIpRegDDaa6j9tH4cDx9+xJrd9awCXWfC7/wBs
WhA+YxxqRcLn08os+O5jWuf/AGFPiI/jL9jdPDd7MZdV8JXhsDuOWa2fMkBPsAXjHtEK/Oct/wBg
zmthfsVVzx9ftL9fRI/qbjKf+tfhzgM83xGBl9Xqvq4PWlJ+l1G/WUpH2pRRRX2J/OIUUUUAFFFF
ABXzt8YdE+JWv+FvGz2/xM0D4LeEdIt7S/tPEVw0lxB5Vs63VzcXhjnspbZE8pkeMXJheIBpGZXl
gH0TWfq2mwaz4V1PSLp5Y7a+tJLaVoiA4WRSpKkgjODxkGgD4r+Emk6joXgPw74i8Y+CYvGXhfU7
T7TrmrTeH/s39jXmm38ZhuI7S5dpzC80aXcMkSygLbrKJfkhebze6+FXhz4Mf8FX/wBmPWvDHiPx
RqXhrxJYapp8Ed3qazW8Aj0/5EiMaLuilmna5KuWXzpXZNqhET73/wCEQmn/AGdP+ECvNcu7a4k8
N/2RPrOl28cU0bG38lriGOYTIjA5dVkEqg4DBxnPyx+1nZWvhJ/2YfFljF9nsfDHxP0yyKhi3lWk
qlXG4knG2FVySeormxX8O/Zp/ifYcDe/mvsP+fsKsP8AwKnJL/yazPtyiiiuk+PCiiigAooooAKK
K/M39oX9sPU/BH7bfh3QPBsv2/w14UuWXxPbRyALqczjbLBu7eUpOD2lzkHaK8zNc3w+X0lUrPRt
L7/8lqfbcB+H+b8X5hPBZbC8owlNt6JKK0TfeTtFeb10Ta/TKvm/4m/tXfBb4XTT2Wp+JR4h12Il
X0nQFW7nRh1V23COMjuHcN7V8A6v8V/2l/2uPFl54b+HemXnhnwTv8u5h0+cw20aH/n7vCAXOD/q
1wGHSM4zX0d8LP2AvAHhyC11H4l6lc+OtZXDPY27tbadGfTjEkuD3LKD3SvAefY7Hvly6l7v889F
8lu/6uj9YXhVwxwnTVXjHH/vrX+rULSqek5fDH00T6TZ5Rr3/BRDxZqetPZ/D34YacueIDqlxLdy
ye5ih2Y+gY/WsR/22f2mdGjF9r3wv8PxaXH80z3Hhy/txt/66GbC/Ug1+qHhvwj4V8HaKNO8KeG9
D8N2OBmHTbKO3VsdzsAyfc810RAIIIyD1FX/AGFm0/eqY5p+UVb89TmfijwDhn7LC8MQlTXWdWTm
/O9nyv0bPgL4Zft//DzxPfxab8QdFvfh/euQqXqSm8sWP+0yqHjyfVWUd2FfeOn6jYatolrqelX1
pqWnXMYltrq1mWWKZD0ZWUkMD6ivnP4u/sofCb4s6dd3MuiweE/FUikxa5o8KxOX9ZYxhJh0zuG7
HAZa/PvTNe+N37Dvxrj0bXIpPEvw4v5iyQrI32C/TPzSQMc+RcAfeXHpkMNrVk81zHKpJY9c9N/b
itV/iX+X4s7o8CcHcdUZT4Uk8LjYpv6tVleM7av2VRu7flJ+qitT9nKK4X4dfEbwn8U/hXYeL/B2
orf6XcjDo2BNaygDdDKufldc8jvkEEggnuq+wpVYVYKcHdPZn87Y7A4jB4ieHxEHCpBtSi1ZprdN
dwopu5f7y/nS5HqPzrQ5RaKKKACiiigAooooAKKKKAPGfEuuaD4c/aKvda16+t9LsrDwNcXElxK2
FVGuohIcAcnKQqMcn5QAeK9G8K+KtA8beAtP8T+F9RTVdCvlY2t0sboH2uyN8rgMCGVhggHiuO+I
Hwm8JfETxb4U1nxNHe3B0OdjHZxyhbe9V3iby7hSp8yMPEjBcgZHOQcU/wCFtnDYeH/FtvaQpbWH
/CXam1tCi7VRTcNuAHYeYJOnFe5iFhKuBhOLftI2T25UtdF1be/Zbany2DlmFDNalOcY+xndp68z
do6voktY21bdndLR+i3tnbahpF3YXsKXFncwtDPE4+V0YFWU+xBIr8k/2Rbq6+EX/BTnxx8IdRlk
+z6h9r01N3HmzWjNLBL9GiWXH/XQV+utfkP+0zn4Uf8ABYbwX8RU/cWN/Jpuq3LrwpWN/s1wv1Mc
WT/v5r8z4rXsJYbGL/l3NX/wy0f9eZ/WHgK/7UpZzw5LVYvDycV/09paw/Nv5I/XiiiivsD+eAoo
ooAKKKKACiiigAr5D/bo0qa//wCCbHjS/tci+0W7sNStmA5Vo7uJWb8Edz+FfTHiTxXovhXTUn1a
5ZZJc+RbRLvlmI67V9ORljhRkZIyK+aPjj8RNH8Z/sffE/wxDomreZqHhm8jtvM8vcJfJZoyVDH+
MKeCaivSlOlJJdGe3wtmdPBZ5g60n8NSDfpzK/4H1NoOqw674H0bW7fHkahYw3ceDkbZEDj9DWrX
z7+y/wCLbXxP+w38MYzM66xp3hqzstQtpkKTRvDEIdxVgDhvLyG6HnuCK+gqcHeKZxZnhVhsZWoJ
/BKUfubQUUUVRwhUUkyRTQI2d00mxMDvtZv5Kalr44/aF+Ptz8Mfjf4Z0my02zvpbKxbUis8UrGV
5VmgRQUwAoG8nJySR0xz6uT5RiMyxHsKCvKzf3L+keDxJxHg8kwf1vFO0LxW193b8Fd/I9Q/aG+L
Fn8KfgBfXUOv+HtE8W6qj2nh/wDtW7ES+aQN02MEssStuOFI3FFONwr8UbP4a+HtTvZLrW/j18I9
OmmcvM1xeX88zljksdtqQSc5yW5zWr8T7i9+L3xev/GfjbxD4gvtTuDtihjtgsFpECdsMKEHYi5P
HJJJJJJJPjMHh/T7rxZe3UcVyNMtZzbQQ3DBnlMX7su2ABjKnj2/A/CeIPA+d4Wl9bxtBKEWoxjz
q7vdvRNauyVr3d0lc/pP6O/jpw5TqPKcixj9tVTnVqexdo8riopuSdoR5pPmasvecmlY/b79jjwx
c+Ff2abmysviJoXxF8ISX7yaRcadZzQrauf9dGGlwWQthh8owS3Jzx9cV8K/sZeL2sP2btC8OXOh
ahFYXuuXltZatvj8mW6EfnmDbncP3SuwfGCUZeoGfpvQPiZHrvxBm0keH9RstLniuZNF1aS4haPU
xayiG52oG3JtZlKbv9YpLDAFe3w/luIWV0Zez5VyKVr3snrbV30103ST0smflviRxLh8VxXjpTrK
cnVlFyUeXmcWle0YqKvp71rSclq3JX9PoryfQfizpmq2WpXmp6RqPh2wh0f+3LK4u5I2W90z5v8A
SlCMSuAAzIfmVZIz1bAdbfFS2j8G+JdS1/w1r/hy+0W3huZ9LuRG080U4P2bytrbWaRw0QXIIlRl
PQMfblleKTa5NVbt1/PVpabN2Z8JDP8AASipKpo03s9km3fTTRNq+6TaukerVx3j3wV4U+IXwt1T
wr4z0631LQruM+ash2tEwHEqN1R16hh0+mRXF678adC8L/BTXPF/ibTb/QZdHvl0/UdNu5oVkhum
2FEMm7YUKSRy+YCR5bbuoIHFa78TI/GXgtJreG70XQbVmGsCV13TzozL9kR1JV4wV3M6nDKUA+82
OfE5dUVJ+1j7rdns76firddmejlmfxp4uE8LVcakbTTV01Z6O+lmn00afQ+DPgr4N8eeBf24fFnh
H4SfFOzPggWRm1HXLSGK7Etv5m2OPyXBjW7Db1DspVQrthlOxvrrXvin8S/hRrGmWOs65b+PPDmt
TvBp+qapYxQ39lcrE0vkSfZljiljdI5GVhGrKUIYvuBHzfpf7QHg7wx+3DdyeK9UtNJ0rXtLj01b
6TiO3nimZofMI+7GwmkBc8KQpOFyw+UP2rP2x/EsHizxx4f8I3vw68RWHgfxhptzpGo2tnJcwXMF
xZKrLK63DLIwa9kXMYXBgPQtgfkGFeOyziOGHpNrDpp2eqcZNJ287ysv+HOzi7ijiLjbiCpi6z5s
SoxuoK16dOPvTcVo/dUpzk07apWUUo/orf8A7QHjS4bcl/DaqDnEECL/ADB4/Gq0P7UPiLSLhBqF
9ol4AeY5ogHb/vjBr8WfEv7YPi2f4UeGrnUvBdhoXinV4pZoFtXkWznhWTyxL5byGRWJ5CFsY5ye
g+a7342/ETxe10LrxNqFjDINy2dj/oymPcyhiUxuB2ngk47k1+51cXhErKB87Tw2Mvd1LH9Ky/t4
fDTR5I4/GkI0NCQJLkXkSqo/vbJWVsfTNfbWlapYa34bsNX0u5ivNOvIEntp42ysiMMqwPoQa/it
wZtPjuJlEsrvgs3Jbsa/p1/4J1fEKXx1/wAEzvClrfXBm1Pw5LLo8+5sttibEef+AFa8mrKE3eMb
HqUOdaTlc+7aKKKxOkKKKKACiiigCOWPzbdo97xk9HXGVPUEZ44PrxXnfwzjjHgm7nUmSWXxBrZe
ZwN8oGq3IUsQBnjAHoOBxXpFfEnjH4cfEaxsPF3i3XvFv9k6J4M1G71nwVY6TM2bgy30l20l3n7z
bHMATpjPTkv7mUYWnioSozqKF3HfW+6skt9Wr9ld9D5biHHVsDUp4mnQdS0ZXs0kvhk229vdjK3d
2XU+26/MD/gpDom7TfhV4jRPuS31lO+Ou4QyRj/x2T86/T+vgr/gofaCb9jLw1dhQXt/GEGTjorW
t0D+oWvz/i6kqmUVl2Sf3NM/o36PuPlhPEHLZrrKUf8AwKEo/qfYPw41v/hJf2e/AviLf5jan4fs
7tmz3kgRz+OSa7SvBP2Xbs3v/BP34VzE7tuiLFn/AK5u8f8A7LXvdezgKrq4WnN9Yp/ej864rwMc
FneMw0dqdScf/AZNfoFFFFdZ4AUUUUAYPibX7fwz4LvdYuUM3kqBFCGwZXY4VQe2SeTg4GTjivlf
UPHvi/UtTN1Lrt7a/NlIbJzDFGPQBeWH++WPvXoPxd8V6bqEUPhmxaa4u7O+Et3MoHlIRHIpjznJ
cF1zgYGCCcgivEK6qULK7PIxddudk9EX9T1XUta1h9Q1e9lv71kVDK6quFUcABQAB1OAOpJ7mqFF
FbHG23qy9p2p6lo+rpqGk3s2n3qKVWaNVY7W6ghgQQfQg8gHqAa9W8IfFXWovEdtZeJriPUrC4kE
ZuzEkcsBY4DHYApQHrwCAScnGD43TkEZnjE7SLAXUStGu5lUn5iBxkgZIGeamUU9y6dWcHoz7yoq
tZ3ltqGk219ZzLcWlxEssMi9HVhkH8qs1wn0F7hX85Pxf8SeJvFn7THjbWdd8Rate3r6vcRJm4YL
FEkjKkaKDhUVQAAP5k1/RtX82Xjv/kt3jD/sN3X/AKOevzjxCzLF4ONCWHqyg25axbXbsf0N4A5D
luaVsdDHYeFVJQspxUktZdGn2RiaTb3El1JLNqWpSiLBCNcNgk+vNdHgZ/HNfcPjj4eeDv8AhkLX
fEPw60Pwfe6Zp2iWMGqWcti1r4k8N3yzwmd7red0gcLMrBwCuQY8puNfD9fmfE2KzbDYuFOvipTc
bSi+aTS1aTi2/K6a/B3S/pnw9wHC+OwFapgsup0k26c4+zgm1ZNxmktrOzi9Hurxab/XD9kjwzov
ij9gCx0/Wraa4txr888bQ3ctvLDJHKjpJHJEyvG4IHzKQcZGcEivpnV/hp4L1vwNpXhu/wBJnXRt
NjEdhDaajcWrQJ5LQFFkikV9rRuyMu7DA/MDXgv7FP8AyY3Yf9hi7/8AQhX1rX9A8L5ji3lWGm6s
r8qd7u92tX6vq9z+B/EvJMuhxRmFKOHgoqcopcqtyp6Rta3Kui2XQ4vWvh54O8QppKatoyzw6aNl
pDHcywxLHujYwskbKrwkxRkxMDGdi5Xinav4H8Jar4qsNd1Wwkl1Cy2GOX7dPGjiNxJH5qK4SUI4
3oJAwRuVweau+J/FOleFtIiudRuY45p38u0tvMVZLqTBOxATycAn6CvjH4ifEPxp4iuZ4ZvP0vSh
kJZQkqpHq5HLn26e1fTYSWKq2tUaSv1el97evU+DxWEwUeZujFuVr+6tbbX06dO3Qv8A7T7fCHUf
hrrTS6DqvjfxJOYFlsdC1iSKQ+WxAnCtKtvJPGjybTJliDtzjivgT4gftj+DIfBtr4H0zwX42+G2
n6fara6db63ZCJCqrgAOrMC3cknJOTXqHiu71ex8K3t3p+jXXiDUIlBjsIZ44nm55CtIQoOMnkjp
Xj8+q+G/F/gme31/wfrlvKkxjn0jxHpCZBxkFSSUZefvqxFdOIw3PaPtG7Kyvrp2XZeRx4bEQpOT
jSUbu7srNvu+782fmZ8VvGOp+JPGE/nvMYFcnkHFfcn7Mf7OfwV8Z/A2e+8ZeFbPxJY3lpa6jr+s
XHiaaym0uZN8kRSJXYOpI8sqLeUsMYABZqvat8CPAus6NNd6dpWp+Ap5E5vdMvPIjT/tkwKuPbH4
1DpnwM8Qf2bY2nhrU21iG3gEf2y9g+xmQqMAjBYHIHXgV7PC2EwqrVYYrl95LlbV7O6d1tZ6aN6d
09n8nx5jMyVChVy7nbhJuUYuzknFpKWjvG71Ss30aeq9L+K3wR+COq/s46JqreFfCzSRoI5PEFvr
Mv8AaWjymL5LcWyLDEsYXdgeVKrPuAfotfj3ZafaxvDDZWzm6mO1VjDSMfmJ2qvJ6sTgDvX6t6f8
BvETazA/inV9NsbIMDMsE5nuCP7qjG0Z6ZLcdcHpXTeF/Cvh/wCG/jjVIfD/AMOvDdj4dt4UGn6m
j/adUuZD97O7hVHqSK9Li/C4HEVaUMK1e8rtbu7Vk3eztra1kl0PB8O62bYWhiKmYqShywUYuyS5
VLmcYpXV/dbvzNu7ufNnwd/ZHvNZ8Pxa/wDEy6v/AA/p0uHttJgYJdOp5zKxB8vP90Dd6kdK/Vb9
jbwVZ+B/2h9f0rwTp9zpfgJPDcXnw/aGdJL03EhMjbmJLlMDd6ADtXyL41/aA8I/Dzw619rfnPrL
SMEspnVDEo/iYgnCnPG3JPPpXt37Bf7VPgn4mftEax4UstPubTWtY037RA6FTFmBiJFxww++CDjm
vk8bQp4em6aXvfj9/wDkfp+WV6mIkq8XeDvbt223089bn670UUV4Z7gUUUUAFFFFABXmnxUFw/wu
ezhG2PUtU0ywlmypESzahbwk7T97IlPHtXpdeV/GjU/7D/Z/vNfa2vby20jV9K1K7is4vMlNvb6l
azTFV74jjc8kDAOSBXflSbxtJJauUfzR5OfSjHLcRKTslCT/APJWem2/mC0AkkMrqSpcgAtgkAnA
Az9BXxb+32EP7BgLDLDxJaFPY7Zf6Zr1T4XfEvx74t+K0tv4k8KWmgeDtb0ifWPCMrBlvWgiuI4m
W5UsQHZZ4ZAAAAHHLdvIf+CgcyxfsMaejHBm8V2qKPU+Tct/JTXg8a4KphMBiIVLX5Xs01+HVPR+
aP1L6P8AmVHMeMsqq0b29tHdNPTW9nrZqzXdNM9N/Y9Ln/gnB8Mt5y32a6x9Pttxj9MV9LV85/sk
wtB/wTr+F6MCpNhM+PZrmZh/OvoyoyZWy+h/gj+SOfxIkpcW5o11r1v/AE5IKKKK9I+LCiiigD4L
82acme4ZnuZSXmZjks55Yn3JJNFekfFHw5BoPxEFxZq8dlqaNcBD0WXd+9C+3zK2OxY44wB5vXfF
3Vz56cHGTiwooopkBRRUNzGJtPnhaWSEPGymRGwyZGMg9iKBqzep9f8Awzt7i2+B+hR3KskjLLKo
brseZ3Q/irKa7uviHS/2Nw/hrTnn/aJ/actp2tozJDH4z2rG20ZUDyuADxir/wDwxrD/ANHIftQ/
+FqP/jVeRKrVb+D8T9Pp5LkMYJf2j/5Sl/mfZ9fzZeO/+S3eMP8AsN3X/o56/X7/AIY1h/6OQ/ah
/wDC1H/xqvyo0iHQNL/bR0238VTfbPDFp4yjTVpb8+Z5tsl2BK0vHzZQMW455r828QKcsRPCU5e7
zSau3or8qu/Q/oLwKo4DAvMKuFruu1GLaUHF6czSV92zvNY+JPxi8Q/DjWL3xLp32TRfECwR3utQ
+FoLJtVSIgwxvdRwqZVXYuBuOQoznAx5LX6bwnXrL9tP9ojxB8QjeD4JXHhDZbXV28jaRdQskH2V
LUk+XI5BkCiPJDs4GGNfmRX5lxRg6lGtCdSpKTlf4t1yya7vRu79W993+9eGmdUMZhalOhh4UoxV
OXufC3ON+XZe9BJRfly7LRfsf+xT/wAmN2H/AGGLv/0IV9a18lfsU/8AJjdh/wBhi7/9CFfWp5Br
9/4W/wCRRhv8EfyP4R8Tv+StzH/r7P8ANn5Uftu/FiK7/aT8C/Dmwsxd2OnXSprMtw3lJFLcPBte
J/78ce8nPH7wdcGt+5+LGt+DfF3wq8E+P/BWqXGseJtFtzM1uiXEaXslzLbmIRlhIFAjRtyu4Acn
bivGf+CiejWPg39qT4W+ILmLU7Lwr401qysvEV3ZwCc5SZVkIVgcEw7RgDOASORXullpPibw78Jr
3xZ8J/ih4P8AjF8PtKsprmLT/EKia/02FY2LpFOD5qEJuGMluwAr6ONVx2Z8M6cTO8UeNvgnPqmp
2dp4x0mK+stSOnXsloz3VvbzYJO5ggYD5TzjHGM15l4guvBmj6pYW+n61pPiLWtQP+hBLpXZv90Z
+X8ga8Vg0vxdrngjwz8TfhV8F7GP4aaijX8UOjPJqC3UpbDvOj4kUgoV2soxj3zXzx8VP2sZfCHx
Yha2+H2iw61bTEzWxi+yxx7SCgZSN2QVU9scjvXbQxsrpSOLEYHmi3Fan2jfnR9CtV1rxpq1haQb
8K13KFhU/wB1R1dvwr5S+JHxq8ZaQnxTk8D+PmvdCfw9c6j4fvYLG2dNDubNgLi2k3JuJlV4DGH3
HMknZBXxB8RPjT8QfjB8QzrOqata6ZHAgitY7QlLezU/woCfvHu/U/Stn9n74g+J/Avx81zSdV1K
4nt7yxYszyllYrhlfP8AnrVYrHKSajdKz/r5bmWEymSabacm1va346ffofQfxA/aJ8UWuueM7LQr
m7s5bXRfLgv3lR5fNgginNx5ZjZPLZpWTfzk5G3gYt+LfjnczS2MkWqXuk6h5qo0VvewSWE6Ra5b
2croGhEjrJCXKvuUbXb5cqrVUg1iz1e/vJLe6S7nV905Gc5bJzz6818xeMvjdNe21xb+G9N1CMRR
sjtdttUY7hV59e4r894X4jxeJx1WlUoyik3J3ezldpWdrJ7pL7tbn9U+N3hRkmUcP5fmGEx9OpJx
VOKhFWqRp2i2pwcoylB2Tbs2r6tqxS+Kvia4+L3jLxV4htdLez0fTNMMyR27bzbDa0gEoHCsrMUZ
TnBBGSRX2N/wTsvdB+CmoePvi/qmnaRrPi/T9Rj0PTtP1nV20yHSbSXT7rUJb+7mEUvlQzLZCCBg
jb53RCVDA1wX7Jmu6lqvwR1DVL291C5j0bUzJLczyBltLaNEbapY5wMsTjoMe1fs5/wT28Q+CD8F
fEPhPRTdy+KotQWbxEJojs80RCOIoehUJCoIPIYGv0nH04V6Eq8ZPmvFapebskntaNk/y0P5Dy+r
WwuJhg5QSjabVm27JxV22lq3K7Xfq1cZ47/br1K28P8Axe0Dwt4FstC8c+HPAWt+INPi17WMXEBs
tG0rU4muLIQ7xuXVGUpvxvspF34JdOzvP20pf+En8X6Po3gLwvq97ofibQvDwLePoIVmuNVutOt4
pmT7O062kg1Dz7e5WJ454baZiYWAjP3ZgZzgZpa8ebTtZWPooppWbuZ+kS6rP4U0ybXbLT9N1yS0
jbUbSxvWure3nKAyRxTNHE0qK2QrtHGWABKKTtGhRRUFBRRRQAUUUUAeWtqH2j9qPRbeFRKmneFr
pLnbjMTz3dqoBPT/AJdjwDnv6V8i/wDBRe+8v9mfwLpu7/X+J/Px6+XbSr/7Vr6c8V+O/CvgH4xe
Ntc8T6jFZQ2vhTSZY4sgzXH+maiNkSZ+dy2wYHquSByPz+/bw+Iej+PPh98DtR8OzTSaTqFrqF+F
mTZIp3QRBXXsyskqnkjIOCRzXn8f0qtPIp1eRqFoxv0blaVr/Nn6X9GGVDF+JeCw3tE6ilUqON9V
GEJRTtva8UvVn6G/s82P9n/sL/CW327d3hWymI/66wrJ/wCz17JXM+CtJ/sH4N+EtD27P7O0a1tN
vp5cKJj9K6at8HS9nh4Q7JL7kfG8RY1YzNcViF9upOX3ybCiiiuk8YKKKKAOd8TeGNM8V+HTp+pL
Im1t8E8RAkhfplSQR04IIINeLH4J6t/aHljxDp/2X/nubR949vL3Y/HfX0XRVxnJbGNTD05u8kfD
eraVf6H4huNK1OIw3kJ54+WRezr6qccH8DgggZ9fbusaBo2v2K22sadbX8a58syL88ZPUow+ZT7g
iuQ/4VP4Dxj+x7nHp/adz/PzM1sq6tqcE8BO/uvQ+VI4pp5HSCCe4dEMkgiiZyiA4LtgcLkgZPHI
ru/A3gm/8SeJraa5tJ4dChkD3M8sZVZgD/q0z97JGCRwBnnOAfqDSNC0fQNONro+nW1hCxBfyl+a
Qju7Hlj7sSa1qmVfsaU8Ak05MKKKKwPRCv5svHf/ACW7xh/2G7r/ANHPX9JtfzZeO/8Akt3jD/sN
3X/o56/LPE/+Hh/WX6H9O/Rr/wB4x/pD85HrF98HvHHhj4aaje67q+gx/wBm6ba6nd+H/wC1S17Y
wXMsaRSGHG35jMhOwnbn5tpIB8wr7Z8efFTwF4g/Zd8UeE9U8W+HPiNPp9ra2vgbV4bK5g12NBJG
ZIr1mgSNkTYPmU4l2KxUv8y+TfAX4A+IfjX44YoZtI8GWEqjVtXKd+D5EORhpiDn0QEM3VVb87zr
J6dTM44bAe/zJW1Te73torJK+rVveTs7L+huFuLquHyGvj87XsY05PVxcU01FrlTtJ3bas0pX93V
q7/Q/wDYp/5MbsP+wxd/+hCvrWuc8JeEvD/gb4f6d4X8L6dDpei2MeyCBCSeTlmZjyzEkkseSTXR
1/QuTYKeDwNGhN3cIpO3kj/P/i/OaWbZ3i8dSi1GrOUknvZu6v5nGeOfAXhn4heDW0bxNpdrqMKS
CezlkjBks51HyTRN1SRT0Ir+bb4jfG/wz4L/AGuPGngfxF4c1qxsrO/m09vEvgqVrG6XaTFKtzAM
LLlgxz3VhX9Plfnn+0l/wT+8B/Gnxtqnjnw3e/8ACH+Obwb7uRYd9teyAY3OuRhj3YV6XU+eTPzN
+DPx58NeDfj/AOBvBuh/EfXb34d6hOLR7mGZ7Ke0eYOkXmIxwNsmwk9MGvPf2j/hB8LdN/aE8aeL
PEXiLXvExaJ7xmu9QVvNfk43KTu5wK4b4zfsffFn4Wa9dR+IPCeoy2ETHZqunxNLbuOzbl5H415V
8LNB0i3+OljH47ifW9BuIpbWSG/mZo4mcfI5BPZsUW5VdFyu1ZMn+CngOxvbWPxFq+i/b9PguXlt
re5jDWkyIuZFYHqAXXntivEfiLaX2ifG7WdM0OSWw+zzPCPs7EeXG21/LDdcDcQPYV9HeAPjFpXw
3u9Z8IazpV7qusaRrd3DpujRQ747tJMhY0IOVy2xicNlRXtPwe/Ya+OPxq8RyeIdS0JvD1vqFy1z
e6jqqGNQXJbCKeWABAH0rok4+zjbchXvrsfKfwItb3TPFWsJdSSuL+2V2Z2JLPG3GSfZ2rtrX4Qa
t4j+J+q6f4e8Oajrct1cs6Q2lsz8SHdjIGB97Ffs7oP/AATQ8JeEvg74hupfEmpeIvHCaTO2lGKI
QwLciNjGMZJILYBz2NbH/BOvxLpU+l+PfBF5a2S63azx6pZyvEvnPC4EUq567UZYjj1lNfE1JfVO
IlJ7VoW/7ej/AMD8z+icP/wveEVSnHWpltdSt2pVf/t22/KJ8H/AP/gl78cbmK7t/Ffi6TwF4E1C
YSXenLzczx8ZQgfd3AKD6gDNfrt4O/ZB+EvgnTJrS/PiPxHY3Y827t7q9aG3eYYxIUtxGXbG4AyF
8c4xX1zVLUrNdR8PX+ntLJAt1bvCZI/vIGUrke4zX3uDzHEYdtUpuN7Xt+fqrvbuz+YczynCY1J1
6Sm43smrrW101s07LfTRPoeYfA5pk/Zh8HxTNfSwy2stxp0l1MZW+xvM72ylmO47YHhX5gOBXrlf
OXh/wN8YNP8ABmnaHq/xQ8P+EdK8PaOlnYy+HNESWS4jjjCRzXL3m9VwIgWSNADk/OK9U+Gev3/i
f9n7wVruryQvrN/odrdXxj2jMkkSsW2rwu4knb2zjtXZm+GjKpUxEKkZJye19Oa7W6S2XRs8rh3G
zjQo4OrSlCUYK3Ny68qintJtavqlfpc7miiivEPqAooooAKKKKAOF8SfDrwT4n+IHh3xZr/h6y1P
xDocgOl3kpbMOXB5UEK+CMruB2nJXBJr8hP2gBH4w/bu8B+BLQJJGuvXlgYk6CS68R6gcY90eKv2
wmiE9s0ZZ0zghkOCpByCPxr8TPhTHF46/wCCxng6VJftNsmoi/DM2cNBZtct1/6aqT9TXh8ZV6lf
KaeGlJvmq04pdEvfenbX8z9p+jnhKOA4sx2bxgo/V8Hiajkkk3Jeyir93y31fRWP24ooor3D8WCi
iigAooooAKKKKACiiigAooooAKK8t+N3j/UPhR+yH8SPidpulWeu3XhPw9daydNurlrdLtLaJpnj
8xVcozKjAHaRnGRjmvKtA/aa8Ow/s9a78YfHms+BtO+EuladYtf+JPD+oXGpx2eoSsi3FnIkcBLL
E89unmxlsuZVdIjEQQD6nr8qPEX7APxA1rx9resReOPB0MV9fzXKRvHcEoHcsAfk6jNfZvh79rD4
CeKfiho/gzR/G123iXUtdn0K2s7zw3qVns1CKA3Btpnnt0SCR4lZ4hKU84KfK34NNl/a1/Z7g8F6
r4lufiJDZ+GtOvbK2u9YudHvorJUvZpYLS8WdoBG+nzSwTRpfoxtWZGAmyK8fN8iweZKKxEb8t7a
tb+h9bwrxvm3Dsqksvmoupa90nte2/qfIHhX/gn34ns/F9ofEvjnQJNBaVTejTYpftDIDkqm9QoJ
6ZPTOcHGD+lnhfwvoPgzwHpvhnwzptvpOiWEXl21tCOAOpJJ5ZiSWZiSWJJJJJrwCD9sn9nO60zR
7yz8eahfWupJA0Elr4U1aYQm4u5rO3S422p+zSTXFvNHFHNseUodgYEE7GvftW/AHwxbeN7jXviB
Hptr4SjaXWbmTR74w+Wl4thNJbSCEreJDdulvM1sZVglYJKY2OKzyjh3AZbKUsPCzlu936a9Dfiv
xBz3iKFOnmFbmjDaKSirvrZWu+l3stt2fQ1FfPUv7VXwJh+DOtePZfGV8nh/Sden0K/Q+GtS+3xX
9vb/AGqeAWP2f7UxjtwbhisRVYVaUkIrMNDw9+0t8FPFniDW9M8MeMpNfvNIl0OO/Fhol9MkY1sK
dLkDrCVeKdWVhKpMaqwZ2VTmvcPiz3WiiigCrdWVpfWb295bQ3UDjDRyoGUj3Br5W+In7FXwC+I2
uNqmo+EYdI1FzmWbS2MG/wCoXivrOii47nyr8O/2MP2e/ht4qt/EGkeA9N1LxFAcxanqiC4njPba
zdK+po4Y4YwkSLGgGAqjAFSUUBcK/HPx+sv7K/8AwV6tfGNvBPB4K1i6N+yxIdr2d0St1GAOCY5C
7KnbbH0yK/Yyvmb9qn4IH41/s3zWekwwt400ZzeaE7kL5jYxJblj0EigYzgb1QkgA187xNl1TE4V
VKP8Sm+aPqunz/Ox+w+CnGGCybO54TMv9zxkHRq32Slopf8Abr69IuTPpGzu7XUNJtb+xuIruyuY
Vmt54mDJKjAMrKR1BBBBqxX5o/sX/tEm3ig+A3xGlbStZ06Rrbw9cXuY2baxBsZN3KyIchAeoGzg
qob9Lq7sozWlmGGjWp/Ndn1R8p4hcC4/hLOquX4pXS1hLpOD+GS9Vv2d10OL+I2iXniL4DeNdG0u
3hn1m+0C9tdPDsF/fSQOiDcfu/MV57V5Be/EH4m2Pw6m1Tw38IYPDOk+H9H826g8UaukLyLEvzQW
yQCUtgJhZJCin05r6TryD47/AGmH9k3x/PZi7eSTSGgnSBN58l2CSPjBPyo7tx6e1fX5RiYynTw8
6aknJWvfS9k9mvx2PyHiDBTjTq4ynVlBxg78vLry3a+KLa17Wv8AI7PRfFtrrfg3SdZhs7q3iv7K
K6SKXG9BIgcK2O4zg1p/21D/AM8ZfzFfMqfHH4eafYmTQovEuveGbSONLzVNJ0ieaw0xBxullYAB
QpUkJuIAORXV/E74k2Xw48Gw3bWb6trN5cJbabp6SBDPK7YGW7KOpODwPXFY4zLa1Ca56bipPRPf
0/FfmetlubYHE0m4VozcEuZxd11106Np7dmujPb/AO2of+eMv5ij+2of+eMv5ivgG++Inxh1n4kQ
6ZaeI9F0mEWclzcR2mlFljGQsaZd8tuYtzxwh6V8SfH79qr9pX4dfGbT/C3hjQX8RSXOly3My26S
zPFJDL5cu1QwJQh4XXJJxKAc4yeavhKlFrmW/mVTzjB1L8r21+Xc/dn+2of+eMv5ij+2of8AnjL+
Yr+VfVf+CmX7QcOpNYWgsbPVY5/KlgvbWVdjA4KlfMBUg8c16X4D/wCChH7UuoeLtTtdSTwu9jpN
kb7UXt4pXPlLIqSKpEpG8bicHqFJ+uKpSey/E1q5hh6cOaeiP6Wn123jiaR43RFBLMSAAB3r8Sf2
YtHt9b/av1XxjGLrydG1XTrmykRyrK9xrNnFhsdQYGuFIPHze1emaZ+0z8X/ABR8DbC98O2eneNH
8U6PObSw0+1mubuJMGKSTbGS8bRs3UqULAKSNwI6P9ifwJeXfwy+INzdIdLvF8VaZDdw3UbJc27a
fMl2YmiIDIWLbTuxjB4OOPl8RXjU4gwNFPSEnKXlba/4/efsnA+d5RDw94mdOtB4qtCFKEOZKbjK
XvtRvfl1jd2smldn6lf21D/zxl/MUf21D/zxl/MVzlFfUciPy72cTo/7ah/54y/mK2a4Ou8qJpIy
qRS2CiiioMwooooAKKKKACiiigDyz43fDzUPi3+yP8RPhfpviCy8LT+K9BudHk1W60tr9bWK4jMU
rCFZoSz7Gbb+8ADYJDAFT8seN/2O/iD8Qf2KfFXwU1z42+F9P0fWPDdnpjXGifDt7VJrqCbTmfUb
qFtRcSzNFpyxIsRgRPPlYrISAPvqvkb9u3x/4z+Fn/BKf4sfEL4eeIbvwt4y0O3sp9M1O3iilaFm
v7aJwUlR0YNHI6kMp+9kYIBABy7/ALIviW4+Na+LLz4p6DNat8bE+JVxYJ4OmRnYaUNLaxWT+0Dt
Bhywm2nD4OwqNtcT4W/YO1Dwd+x0Pg9ovxC+HBsrTXdLu7DW5/hZGL+7stP1dtWhtNSkhvozet5p
WPzAYVEbTExmSXzF5yf9pLxp4J/4KbeJLHxmPiTpHwm8I/svz/EDUPDGqDTZr6/vba/8l7pXglcF
nhDIImmRPMBYovDGHxj+3R8RTpWi+E/Dvwx8NaB8Wz8TPBGg6np914re60wWXiKIXtuyXgsg2544
Z7WU/ZyYGPmJ54ChgA/aK+Fvx41L/gpDqnxA+HHwz8HeL/DI0vwrKNK1y91OzXxDfaVqN9eKwmsZ
1t0eAzQkNqS+WTHFsjfYQ2xrn/BPWPVf2cvjT8NrT4h+DdOs/Gc10ui6/wD8K1gfW9ItLrWYdWls
7i9F0sl7CskREaAwKpkZnEu2NUr+Hvjt8T/CX/BQ7Ufhz8Y4vH+gXWreNdYn+H2uQGC68IeL9MEN
6tjojTxxf6BeQFY3YhWmd4HEpKvGho6b/wAFJbey+C1742+IPwW1LwnZXnwxj8d+E4NO8Tx6i+pw
Pqsekpa3BMEK2szXFxbOu0zDyZSz7HXyiAeo3f7Ifjs+Pr3xzpHxq0PR/H8fxem+IGkX6+BXlsoB
caXHpVzptxbNqG6eGS2iVTIksTqWcrjK7et0T4RT6z/wVKs/izf6J4w0KbwZ4KHhu91OWeO00vxf
cMsMtpeQW0EzBhbLcarE4njXa08XllvLJXzy7/a1+Jeq/tA/C/4b+Hvht4R03xPP8WdS8F+Oobzx
VLLaQ/Y9J/tJWsbgWQaVJIZY5N8kEbK8LQ+XiUXEf6B0AFFFFABRRRQAUUUUAFFFFAHwl+1F+yJb
/E67vPiD8OzDpfxDVA93ZMwjg1YqODu/5Zz4AAY/K2AGx96vBfhX+2j45+FeoQ/Dz48+Gdd1FdPI
gbUJYzFqtso4HmpJgTgDo2VYjnL1+s9ee/EL4U/D74qeGxpfjvwxp2uxICIJ3UpcW+e8cykOn0Bw
e4NfK47h+rGu8VgKns6j3X2Zeq6ev66n7twt4uYKrlUMj4qwn1vCQ+CSdq1Lp7ktLpdItrs24pRM
zwJ8cPhP8So4R4O8daDql5IMrYPP5F3/AN+JNsn4hce9ejan/wAgOf8A4D/6EK/OPxx/wTq0G5mk
u/hz481HR3zuWx1yAXEefQTR7WUD3Vj715fP+zl+2f8ADq1YeE/HF3q9gmMQaT4tkSIjPGYrny0z
+BrKOd5th3bE4Ny84O/4av8AE9J+GfAObP2mT8QxpX+xiYuDXrPSL+St5n3b8XILuf4Ga3pdtcxW
ya3dWekySsDmNLy6gtH/AA2Sk/8A6+PhD9of4swQ/tq6Va3BurvRfDtmZTIsXy+Y+7jOAufliYex
/GuC8dXX7Zlt8OL3SPHdvr954auCq3Mc1rZXCsVO9f3kYLDBUNkMOQDXhp8a+P4PCD6JdeHdEuLG
SZZna58OQPNIwcN80pTewOMHLHKkg8Gvo8Dx3gY0Yxr4aupRbelNdVFXvzX0ttbXuj5HPPo059iM
RUlgM4wEoTjFXeJlf3XN2UVTtrzL3ubT+Vn1t8J/idpOv67r+vTTRIbq7S1to3kAby4kBGM9fmkf
pXyn+1b4tufDt2vxq0uzfWv7A1qeOW0WTYDaTxNYEEgHC+fbQuT714NqXgYaz47/AOEiS11jSboy
LJDHp97La20W0ggIgYKBkZxXpPh3TvHfxE0Pxf4H0Sxu/FtpHbGz8Q6fJbRSlI5pTLhy4yNzqWDA
54OCK5MZx5hq1KUfqtX/AMA/4PYywf0Vs0pVf32b4FRa5Xeu1pbygfk38VPH4+JvxjvfGLaFY+H7
q7hjW5gtHZlkdF2+YSf4iAufpXqHwk+Kl74cuJjqMU2rabPZvBqNvLIsaSJ5YiXGcZYIoGByccnm
vr25/Zf0DRNe/sy++HFrZ34/5Y3VyST/AN9SEGur8N/s8+Apdfih8Q+AvDn9m4O5UCLJv6KMod3U
4xmufKuIa2IrwpU8JUSk0ruNkvNvUXFvgVlmXZLWqVs9wcnRi2oQrc03ZfDFaO76edj73/4Juaf4
b07/AIJ932u2d1BNcS61PHf38zKGSOJEdY2bsiGWVhnoZGNcv+0J8f8ARvhP+2F4N+LPwk8b+DNa
utT0AprmmQa1A1j4ktoZ3QRvIrFfPUbxHLyUaML90up8r8P+Ita/Z416zh+C9rZadoWowmO50CSF
ri0mmDHD7NwZX/eDBVlz3zXj/hT4A33jbQPg1oXj3w3rsE6XGvp4tvft2myjTra5WcWsdurySqql
pN/7pGZXdmyDgj5nBcL4/D8T4jE1U1yyvqmrqSfdLy2/4B+P0eE5UsLhsw9rCVGtzypyp1ISbaun
FxTcouMmlJTUVJX5ZPc/c/4N/GrwB8dvgzYeNvh/q66hYTRr9qtZBsuLCYj5oJk/hkU5BHTjgkc1
6JpGuaL4g0t77QtX0zWrJZnha4sLpJ4xIh2um5CRuU5BHUEYNfjp/wAKF8VeC/CPx38H/BuU+GPC
mu+E1bwylnrEltNLqElpJZy2krh8vEETzQ0oOJLoEMPL+X75/Zm1nxLpXwiufCnjt7ixe31m6Xwl
ZXYt2mstGUqtpbSvb5j3RqCo5J2eWGYsGNfpFKrGba8rr77W9f0u9NL+pJzgo8y3dvwun6Pbyene
31NXeVwdd5TqE1egUUUVmYhRRRQAUUUUAFFFFABXnvxT+FfgX40/BLVvhz8SdHuPEHgzU2iOoadF
qdzZC48uRZEDSW0kchUOitt3YOBkGvQqKAPCJ/2afgzefF5/Hep+GNU1vxRL4LbwZdXOreJtSvo7
zRHBD2NxDNcNFPExYs3mIxZzvJL/ADVz6/sgfs8jwJf+H38C3s8V5rem61Nqc/ifU5NXF7psKW+n
zJqTXJu4zbxIEiCTAIGfAG9930vRQB4dD+z78NdK1ttc0bRdUk1e21zU/EWlWupeKNSudNs9W1AX
BubqK0lneCFna6uDmOIBPPlKBS7Z8M+Cn7Cnwj8BfslweAviJ4esPiJ4ivPBjeEfEOrXep6hPHd6
b9qe5ENtHPO32BDKyzbbby9sqq6nciMPuSigDwiH9mn4MQW3h8J4W1A3ujeLpPFlnqj+I9RbUX1W
SIwy3E94bjz7gPCRC8U0jxtEqRshRFUe70UUAFFFFABRRRQAUUUUAFFFFABRRRQAVQ1P/kBz/wDA
f/QhV+qGp/8AIDn/AOA/+hCmtyo7o/OH/goAvxJvv2afh/4a+GOtDQda8Q+O7PTprxnZVij8uacs
5UE7MQEMo+8CR3r8908UW3/CG6bPrRl0xpIVUSTA7A54KE9iDkYNfr58f3eLw58PJ44ppHTxhEFa
GJHaMvaXcYbD/LjL8+gJxzX85Vh+1Bo3h/x94u8DeJ7G9u9Istf1CCw1Z4t7zQG6lKefEeQwBGdu
f92vXy/ExpSfM9zzMzpSnP3eh9Wa7Kz27mFhLC38SNkVU0Tx54K+F/2Q6v461nwn4u8QK76Na6c5
US7Tt3znOArMNqjuQa8z0vxF4Rl1ay8SeHrqG90zfulsoLsmzuB3RlB+Q/7u0g18+eIPhjrX7QH7
S/j6Wz8QaZ4bsPCPheNrWW9V2jmlS2e5jtQV+4X23DbzkAITgniu/G4i1NWVzxcFFSrO7tY+uvEf
xk1nxI8Z14W+qzJxFeRgRSkepIGCfwr3XwP8W/h5H4r+H15o+q6r8PZbTw5ZnWPEUWmvdvJqPkMb
gsquryqS/lnnBzIuAMmvzP8ACOpXWsfCDRdYbUJEkmixL5gz+8QlHPqMspP412Pw0u9XvfjBJ4UX
UfDn2KaGWYpe3zQu0rMzJ5RIIXjaGUhsgZGDT4dzHDYPHOdR2i4yV7J25lbZprbyPC4tyzGZll7o
U7OopRkk5Sjdxle14tPfzW25+q178dvhv/Y/ji30PWNQ8GXGpMWsp9K0y2SO6hSJF+yziC3jdEkZ
GY7Ts+dVdGwXPH+CNNj8b6FDrFj488F6TdSl2bSrrWY1vrdVkZA0kQJZN20Nz/eGCc14no37PvxL
8QaIZ7bWPhzpkoUbZG1R7yNmy3BCrGR8uw9epPpkz/DP9mL43fB/9pG0+Lel/Ej4farfTxSW2p26
zmIXltIoHl5J2/KY42Hp5YFenxZxVldbBKhgJq/Mnqu0eW13713pu2tDy/D3gnPcJmc8ZmsNOSUU
lL+aanfli+RJa7JPXW59qaJ4b1GSdrQfELw1cXkSBngtZXuJtp4DbEBbB9cYNec6h+0d8NfAvxPj
0eL4ga74g8T2GpC1nstL8N3REUyvsdJHkVVAByG54GafoFl8UYv2x7Xxy9v4etba5u/tGoammpQF
jbnTxataELmR0MkFrKo+6DvOMgE0Lv4CfDrUPip4j8a+JfiAb281HU5r6azsplijhMjlwu7g9+pP
NfnOGmpS/ez0av7qv8tj9nrS5Yvkj5av8dz9Gvg/4k13xL8IXufE0tjLrlrqt5bTG0ZdnlrO5gyF
J2t5DREg85NfR9fnT+y1daPoHj/xN4J8PamNS0eeA6giCTcIHV1Q7QoEaghgML/dFfotXo1rX02O
KnNypq7u0FFFFYlBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF
FFABVDU/+QHP/wAB/wDQhV+qGp/8gOf/AID/AOhCmtyo7o+cvjt8OdY+KX7M+u+FfDOvReGPFm+G
90LVZYvMjtbuCVZYy6942KlHHPyu1fzjeP8A/glx+1x4cGp61Jp/hHxs7SvNNJo2stJLMxJYttlj
jOSefxr+pmjqK3sr6mtSlzap2Z/D/rfh74kfCXxrJp2v6T4i8F6whw8N1C0W/H1+Vx+Yr9M/+CeW
rQeKrb4sR67N4SubjUtQ01NSsNTfZNfxrbXcSC3A5Lrl2ccDYWr95fiz8Afhh8ZvBd1o3jbwvpep
JKhAmeBd6H1B6g1+Pmq/BbSv2E/2l723fUNOsvh747gDaRr+s3Bjj0i7tWPnReb0Dy2NzeomSCW4
ByRXRTUVa0tOz/r/ACPKxFGavzR17o/OH/hJ7zRviD8SPD3i2ztvDXiKDxlfvc6OXVRZyPKfMhQd
1R1YDHHT1rK1y1srHWNF8VXes3PhpLi4jjS+SCR0ZM4mXMeWDBCrqCMMVxnrj548S6rda58Q9c1i
91W8126vL6WaTUbsYmuyzk+a/wDtN1PuayvtNwbD7KZ5vsu/f5O87N3Izjpnk8+5rz6zlJrldhww
UOdylrfofUvhX4mw+B9N0rQLXxrr+i2llqE63Onm1dfIH28bvMGN2TbmQgL8wkGGwK7H4efHLwrp
V94N8PeI/Eur6h4O029hlNrfaekkVl8t4JmiA5AAkg2EfPkyDOOvxK7vLM8kjtJI7FndjksT1JPc
02o5ZO3NNu39W9DpdKn71opc1/xvr66n6XfCf9qrwd4Q0nw9onizxJNLoWleHrS0traw8MJcgMLK
BXDO8kbefHMk68homSRWDBl58O1b9pi20rxBYXngbQLHzbBddjsru70xLWYDUdTkukaby5HFwEj8
nYh2LGxkGJBg18uaH4e1nxHrUWn6NYy3lzI2FC8AfUngV+137Bf/AAT28FavfXnjv9oGy0/xfug2
aN4WV5PskZJBM9w6spkfA2rH9wAsTuONvbVpVpx9q42WuvqZU/ZKfs09dNPT+upS/YP8Yfta+Pry
58c+FtIu9V8Jf2lp2k32p2VjpVskSx6rZTX6ubp0eUNp7XC5hVmDbcbWwT+kXgHw1+2n4LstP8M3
Fz4ov9FiXxNey6m76Df3N7fzanq88AuWlmiMcMsM2nSWzQIfLmEyXEKQ7Fj+wfCnhDwr4F8C2Xhj
wV4b0Twn4cswRa6ZpNkltbxZOTtRAACSSSepJya9erOpL3VHtf8AG3+Wnqzp9lyddzyv4Kad8RdO
/Ze8F/8AC2te1fXviVdaRbXXiU38NhGbK+kgja4tYxYxpCYo5fMVCDISBzJJw1FeqUViAUUUUAFF
FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVQ1P/kBz/8AAf8A0IVf
qjqX/IFm/D/0IU1uVHdHI0VJRW51Edee/E74UfDv4zfCq68E/E7wppni7w1O4kNrdhgY5BnEkciE
PG4ycMjA8nnmvRqKBNXPzC1j/gkt+yffvI+l2fjrQyxJVIteeZV9h5gJ/MmuCuf+CPvwMM7G08U+
LY4z0WWYMR+Vfr1RWsa0o7Jfcv8AI554SnLv97/zPyEt/wDgkF8F4jmTxLr03PRnP+NdrpP/AASj
/Z5sJ0ku21W+x1Vm4P5mv1GorRYyqtnb5IzeX0Xum/mz5D8C/sRfs+eAXSTSfCEU8y/8tJ2zX09o
/h3RPD9glto2mWunwoMKsSYreoqKuIqVPjk2bUsLRpfBFIjrvK4eu4rlqDq9AooorMxP/9k=

--_004_2134F8430051B64F815C691A62D9831832D26DF1XCHBLV504nwnosb_--


From nobody Wed Sep 24 23:08:05 2014
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 09A381A1BFC for ; Wed, 24 Sep 2014 23:07:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 x3ssdMp8Wesq for ; Wed, 24 Sep 2014 23:07:51 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC561A1A8C for ; Wed, 24 Sep 2014 23:07:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11471; q=dns/txt; s=iport; t=1411625272; x=1412834872; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=VQIMQLQGD5mKDt0hE8H9/z6vxR84ts5KAs/D1AjVssM=; b=Y63Gi7+FNAMAK4plQHyDVhVG5XTeH6X9UTl+B4bd7lnZwc/ghAeft8Mh xBxFKBiapS8dnJuc5WGlPbpAPxOPmoe1N28Vi8YyO1zkj5ZdblVbel1da tbx6xTxBdVZWYZJZ4IjCB4z7joKMqwhKIEjYnBxCIzxtYIuhDLfYR9mWJ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQFANOwI1StJV2c/2dsb2JhbABggkhGgSoE0hYBgQYWAXqEAwECBIELAQgRAwECKDkUCQgCBAESiD7DSQEXj3MaGAaERQWPRoIYi0OVVINibAGBR4ECAQEB
X-IronPort-AV: E=Sophos;i="5.04,595,1406592000";  d="scan'208,217";a="358038687"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 25 Sep 2014 06:07:50 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8P67ncC024805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 06:07:49 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 01:07:49 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP2IcIByLI2/gAaEy/vf/5RLASNA==
Date: Thu, 25 Sep 2014 06:07:49 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D26DF1@XCH-BLV-504.nw.nos.boeing.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.217]
Content-Type: multipart/alternative; boundary="_000_D048FE43166989sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/mOEs89M4z_YpufE1YLOc6_5hggY
Subject: Re: [DMM] Signaling Message Fragmentation
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, 25 Sep 2014 06:08:00 -0000

--_000_D048FE43166989sgundaveciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Fred,

Ok ! Not my area of interest, but I understand the requirement.

Regards
Sri

From: , Fred L >
Date: Wednesday, September 24, 2014 3:59 PM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: Signaling Message Fragmentation

Hi Sri,

Sure, that diagram could be redrawn with airplanes instead of automobiles. =
But,
consider also the case where the airplane is a mobile router that connects =
into a
home network provided by an aeronautical Internet service provider. Then, t=
he
passenger devices are also mobile routers with their own home networks. Tha=
t
would represent a single mobile-router-within-mobile-router nesting, but a
=93nested NEMO=94 case nonetheless.

We also care about use cases outside of just commercial aviation. Unmanned =
Air
Systems, Unmanned Underwater Vehicles, MANETs, disaster relief networks,
search and rescue networks, space-based systems etc.

About tunnels within tunnels, we should be able to nest them to infinite le=
vels
of recursion where each level sees at least a 1500 MTU. None of this 1460
reduced to 1420 reduced to 1380, etc. until we run out of space - there sho=
uld
be a solid 1500 at every level with the ability to go bigger if the path MT=
U can
support it.

Thanks - Fred

--_000_D048FE43166989sgundaveciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <18A8A550E08CAC4EB86B76E4AA7FE0E1@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable








Hi Fred,









Ok ! Not my area of interest, but I understand the requirement. 









Regards



Sri










From: <Templin>, Fred L <<=
a href=3D"mailto:Fred.L.Templin@boeing.com">Fred.L.Templin@boeing.com&g=
t;

Date: Wednesday, September 24, 2014=
 3:59 PM

To: Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>

Subject: RE: Signaling Message Frag=
mentation











Hi Sri,



 



Sure, that diagram could be redrawn with airplanes instea=
d of automobiles. But,



consider also the case where the airplane is a mobile rou=
ter that connects into a



home network provided by an aeronautical Internet service=
 provider. Then, the



passenger devices are also mobile routers with their own =
home networks. That



would represent a single mobile-router-within-mobile-rout=
er nesting, but a



=93nested NEMO=94 case nonetheless.



 



We also care about use cases outside of just commercial a=
viation. Unmanned Air



Systems, Unmanned Underwater Vehicles, MANETs, disaster r=
elief networks,



search and rescue networks, space-based systems etc.=




 



About tunnels within tunnels, we should be able to nest t=
hem to infinite levels



of recursion where each level sees at least a 1500 MTU. N=
one of this 1460



reduced to 1420 reduced to 1380, etc. until we run out of=
 space - there should



be a solid 1500 at every level with the ability to go big=
ger if the path MTU can



support it.



 



Thanks - Fred





--_000_D048FE43166989sgundaveciscocom_--


From nobody Thu Sep 25 01:09:14 2014
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 144AA1A02D7 for ; Thu, 25 Sep 2014 01:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ocqh3KWQURK9 for ; Thu, 25 Sep 2014 01:09:08 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545511A02C2 for ; Thu, 25 Sep 2014 01:09:07 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 1B9282AC936; Thu, 25 Sep 2014 10:09:05 +0200 (CEST)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id F087C18008D; Thu, 25 Sep 2014 10:09:04 +0200 (CEST)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 10:09:04 +0200
From: 
To: "Sri Gundavelli (sgundave)" , "Charles E. Perkins" , "dmm@ietf.org" 
Thread-Topic: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt
Thread-Index: AQHP2BAVWlLgDTsn+0CQTVcR3RCAQpwQbbgAgAER8SA=
Date: Thu, 25 Sep 2014 08:09:03 +0000
Message-ID: <13892_1411632545_5423CDA1_13892_3313_1_81C77F07008CA24F9783A98CFD706F71142A4FA6@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <13894_1411574165_5422E995_13894_4130_1_81C77F07008CA24F9783A98CFD706F71142A4CBB@PEXCVZYM12.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
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: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71142A4FA6PEXCVZYM12corpo_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.9.25.40019
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/mEHsbc8i4ppbN2s6EXRzpqVy8PI
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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, 25 Sep 2014 08:09:12 -0000

--_000_81C77F07008CA24F9783A98CFD706F71142A4FA6PEXCVZYM12corpo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



De : Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Envoy=E9 : mercredi 24 septembre 2014 19:48
=C0 : SEITE Pierrick IMT/OLN; Charles E. Perkins; dmm@ietf.org
Objet : Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283m=
nids-00.txt

Hi Pierrick,

The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP TS 2=
3.003. It is sent in PBU/PBA messages. Not sure, if IMSI information is see=
n as a confidential IE. But, I agree on the need to include some text on ho=
w the signaling message can be protected with privacy / confidentiality ser=
vice set, when the identifier is based on some confidential data.

>> I agree, thanks.


Regards
Sri

From: "pierrick.seite@orange.com" >
Date: Wednesday, September 24, 2014 8:56 AM
To: "Charles E. Perkins" >, "dmm@ietf.org" >
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283=
mnids-00.txt

Hi Charlie,

Thanks for the list... it looks good. I'm just wondering about security con=
siderations... Actually, from 3GPP standpoint, security constrains on IMSI =
and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI is very rar=
ely sent on the air (maybe only one time at the beginning of the 3GPP authe=
ntication process) for security reasons. So, I'm wondering if adding IMSI t=
o the list of IDs, without any warnings, is somehow introducing security we=
akness to the 3GPP security process.   Consequently, I'm not sure about the=
 following statement "This document does not introduce any security mechani=
sms, and does not have any impact on existing security mechanisms." It's ma=
ybe not so true from the 3GPP point of view...

Maybe we should state that the ID option MUST be used in a way that it does=
 not harm existing security mechanisms (i.e. use the option with caution :)=
). For example, to address the issue above (maybe there are other examples.=
.. I don't know...), we could state that the IMSI should be transmitted onl=
y during first binding update, and not transmitted anymore as long as the a=
ssociation IMSI/HoA/HNP is done.... Or... simpler way to address the issue:=
  if nobody has use-case for transmitting the IMSI, we can simply remove th=
e IMSI from the list :)

BR,
Pierrick


De : dmm [mailto:dmm-bounces@ietf.org] De la part de Charles E. Perkins
Envoy=E9 : mardi 23 septembre 2014 21:10
=C0 : dmm@ietf.org
Objet : [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids=
-00.txt

Hello folks,

We have published a ...-00 version of the MNIDs draft.  This is mainly for
reference purposes.  A new version should be out within a week or so,
incorporating the suggestions and comments from people who responded
to the earlier suggestion to revisit this work.

Regards,
Charlie P.


-------- Original Message --------
Subject:

New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Date:

Tue, 23 Sep 2014 10:43:12 -0700

From:



To:

Charles E. Perkins , V=
ijay Devarapalli , Charles E.Perkins 



A new version of I-D, draft-perkins-dmm-4283mnids-00.txt

has been successfully submitted by Charles E. Perkins and posted to the

IETF repository.



Name:         draft-perkins-dmm-4283mnids

Revision:     00

Title:        MN Identifier Types for RFC 4283 Mobile Node Identifier Option

Document date: 2014-09-23

Group:        Individual Submission

Pages:        4

URL:            http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283m=
nids-00.txt

Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnid=
s/

Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00





Abstract:

   Additional Identifier Types are proposed for use with the Mobile Node

   Identifier Option for MIPv6 (RFC 4283).









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.



The IETF Secretariat







___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________

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.


--_000_81C77F07008CA24F9783A98CFD706F71142A4FA6PEXCVZYM12corpo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











 <=
/p>

 <=
/p>







De :=
 Sri Gundavelli (sgundave) [mailto:sgundave@ci=
sco.com]


Envoy=E9 : mercredi 24 septembre 2014 19:48

=C0 : SEITE Pierrick IMT/OLN; Charles E. Perkins; dmm@ietf.org<=
br>
Objet : Re: [DMM] Fwd: New Version Notification for draft-perki=
ns-dmm-4283mnids-00.txt






 




Hi Pierrick,






 






The NAI that is used in S2a/S5 procedur=
es is a IMSI-NAI, based on 3GPP TS 23.003. It is sent in PBU/PBA messages. =
Not sure, if IMSI information is seen as a confidential
 IE. But, I agree on the need to include some text on how the signaling mes=
sage can be protected with privacy / confidentiality service set, when the =
identifier is based on some confidential data.


 <=
/p>

>> I agree, thanks.=







 






 






Regards






Sri






 






From:
"=
pierrick.seite@orange.com" <pierrick.seite@orange.com>

Date: Wednesday, September 24, 2014 8:56 AM

To: "Charles E. Perkins" <charliep@computer.org>, "dmm@ietf.org" <dmm@ietf.o=
rg>

Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-d=
mm-4283mnids-00.txt






 








Hi Charlie,


 <=
/p>

Thanks for=
 the list… it looks good. I’m just wondering about security con=
siderations… Actually, from 3GPP standpoint, security constrains on I=
MSI
 and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI is very ra=
rely sent on the air (maybe only one time at the beginning of the 3GPP auth=
entication process) for security reasons. So, I’m wondering if adding=
 IMSI to the list of IDs, without any
 warnings, is somehow introducing security weakness to the 3GPP security pr=
ocess.   Consequently, I’m not sure about the following sta=
tement “This document does not
 introduce any security mechanisms, and does not have any impact on existin=
g security mechanisms.”
It’s maybe not so tr=
ue from the 3GPP point of view…


 


Maybe we s=
hould state that the ID option MUST be used in a way that it does not harm =
existing security mechanisms (i.e. use the option with caution
J). For ex=
ample, to address the issue above (maybe there are other examples…
 I don’t know…), we could state that the IMSI should be transmi=
tted only during first binding update, and not transmitted anymore as long =
as the association IMSI/HoA/HNP is done…. Or... simpler way to addres=
s the issue:  if nobody has use-case for transmitting
 the IMSI, we can simply remove the IMSI from the list J


 


BR,=



Pierrick


 


 








De :=
 dmm [=
mailto:dmm-bounces@ietf.org]
De la part de Charles E. Perkins

Envoy=E9 : mardi 23 septembre 2014 21:10

=C0 : dmm@ietf.org

Objet : [DMM] Fwd: New Version Notification for draft-perkins-d=
mm-4283mnids-00.txt






 


Hello folks,



We have published a ...-00 version of the MNIDs draft.  This is mainly=
 for

reference purposes.  A new version should be out within a week or so,<=
br>
incorporating the suggestions and comments from people who responded

to the earlier suggestion to revisit this work.



Regards,

Charlie P.








-------- Original Message -------- 








Subjec=
t: 




New Version Notification for draft-perkins-dmm-4283m=
nids-00.txt








Date: =





Tue, 23 Sep 2014 10:43:12 -0700








From: =





<inte=
rnet-drafts@ietf.org>








To: 




Charles E. Perkins <charliep@computer.org>, Vijay Devarapalli
<unkno=
wn-email-Vijay-Devarapalli@ietfa.amsl.com>, Charles E.Perkins
<charliep@computer.org><=
o:p>








 


A new version of I-D, draft-perkins-dmm-4283mnids-00.txt

has been successfully submitted by Charles E. Perkins and posted to th=
e


IETF repository.


 


Name:         draft-perkins-dm=
m-4283mnids


Revision:     00


Title:        MN Identifier Types f=
or RFC 4283 Mobile Node Identifier Option


Document date: 2014-09-23


Group:        Individual Submission=



Pages:        4


URL:           =
 http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00=
.txt


Status:         https://datatra=
cker.ietf.org/doc/draft-perkins-dmm-4283mnids/


Htmlized:       http://tools.ietf.org/html/dr=
aft-perkins-dmm-4283mnids-00


 


 


Abstract:


   Additional Identifier Types are proposed for use with the=
 Mobile Node


   Identifier Option for MIPv6 (RFC 4283).


 


            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       


 


 


Please note that it may take a couple of minutes from the time of subm=
ission


until the htmlized version and diff are available at tools.ietf.org.


 


The IETF Secretariat


 


 


 




 




______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.










______________________________________________________________________=
___________________________________________________

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.




--_000_81C77F07008CA24F9783A98CFD706F71142A4FA6PEXCVZYM12corpo_--


From nobody Thu Sep 25 07:58:35 2014
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 BC3831A007B for ; Thu, 25 Sep 2014 07:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 cqtDGvNq9dJI for ; Thu, 25 Sep 2014 07:58:31 -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 AAE231A0123 for ; Thu, 25 Sep 2014 07:58:31 -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 s8PEwVae018327; Thu, 25 Sep 2014 07:58:31 -0700
Received: from XCH-BLV-501.nw.nos.boeing.com (xch-blv-501.nw.nos.boeing.com [130.247.25.190]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8PEwOqv018238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 25 Sep 2014 07:58:24 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-501.nw.nos.boeing.com ([169.254.1.101]) with mapi id 14.03.0181.006; Thu, 25 Sep 2014 07:58:23 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1YkwgAEM+6CAAPHCgP//i1OggAB4a4D//5S3IIABoMoA//+6RxAAEnVNAAAOGsXgAAIEtIAAA9MEAA==
Date: Thu, 25 Sep 2014 14:58:22 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D27453@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D26DF1@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_2134F8430051B64F815C691A62D9831832D27453XCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/yrZEdsT891JrGtuY5Xm9jVTSZNQ
Subject: Re: [DMM] Signaling Message Fragmentation
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, 25 Sep 2014 14:58:33 -0000

--_000_2134F8430051B64F815C691A62D9831832D27453XCHBLV504nwnosb_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

OK, then it sounds like you would agree that fixing tunnel MTU once and for
all would be a good thing?

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, September 24, 2014 11:08 PM
To: Templin, Fred L; dmm@ietf.org
Subject: Re: Signaling Message Fragmentation

Hi Fred,

Ok ! Not my area of interest, but I understand the requirement.

Regards
Sri

From: , Fred L >
Date: Wednesday, September 24, 2014 3:59 PM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: Signaling Message Fragmentation

Hi Sri,

Sure, that diagram could be redrawn with airplanes instead of automobiles. =
But,
consider also the case where the airplane is a mobile router that connects =
into a
home network provided by an aeronautical Internet service provider. Then, t=
he
passenger devices are also mobile routers with their own home networks. Tha=
t
would represent a single mobile-router-within-mobile-router nesting, but a
"nested NEMO" case nonetheless.

We also care about use cases outside of just commercial aviation. Unmanned =
Air
Systems, Unmanned Underwater Vehicles, MANETs, disaster relief networks,
search and rescue networks, space-based systems etc.

About tunnels within tunnels, we should be able to nest them to infinite le=
vels
of recursion where each level sees at least a 1500 MTU. None of this 1460
reduced to 1420 reduced to 1380, etc. until we run out of space - there sho=
uld
be a solid 1500 at every level with the ability to go bigger if the path MT=
U can
support it.

Thanks - Fred

--_000_2134F8430051B64F815C691A62D9831832D27453XCHBLV504nwnosb_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











OK, then it sounds like y=
ou would agree that fixing tunnel MTU once and for


all would be a good thing=
?


 <=
/p>

Thanks - Fred<=
/span>


 <=
/p>







From: Sri Gund=
avelli (sgundave) [mailto:sgundave@cisco.com]


Sent: Wednesday, September 24, 2014 11:08 PM

To: Templin, Fred L; dmm@ietf.org

Subject: Re: Signaling Message Fragmentation






 




Hi Fred,<=
/p>





 





Ok ! Not my area of interes=
t, but I understand the requirement. 






 





Regards





Sri






 





From:
<Templin>, Fred L <Fred.L.Templin@boeing.com>

Date: Wednesday, September 24, 2014 3:59 PM

To: Sri Gundavelli <sgundav=
e@cisco.com>, "dmm@ietf.org=
" <dmm@ietf.org>

Subject: RE: Signaling Message Fragmentation






 



Hi Sri,


 


Sure, that diagram could =
be redrawn with airplanes instead of automobiles. But,


consider also the case wh=
ere the airplane is a mobile router that connects into a


home network provided by =
an aeronautical Internet service provider. Then, the


passenger devices are als=
o mobile routers with their own home networks. That


would represent a single =
mobile-router-within-mobile-router nesting, but a


“nested NEMO”=
 case nonetheless.


 


We also care about use ca=
ses outside of just commercial aviation. Unmanned Air


Systems, Unmanned Underwa=
ter Vehicles, MANETs, disaster relief networks,


search and rescue network=
s, space-based systems etc.


 


About tunnels within tunn=
els, we should be able to nest them to infinite levels


of recursion where each l=
evel sees at least a 1500 MTU. None of this 1460


reduced to 1420 reduced t=
o 1380, etc. until we run out of space - there should


be a solid 1500 at every =
level with the ability to go bigger if the path MTU can


support it.


 


Thanks - Fred








--_000_2134F8430051B64F815C691A62D9831832D27453XCHBLV504nwnosb_--


From nobody Thu Sep 25 10:06:13 2014
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 06B5E1A01E5 for ; Thu, 25 Sep 2014 10:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 T9MzY1TGyVOt for ; Thu, 25 Sep 2014 10:06:09 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3491A8729 for ; Thu, 25 Sep 2014 10:06:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14503; q=dns/txt; s=iport; t=1411664769; x=1412874369; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ZoCy55znULYT8/bwZFrvcTpZBTsuD+a9G098UFp1Ia4=; b=GMmVQHaVq3mFy5r+G4jlTULxR+T7Q9OAXMe/0TL8pZNjwshvNa6NHBqL WYZJeVuD+ARaSBjOOBYh9cubGY5tswXvT/vL357GCnpYqsNMFw4c1FWQ2 P1qIpCoHptrtEKlH9Hz1z2yTkoEKaftypKVAwTXP0vB+WxR24iNh+00gk E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkwFANBKJFStJA2J/2dsb2JhbABggkhGU1cE0jgCgQUWAXuEAwEBAQQtXgEIEQMBAQEoORQJCAIEARKIPsFLARePcwcTFwEGhEUFj0iCGItDlVaDY2wBgUeBAgEBAQ
X-IronPort-AV: E=Sophos; i="5.04,598,1406592000"; d="scan'208,217"; a="81263554"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 25 Sep 2014 17:06:08 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8PH68AN003915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Sep 2014 17:06:08 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 12:06:07 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Templin, Fred L" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP2OL+Q82TOW+4mk2ZxUN/Y/E/Vw==
Date: Thu, 25 Sep 2014 17:06:06 +0000
Message-ID: 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D27453@XCH-BLV-504.nw.nos.boeing.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.217]
Content-Type: multipart/alternative; boundary="_000_D0499861166C05sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/xVzDNENmap2pC5ZmFqOVyqzwOvM
Subject: Re: [DMM] Signaling Message Fragmentation
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, 25 Sep 2014 17:06:11 -0000

--_000_D0499861166C05sgundaveciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Fred - If there is interest to do that work and the chair's are ok with it,=
 I'll not object to that work.

Regards
Sri



From: , Fred L >
Date: Thursday, September 25, 2014 7:58 AM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: Signaling Message Fragmentation

OK, then it sounds like you would agree that fixing tunnel MTU once and for
all would be a good thing?

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, September 24, 2014 11:08 PM
To: Templin, Fred L; dmm@ietf.org
Subject: Re: Signaling Message Fragmentation

Hi Fred,

Ok ! Not my area of interest, but I understand the requirement.

Regards
Sri

From: , Fred L >
Date: Wednesday, September 24, 2014 3:59 PM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: Signaling Message Fragmentation

Hi Sri,

Sure, that diagram could be redrawn with airplanes instead of automobiles. =
But,
consider also the case where the airplane is a mobile router that connects =
into a
home network provided by an aeronautical Internet service provider. Then, t=
he
passenger devices are also mobile routers with their own home networks. Tha=
t
would represent a single mobile-router-within-mobile-router nesting, but a
=93nested NEMO=94 case nonetheless.

We also care about use cases outside of just commercial aviation. Unmanned =
Air
Systems, Unmanned Underwater Vehicles, MANETs, disaster relief networks,
search and rescue networks, space-based systems etc.

About tunnels within tunnels, we should be able to nest them to infinite le=
vels
of recursion where each level sees at least a 1500 MTU. None of this 1460
reduced to 1420 reduced to 1380, etc. until we run out of space - there sho=
uld
be a solid 1500 at every level with the ability to go bigger if the path MT=
U can
support it.

Thanks - Fred

--_000_D0499861166C05sgundaveciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <7E72C87E0EE2AE4BB79EE721417F5469@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Fred - If there is interest to do that work and the chair's are ok wit=
h it, I'll not object to that work.







Regards


Sri



















From: <Templin>, Fred L <<=
a href=3D"mailto:Fred.L.Templin@boeing.com">Fred.L.Templin@boeing.com&g=
t;

Date: Thursday, September 25, 2014 =
7:58 AM

To: Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>

Subject: RE: Signaling Message Frag=
mentation

















OK, then it sounds like you would =
agree that fixing tunnel MTU once and for


all would be a good thing?


 


Thanks - Fred

 








From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]


Sent: Wednesday, September 24, 2014 11:08 PM

To: Templin, Fred L; dmm@ietf.org

Subject: Re: Signaling Message Fragmentation






 




Hi Fred,






 






Ok ! Not my area of interest, but I underst=
and the requirement. 






 






Regards






Sri






 






From:
<Templin>, Fred L <Fred.L.Templin@boeing.com>

Date: Wednesday, September 24, 2014 3:59 PM

To: Sri Gundavelli <sgundav=
e@cisco.com>, "dmm@ietf.org=
" <dmm@ietf.org>

Subject: RE: Signaling Message Fragmentation






 




Hi Sri,


 


Sure, that diagram could be redraw=
n with airplanes instead of automobiles. But,


consider also the case where the a=
irplane is a mobile router that connects into a


home network provided by an aerona=
utical Internet service provider. Then, the


passenger devices are also mobile =
routers with their own home networks. That


would represent a single mobile-ro=
uter-within-mobile-router nesting, but a=



=93nested NEMO=94 case nonetheless=
.


 


We also care about use cases outsi=
de of just commercial aviation. Unmanned Air


Systems, Unmanned Underwater Vehic=
les, MANETs, disaster relief networks,


search and rescue networks, space-=
based systems etc.


 


About tunnels within tunnels, we s=
hould be able to nest them to infinite levels


of recursion where each level sees=
 at least a 1500 MTU. None of this 1460<=
o:p>


reduced to 1420 reduced to 1380, e=
tc. until we run out of space - there should


be a solid 1500 at every level wit=
h the ability to go bigger if the path MTU can


support it.


 


Thanks - Fred













--_000_D0499861166C05sgundaveciscocom_--


From nobody Thu Sep 25 11:43:19 2014
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 1ECDD1A87A9 for ; Thu, 25 Sep 2014 11:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 zg4iwJfM7OVl for ; Thu, 25 Sep 2014 11:43:15 -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 ACB1F1A87B0 for ; Thu, 25 Sep 2014 11:43:15 -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 s8PIhExD021361; Thu, 25 Sep 2014 13:43:15 -0500
Received: from XCH-BLV-207.nw.nos.boeing.com (xch-blv-207.nw.nos.boeing.com [10.57.37.63]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8PIh59g020775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 25 Sep 2014 13:43:06 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-207.nw.nos.boeing.com ([169.254.7.31]) with mapi id 14.03.0181.006; Thu, 25 Sep 2014 11:43:05 -0700
From: "Templin, Fred L" 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: Signaling Message Fragmentation
Thread-Index: AQHP03upltDWAX+NA0eWoFFgaPoH75wN1YkwgAEM+6CAAPHCgP//i1OggAB4a4D//5S3IIABoMoA//+6RxAAEnVNAAAOGsXgAAIEtIAAA9MEAAATKn8AAAtd7JA=
Date: Thu, 25 Sep 2014 18:43:04 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D2788D@XCH-BLV-504.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D9831832D27453@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_2134F8430051B64F815C691A62D9831832D2788DXCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/v1Lvd62mnVtJyl86EL0CCOx7Zp8
Subject: Re: [DMM] Signaling Message Fragmentation
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, 25 Sep 2014 18:43:18 -0000

--_000_2134F8430051B64F815C691A62D9831832D2788DXCHBLV504nwnosb_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

OK Sri; thanks. I just dropped a -40 version of the spec that includes subs=
tantial
improvements to the fragmentation and MTU section beyond what you have
already seen. If the WG wants to use this as a starting point, that would b=
e OK
with me.

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Thursday, September 25, 2014 10:06 AM
To: Templin, Fred L; dmm@ietf.org
Subject: Re: Signaling Message Fragmentation

Fred - If there is interest to do that work and the chair's are ok with it,=
 I'll not object to that work.

Regards
Sri



From: , Fred L >
Date: Thursday, September 25, 2014 7:58 AM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: Signaling Message Fragmentation

OK, then it sounds like you would agree that fixing tunnel MTU once and for
all would be a good thing?

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, September 24, 2014 11:08 PM
To: Templin, Fred L; dmm@ietf.org
Subject: Re: Signaling Message Fragmentation

Hi Fred,

Ok ! Not my area of interest, but I understand the requirement.

Regards
Sri

From: , Fred L >
Date: Wednesday, September 24, 2014 3:59 PM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: Signaling Message Fragmentation

Hi Sri,

Sure, that diagram could be redrawn with airplanes instead of automobiles. =
But,
consider also the case where the airplane is a mobile router that connects =
into a
home network provided by an aeronautical Internet service provider. Then, t=
he
passenger devices are also mobile routers with their own home networks. Tha=
t
would represent a single mobile-router-within-mobile-router nesting, but a
"nested NEMO" case nonetheless.

We also care about use cases outside of just commercial aviation. Unmanned =
Air
Systems, Unmanned Underwater Vehicles, MANETs, disaster relief networks,
search and rescue networks, space-based systems etc.

About tunnels within tunnels, we should be able to nest them to infinite le=
vels
of recursion where each level sees at least a 1500 MTU. None of this 1460
reduced to 1420 reduced to 1380, etc. until we run out of space - there sho=
uld
be a solid 1500 at every level with the ability to go bigger if the path MT=
U can
support it.

Thanks - Fred

--_000_2134F8430051B64F815C691A62D9831832D2788DXCHBLV504nwnosb_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











OK Sri; thanks. I just dr=
opped a -40 version of the spec that includes substantial=



improvements to the fragm=
entation and MTU section beyond what you have


already seen. If the WG w=
ants to use this as a starting point, that would be OK

with me.


 <=
/p>

Thanks - Fred<=
/span>


 <=
/p>







From: Sri Gund=
avelli (sgundave) [mailto:sgundave@cisco.com]


Sent: Thursday, September 25, 2014 10:06 AM

To: Templin, Fred L; dmm@ietf.org

Subject: Re: Signaling Message Fragmentation






 




Fred - If there is interest=
 to do that work and the chair's are ok with it, I'll not object to that wo=
rk.






 





Regards





Sri






 





 





 





From:
<Templin>, Fred L <Fred.L.Templin@boeing.com>

Date: Thursday, September 25, 2014 7:58 AM

To: Sri Gundavelli <sgundav=
e@cisco.com>, "dmm@ietf.org=
" <dmm@ietf.org>

Subject: RE: Signaling Message Fragmentation






 







OK, then it sounds like y=
ou would agree that fixing tunnel MTU once and for


all would be a good thing=
?


 


Thanks - Fred


 








From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]


Sent: Wednesday, September 24, 2014 11:08 PM

To: Templin, Fred L; dmm@ietf.org

Subject: Re: Signaling Message Fragmentation






 =





Hi Fred,






 






Ok ! Not my area of interes=
t, but I understand the requirement. 






 






Regards






Sri






 






From:
<Templin>, Fred L <Fred.L.Templin@boeing.com>

Date: Wednesday, September 24, 2014 3:59 PM

To: Sri Gundavelli <sgundav=
e@cisco.com>, "dmm@ietf.org=
" <dmm@ietf.org>

Subject: RE: Signaling Message Fragmentation






 




Hi Sri,


 


Sure, that diagram could =
be redrawn with airplanes instead of automobiles. But,


consider also the case wh=
ere the airplane is a mobile router that connects into a


home network provided by =
an aeronautical Internet service provider. Then, the


passenger devices are als=
o mobile routers with their own home networks. That


would represent a single =
mobile-router-within-mobile-router nesting, but a


“nested NEMO”=
 case nonetheless.


 


We also care about use ca=
ses outside of just commercial aviation. Unmanned Air


Systems, Unmanned Underwa=
ter Vehicles, MANETs, disaster relief networks,


search and rescue network=
s, space-based systems etc.


 


About tunnels within tunn=
els, we should be able to nest them to infinite levels


of recursion where each l=
evel sees at least a 1500 MTU. None of this 1460


reduced to 1420 reduced t=
o 1380, etc. until we run out of space - there should


be a solid 1500 at every =
level with the ability to go bigger if the path MTU can


support it.


 


Thanks - Fred














--_000_2134F8430051B64F815C691A62D9831832D2788DXCHBLV504nwnosb_--


From nobody Thu Sep 25 12:02:32 2014
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 4B26A1A87B1 for ; Thu, 25 Sep 2014 12:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 wYZ_6qmqFz5w for ; Thu, 25 Sep 2014 12:02:28 -0700 (PDT)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 82ADE1A031B for ; Thu, 25 Sep 2014 12:02:26 -0700 (PDT)
Received: from [107.1.141.74] (helo=[192.168.254.194]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XXEJ5-0008Il-Kd; Thu, 25 Sep 2014 15:02:23 -0400
Message-ID: <542466BC.6020702@computer.org>
Date: Thu, 25 Sep 2014 12:02:20 -0700
From: "Charles E. Perkins" 
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Sri Gundavelli (sgundave)" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080905030506040702000209"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7d10c54ef1fd5595c45f66601170a0de7350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/vlz47XyVi1DKT6lrx7x1BkBkyDQ
Cc: Vijay Devarapalli , dmm@ietf.org
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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, 25 Sep 2014 19:02:30 -0000

This is a multi-part message in MIME format.
--------------080905030506040702000209
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit


Hello folks,

I think the best solution for this would be a section in the Security
Considerations explaining the need.   I will fashion some text for the
upcoming revision ....-01.txt

Regards,
Charlie P.


On 9/24/2014 10:48 AM, Sri Gundavelli (sgundave) wrote:
> Hi Pierrick,
>
> The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP 
> TS 23.003. It is sent in PBU/PBA messages. Not sure, if IMSI 
> information is seen as a confidential IE. But, I agree on the need to 
> include some text on how the signaling message can be protected with 
> privacy / confidentiality service set, when the identifier is based on 
> some confidential data.
>
>
> Regards
> Sri
>
> From: "pierrick.seite@orange.com " 
> >
> Date: Wednesday, September 24, 2014 8:56 AM
> To: "Charles E. Perkins"  >, "dmm@ietf.org " 
> >
> Subject: Re: [DMM] Fwd: New Version Notification for 
> draft-perkins-dmm-4283mnids-00.txt
>
> Hi Charlie,
>
> Thanks for the list… it looks good. I’m just wondering about security 
> considerations… Actually, from 3GPP standpoint, security constrains on 
> IMSI and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI 
> is very rarely sent on the air (maybe only one time at the beginning 
> of the 3GPP authentication process) for security reasons. So, I’m 
> wondering if adding IMSI to the list of IDs, without any warnings, is 
> somehow introducing security weakness to the 3GPP security process. 
>   Consequently, I’m not sure about the following statement “This 
> document does not introduce any security mechanisms, and does not have 
> any impact on existing security mechanisms.” It’s maybe not so true 
> from the 3GPP point of view…
>
> Maybe we should state that the ID option MUST be used in a way that it 
> does not harm existing security mechanisms (i.e. use the option with 
> caution J). For example, to address the issue above (maybe there are 
> other examples… I don’t know…), we could state that the IMSI should be 
> transmitted only during first binding update, and not transmitted 
> anymore as long as the association IMSI/HoA/HNP is done…. Or... 
> simpler way to address the issue:  if nobody has use-case for 
> transmitting the IMSI, we can simply remove the IMSI from the list J
>
> BR,
>
> Pierrick
>
> *De :*dmm [mailto:dmm-bounces@ietf.org] *De la part de* Charles E. Perkins
> *Envoyé :* mardi 23 septembre 2014 21:10
> *À :* dmm@ietf.org 
> *Objet :* [DMM] Fwd: New Version Notification for 
> draft-perkins-dmm-4283mnids-00.txt
>
> Hello folks,
>
> We have published a ...-00 version of the MNIDs draft.  This is mainly for
> reference purposes.  A new version should be out within a week or so,
> incorporating the suggestions and comments from people who responded
> to the earlier suggestion to revisit this work.
>
> Regards,
> Charlie P.
>
>
>
> -------- Original Message --------
>
> *Subject: *
>
> 	
>
> New Version Notification for draft-perkins-dmm-4283mnids-00.txt
>
> *Date: *
>
> 	
>
> Tue, 23 Sep 2014 10:43:12 -0700
>
> *From: *
>
> 	
>
>  
>
> *To: *
>
> 	
>
> Charles E. Perkins  
> , Vijay Devarapalli 
>  
> , Charles 
> E.Perkins  
>
> A new version of I-D, draft-perkins-dmm-4283mnids-00.txt
> has been successfully submitted by Charles E. Perkins and posted to the
> IETF repository.
>   
> Name:         draft-perkins-dmm-4283mnids
> Revision:     00
> Title:        MN Identifier Types for RFC 4283 Mobile Node Identifier Option
> Document date: 2014-09-23
> Group:        Individual Submission
> Pages:        4
> URL:http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt
> Status:https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/
> Htmlized:http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00
>   
>   
> Abstract:
>     Additional Identifier Types are proposed for use with the Mobile Node
>     Identifier Option for MIPv6 (RFC 4283).
>   
>                                                                                    
>   
>   
> 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.
>   
> The IETF Secretariat
>   
>   
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> 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.

-- 
Regards,
Charlie P.


--------------080905030506040702000209
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    Hello folks,

    

    I think the best solution for this would be a section in the
    Security

    Considerations explaining the need.   I will fashion some text for
    the

    upcoming revision ....-01.txt

    

    Regards,

    Charlie P.

    

    

    
On 9/24/2014 10:48 AM, Sri Gundavelli
      (sgundave) wrote:

    

    

      
      
Hi Pierrick,

      


      

      
The NAI that is used in S2a/S5 procedures is a IMSI-NAI,
        based on 3GPP TS 23.003. It is sent in PBU/PBA messages. Not
        sure, if IMSI information is seen as a confidential IE. But, I
        agree on the need to include some text on how the signaling
        message can be protected with privacy / confidentiality service
        set, when the identifier is based on some confidential data.

      


      

      


      

      
Regards

      
Sri

      


      

      
        

          From: "pierrick.seite@orange.com"
          <pierrick.seite@orange.com>

          Date: Wednesday,
          September 24, 2014 8:56 AM

          To: "Charles E.
          Perkins" <charliep@computer.org>,
          "dmm@ietf.org"
          <dmm@ietf.org>

          Subject: Re: [DMM] Fwd:
          New Version Notification for
          draft-perkins-dmm-4283mnids-00.txt

        

        


        

        

          
          
          

            

              
Hi
                  Charlie,

              
 

              
Thanks for the list… it looks good. I’m
                  just wondering about security considerations…
                  Actually, from 3GPP standpoint, security constrains on
                  IMSI and GPRSS/LTE temporary identifiers (P-TMSI,
                  GUTI). AFAIK, IMSI is very rarely sent on the air
                  (maybe only one time at the beginning of the 3GPP
                  authentication process) for security reasons. So, I’m
                  wondering if adding IMSI to the list of IDs, without
                  any warnings, is somehow introducing security weakness
                  to the 3GPP security process.   Consequently, I’m not
                  sure about the following statement “This
                  document does not introduce any security mechanisms,
                  and does not have any impact on existing security
                  mechanisms.”
                It’s
                  maybe not so true from the 3GPP point of view…

              
 

              
Maybe we should state that the ID option
                  MUST be used in a way that it does not harm existing
                  security mechanisms (i.e. use the option with caution
                J). For example, to address
                  the issue above (maybe there are other examples… I
                  don’t know…), we could state that the IMSI should be
                  transmitted only during first binding update, and not
                  transmitted anymore as long as the association
                  IMSI/HoA/HNP is done…. Or... simpler way to address
                  the issue:  if nobody has use-case for transmitting
                  the IMSI, we can simply remove the IMSI from the list
                J

              
 

              
BR,

              
Pierrick

              
 

              
 

              

                

                  

                    
De : dmm [mailto:dmm-bounces@ietf.org]
                        De la part de Charles E. Perkins

                        Envoyé : mardi 23 septembre 2014 21:10

                        À : dmm@ietf.org

                        Objet : [DMM] Fwd: New Version
                        Notification for
                        draft-perkins-dmm-4283mnids-00.txt

                  

                

                
 

                
Hello
                  folks,

                  

                  We have published a ...-00 version of the MNIDs
                  draft.  This is mainly for

                  reference purposes.  A new version should be out
                  within a week or so,

                  incorporating the suggestions and comments from people
                  who responded

                  to the earlier suggestion to revisit this work.

                  

                  Regards,

                  Charlie P.

                

                  


                    

                    -------- Original Message -------- 

                  

                    
                      

                        
                          
Subject: 

                        		
                        
                          
New Version Notification
                            for draft-perkins-dmm-4283mnids-00.txt

                        		
                      

                      

                        
                          
Date: 

                        		
                        
                          
Tue, 23 Sep 2014 10:43:12
                            -0700

                        		
                      

                      

                        
                          
From: 

                        		
                        
                          
<internet-drafts@ietf.org>

                        		
                      

                      

                        
                          
To: 

                        		
                        
                          
Charles E. Perkins <charliep@computer.org>,
                            Vijay Devarapalli
                            <unknown-email-Vijay-Devarapalli@ietfa.amsl.com>,
                            Charles E.Perkins
                            <charliep@computer.org>

                        		
                      

                    
                  

                  
 

                  
A new version of I-D, draft-perkins-dmm-4283mnids-00.txt

                  
has been successfully submitted by Charles E. Perkins and posted to the

                  
IETF repository.

                  
 

                  
Name:         draft-perkins-dmm-4283mnids

                  
Revision:     00

                  
Title:        MN Identifier Types for RFC 4283 Mobile Node Identifier Option

                  
Document date: 2014-09-23

                  
Group:        Individual Submission

                  
Pages:        4

                  
URL:            http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt

                  
Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/

                  
Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00

                  
 

                  
 

                  
Abstract:

                  
   Additional Identifier Types are proposed for use with the Mobile Node

                  
   Identifier Option for MIPv6 (RFC 4283).

                  
 

                  
                                                                                  

                  
 

                  
 

                  
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.

                  
 

                  
The IETF Secretariat

                  
 

                  
 

                  
 

                

                
 

              

            

            
_________________________________________________________________________________________________________________________

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.

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.


          

        

      
    

    

    
-- 
Regards,
Charlie P.

  


--------------080905030506040702000209--


From nobody Thu Sep 25 13:38:58 2014
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 167DA1A0378 for ; Thu, 25 Sep 2014 13:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] 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 I7o2BGnmgZ_u for ; Thu, 25 Sep 2014 13:38:45 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id CD7201A036C for ; Thu, 25 Sep 2014 13:38:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EJV/I0PKKev6Q9vsKKEOrICSNmz5eQaaw2fqFtPzTjnJbE4Efjy98EQVAMwHfnTz; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [107.1.141.74] (helo=[192.168.254.194]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XXFoI-0007Rx-Ox; Thu, 25 Sep 2014 16:38:42 -0400
Message-ID: <54247D52.3000903@earthlink.net>
Date: Thu, 25 Sep 2014 13:38:42 -0700
From: Charlie Perkins 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Hakima Chaouchi 
References:  <2007180277.6484923.1411312300022.JavaMail.zimbra@telecom-sudparis.eu>
In-Reply-To: <2007180277.6484923.1411312300022.JavaMail.zimbra@telecom-sudparis.eu>
Content-Type: multipart/alternative; boundary="------------040207040805050301060406"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7db4d9a77afc4ce13cdd8fd7a1a5c0fef350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/8gZUwT80LzyVkCuV7yJXN8nflZ0
Cc: Vijay Devarapalli , dmm@ietf.org
Subject: Re: [DMM] MNID Types
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, 25 Sep 2014 20:38:52 -0000

This is a multi-part message in MIME format.
--------------040207040805050301060406
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Hakima,

I'm putting in the RFID as a selection in the draft.  I have two
questions:

- Do we need to include various types of RFIDs?
- Can you send good citations for the Normative References?

I have 
http://www.acq.osd.mil/log/sci/ait/DoD_Suppliers_Passive_RFID_Info_Guide_v15update.pdf 
but I am not sure if that's the correct normative reference.

Regards,
Charlie P.

On 9/21/2014 8:11 AM, Hakima Chaouchi wrote:
> Hello Folks,
>
> Do you think that considering specific but needed technologies for 
> moving objects in  Internet of Things  such as RFID (Radio Frequency 
> Identifier) with 96 bits identifiers will be also relevent to 
> Charlie's current draft and the efforts related to MNID?
>
> Regards,
>
> Hakima
>
>
> ------------------------------------------------------------------------
> *De: *"Sri Gundavelli (sgundave)" 
> *À: *"Charlie Perkins" , "Marco 
> Liebsch" , dmm@ietf.org, "Vijay Devarapalli" 
> 
> *Envoyé: *Jeudi 11 Septembre 2014 23:57:11
> *Objet: *Re: [DMM] MNID Types
>
> Hi Charlie,
>
> Few more reviews/discussions and capturing the consensus in the base 
> version will help. But, I'm ok either way …
>
>
> Regards
> Sri
>
> From: Charlie Perkins  >
> Date: Thursday, September 11, 2014 2:46 PM
> To: Sri Gundavelli >, 
> Marco Liebsch  >, "dmm@ietf.org 
> " >, Vijay 
> Devarapalli >
> Subject: Re: [DMM] MNID Types
>
>
> Hello folks,
>
> I propose to submit the ....-00.txt document as it is to the Internet
> Drafts directory, and then to go about making updates according to
> the discussion on this list.  Do you think this is reasonable?
>
> Regards,
> Charlie P.
>
>
> On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:
>
>     
>
>
>     Marco,
>
>
>     Thinking further on the complementary identifier option.
>
>     - There is already the link-layer identifier option that can be used for
>     carrying the Mac address
>     - IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's
>
>     In some sense, the complementary identifiers are already present.
>
>     Sri
>
>
>
>
>
>     On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)"  wrote:
>
>         I do not see a reason why multiple MN-Id instances need to be present in a
>         single message ? In my experience, this is strictly a deployment
>         consideration, when to use what type of identifiers.
>
>         Assuming the backend system can tie all the MN-Id's to a single
>         subscription, any presented identifier can be sufficient for the gateway
>         to do the BCE lookup.
>
>         If multiple instances can be present, then we need to deal with more error
>         cases. Is that really needed ?
>
>
>             I am wondering if it would not be more appropriate to go for a different
>             container option to carry such information. Something like a
>             complementary identifier option.
>
>         Sounds interesting. Are you suggesting we leave the current MN-ID as it
>         is, but use a new complementary option ? But, if the requirement is for a
>         Mac based identifiers, what will be there in the current MN-Id option ? We
>         still need to have identifier there ?
>
>
>
>
>         Sri
>
>
>
>
>
>         On 9/11/14 2:03 AM, "Marco Liebsch"  wrote:
>
>             No issue with logical vs. physical ID. But I am wondering about two
>             things:
>
>             Operation is clear to me in case a single MNID is present in a message
>             and I see the value in being
>             flexible to choose from different sub-types. If multiple MNIDs with
>             different sub-types are present in
>             a single message, which one should e.g. the LMA take for the BC lookup..
>             No big problem to solve, but
>             to be considered in implementations.
>
>             If the reason for multiple present MNIDs with different sub-types is to
>             do other things than identifying
>             the node or using the ID as key for a lookup, I am wondering if it would
>             not be more appropriate
>             to go for a different container option to carry such information.
>             Something like a complementary
>             identifier option.
>
>             marco
>
>                 -----Original Message-----
>                 From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>                 Sent: Donnerstag, 11. September 2014 00:42
>                 To: Charlie Perkins; Marco Liebsch;dmm@ietf.org
>                 Cc: Vijay Devarapalli
>                 Subject: Re: [DMM] regarding the re-chartering..
>
>                 Hello Charlie,
>
>                 Agree with that. MN-Id as its defined today is a logical identifier. It
>                 does not
>                 require the identifier to be bound to a physical device or a interface
>                 identity.
>                 But, we have clearly seen requirements where the need is for generating
>                 identifiers based on some physical identifiers. Those physical
>                 identifiers include
>                 IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
>                 source
>                 and the rules for generating MN-ID based using those sources, the sender
>                 and
>                 receiver will have clear guidance on how to use the spec. Some pointers,
>                 explanation and examples for each of those identifiers will greatly help
>                 avoid
>                 inter-op issues.
>
>
>                 Regards
>                 Sri
>
>
>
>
>
>
>
>                 On 9/10/14 3:21 PM, "Charlie Perkins"
>                 wrote:
>
>                     Hello folks,
>
>                     I think it's best to consider the MNID as simply living in a space of
>                     identifiers, and not worry too much about whether it's a logical
>                     identifier or a physical identifier.  If the former, then somewhere
>                     (perhaps below the network layer) the logical identifier has been bound
>                     to something in the physical interface, but that's not our problem.
>
>                     The number space for types of MNIDs is likely to stay pretty empty, so
>                     I'd say we could add as many types as would be convenient for the
>                     software designers.  So, we could conceivably have several MNIDs
>                     defined that all "looked like" NAIs (which, themselves, "look like"
>                     FQDNs).
>
>                     Regards,
>                     Charlie P.
>
>
>
>                     On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:
>
>                         Yes. Currently, the MNID is if the nai format and is overloaded. The
>                         MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
>                         IMSI. Ex:
>                         "@epc.mnc.mcc.3gppnetwork.org²
>
>                         We also have MAC48@REALM;
>
>                         We also have approaches to transform MAC to Pseudo IMSI, and then
>                         carry IMSI-NAI as the MN-ID.
>
>
>                         So, we need unique sub-types for each of the types/sources.
>
>                         MN-Id based on IMSI, MSISDN, IMEI, MAC ..
>
>                         Also, do we need to distinguish between IMSI and IMSI-NAI ?
>
>                         Sri
>
>
>
>                         On 9/10/14 6:29 AM, "Marco Liebsch"  wrote:
>
>                             It seems the MNID is somehow overloaded to carry both, node-specific
>                             IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
>                             There may be value in adding the IMEI to the list of possible types
>                             of  node-specific IDs.
>
>                             marco
>
>                                 -----Original Message-----
>                                 From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
>                                 (sgundave)
>                                 Sent: Dienstag, 9. September 2014 23:30
>                                 To: Sri Gundavelli (sgundave); Charlie Perkins;dmm@ietf.org
>                                 Cc: Vijay Devarapalli
>                                 Subject: Re: [DMM] regarding the re-chartering..
>
>                                 Two more comments.
>
>
>
>                                 4.) I'd also use sub-type value of (2) for IMSI. Just to align with
>                                 the  sub-types  defined for MN Id defined for ICMP. I suspect there
>                                 are some  implementations  already using sub-type (2). Please see
>                                 the other thread.
>
>
>                                 5.) For each of the sub-types, we need text including examples and
>                                 some
>                                 explanation on how they are used.
>
>
>                                 Sri
>
>
>
>                                 On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)"
>                                 wrote:
>
>                                     Hi Charlie,
>
>                                     This is good. Thanks.
>
>
>                                     1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
>                                     802.2
>                                     address, why do we need to two sub-types ? Why not have just one
>                                     sub-type for mac based identifiers ?
>
>                                     2.) Sub type value (1) is currently used. Its currently overloaded
>                                     for
>                                     IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
>                                     definition of new sub-types, we need some text explaining the
>                                     motivation
>
>                                     3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
>                                     is
>                                     this ? Are these CGA-based IPv6 addresses ?
>
>
>
>
>                                                           New Mobile Node Identifier Types
>
>                                                     +-----------------+------------------------+
>                                                     | Identifier Type | Identifier Type Number |
>                                                     +-----------------+------------------------+
>                                                     | IPv6 Address    | 2                      |
>                                                     |                 |                        |
>                                                     | IMSI            | 3                      |
>                                                     |                 |                        |
>                                                     | P-TMSI          | 4                      |
>                                                     |                 |                        |
>                                                     | EUI-48 address  | 5                      |
>                                                     |                 |                        |
>                                                     | EUI-64 address  | 6                      |
>                                                     |                 |                        |
>                                                     | GUTI            | 7                      |
>                                                     +-----------------+------------------------+
>
>
>
>
>
>
>
>                                     Regards
>                                     Sri
>                                     PS: Good to see Vijay back
>
>
>                                     On 9/9/14 1:28 PM, "Charlie Perkins"
>                                     
>                                     wrote:
>
>                                         Hello folks,
>
>                                         Here's the last Internet Draft that we did, long ago expired:
>
>                                         http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt
>
>                                         I'll resubmit it with a few updates as a personal draft to dmm.
>
>                                         Regards,
>                                         Charlie P.
>
>                                     _______________________________________________
>                                     dmm mailing list
>                                     dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>                                 _______________________________________________
>                                 dmm mailing list
>                                 dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>         _______________________________________________
>         dmm mailing list
>         dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>     _______________________________________________
>     dmm mailing list
>     dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
> -- 
> ---------------------------------
> Hakima Chaouchi
> Professor
> Telecom Sud Paris
> Institut Mines Telecom
> 9 rue Charles Fourier
> 91011 Evry
> 0160764443
>
>
>
> Email secured by Check Point
>


--------------040207040805050301060406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hello Hakima,

    

    I'm putting in the RFID as a selection in the draft.  I have two

    questions:

    

    - Do we need to include various types of RFIDs?

    - Can you send good citations for the Normative References?

    

    I have
http://www.acq.osd.mil/log/sci/ait/DoD_Suppliers_Passive_RFID_Info_Guide_v15update.pdf
    but I am not sure if that's the correct normative reference.

    

    Regards,

    Charlie P.

    

    
On 9/21/2014 8:11 AM, Hakima Chaouchi
      wrote:

    

    

      

        
Hello Folks,

        

        


        

        
Do you think that considering specific but needed
          technologies for moving objects in  Internet of Things  such
          as RFID (Radio Frequency Identifier) with 96 bits identifiers
          will be also relevent to Charlie's current draft and the
          efforts related to MNID?  

        

        


        

        
Regards,

        

        


        

        
Hakima

        

        


        

        


        

        

        
De:
          "Sri Gundavelli (sgundave)" <sgundave@cisco.com>

          À: "Charlie Perkins"
          <charles.perkins@earthlink.net>, "Marco Liebsch"
          <Marco.Liebsch@neclab.eu>, dmm@ietf.org, "Vijay
          Devarapalli" <dvijay@rocketmail.com>

          Envoyé: Jeudi 11 Septembre 2014 23:57:11

          Objet: Re: [DMM] MNID Types

          


          

          
Hi Charlie,

          


          

          
Few more reviews/discussions and capturing the consensus
            in the base version will help. But, I'm ok either way …

          


          

          


          

          
Regards

          
Sri

          


          

          
            

              From: Charlie
              Perkins <charles.perkins@earthlink.net>

              Date: Thursday,
              September 11, 2014 2:46 PM

              To: Sri Gundavelli
              <sgundave@cisco.com>,
              Marco Liebsch <Marco.Liebsch@neclab.eu>,
              "dmm@ietf.org" <dmm@ietf.org>, Vijay Devarapalli
              <dvijay@rocketmail.com>

              Subject: Re: [DMM]
              MNID Types

            

            


            

            

              


                Hello
                    folks,

                    

                    I propose to submit the ....-00.txt document as it
                    is to the Internet

                    Drafts directory, and then to go about making
                    updates according to

                    the discussion on this list.  Do you think this is
                    reasonable?

                    

                    Regards,

                    Charlie P.

                    

                  

                
On 9/11/2014 7:21 AM, Sri
                  Gundavelli (sgundave) wrote:

                

                

                  
<Changing the subject line to reflect the MNId discussion>


Marco,


Thinking further on the complementary identifier option.

- There is already the link-layer identifier option that can be used for
carrying the Mac address
- IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's

In some sense, the complementary identifiers are already present.

Sri





On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com> wrote:


                  

                    
I do not see a reason why multiple MN-Id instances need to be present in a
single message ? In my experience, this is strictly a deployment
consideration, when to use what type of identifiers.

Assuming the backend system can tie all the MN-Id's to a single
subscription, any presented identifier can be sufficient for the gateway
to do the BCE lookup.

If multiple instances can be present, then we need to deal with more error
cases. Is that really needed ?




                    

                      
I am wondering if it would not be more appropriate to go for a different
container option to carry such information. Something like a
complementary identifier option.


                    

                    
Sounds interesting. Are you suggesting we leave the current MN-ID as it
is, but use a new complementary option ? But, if the requirement is for a
Mac based identifiers, what will be there in the current MN-Id option ? We
still need to have identifier there ?




Sri





On 9/11/14 2:03 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:



                    

                      
No issue with logical vs. physical ID. But I am wondering about two
things:

Operation is clear to me in case a single MNID is present in a message
and I see the value in being
flexible to choose from different sub-types. If multiple MNIDs with
different sub-types are present in
a single message, which one should e.g. the LMA take for the BC lookup..
No big problem to solve, but
to be considered in implementations.

If the reason for multiple present MNIDs with different sub-types is to
do other things than identifying
the node or using the ID as key for a lookup, I am wondering if it would
not be more appropriate
to go for a different container option to carry such information.
Something like a complementary
identifier option.

marco



                      

                        
-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Agree with that. MN-Id as its defined today is a logical identifier. It
does not
require the identifier to be bound to a physical device or a interface
identity.
But, we have clearly seen requirements where the need is for generating
identifiers based on some physical identifiers. Those physical
identifiers include
IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
source
and the rules for generating MN-ID based using those sources, the sender
and
receiver will have clear guidance on how to use the spec. Some pointers,
explanation and examples for each of those identifiers will greatly help
avoid
inter-op issues.


Regards
Sri







On 9/10/14 3:21 PM, "Charlie Perkins" <charles.perkins@earthlink.net>
wrote:



                        

                          
Hello folks,

I think it's best to consider the MNID as simply living in a space of
identifiers, and not worry too much about whether it's a logical
identifier or a physical identifier.  If the former, then somewhere
(perhaps below the network layer) the logical identifier has been bound
to something in the physical interface, but that's not our problem.

The number space for types of MNIDs is likely to stay pretty empty, so
I'd say we could add as many types as would be convenient for the
software designers.  So, we could conceivably have several MNIDs
defined that all "looked like" NAIs (which, themselves, "look like"
FQDNs).

Regards,
Charlie P.



On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:


                          

                            
Yes. Currently, the MNID is if the nai format and is overloaded. The
MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
IMSI. Ex:
"<IMSI>@epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org²

We also have MAC48@REALM;

We also have approaches to transform MAC to Pseudo IMSI, and then
carry IMSI-NAI as the MN-ID.


So, we need unique sub-types for each of the types/sources.

MN-Id based on IMSI, MSISDN, IMEI, MAC ..

Also, do we need to distinguish between IMSI and IMSI-NAI ?

Sri



On 9/10/14 6:29 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:



                            

                              
It seems the MNID is somehow overloaded to carry both, node-specific
IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
There may be value in adding the IMEI to the list of possible types
of  node-specific IDs.

marco



                              

                                
-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Dienstag, 9. September 2014 23:30
To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Two more comments.



4.) I'd also use sub-type value of (2) for IMSI. Just to align with
the  sub-types  defined for MN Id defined for ICMP. I suspect there
are some  implementations  already using sub-type (2). Please see
the other thread.


5.) For each of the sub-types, we need text including examples and
some
explanation on how they are used.


Sri



On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
wrote:



                                

                                  
Hi Charlie,

This is good. Thanks.


1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
802.2
address, why do we need to two sub-types ? Why not have just one
sub-type for mac based identifiers ?

2.) Sub type value (1) is currently used. Its currently overloaded
for
IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
definition of new sub-types, we need some text explaining the
motivation

3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
is
this ? Are these CGA-based IPv6 addresses ?




                     New Mobile Node Identifier Types

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |
               |                 |                        |
               | IMSI            | 3                      |
               |                 |                        |
               | P-TMSI          | 4                      |
               |                 |                        |
               | EUI-48 address  | 5                      |
               |                 |                        |
               | EUI-64 address  | 6                      |
               |                 |                        |
               | GUTI            | 7                      |
               +-----------------+------------------------+







Regards
Sri
PS: Good to see Vijay back


On 9/9/14 1:28 PM, "Charlie Perkins"
<charles.perkins@earthlink.net>
wrote:



                                  

                                    
Hello folks,

Here's the last Internet Draft that we did, long ago expired:

http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt

I'll resubmit it with a few updates as a personal draft to dmm.

Regards,
Charlie P.


                                  

                                  
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                                

                                
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                              

                            

                          

                        

                      

                    

                    
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                  

                  
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                

                

              

            

          
          

          _______________________________________________

          dmm mailing list

          dmm@ietf.org

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

        

        


          

        

        


        

        
-- 

        

        

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

          
Hakima Chaouchi

          
Professor

          
Telecom Sud Paris

          
Institut Mines Telecom

          
9 rue Charles Fourier

          
91011 Evry

          
0160764443

          

        

      

      

      

      Email secured by Check Point
      

      

    

    

  


--------------040207040805050301060406--


From nobody Thu Sep 25 13:42:44 2014
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 44FB01A036C for ; Thu, 25 Sep 2014 13:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 iZU6I0amMxqG for ; Thu, 25 Sep 2014 13:42:40 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 765131A035A for ; Thu, 25 Sep 2014 13:42:40 -0700 (PDT)
Received: from [107.1.141.74] (helo=[192.168.254.194]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XXFs6-0003Ks-Tn; Thu, 25 Sep 2014 16:42:39 -0400
Message-ID: <54247E3C.7050800@computer.org>
Date: Thu, 25 Sep 2014 13:42:36 -0700
From: "Charles E. Perkins" 
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Sri Gundavelli (sgundave)" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060703090607020505000402"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7a97a29557de588b54ff6719a4a0d3cc8350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/np__YRuf83jPz6KQC4161Als4o4
Cc: Vijay Devarapalli , dmm@ietf.org
Subject: Re: [DMM] MNID Types
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, 25 Sep 2014 20:42:43 -0000

This is a multi-part message in MIME format.
--------------060703090607020505000402
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


Hello Sri,

Is the DoD-96 identifier for a special kind of RFID, or is it
valid for all the RFID devices that would be of interest?

Regards,
Charlie P.


On 9/21/2014 9:59 AM, Sri Gundavelli (sgundave) wrote:
> Hi Hakima,
>
> That is a good idea. We should register a type for the Dod-96 
> identifier as well.
>
>
> Regards
> Sri
>
>
> From: Hakima Chaouchi  >
> Date: Sunday, September 21, 2014 8:11 AM
> To: Sri Gundavelli >
> Cc: Charlie Perkins  >, Marco Liebsch 
> >, 
> "dmm@ietf.org "  >, Vijay Devarapalli  >
> Subject: Re: [DMM] MNID Types
>
> Hello Folks,
>
> Do you think that considering specific but needed technologies for 
> moving objects in  Internet of Things such as RFID (Radio Frequency 
> Identifier) with 96 bits identifiers will be also relevent to 
> Charlie's current draft and the efforts related to MNID?
>
> Regards,
>
> Hakima
>
>
> ------------------------------------------------------------------------
> *De: *"Sri Gundavelli (sgundave)"  >
> *À: *"Charlie Perkins"  >, "Marco Liebsch" 
> >, 
> dmm@ietf.org , "Vijay Devarapalli" 
> >
> *Envoyé: *Jeudi 11 Septembre 2014 23:57:11
> *Objet: *Re: [DMM] MNID Types
>
> Hi Charlie,
>
> Few more reviews/discussions and capturing the consensus in the base 
> version will help. But, I'm ok either way …
>
>
> Regards
> Sri
>
> From: Charlie Perkins  >
> Date: Thursday, September 11, 2014 2:46 PM
> To: Sri Gundavelli >, 
> Marco Liebsch  >, "dmm@ietf.org 
> " >, Vijay 
> Devarapalli >
> Subject: Re: [DMM] MNID Types
>
>
> Hello folks,
>
> I propose to submit the ....-00.txt document as it is to the Internet
> Drafts directory, and then to go about making updates according to
> the discussion on this list.  Do you think this is reasonable?
>
> Regards,
> Charlie P.
>
>
> On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:
>
>     
>
>
>     Marco,
>
>
>     Thinking further on the complementary identifier option.
>
>     - There is already the link-layer identifier option that can be used for
>     carrying the Mac address
>     - IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's
>
>     In some sense, the complementary identifiers are already present.
>
>     Sri
>
>
>
>
>
>     On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)"  wrote:
>
>         I do not see a reason why multiple MN-Id instances need to be present in a
>         single message ? In my experience, this is strictly a deployment
>         consideration, when to use what type of identifiers.
>
>         Assuming the backend system can tie all the MN-Id's to a single
>         subscription, any presented identifier can be sufficient for the gateway
>         to do the BCE lookup.
>
>         If multiple instances can be present, then we need to deal with more error
>         cases. Is that really needed ?
>
>
>             I am wondering if it would not be more appropriate to go for a different
>             container option to carry such information. Something like a
>             complementary identifier option.
>
>         Sounds interesting. Are you suggesting we leave the current MN-ID as it
>         is, but use a new complementary option ? But, if the requirement is for a
>         Mac based identifiers, what will be there in the current MN-Id option ? We
>         still need to have identifier there ?
>
>
>
>
>         Sri
>
>
>
>
>
>         On 9/11/14 2:03 AM, "Marco Liebsch"  wrote:
>
>             No issue with logical vs. physical ID. But I am wondering about two
>             things:
>
>             Operation is clear to me in case a single MNID is present in a message
>             and I see the value in being
>             flexible to choose from different sub-types. If multiple MNIDs with
>             different sub-types are present in
>             a single message, which one should e.g. the LMA take for the BC lookup..
>             No big problem to solve, but
>             to be considered in implementations.
>
>             If the reason for multiple present MNIDs with different sub-types is to
>             do other things than identifying
>             the node or using the ID as key for a lookup, I am wondering if it would
>             not be more appropriate
>             to go for a different container option to carry such information.
>             Something like a complementary
>             identifier option.
>
>             marco
>
>                 -----Original Message-----
>                 From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>                 Sent: Donnerstag, 11. September 2014 00:42
>                 To: Charlie Perkins; Marco Liebsch;dmm@ietf.org
>                 Cc: Vijay Devarapalli
>                 Subject: Re: [DMM] regarding the re-chartering..
>
>                 Hello Charlie,
>
>                 Agree with that. MN-Id as its defined today is a logical identifier. It
>                 does not
>                 require the identifier to be bound to a physical device or a interface
>                 identity.
>                 But, we have clearly seen requirements where the need is for generating
>                 identifiers based on some physical identifiers. Those physical
>                 identifiers include
>                 IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
>                 source
>                 and the rules for generating MN-ID based using those sources, the sender
>                 and
>                 receiver will have clear guidance on how to use the spec. Some pointers,
>                 explanation and examples for each of those identifiers will greatly help
>                 avoid
>                 inter-op issues.
>
>
>                 Regards
>                 Sri
>
>
>
>
>
>
>
>                 On 9/10/14 3:21 PM, "Charlie Perkins"
>                 wrote:
>
>                     Hello folks,
>
>                     I think it's best to consider the MNID as simply living in a space of
>                     identifiers, and not worry too much about whether it's a logical
>                     identifier or a physical identifier.  If the former, then somewhere
>                     (perhaps below the network layer) the logical identifier has been bound
>                     to something in the physical interface, but that's not our problem.
>
>                     The number space for types of MNIDs is likely to stay pretty empty, so
>                     I'd say we could add as many types as would be convenient for the
>                     software designers.  So, we could conceivably have several MNIDs
>                     defined that all "looked like" NAIs (which, themselves, "look like"
>                     FQDNs).
>
>                     Regards,
>                     Charlie P.
>
>
>
>                     On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:
>
>                         Yes. Currently, the MNID is if the nai format and is overloaded. The
>                         MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
>                         IMSI. Ex:
>                         "@epc.mnc.mcc.3gppnetwork.org²
>
>                         We also have MAC48@REALM;
>
>                         We also have approaches to transform MAC to Pseudo IMSI, and then
>                         carry IMSI-NAI as the MN-ID.
>
>
>                         So, we need unique sub-types for each of the types/sources.
>
>                         MN-Id based on IMSI, MSISDN, IMEI, MAC ..
>
>                         Also, do we need to distinguish between IMSI and IMSI-NAI ?
>
>                         Sri
>
>
>
>                         On 9/10/14 6:29 AM, "Marco Liebsch"  wrote:
>
>                             It seems the MNID is somehow overloaded to carry both, node-specific
>                             IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
>                             There may be value in adding the IMEI to the list of possible types
>                             of  node-specific IDs.
>
>                             marco
>
>                                 -----Original Message-----
>                                 From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
>                                 (sgundave)
>                                 Sent: Dienstag, 9. September 2014 23:30
>                                 To: Sri Gundavelli (sgundave); Charlie Perkins;dmm@ietf.org
>                                 Cc: Vijay Devarapalli
>                                 Subject: Re: [DMM] regarding the re-chartering..
>
>                                 Two more comments.
>
>
>
>                                 4.) I'd also use sub-type value of (2) for IMSI. Just to align with
>                                 the  sub-types  defined for MN Id defined for ICMP. I suspect there
>                                 are some  implementations  already using sub-type (2). Please see
>                                 the other thread.
>
>
>                                 5.) For each of the sub-types, we need text including examples and
>                                 some
>                                 explanation on how they are used.
>
>
>                                 Sri
>
>
>
>                                 On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)"
>                                 wrote:
>
>                                     Hi Charlie,
>
>                                     This is good. Thanks.
>
>
>                                     1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
>                                     802.2
>                                     address, why do we need to two sub-types ? Why not have just one
>                                     sub-type for mac based identifiers ?
>
>                                     2.) Sub type value (1) is currently used. Its currently overloaded
>                                     for
>                                     IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
>                                     definition of new sub-types, we need some text explaining the
>                                     motivation
>
>                                     3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
>                                     is
>                                     this ? Are these CGA-based IPv6 addresses ?
>
>
>
>
>                                                           New Mobile Node Identifier Types
>
>                                                     +-----------------+------------------------+
>                                                     | Identifier Type | Identifier Type Number |
>                                                     +-----------------+------------------------+
>                                                     | IPv6 Address    | 2                      |
>                                                     |                 |                        |
>                                                     | IMSI            | 3                      |
>                                                     |                 |                        |
>                                                     | P-TMSI          | 4                      |
>                                                     |                 |                        |
>                                                     | EUI-48 address  | 5                      |
>                                                     |                 |                        |
>                                                     | EUI-64 address  | 6                      |
>                                                     |                 |                        |
>                                                     | GUTI            | 7                      |
>                                                     +-----------------+------------------------+
>
>
>
>
>
>
>
>                                     Regards
>                                     Sri
>                                     PS: Good to see Vijay back
>
>
>                                     On 9/9/14 1:28 PM, "Charlie Perkins"
>                                     
>                                     wrote:
>
>                                         Hello folks,
>
>                                         Here's the last Internet Draft that we did, long ago expired:
>
>                                         http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt
>
>                                         I'll resubmit it with a few updates as a personal draft to dmm.
>
>                                         Regards,
>                                         Charlie P.
>
>                                     _______________________________________________
>                                     dmm mailing list
>                                     dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>                                 _______________________________________________
>                                 dmm mailing list
>                                 dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>         _______________________________________________
>         dmm mailing list
>         dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>     _______________________________________________
>     dmm mailing list
>     dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org 
> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
> -- 
> ---------------------------------
> Hakima Chaouchi
> Professor
> Telecom Sud Paris
> Institut Mines Telecom
> 9 rue Charles Fourier
> 91011 Evry
> 0160764443
>


-- 
Regards,
Charlie P.


--------------060703090607020505000402
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    Hello Sri,

    

    Is the DoD-96 identifier for a special kind of RFID, or is it

    valid for all the RFID devices that would be of interest?

    

    Regards,

    Charlie P.

    

    

    
On 9/21/2014 9:59 AM, Sri Gundavelli
      (sgundave) wrote:

    

    

      
      
Hi Hakima,

      


      

      
That is a good idea. We should register a type for the Dod-96
        identifier as well.

      


      

      


      

      
Regards

      
Sri

      


      

      


      

      
        

          From: Hakima Chaouchi
          <hakima.chaouchi@telecom-sudparis.eu>

          Date: Sunday, September
          21, 2014 8:11 AM

          To: Sri Gundavelli <sgundave@cisco.com>

          Cc: Charlie Perkins
          <charles.perkins@earthlink.net>,
          Marco Liebsch <Marco.Liebsch@neclab.eu>,
          "dmm@ietf.org"
          <dmm@ietf.org>,
          Vijay Devarapalli <dvijay@rocketmail.com>

          Subject: Re: [DMM] MNID
          Types

        

        


        

        

          

            

              
Hello Folks,

              

              


              

              
Do you think that considering specific but needed
                technologies for moving objects in  Internet of Things 
                such as RFID (Radio Frequency Identifier) with 96 bits
                identifiers will be also relevent to Charlie's current
                draft and the efforts related to MNID? 
                

              

              


              

              
Regards,

              

              


              

              
Hakima

              

              


              

              


              

              

              
De:
                "Sri Gundavelli (sgundave)" <sgundave@cisco.com>

                À: "Charlie Perkins" <charles.perkins@earthlink.net>,
                "Marco Liebsch" <Marco.Liebsch@neclab.eu>,
                dmm@ietf.org,
                "Vijay Devarapalli" <dvijay@rocketmail.com>

                Envoyé: Jeudi 11 Septembre 2014 23:57:11

                Objet: Re: [DMM] MNID Types

                


                

                
Hi Charlie,

                


                

                
Few more reviews/discussions and capturing the
                  consensus in the base version will help. But, I'm ok
                  either way …

                


                

                


                

                
Regards

                
Sri

                


                

                
                  

                    From: Charlie
                    Perkins <charles.perkins@earthlink.net>

                    Date: Thursday,
                    September 11, 2014 2:46 PM

                    To: Sri
                    Gundavelli <sgundave@cisco.com>,
                    Marco Liebsch <Marco.Liebsch@neclab.eu>, "dmm@ietf.org" <dmm@ietf.org>, Vijay
                    Devarapalli <dvijay@rocketmail.com>

                    Subject: Re:
                    [DMM] MNID Types

                  

                  


                  

                  

                    


                      Hello folks,

                          

                          I propose to submit the ....-00.txt document
                          as it is to the Internet

                          Drafts directory, and then to go about making
                          updates according to

                          the discussion on this list.  Do you think
                          this is reasonable?

                          

                          Regards,

                          Charlie P.

                          

                        

                      
On 9/11/2014 7:21 AM,
                        Sri Gundavelli (sgundave) wrote:

                      

                      

                        
<Changing the subject line to reflect the MNId discussion>


Marco,


Thinking further on the complementary identifier option.

- There is already the link-layer identifier option that can be used for
carrying the Mac address
- IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's

In some sense, the complementary identifiers are already present.

Sri





On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com> wrote:


                        

                          
I do not see a reason why multiple MN-Id instances need to be present in a
single message ? In my experience, this is strictly a deployment
consideration, when to use what type of identifiers.

Assuming the backend system can tie all the MN-Id's to a single
subscription, any presented identifier can be sufficient for the gateway
to do the BCE lookup.

If multiple instances can be present, then we need to deal with more error
cases. Is that really needed ?




                          

                            
I am wondering if it would not be more appropriate to go for a different
container option to carry such information. Something like a
complementary identifier option.


                          

                          
Sounds interesting. Are you suggesting we leave the current MN-ID as it
is, but use a new complementary option ? But, if the requirement is for a
Mac based identifiers, what will be there in the current MN-Id option ? We
still need to have identifier there ?




Sri





On 9/11/14 2:03 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:



                          

                            
No issue with logical vs. physical ID. But I am wondering about two
things:

Operation is clear to me in case a single MNID is present in a message
and I see the value in being
flexible to choose from different sub-types. If multiple MNIDs with
different sub-types are present in
a single message, which one should e.g. the LMA take for the BC lookup..
No big problem to solve, but
to be considered in implementations.

If the reason for multiple present MNIDs with different sub-types is to
do other things than identifying
the node or using the ID as key for a lookup, I am wondering if it would
not be more appropriate
to go for a different container option to carry such information.
Something like a complementary
identifier option.

marco



                            

                              
-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Agree with that. MN-Id as its defined today is a logical identifier. It
does not
require the identifier to be bound to a physical device or a interface
identity.
But, we have clearly seen requirements where the need is for generating
identifiers based on some physical identifiers. Those physical
identifiers include
IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
source
and the rules for generating MN-ID based using those sources, the sender
and
receiver will have clear guidance on how to use the spec. Some pointers,
explanation and examples for each of those identifiers will greatly help
avoid
inter-op issues.


Regards
Sri







On 9/10/14 3:21 PM, "Charlie Perkins" <charles.perkins@earthlink.net>
wrote:



                              

                                
Hello folks,

I think it's best to consider the MNID as simply living in a space of
identifiers, and not worry too much about whether it's a logical
identifier or a physical identifier.  If the former, then somewhere
(perhaps below the network layer) the logical identifier has been bound
to something in the physical interface, but that's not our problem.

The number space for types of MNIDs is likely to stay pretty empty, so
I'd say we could add as many types as would be convenient for the
software designers.  So, we could conceivably have several MNIDs
defined that all "looked like" NAIs (which, themselves, "look like"
FQDNs).

Regards,
Charlie P.



On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:


                                

                                  
Yes. Currently, the MNID is if the nai format and is overloaded. The
MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
IMSI. Ex:
"<IMSI>@epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org²

We also have MAC48@REALM;

We also have approaches to transform MAC to Pseudo IMSI, and then
carry IMSI-NAI as the MN-ID.


So, we need unique sub-types for each of the types/sources.

MN-Id based on IMSI, MSISDN, IMEI, MAC ..

Also, do we need to distinguish between IMSI and IMSI-NAI ?

Sri



On 9/10/14 6:29 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:



                                  

                                    
It seems the MNID is somehow overloaded to carry both, node-specific
IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
There may be value in adding the IMEI to the list of possible types
of  node-specific IDs.

marco



                                    

                                      
-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Dienstag, 9. September 2014 23:30
To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Two more comments.



4.) I'd also use sub-type value of (2) for IMSI. Just to align with
the  sub-types  defined for MN Id defined for ICMP. I suspect there
are some  implementations  already using sub-type (2). Please see
the other thread.


5.) For each of the sub-types, we need text including examples and
some
explanation on how they are used.


Sri



On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
wrote:



                                      

                                        
Hi Charlie,

This is good. Thanks.


1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
802.2
address, why do we need to two sub-types ? Why not have just one
sub-type for mac based identifiers ?

2.) Sub type value (1) is currently used. Its currently overloaded
for
IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
definition of new sub-types, we need some text explaining the
motivation

3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
is
this ? Are these CGA-based IPv6 addresses ?




                     New Mobile Node Identifier Types

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |
               |                 |                        |
               | IMSI            | 3                      |
               |                 |                        |
               | P-TMSI          | 4                      |
               |                 |                        |
               | EUI-48 address  | 5                      |
               |                 |                        |
               | EUI-64 address  | 6                      |
               |                 |                        |
               | GUTI            | 7                      |
               +-----------------+------------------------+







Regards
Sri
PS: Good to see Vijay back


On 9/9/14 1:28 PM, "Charlie Perkins"
<charles.perkins@earthlink.net>
wrote:



                                        

                                          
Hello folks,

Here's the last Internet Draft that we did, long ago expired:

http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt

I'll resubmit it with a few updates as a personal draft to dmm.

Regards,
Charlie P.


                                        

                                        
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                                      

                                      
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                                    

                                  

                                

                              

                            

                          

                          
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                        

                        
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                      

                      

                    

                  

                

                _______________________________________________

                dmm mailing list

                dmm@ietf.org

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

              

              


                

              

              


              

              
-- 

              

              

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

                
Hakima Chaouchi

                
Professor

                
Telecom Sud Paris

                
Institut Mines Telecom

                
9 rue Charles Fourier

                
91011 Evry

                
0160764443

                

              

            

          

        

      
    

    

    

    
-- 
Regards,
Charlie P.

  


--------------060703090607020505000402--


From nobody Thu Sep 25 14:00:21 2014
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 B80DA1A0371 for ; Thu, 25 Sep 2014 14:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 tkBunjZ4aFGQ for ; Thu, 25 Sep 2014 14:00:16 -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 E04271A0351 for ; Thu, 25 Sep 2014 14:00:15 -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 s8PL0FOf011938; Thu, 25 Sep 2014 14:00:15 -0700
Received: from XCH-BLV-106.nw.nos.boeing.com (xch-blv-106.nw.nos.boeing.com [130.247.25.122]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8PL06nY011640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 25 Sep 2014 14:00:07 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-106.nw.nos.boeing.com ([169.254.6.171]) with mapi id 14.03.0181.006; Thu, 25 Sep 2014 14:00:06 -0700
From: "Templin, Fred L" 
To: "Charles E. Perkins" , "Sri Gundavelli (sgundave)" 
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHP2QFRBFXGK7SLlEqDWEHLMXPWTJwSUuCw
Date: Thu, 25 Sep 2014 21:00:05 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D27B1E@XCH-BLV-504.nw.nos.boeing.com>
References:  <54247E3C.7050800@computer.org>
In-Reply-To: <54247E3C.7050800@computer.org>
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_2134F8430051B64F815C691A62D9831832D27B1EXCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/5Zq5ezfVML1SaWnibTUvb1S9nQk
Cc: Vijay Devarapalli , "dmm@ietf.org" 
Subject: Re: [DMM] MNID Types
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, 25 Sep 2014 21:00:20 -0000

--_000_2134F8430051B64F815C691A62D9831832D27B1EXCHBLV504nwnosb_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQ2hhcmxpZSwNCg0KSSBhbSBpbnRlcmVzdGVkIGluIG5vZGUgSURzIHRoYXQgY2FuIGJlIHJl
cHJlc2VudGVkIGluIGEgREhDUHY2IERVSUQuIFRoZXJlIGlzDQpSRkM2MzU1IHdoaWNoIGVuY29k
ZXMgYSBub2RlIElEIGJhc2VkIG9uIERVSUQtVVVJRCAoVW5pdmVyc2FsbHkgVW5pcXVlDQpJRGVu
dGlmaWVyKS4gQUZBSUNULCB0aGUgVVVJRCBpcyBhIDEyOC1iaXQgY29udGFpbmVyIGZvcm1hdHRl
ZCBwZXIgUkZDNDEyMg0Kc3BlY2lmaWNhdGlvbnMgdGhhdCBpbmNsdWRlcyBhIHRpbWUgcG9ydGlv
biBhbmQgYSBub2RlIElEIHBvcnRpb24uIEFueSBjaGFuY2UNCnRoaXMgd291bGQgc2F0aXNmeSB3
aGF0IHlvdSBhcmUgbG9va2luZyBmb3I/DQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogZG1tIFtt
YWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaGFybGVzIEUuIFBlcmtp
bnMNClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQgMTo0MyBQTQ0KVG86IFNyaSBH
dW5kYXZlbGxpIChzZ3VuZGF2ZSkNCkNjOiBWaWpheSBEZXZhcmFwYWxsaTsgZG1tQGlldGYub3Jn
DQpTdWJqZWN0OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0KDQoNCkhlbGxvIFNyaSwNCg0KSXMgdGhl
IERvRC05NiBpZGVudGlmaWVyIGZvciBhIHNwZWNpYWwga2luZCBvZiBSRklELCBvciBpcyBpdA0K
dmFsaWQgZm9yIGFsbCB0aGUgUkZJRCBkZXZpY2VzIHRoYXQgd291bGQgYmUgb2YgaW50ZXJlc3Q/
DQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCk9uIDkvMjEvMjAxNCA5OjU5IEFNLCBTcmkgR3Vu
ZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0KSGkgSGFraW1hLA0KDQpUaGF0IGlzIGEgZ29vZCBp
ZGVhLiBXZSBzaG91bGQgcmVnaXN0ZXIgYSB0eXBlIGZvciB0aGUgRG9kLTk2IGlkZW50aWZpZXIg
YXMgd2VsbC4NCg0KDQpSZWdhcmRzDQpTcmkNCg0KDQpGcm9tOiBIYWtpbWEgQ2hhb3VjaGkgPGhh
a2ltYS5jaGFvdWNoaUB0ZWxlY29tLXN1ZHBhcmlzLmV1PG1haWx0bzpoYWtpbWEuY2hhb3VjaGlA
dGVsZWNvbS1zdWRwYXJpcy5ldT4+DQpEYXRlOiBTdW5kYXksIFNlcHRlbWJlciAyMSwgMjAxNCA4
OjExIEFNDQpUbzogU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1
bmRhdmVAY2lzY28uY29tPj4NCkNjOiBDaGFybGllIFBlcmtpbnMgPGNoYXJsZXMucGVya2luc0Bl
YXJ0aGxpbmsubmV0PG1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4+LCBNYXJj
byBMaWVic2NoIDxNYXJjby5MaWVic2NoQG5lY2xhYi5ldTxtYWlsdG86TWFyY28uTGllYnNjaEBu
ZWNsYWIuZXU+PiwgImRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiIgPGRtbUBpZXRm
Lm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPj4sIFZpamF5IERldmFyYXBhbGxpIDxkdmlqYXlAcm9j
a2V0bWFpbC5jb208bWFpbHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTog
W0RNTV0gTU5JRCBUeXBlcw0KDQpIZWxsbyBGb2xrcywNCg0KRG8geW91IHRoaW5rIHRoYXQgY29u
c2lkZXJpbmcgc3BlY2lmaWMgYnV0IG5lZWRlZCB0ZWNobm9sb2dpZXMgZm9yIG1vdmluZyBvYmpl
Y3RzIGluICBJbnRlcm5ldCBvZiBUaGluZ3MgIHN1Y2ggYXMgUkZJRCAoUmFkaW8gRnJlcXVlbmN5
IElkZW50aWZpZXIpIHdpdGggOTYgYml0cyBpZGVudGlmaWVycyB3aWxsIGJlIGFsc28gcmVsZXZl
bnQgdG8gQ2hhcmxpZSdzIGN1cnJlbnQgZHJhZnQgYW5kIHRoZSBlZmZvcnRzIHJlbGF0ZWQgdG8g
TU5JRD8NCg0KUmVnYXJkcywNCg0KSGFraW1hDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCkRlOiAiU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSIgPHNndW5kYXZlQGNpc2Nv
LmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4NCsOAOiAiQ2hhcmxpZSBQZXJraW5zIiA8
Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0
aGxpbmsubmV0Pj4sICJNYXJjbyBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8bWFp
bHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1Pj4sIGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGll
dGYub3JnPiwgIlZpamF5IERldmFyYXBhbGxpIiA8ZHZpamF5QHJvY2tldG1haWwuY29tPG1haWx0
bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20+Pg0KRW52b3nDqTogSmV1ZGkgMTEgU2VwdGVtYnJlIDIw
MTQgMjM6NTc6MTENCk9iamV0OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0KDQpIaSBDaGFybGllLA0K
DQpGZXcgbW9yZSByZXZpZXdzL2Rpc2N1c3Npb25zIGFuZCBjYXB0dXJpbmcgdGhlIGNvbnNlbnN1
cyBpbiB0aGUgYmFzZSB2ZXJzaW9uIHdpbGwgaGVscC4gQnV0LCBJJ20gb2sgZWl0aGVyIHdheSDi
gKYNCg0KDQpSZWdhcmRzDQpTcmkNCg0KRnJvbTogQ2hhcmxpZSBQZXJraW5zIDxjaGFybGVzLnBl
cmtpbnNAZWFydGhsaW5rLm5ldDxtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+
Pg0KRGF0ZTogVGh1cnNkYXksIFNlcHRlbWJlciAxMSwgMjAxNCAyOjQ2IFBNDQpUbzogU3JpIEd1
bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4s
IE1hcmNvIExpZWJzY2ggPE1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PG1haWx0bzpNYXJjby5MaWVi
c2NoQG5lY2xhYi5ldT4+LCAiZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+IiA8ZG1t
QGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+PiwgVmlqYXkgRGV2YXJhcGFsbGkgPGR2aWph
eUByb2NrZXRtYWlsLmNvbTxtYWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29tPj4NClN1YmplY3Q6
IFJlOiBbRE1NXSBNTklEIFR5cGVzDQoNCg0KSGVsbG8gZm9sa3MsDQoNCkkgcHJvcG9zZSB0byBz
dWJtaXQgdGhlIC4uLi4tMDAudHh0IGRvY3VtZW50IGFzIGl0IGlzIHRvIHRoZSBJbnRlcm5ldA0K
RHJhZnRzIGRpcmVjdG9yeSwgYW5kIHRoZW4gdG8gZ28gYWJvdXQgbWFraW5nIHVwZGF0ZXMgYWNj
b3JkaW5nIHRvDQp0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3QuICBEbyB5b3UgdGhpbmsgdGhp
cyBpcyByZWFzb25hYmxlPw0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCk9uIDkvMTEvMjAx
NCA3OjIxIEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0KDQo8Q2hhbmdpbmcg
dGhlIHN1YmplY3QgbGluZSB0byByZWZsZWN0IHRoZSBNTklkIGRpc2N1c3Npb24+DQoNCg0KDQoN
Cg0KTWFyY28sDQoNCg0KDQoNCg0KVGhpbmtpbmcgZnVydGhlciBvbiB0aGUgY29tcGxlbWVudGFy
eSBpZGVudGlmaWVyIG9wdGlvbi4NCg0KDQoNCi0gVGhlcmUgaXMgYWxyZWFkeSB0aGUgbGluay1s
YXllciBpZGVudGlmaWVyIG9wdGlvbiB0aGF0IGNhbiBiZSB1c2VkIGZvcg0KDQpjYXJyeWluZyB0
aGUgTWFjIGFkZHJlc3MNCg0KLSBJTUVJIGFuZCBNU0lTRE4gYXJlIGFscmVhZHkgZGVmaW5lZCBp
biAyOS4yNzUgYXMgYSAzR1BQIFZTRSdzDQoNCg0KDQpJbiBzb21lIHNlbnNlLCB0aGUgY29tcGxl
bWVudGFyeSBpZGVudGlmaWVycyBhcmUgYWxyZWFkeSBwcmVzZW50Lg0KDQoNCg0KU3JpDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KT24gOS8xMS8xNCA2OjU4IEFNLCAiU3JpIEd1bmRhdmVsbGkgKHNn
dW5kYXZlKSIgPHNndW5kYXZlQGNpc2NvLmNvbT48bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbT4g
d3JvdGU6DQoNCkkgZG8gbm90IHNlZSBhIHJlYXNvbiB3aHkgbXVsdGlwbGUgTU4tSWQgaW5zdGFu
Y2VzIG5lZWQgdG8gYmUgcHJlc2VudCBpbiBhDQoNCnNpbmdsZSBtZXNzYWdlID8gSW4gbXkgZXhw
ZXJpZW5jZSwgdGhpcyBpcyBzdHJpY3RseSBhIGRlcGxveW1lbnQNCg0KY29uc2lkZXJhdGlvbiwg
d2hlbiB0byB1c2Ugd2hhdCB0eXBlIG9mIGlkZW50aWZpZXJzLg0KDQoNCg0KQXNzdW1pbmcgdGhl
IGJhY2tlbmQgc3lzdGVtIGNhbiB0aWUgYWxsIHRoZSBNTi1JZCdzIHRvIGEgc2luZ2xlDQoNCnN1
YnNjcmlwdGlvbiwgYW55IHByZXNlbnRlZCBpZGVudGlmaWVyIGNhbiBiZSBzdWZmaWNpZW50IGZv
ciB0aGUgZ2F0ZXdheQ0KDQp0byBkbyB0aGUgQkNFIGxvb2t1cC4NCg0KDQoNCklmIG11bHRpcGxl
IGluc3RhbmNlcyBjYW4gYmUgcHJlc2VudCwgdGhlbiB3ZSBuZWVkIHRvIGRlYWwgd2l0aCBtb3Jl
IGVycm9yDQoNCmNhc2VzLiBJcyB0aGF0IHJlYWxseSBuZWVkZWQgPw0KDQoNCg0KDQoNCkkgYW0g
d29uZGVyaW5nIGlmIGl0IHdvdWxkIG5vdCBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIGdvIGZvciBh
IGRpZmZlcmVudA0KDQpjb250YWluZXIgb3B0aW9uIHRvIGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24u
IFNvbWV0aGluZyBsaWtlIGENCg0KY29tcGxlbWVudGFyeSBpZGVudGlmaWVyIG9wdGlvbi4NCg0K
U291bmRzIGludGVyZXN0aW5nLiBBcmUgeW91IHN1Z2dlc3Rpbmcgd2UgbGVhdmUgdGhlIGN1cnJl
bnQgTU4tSUQgYXMgaXQNCg0KaXMsIGJ1dCB1c2UgYSBuZXcgY29tcGxlbWVudGFyeSBvcHRpb24g
PyBCdXQsIGlmIHRoZSByZXF1aXJlbWVudCBpcyBmb3IgYQ0KDQpNYWMgYmFzZWQgaWRlbnRpZmll
cnMsIHdoYXQgd2lsbCBiZSB0aGVyZSBpbiB0aGUgY3VycmVudCBNTi1JZCBvcHRpb24gPyBXZQ0K
DQpzdGlsbCBuZWVkIHRvIGhhdmUgaWRlbnRpZmllciB0aGVyZSA/DQoNCg0KDQoNCg0KDQoNCg0K
DQpTcmkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiA5LzExLzE0IDI6MDMgQU0sICJNYXJjbyBM
aWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PG1haWx0bzpNYXJjby5MaWVic2NoQG5l
Y2xhYi5ldT4gd3JvdGU6DQoNCg0KDQpObyBpc3N1ZSB3aXRoIGxvZ2ljYWwgdnMuIHBoeXNpY2Fs
IElELiBCdXQgSSBhbSB3b25kZXJpbmcgYWJvdXQgdHdvDQoNCnRoaW5nczoNCg0KDQoNCk9wZXJh
dGlvbiBpcyBjbGVhciB0byBtZSBpbiBjYXNlIGEgc2luZ2xlIE1OSUQgaXMgcHJlc2VudCBpbiBh
IG1lc3NhZ2UNCg0KYW5kIEkgc2VlIHRoZSB2YWx1ZSBpbiBiZWluZw0KDQpmbGV4aWJsZSB0byBj
aG9vc2UgZnJvbSBkaWZmZXJlbnQgc3ViLXR5cGVzLiBJZiBtdWx0aXBsZSBNTklEcyB3aXRoDQoN
CmRpZmZlcmVudCBzdWItdHlwZXMgYXJlIHByZXNlbnQgaW4NCg0KYSBzaW5nbGUgbWVzc2FnZSwg
d2hpY2ggb25lIHNob3VsZCBlLmcuIHRoZSBMTUEgdGFrZSBmb3IgdGhlIEJDIGxvb2t1cC4uDQoN
Ck5vIGJpZyBwcm9ibGVtIHRvIHNvbHZlLCBidXQNCg0KdG8gYmUgY29uc2lkZXJlZCBpbiBpbXBs
ZW1lbnRhdGlvbnMuDQoNCg0KDQpJZiB0aGUgcmVhc29uIGZvciBtdWx0aXBsZSBwcmVzZW50IE1O
SURzIHdpdGggZGlmZmVyZW50IHN1Yi10eXBlcyBpcyB0bw0KDQpkbyBvdGhlciB0aGluZ3MgdGhh
biBpZGVudGlmeWluZw0KDQp0aGUgbm9kZSBvciB1c2luZyB0aGUgSUQgYXMga2V5IGZvciBhIGxv
b2t1cCwgSSBhbSB3b25kZXJpbmcgaWYgaXQgd291bGQNCg0Kbm90IGJlIG1vcmUgYXBwcm9wcmlh
dGUNCg0KdG8gZ28gZm9yIGEgZGlmZmVyZW50IGNvbnRhaW5lciBvcHRpb24gdG8gY2Fycnkgc3Vj
aCBpbmZvcm1hdGlvbi4NCg0KU29tZXRoaW5nIGxpa2UgYSBjb21wbGVtZW50YXJ5DQoNCmlkZW50
aWZpZXIgb3B0aW9uLg0KDQoNCg0KbWFyY28NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQoNCkZyb206IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgW21haWx0bzpzZ3VuZGF2ZUBj
aXNjby5jb21dDQoNClNlbnQ6IERvbm5lcnN0YWcsIDExLiBTZXB0ZW1iZXIgMjAxNCAwMDo0Mg0K
DQpUbzogQ2hhcmxpZSBQZXJraW5zOyBNYXJjbyBMaWVic2NoOyBkbW1AaWV0Zi5vcmc8bWFpbHRv
OmRtbUBpZXRmLm9yZz4NCg0KQ2M6IFZpamF5IERldmFyYXBhbGxpDQoNClN1YmplY3Q6IFJlOiBb
RE1NXSByZWdhcmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLg0KDQoNCg0KSGVsbG8gQ2hhcmxpZSwN
Cg0KDQoNCkFncmVlIHdpdGggdGhhdC4gTU4tSWQgYXMgaXRzIGRlZmluZWQgdG9kYXkgaXMgYSBs
b2dpY2FsIGlkZW50aWZpZXIuIEl0DQoNCmRvZXMgbm90DQoNCnJlcXVpcmUgdGhlIGlkZW50aWZp
ZXIgdG8gYmUgYm91bmQgdG8gYSBwaHlzaWNhbCBkZXZpY2Ugb3IgYSBpbnRlcmZhY2UNCg0KaWRl
bnRpdHkuDQoNCkJ1dCwgd2UgaGF2ZSBjbGVhcmx5IHNlZW4gcmVxdWlyZW1lbnRzIHdoZXJlIHRo
ZSBuZWVkIGlzIGZvciBnZW5lcmF0aW5nDQoNCmlkZW50aWZpZXJzIGJhc2VkIG9uIHNvbWUgcGh5
c2ljYWwgaWRlbnRpZmllcnMuIFRob3NlIHBoeXNpY2FsDQoNCmlkZW50aWZpZXJzIGluY2x1ZGUN
Cg0KSU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi5ldGMuIElmIHdlIGNhbiBkZWZpbmUgYSB0eXBl
IGZvciBlYWNoIG9mIHRoZQ0KDQpzb3VyY2UNCg0KYW5kIHRoZSBydWxlcyBmb3IgZ2VuZXJhdGlu
ZyBNTi1JRCBiYXNlZCB1c2luZyB0aG9zZSBzb3VyY2VzLCB0aGUgc2VuZGVyDQoNCmFuZA0KDQpy
ZWNlaXZlciB3aWxsIGhhdmUgY2xlYXIgZ3VpZGFuY2Ugb24gaG93IHRvIHVzZSB0aGUgc3BlYy4g
U29tZSBwb2ludGVycywNCg0KZXhwbGFuYXRpb24gYW5kIGV4YW1wbGVzIGZvciBlYWNoIG9mIHRo
b3NlIGlkZW50aWZpZXJzIHdpbGwgZ3JlYXRseSBoZWxwDQoNCmF2b2lkDQoNCmludGVyLW9wIGlz
c3Vlcy4NCg0KDQoNCg0KDQpSZWdhcmRzDQoNClNyaQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KT24gOS8xMC8xNCAzOjIxIFBNLCAiQ2hhcmxpZSBQZXJraW5zIiA8Y2hhcmxlcy5wZXJr
aW5zQGVhcnRobGluay5uZXQ+PG1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4N
Cg0Kd3JvdGU6DQoNCg0KDQpIZWxsbyBmb2xrcywNCg0KDQoNCkkgdGhpbmsgaXQncyBiZXN0IHRv
IGNvbnNpZGVyIHRoZSBNTklEIGFzIHNpbXBseSBsaXZpbmcgaW4gYSBzcGFjZSBvZg0KDQppZGVu
dGlmaWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVjaCBhYm91dCB3aGV0aGVyIGl0J3MgYSBsb2dp
Y2FsDQoNCmlkZW50aWZpZXIgb3IgYSBwaHlzaWNhbCBpZGVudGlmaWVyLiAgSWYgdGhlIGZvcm1l
ciwgdGhlbiBzb21ld2hlcmUNCg0KKHBlcmhhcHMgYmVsb3cgdGhlIG5ldHdvcmsgbGF5ZXIpIHRo
ZSBsb2dpY2FsIGlkZW50aWZpZXIgaGFzIGJlZW4gYm91bmQNCg0KdG8gc29tZXRoaW5nIGluIHRo
ZSBwaHlzaWNhbCBpbnRlcmZhY2UsIGJ1dCB0aGF0J3Mgbm90IG91ciBwcm9ibGVtLg0KDQoNCg0K
VGhlIG51bWJlciBzcGFjZSBmb3IgdHlwZXMgb2YgTU5JRHMgaXMgbGlrZWx5IHRvIHN0YXkgcHJl
dHR5IGVtcHR5LCBzbw0KDQpJJ2Qgc2F5IHdlIGNvdWxkIGFkZCBhcyBtYW55IHR5cGVzIGFzIHdv
dWxkIGJlIGNvbnZlbmllbnQgZm9yIHRoZQ0KDQpzb2Z0d2FyZSBkZXNpZ25lcnMuICBTbywgd2Ug
Y291bGQgY29uY2VpdmFibHkgaGF2ZSBzZXZlcmFsIE1OSURzDQoNCmRlZmluZWQgdGhhdCBhbGwg
Imxvb2tlZCBsaWtlIiBOQUlzICh3aGljaCwgdGhlbXNlbHZlcywgImxvb2sgbGlrZSINCg0KRlFE
TnMpLg0KDQoNCg0KUmVnYXJkcywNCg0KQ2hhcmxpZSBQLg0KDQoNCg0KDQoNCg0KDQpPbiA5LzEw
LzIwMTQgODoxMSBBTSwgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSB3cm90ZToNCg0KWWVzLiBD
dXJyZW50bHksIHRoZSBNTklEIGlzIGlmIHRoZSBuYWkgZm9ybWF0IGFuZCBpcyBvdmVybG9hZGVk
LiBUaGUNCg0KTU5JRCAgaW4gM0dQUCBzcGVjcyBpcyB0aGUgSU1TSS1OQUkgKElNU0lAUkVBTE0p
LCBpdHMgYmFzZWQgb24gdGhlDQoNCklNU0kuIEV4Og0KDQoiPElNU0k+QGVwYy5tbmM8TU5DPi5t
Y2M8TUNDPi4zZ3BwbmV0d29yay5vcmfCsg0KDQoNCg0KV2UgYWxzbyBoYXZlIE1BQzQ4QFJFQUxN
Ow0KDQoNCg0KV2UgYWxzbyBoYXZlIGFwcHJvYWNoZXMgdG8gdHJhbnNmb3JtIE1BQyB0byBQc2V1
ZG8gSU1TSSwgYW5kIHRoZW4NCg0KY2FycnkgSU1TSS1OQUkgYXMgdGhlIE1OLUlELg0KDQoNCg0K
DQoNClNvLCB3ZSBuZWVkIHVuaXF1ZSBzdWItdHlwZXMgZm9yIGVhY2ggb2YgdGhlIHR5cGVzL3Nv
dXJjZXMuDQoNCg0KDQpNTi1JZCBiYXNlZCBvbiBJTVNJLCBNU0lTRE4sIElNRUksIE1BQyAuLg0K
DQoNCg0KQWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElNU0kgYW5kIElN
U0ktTkFJID8NCg0KDQoNClNyaQ0KDQoNCg0KDQoNCg0KDQpPbiA5LzEwLzE0IDY6MjkgQU0sICJN
YXJjbyBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PG1haWx0bzpNYXJjby5MaWVi
c2NoQG5lY2xhYi5ldT4gd3JvdGU6DQoNCg0KDQpJdCBzZWVtcyB0aGUgTU5JRCBpcyBzb21laG93
IG92ZXJsb2FkZWQgdG8gY2FycnkgYm90aCwgbm9kZS1zcGVjaWZpYw0KDQpJRHMsICBlLmcuIE1B
QywgYXMgd2VsbCBhcyBzdWJzY3JpYmVyIElEcywgd2hpY2ggaXMgdGhlIElNU0kuDQoNClRoZXJl
IG1heSBiZSB2YWx1ZSBpbiBhZGRpbmcgdGhlIElNRUkgdG8gdGhlIGxpc3Qgb2YgcG9zc2libGUg
dHlwZXMNCg0Kb2YgIG5vZGUtc3BlY2lmaWMgSURzLg0KDQoNCg0KbWFyY28NCg0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgU3JpIEd1bmRhdmVsbGkNCg0KKHNndW5kYXZlKQ0KDQpTZW50
OiBEaWVuc3RhZywgOS4gU2VwdGVtYmVyIDIwMTQgMjM6MzANCg0KVG86IFNyaSBHdW5kYXZlbGxp
IChzZ3VuZGF2ZSk7IENoYXJsaWUgUGVya2luczsgZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0
Zi5vcmc+DQoNCkNjOiBWaWpheSBEZXZhcmFwYWxsaQ0KDQpTdWJqZWN0OiBSZTogW0RNTV0gcmVn
YXJkaW5nIHRoZSByZS1jaGFydGVyaW5nLi4NCg0KDQoNClR3byBtb3JlIGNvbW1lbnRzLg0KDQoN
Cg0KDQoNCg0KDQo0LikgSSdkIGFsc28gdXNlIHN1Yi10eXBlIHZhbHVlIG9mICgyKSBmb3IgSU1T
SS4gSnVzdCB0byBhbGlnbiB3aXRoDQoNCnRoZSAgc3ViLXR5cGVzICBkZWZpbmVkIGZvciBNTiBJ
ZCBkZWZpbmVkIGZvciBJQ01QLiBJIHN1c3BlY3QgdGhlcmUNCg0KYXJlIHNvbWUgIGltcGxlbWVu
dGF0aW9ucyAgYWxyZWFkeSB1c2luZyBzdWItdHlwZSAoMikuIFBsZWFzZSBzZWUNCg0KdGhlIG90
aGVyIHRocmVhZC4NCg0KDQoNCg0KDQo1LikgRm9yIGVhY2ggb2YgdGhlIHN1Yi10eXBlcywgd2Ug
bmVlZCB0ZXh0IGluY2x1ZGluZyBleGFtcGxlcyBhbmQNCg0Kc29tZQ0KDQpleHBsYW5hdGlvbiBv
biBob3cgdGhleSBhcmUgdXNlZC4NCg0KDQoNCg0KDQpTcmkNCg0KDQoNCg0KDQoNCg0KT24gOS85
LzE0IDI6MjAgUE0sICJTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIiA8c2d1bmRhdmVAY2lzY28u
Y29tPjxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPg0KDQp3cm90ZToNCg0KDQoNCkhpIENoYXJs
aWUsDQoNCg0KDQpUaGlzIGlzIGdvb2QuIFRoYW5rcy4NCg0KDQoNCg0KDQoxLikgSWYgRVVJLTQ4
IGFuZCBFVUktNjQgYWRkcmVzc2VzIGFyZSBkZXJpdmVkIG9mIGEgNDgtYml0IElFRUUNCg0KODAy
LjINCg0KYWRkcmVzcywgd2h5IGRvIHdlIG5lZWQgdG8gdHdvIHN1Yi10eXBlcyA/IFdoeSBub3Qg
aGF2ZSBqdXN0IG9uZQ0KDQpzdWItdHlwZSBmb3IgbWFjIGJhc2VkIGlkZW50aWZpZXJzID8NCg0K
DQoNCjIuKSBTdWIgdHlwZSB2YWx1ZSAoMSkgaXMgY3VycmVudGx5IHVzZWQuIEl0cyBjdXJyZW50
bHkgb3ZlcmxvYWRlZA0KDQpmb3INCg0KSU1TSS1OQUkgKDNHUFAgc3BlY3MpIGFuZCBnZW5lcmlj
IE5BSSBiYXNlZCBpZGVudGlmaWVycy4gR2l2ZW4gdGhlDQoNCmRlZmluaXRpb24gb2YgbmV3IHN1
Yi10eXBlcywgd2UgbmVlZCBzb21lIHRleHQgZXhwbGFpbmluZyB0aGUNCg0KbW90aXZhdGlvbg0K
DQoNCg0KMy4pIFByb3Bvc2VkIFN1Yi10eXBlIHZhbHVlIG9mICgyKSBmb3IgSVB2NiBhZGRyZXNz
LiBXaGF0IGV4YWN0bHkNCg0KaXMNCg0KdGhpcyA/IEFyZSB0aGVzZSBDR0EtYmFzZWQgSVB2NiBh
ZGRyZXNzZXMgPw0KDQoNCg0KDQoNCg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgTmV3IE1v
YmlsZSBOb2RlIElkZW50aWZpZXIgVHlwZXMNCg0KDQoNCiAgICAgICAgICAgICAgICstLS0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgIHwg
SWRlbnRpZmllciBUeXBlIHwgSWRlbnRpZmllciBUeXBlIE51bWJlciB8DQoNCiAgICAgICAgICAg
ICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAg
ICAgICAgICAgIHwgSVB2NiBBZGRyZXNzICAgIHwgMiAgICAgICAgICAgICAgICAgICAgICB8DQoN
CiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg
ICB8DQoNCiAgICAgICAgICAgICAgIHwgSU1TSSAgICAgICAgICAgIHwgMyAgICAgICAgICAgICAg
ICAgICAgICB8DQoNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAg
ICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgIHwgUC1UTVNJICAgICAgICAgIHwgNCAg
ICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg
IHwgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgIHwgRVVJLTQ4IGFk
ZHJlc3MgIHwgNSAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgIHwgICAg
ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAg
IHwgRVVJLTY0IGFkZHJlc3MgIHwgNiAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAg
ICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAg
ICAgICAgICAgICAgIHwgR1VUSSAgICAgICAgICAgIHwgNyAgICAgICAgICAgICAgICAgICAgICB8
DQoNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0rDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSZWdhcmRzDQoNClNyaQ0KDQpQ
UzogR29vZCB0byBzZWUgVmlqYXkgYmFjaw0KDQoNCg0KDQoNCk9uIDkvOS8xNCAxOjI4IFBNLCAi
Q2hhcmxpZSBQZXJraW5zIg0KDQo8Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+PG1haWx0
bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4NCg0Kd3JvdGU6DQoNCg0KDQpIZWxsbyBm
b2xrcywNCg0KDQoNCkhlcmUncyB0aGUgbGFzdCBJbnRlcm5ldCBEcmFmdCB0aGF0IHdlIGRpZCwg
bG9uZyBhZ28gZXhwaXJlZDoNCg0KDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9k
cmFmdC1wZXJraW5zLW1leHQtNDI4M21uaWRzLTAxLnR4dA0KDQoNCg0KSSdsbCByZXN1Ym1pdCBp
dCB3aXRoIGEgZmV3IHVwZGF0ZXMgYXMgYSBwZXJzb25hbCBkcmFmdCB0byBkbW0uDQoNCg0KDQpS
ZWdhcmRzLA0KDQpDaGFybGllIFAuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNCmRtbSBtYWlsaW5nIGxpc3QNCg0KZG1tQGlldGYub3JnPG1haWx0
bzpkbW1AaWV0Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0N
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KZG1t
IG1haWxpbmcgbGlzdA0KDQpkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpkbW0gbWFpbGluZyBsaXN0DQoNCmRtbUBp
ZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZG1tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCmRtbSBtYWlsaW5nIGxpc3QNCg0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0
Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcg
bGlzdA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCkhha2ltYSBDaGFvdWNoaQ0KUHJvZmVzc29yDQpUZWxlY29tIFN1ZCBQYXJp
cw0KSW5zdGl0dXQgTWluZXMgVGVsZWNvbQ0KOSBydWUgQ2hhcmxlcyBGb3VyaWVyDQo5MTAxMSBF
dnJ5DQowMTYwNzY0NDQzDQoNCg0KDQoNCg0KLS0NCg0KUmVnYXJkcywNCg0KQ2hhcmxpZSBQLg0K

--_000_2134F8430051B64F815C691A62D9831832D27B1EXCHBLV504nwnosb_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnBy
ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y
bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj
azt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K
CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN
Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh
bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0
ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M
IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0K
c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u
QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K
CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQouTXNv
Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu
MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46
MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMi
IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5IaSBDaGFybGllLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBpbnRlcmVzdGVkIGluIG5vZGUgSURz
IHRoYXQgY2FuIGJlIHJlcHJlc2VudGVkIGluIGEgREhDUHY2IERVSUQuIFRoZXJlIGlzPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJGQzYzNTUgd2hpY2ggZW5jb2RlcyBhIG5vZGUgSUQg
YmFzZWQgb24gRFVJRC1VVUlEIChVbml2ZXJzYWxseSBVbmlxdWU8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+SURlbnRpZmllcikuIEFGQUlDVCwgdGhlIFVVSUQgaXMgYSAxMjgtYml0IGNv
bnRhaW5lciBmb3JtYXR0ZWQgcGVyIFJGQzQxMjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+c3BlY2lmaWNhdGlvbnMgdGhhdCBpbmNsdWRlcyBhIHRpbWUgcG9ydGlvbiBhbmQgYSBub2Rl
IElEIHBvcnRpb24uIEFueSBjaGFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dGhp
cyB3b3VsZCBzYXRpc2Z5IHdoYXQgeW91IGFyZSBsb29raW5nIGZvcj88bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5r
cyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1
ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw
aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGll
dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaGFybGVzIEUuIFBlcmtpbnM8YnI+DQo8Yj5T
ZW50OjwvYj4gVGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAxNCAxOjQzIFBNPGJyPg0KPGI+VG86
PC9iPiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpPGJyPg0KPGI+Q2M6PC9iPiBWaWpheSBEZXZh
cmFwYWxsaTsgZG1tQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRE1NXSBNTklE
IFR5cGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpIZWxsbyBTcmksPGJyPg0KPGJyPg0KSXMg
dGhlIERvRC05NiBpZGVudGlmaWVyIGZvciBhIHNwZWNpYWwga2luZCBvZiBSRklELCBvciBpcyBp
dDxicj4NCnZhbGlkIGZvciBhbGwgdGhlIFJGSUQgZGV2aWNlcyB0aGF0IHdvdWxkIGJlIG9mIGlu
dGVyZXN0Pzxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KQ2hhcmxpZSBQLjxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDkvMjEvMjAxNCA5
OjU5IEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBIYWtpbWEsPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgYSBn
b29kIGlkZWEuIFdlIHNob3VsZCByZWdpc3RlciBhIHR5cGUgZm9yIHRoZSBEb2QtOTYgaWRlbnRp
ZmllciBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlNyaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkhha2ltYSBDaGFvdWNoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhha2ltYS5jaGFvdWNoaUB0
ZWxlY29tLXN1ZHBhcmlzLmV1Ij5oYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJpcy5ldTwv
YT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlN1bmRheSwgU2VwdGVtYmVyIDIxLCAyMDE0IDg6MTEg
QU08YnI+DQo8Yj5UbzogPC9iPlNyaSBHdW5kYXZlbGxpICZsdDs8YSBocmVmPSJtYWlsdG86c2d1
bmRhdmVAY2lzY28uY29tIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8
L2I+Q2hhcmxpZSBQZXJraW5zICZsdDs8YSBocmVmPSJtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVh
cnRobGluay5uZXQiPmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PC9hPiZndDssIE1hcmNv
IExpZWJzY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldSI+TWFy
Y28uTGllYnNjaEBuZWNsYWIuZXU8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRtbUBp
ZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRtbUBp
ZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPiZndDssDQogVmlqYXkgRGV2YXJhcGFsbGkgJmx0Ozxh
IGhyZWY9Im1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20iPmR2aWpheUByb2NrZXRtYWlsLmNv
bTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbRE1NXSBNTklEIFR5cGVzPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBGb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8geW91IHRoaW5rIHRoYXQgY29uc2lkZXJp
bmcgc3BlY2lmaWMgYnV0IG5lZWRlZCB0ZWNobm9sb2dpZXMgZm9yIG1vdmluZyBvYmplY3RzIGlu
Jm5ic3A7IEludGVybmV0IG9mIFRoaW5ncyZuYnNwOyBzdWNoIGFzIFJGSUQgKFJhZGlvIEZyZXF1
ZW5jeSBJZGVudGlmaWVyKSB3aXRoIDk2IGJpdHMgaWRlbnRpZmllcnMgd2lsbCBiZSBhbHNvIHJl
bGV2ZW50IHRvIENoYXJsaWUncyBjdXJyZW50IGRyYWZ0IGFuZCB0aGUgZWZmb3J0cw0KIHJlbGF0
ZWQgdG8gTU5JRD8mbmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhha2ltYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj
ZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIiBpZD0iendj
aHIiPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij5EZTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7U3JpIEd1bmRhdmVsbGkgKHNn
dW5kYXZlKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSI+c2d1
bmRhdmVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj7DgDogPC9iPiZxdW90O0NoYXJsaWUgUGVy
a2lucyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsu
bmV0Ij5jaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDwvYT4mZ3Q7LCAmcXVvdDtNYXJjbyBM
aWVic2NoJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXUi
Pk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PC9hPiZndDssDQo8YSBocmVmPSJtYWlsdG86ZG1tQGll
dGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+LCAmcXVvdDtWaWpheSBEZXZhcmFwYWxsaSZxdW90OyAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbSI+ZHZpamF5QHJvY2tldG1h
aWwuY29tPC9hPiZndDs8YnI+DQo8Yj5FbnZvecOpOiA8L2I+SmV1ZGkgMTEgU2VwdGVtYnJlIDIw
MTQgMjM6NTc6MTE8YnI+DQo8Yj5PYmpldDogPC9iPlJlOiBbRE1NXSBNTklEIFR5cGVzPG86cD48
L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBDaGFybGllLDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5GZXcgbW9yZSByZXZpZXdzL2Rpc2N1c3Npb25zIGFuZCBjYXB0
dXJpbmcgdGhlIGNvbnNlbnN1cyBpbiB0aGUgYmFzZSB2ZXJzaW9uIHdpbGwgaGVscC4gQnV0LCBJ
J20gb2sgZWl0aGVyIHdheSDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Tcmk8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPkNoYXJsaWUgUGVya2lucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2lu
c0BlYXJ0aGxpbmsubmV0IiB0YXJnZXQ9Il9ibGFuayI+Y2hhcmxlcy5wZXJraW5zQGVhcnRobGlu
ay5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgU2VwdGVtYmVyIDExLCAy
MDE0IDI6NDYgUE08YnI+DQo8Yj5UbzogPC9iPlNyaSBHdW5kYXZlbGxpICZsdDs8YSBocmVmPSJt
YWlsdG86c2d1bmRhdmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c2d1bmRhdmVAY2lzY28u
Y29tPC9hPiZndDssIE1hcmNvIExpZWJzY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpNYXJjby5MaWVi
c2NoQG5lY2xhYi5ldSIgdGFyZ2V0PSJfYmxhbmsiPk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PC9h
PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5kbW1AaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+Jmd0OywgVmlqYXkgRGV2YXJhcGFs
bGkgJmx0OzxhIGhyZWY9Im1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20iIHRhcmdldD0iX2Js
YW5rIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5S
ZTogW0RNTV0gTU5JRCBUeXBlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGVsbG8g
Zm9sa3MsPGJyPg0KPGJyPg0KSSBwcm9wb3NlIHRvIHN1Ym1pdCB0aGUgLi4uLi0wMC50eHQgZG9j
dW1lbnQgYXMgaXQgaXMgdG8gdGhlIEludGVybmV0PGJyPg0KRHJhZnRzIGRpcmVjdG9yeSwgYW5k
IHRoZW4gdG8gZ28gYWJvdXQgbWFraW5nIHVwZGF0ZXMgYWNjb3JkaW5nIHRvPGJyPg0KdGhlIGRp
c2N1c3Npb24gb24gdGhpcyBsaXN0LiZuYnNwOyBEbyB5b3UgdGhpbmsgdGhpcyBpcyByZWFzb25h
YmxlPzxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KQ2hhcmxpZSBQLjxicj4NCjxicj4NCjxicj4N
Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIDkvMTEvMjAxNCA3OjIxIEFNLCBTcmkg
R3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cHJlPiZsdDtDaGFuZ2luZyB0aGUgc3ViamVjdCBsaW5lIHRvIHJlZmxlY3QgdGhlIE1O
SWQgZGlzY3Vzc2lvbiZndDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5NYXJjbyw8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT5UaGlua2luZyBmdXJ0aGVyIG9uIHRoZSBjb21wbGVtZW50YXJ5
IGlkZW50aWZpZXIgb3B0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPi0gVGhlcmUgaXMgYWxyZWFkeSB0aGUgbGluay1sYXllciBpZGVudGlm
aWVyIG9wdGlvbiB0aGF0IGNhbiBiZSB1c2VkIGZvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNh
cnJ5aW5nIHRoZSBNYWMgYWRkcmVzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gSU1FSSBhbmQg
TVNJU0ROIGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gMjkuMjc1IGFzIGEgM0dQUCBWU0UnczxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkluIHNvbWUg
c2Vuc2UsIHRoZSBjb21wbGVtZW50YXJ5IGlkZW50aWZpZXJzIGFyZSBhbHJlYWR5IHByZXNlbnQu
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U3Jp
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+T24gOS8xMS8xNCA2OjU4IEFNLCAmcXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1
b3Q7IDxhIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj4m
bHQ7c2d1bmRhdmVAY2lzY28uY29tJmd0OzwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHByZT5JIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5IG11bHRpcGxlIE1OLUlkIGluc3RhbmNlcyBu
ZWVkIHRvIGJlIHByZXNlbnQgaW4gYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNpbmdsZSBtZXNz
YWdlID8gSW4gbXkgZXhwZXJpZW5jZSwgdGhpcyBpcyBzdHJpY3RseSBhIGRlcGxveW1lbnQ8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5jb25zaWRlcmF0aW9uLCB3aGVuIHRvIHVzZSB3aGF0IHR5cGUg
b2YgaWRlbnRpZmllcnMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+QXNzdW1pbmcgdGhlIGJhY2tlbmQgc3lzdGVtIGNhbiB0aWUgYWxsIHRoZSBN
Ti1JZCdzIHRvIGEgc2luZ2xlPG86cD48L286cD48L3ByZT4NCjxwcmU+c3Vic2NyaXB0aW9uLCBh
bnkgcHJlc2VudGVkIGlkZW50aWZpZXIgY2FuIGJlIHN1ZmZpY2llbnQgZm9yIHRoZSBnYXRld2F5
PG86cD48L286cD48L3ByZT4NCjxwcmU+dG8gZG8gdGhlIEJDRSBsb29rdXAuPG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SWYgbXVsdGlwbGUgaW5z
dGFuY2VzIGNhbiBiZSBwcmVzZW50LCB0aGVuIHdlIG5lZWQgdG8gZGVhbCB3aXRoIG1vcmUgZXJy
b3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jYXNlcy4gSXMgdGhhdCByZWFsbHkgbmVlZGVkID88
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkkgYW0gd29uZGVyaW5nIGlmIGl0IHdvdWxkIG5v
dCBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIGdvIGZvciBhIGRpZmZlcmVudDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmNvbnRhaW5lciBvcHRpb24gdG8gY2Fycnkgc3VjaCBpbmZvcm1hdGlvbi4gU29t
ZXRoaW5nIGxpa2UgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvbXBsZW1lbnRhcnkgaWRlbnRp
ZmllciBvcHRpb24uPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+U291bmRz
IGludGVyZXN0aW5nLiBBcmUgeW91IHN1Z2dlc3Rpbmcgd2UgbGVhdmUgdGhlIGN1cnJlbnQgTU4t
SUQgYXMgaXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pcywgYnV0IHVzZSBhIG5ldyBjb21wbGVt
ZW50YXJ5IG9wdGlvbiA/IEJ1dCwgaWYgdGhlIHJlcXVpcmVtZW50IGlzIGZvciBhPG86cD48L286
cD48L3ByZT4NCjxwcmU+TWFjIGJhc2VkIGlkZW50aWZpZXJzLCB3aGF0IHdpbGwgYmUgdGhlcmUg
aW4gdGhlIGN1cnJlbnQgTU4tSWQgb3B0aW9uID8gV2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5z
dGlsbCBuZWVkIHRvIGhhdmUgaWRlbnRpZmllciB0aGVyZSA/PG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+U3JpPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+T24gOS8xMS8xNCAyOjAzIEFNLCAmcXVvdDtNYXJjbyBMaWVic2NoJnF1
b3Q7IDxhIGhyZWY9Im1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldSIgdGFyZ2V0PSJfYmxh
bmsiPiZsdDtNYXJjby5MaWVic2NoQG5lY2xhYi5ldSZndDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+Tm8gaXNzdWUgd2l0
aCBsb2dpY2FsIHZzLiBwaHlzaWNhbCBJRC4gQnV0IEkgYW0gd29uZGVyaW5nIGFib3V0IHR3bzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoaW5nczo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PcGVyYXRpb24gaXMgY2xlYXIgdG8gbWUgaW4gY2Fz
ZSBhIHNpbmdsZSBNTklEIGlzIHByZXNlbnQgaW4gYSBtZXNzYWdlPG86cD48L286cD48L3ByZT4N
CjxwcmU+YW5kIEkgc2VlIHRoZSB2YWx1ZSBpbiBiZWluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PmZsZXhpYmxlIHRvIGNob29zZSBmcm9tIGRpZmZlcmVudCBzdWItdHlwZXMuIElmIG11bHRpcGxl
IE1OSURzIHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kaWZmZXJlbnQgc3ViLXR5cGVzIGFy
ZSBwcmVzZW50IGluPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBzaW5nbGUgbWVzc2FnZSwgd2hp
Y2ggb25lIHNob3VsZCBlLmcuIHRoZSBMTUEgdGFrZSBmb3IgdGhlIEJDIGxvb2t1cC4uPG86cD48
L286cD48L3ByZT4NCjxwcmU+Tm8gYmlnIHByb2JsZW0gdG8gc29sdmUsIGJ1dDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPnRvIGJlIGNvbnNpZGVyZWQgaW4gaW1wbGVtZW50YXRpb25zLjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPklmIHRoZSByZWFz
b24gZm9yIG11bHRpcGxlIHByZXNlbnQgTU5JRHMgd2l0aCBkaWZmZXJlbnQgc3ViLXR5cGVzIGlz
IHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+ZG8gb3RoZXIgdGhpbmdzIHRoYW4gaWRlbnRpZnlp
bmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgbm9kZSBvciB1c2luZyB0aGUgSUQgYXMga2V5
IGZvciBhIGxvb2t1cCwgSSBhbSB3b25kZXJpbmcgaWYgaXQgd291bGQ8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5ub3QgYmUgbW9yZSBhcHByb3ByaWF0ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRv
IGdvIGZvciBhIGRpZmZlcmVudCBjb250YWluZXIgb3B0aW9uIHRvIGNhcnJ5IHN1Y2ggaW5mb3Jt
YXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+U29tZXRoaW5nIGxpa2UgYSBjb21wbGVtZW50
YXJ5PG86cD48L286cD48L3ByZT4NCjxwcmU+aWRlbnRpZmllciBvcHRpb24uPG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+bWFyY288bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogU3JpIEd1bmRhdmVs
bGkgKHNndW5kYXZlKSBbPGEgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPm1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPlNlbnQ6IERvbm5lcnN0YWcsIDExLiBTZXB0ZW1iZXIgMjAxNCAwMDo0MjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPlRvOiBDaGFybGllIFBlcmtpbnM7IE1hcmNvIExpZWJzY2g7IDxhIGhy
ZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2M6IFZpamF5IERldmFyYXBhbGxpPG86cD48L286cD48
L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hhcnRlcmlu
Zy4uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
SGVsbG8gQ2hhcmxpZSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5BZ3JlZSB3aXRoIHRoYXQuIE1OLUlkIGFzIGl0cyBkZWZpbmVkIHRvZGF5IGlz
IGEgbG9naWNhbCBpZGVudGlmaWVyLiBJdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRvZXMgbm90
PG86cD48L286cD48L3ByZT4NCjxwcmU+cmVxdWlyZSB0aGUgaWRlbnRpZmllciB0byBiZSBib3Vu
ZCB0byBhIHBoeXNpY2FsIGRldmljZSBvciBhIGludGVyZmFjZTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPmlkZW50aXR5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJ1dCwgd2UgaGF2ZSBjbGVhcmx5
IHNlZW4gcmVxdWlyZW1lbnRzIHdoZXJlIHRoZSBuZWVkIGlzIGZvciBnZW5lcmF0aW5nPG86cD48
L286cD48L3ByZT4NCjxwcmU+aWRlbnRpZmllcnMgYmFzZWQgb24gc29tZSBwaHlzaWNhbCBpZGVu
dGlmaWVycy4gVGhvc2UgcGh5c2ljYWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pZGVudGlmaWVy
cyBpbmNsdWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+SU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMg
Li5ldGMuIElmIHdlIGNhbiBkZWZpbmUgYSB0eXBlIGZvciBlYWNoIG9mIHRoZTxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPnNvdXJjZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFuZCB0aGUgcnVsZXMg
Zm9yIGdlbmVyYXRpbmcgTU4tSUQgYmFzZWQgdXNpbmcgdGhvc2Ugc291cmNlcywgdGhlIHNlbmRl
cjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJlY2Vp
dmVyIHdpbGwgaGF2ZSBjbGVhciBndWlkYW5jZSBvbiBob3cgdG8gdXNlIHRoZSBzcGVjLiBTb21l
IHBvaW50ZXJzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmV4cGxhbmF0aW9uIGFuZCBleGFtcGxl
cyBmb3IgZWFjaCBvZiB0aG9zZSBpZGVudGlmaWVycyB3aWxsIGdyZWF0bHkgaGVscDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPmF2b2lkPG86cD48L286cD48L3ByZT4NCjxwcmU+aW50ZXItb3AgaXNz
dWVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHM8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5Tcmk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5PbiA5LzEwLzE0IDM6MjEgUE0sICZxdW90O0NoYXJsaWUgUGVya2lucyZx
dW90OyA8YSBocmVmPSJtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQiIHRhcmdl
dD0iX2JsYW5rIj4mbHQ7Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQmZ3Q7PC9hPjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPndyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SGVsbG8gZm9sa3MsPG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSB0aGluayBpdCdzIGJlc3QgdG8gY29u
c2lkZXIgdGhlIE1OSUQgYXMgc2ltcGx5IGxpdmluZyBpbiBhIHNwYWNlIG9mPG86cD48L286cD48
L3ByZT4NCjxwcmU+aWRlbnRpZmllcnMsIGFuZCBub3Qgd29ycnkgdG9vIG11Y2ggYWJvdXQgd2hl
dGhlciBpdCdzIGEgbG9naWNhbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlkZW50aWZpZXIgb3Ig
YSBwaHlzaWNhbCBpZGVudGlmaWVyLiZuYnNwOyBJZiB0aGUgZm9ybWVyLCB0aGVuIHNvbWV3aGVy
ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPihwZXJoYXBzIGJlbG93IHRoZSBuZXR3b3JrIGxheWVy
KSB0aGUgbG9naWNhbCBpZGVudGlmaWVyIGhhcyBiZWVuIGJvdW5kPG86cD48L286cD48L3ByZT4N
CjxwcmU+dG8gc29tZXRoaW5nIGluIHRoZSBwaHlzaWNhbCBpbnRlcmZhY2UsIGJ1dCB0aGF0J3Mg
bm90IG91ciBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPlRoZSBudW1iZXIgc3BhY2UgZm9yIHR5cGVzIG9mIE1OSURzIGlzIGxpa2Vs
eSB0byBzdGF5IHByZXR0eSBlbXB0eSwgc288bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JJ2Qgc2F5
IHdlIGNvdWxkIGFkZCBhcyBtYW55IHR5cGVzIGFzIHdvdWxkIGJlIGNvbnZlbmllbnQgZm9yIHRo
ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNvZnR3YXJlIGRlc2lnbmVycy4mbmJzcDsgU28sIHdl
IGNvdWxkIGNvbmNlaXZhYmx5IGhhdmUgc2V2ZXJhbCBNTklEczxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPmRlZmluZWQgdGhhdCBhbGwgJnF1b3Q7bG9va2VkIGxpa2UmcXVvdDsgTkFJcyAod2hpY2gs
IHRoZW1zZWx2ZXMsICZxdW90O2xvb2sgbGlrZSZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PkZRRE5zKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNoYXJsaWUgUC48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiA5LzEwLzIw
MTQgODoxMSBBTSwgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSB3cm90ZTo8bzpwPjwvbzpwPjwv
cHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cHJlPlllcy4gQ3VycmVudGx5LCB0aGUgTU5JRCBpcyBpZiB0aGUgbmFpIGZvcm1h
dCBhbmQgaXMgb3ZlcmxvYWRlZC4gVGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+TU5JRCZuYnNw
OyBpbiAzR1BQIHNwZWNzIGlzIHRoZSBJTVNJLU5BSSAoSU1TSUBSRUFMTSksIGl0cyBiYXNlZCBv
biB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JTVNJLiBFeDo8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mcXVvdDsmbHQ7SU1TSSZndDtAZXBjLm1uYyZsdDtNTkMmZ3Q7Lm1jYyZsdDtNQ0MmZ3Q7
LjNncHBuZXR3b3JrLm9yZ8KyPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+V2UgYWxzbyBoYXZlIE1BQzQ4QFJFQUxNOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPldlIGFsc28gaGF2ZSBhcHByb2Fj
aGVzIHRvIHRyYW5zZm9ybSBNQUMgdG8gUHNldWRvIElNU0ksIGFuZCB0aGVuPG86cD48L286cD48
L3ByZT4NCjxwcmU+Y2FycnkgSU1TSS1OQUkgYXMgdGhlIE1OLUlELjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPlNvLCB3ZSBuZWVkIHVuaXF1ZSBzdWItdHlwZXMgZm9yIGVhY2ggb2YgdGhlIHR5
cGVzL3NvdXJjZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+TU4tSWQgYmFzZWQgb24gSU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BbHNvLCBkbyB3
ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gSU1TSSBhbmQgSU1TSS1OQUkgPzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNyaTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9uIDkvMTAv
MTQgNjoyOSBBTSwgJnF1b3Q7TWFyY28gTGllYnNjaCZxdW90OyA8YSBocmVmPSJtYWlsdG86TWFy
Y28uTGllYnNjaEBuZWNsYWIuZXUiIHRhcmdldD0iX2JsYW5rIj4mbHQ7TWFyY28uTGllYnNjaEBu
ZWNsYWIuZXUmZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPkl0IHNlZW1zIHRoZSBNTklEIGlzIHNvbWVob3cgb3Zlcmxv
YWRlZCB0byBjYXJyeSBib3RoLCBub2RlLXNwZWNpZmljPG86cD48L286cD48L3ByZT4NCjxwcmU+
SURzLCZuYnNwOyBlLmcuIE1BQywgYXMgd2VsbCBhcyBzdWJzY3JpYmVyIElEcywgd2hpY2ggaXMg
dGhlIElNU0kuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlcmUgbWF5IGJlIHZhbHVlIGluIGFk
ZGluZyB0aGUgSU1FSSB0byB0aGUgbGlzdCBvZiBwb3NzaWJsZSB0eXBlczxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPm9mJm5ic3A7IG5vZGUtc3BlY2lmaWMgSURzLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPm1hcmNvPG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4tLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IGRtbSBbPGEgaHJlZj0ibWFpbHRv
OmRtbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmRtbS1ib3VuY2Vz
QGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFNyaSBHdW5kYXZlbGxpPG86cD48L286cD48L3By
ZT4NCjxwcmU+KHNndW5kYXZlKTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IERpZW5zdGFn
LCA5LiBTZXB0ZW1iZXIgMjAxNCAyMzozMDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBTcmkg
R3VuZGF2ZWxsaSAoc2d1bmRhdmUpOyBDaGFybGllIFBlcmtpbnM7IDxhIGhyZWY9Im1haWx0bzpk
bW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PG86cD48L286cD48
L3ByZT4NCjxwcmU+Q2M6IFZpamF5IERldmFyYXBhbGxpPG86cD48L286cD48L3ByZT4NCjxwcmU+
U3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hhcnRlcmluZy4uPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VHdvIG1vcmUgY29t
bWVudHMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+NC4pIEknZCBhbHNvIHVzZSBzdWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElNU0kuIEp1
c3QgdG8gYWxpZ24gd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSZuYnNwOyBzdWItdHlw
ZXMmbmJzcDsgZGVmaW5lZCBmb3IgTU4gSWQgZGVmaW5lZCBmb3IgSUNNUC4gSSBzdXNwZWN0IHRo
ZXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+YXJlIHNvbWUmbmJzcDsgaW1wbGVtZW50YXRpb25z
Jm5ic3A7IGFscmVhZHkgdXNpbmcgc3ViLXR5cGUgKDIpLiBQbGVhc2Ugc2VlPG86cD48L286cD48
L3ByZT4NCjxwcmU+dGhlIG90aGVyIHRocmVhZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT41
LikgRm9yIGVhY2ggb2YgdGhlIHN1Yi10eXBlcywgd2UgbmVlZCB0ZXh0IGluY2x1ZGluZyBleGFt
cGxlcyBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zb21lPG86cD48L286cD48L3ByZT4NCjxw
cmU+ZXhwbGFuYXRpb24gb24gaG93IHRoZXkgYXJlIHVzZWQuPG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+U3JpPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+T24gOS85LzE0IDI6MjAgUE0sICZxdW90O1NyaSBHdW5kYXZlbGxpIChzZ3VuZGF2
ZSkmcXVvdDsgPGEgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh
bmsiPiZsdDtzZ3VuZGF2ZUBjaXNjby5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
Pndyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxwcmU+SGkgQ2hhcmxpZSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5UaGlzIGlzIGdvb2QuIFRoYW5rcy48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT4xLikgSWYgRVVJLTQ4IGFuZCBFVUktNjQgYWRkcmVzc2VzIGFyZSBkZXJpdmVkIG9mIGEg
NDgtYml0IElFRUU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT44MDIuMjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPmFkZHJlc3MsIHdoeSBkbyB3ZSBuZWVkIHRvIHR3byBzdWItdHlwZXMgPyBXaHkgbm90
IGhhdmUganVzdCBvbmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdWItdHlwZSBmb3IgbWFjIGJh
c2VkIGlkZW50aWZpZXJzID88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT4yLikgU3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJlbnRseSB1c2VkLiBJ
dHMgY3VycmVudGx5IG92ZXJsb2FkZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5mb3I8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5JTVNJLU5BSSAoM0dQUCBzcGVjcykgYW5kIGdlbmVyaWMgTkFJIGJh
c2VkIGlkZW50aWZpZXJzLiBHaXZlbiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kZWZpbml0
aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxhaW5pbmcgdGhlPG86
cD48L286cD48L3ByZT4NCjxwcmU+bW90aXZhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1ZSBv
ZiAoMikgZm9yIElQdjYgYWRkcmVzcy4gV2hhdCBleGFjdGx5PG86cD48L286cD48L3ByZT4NCjxw
cmU+aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGlzID8gQXJlIHRoZXNlIENHQS1iYXNlZCBJ
UHY2IGFkZHJlc3NlcyA/PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5ldyBN
b2JpbGUgTm9kZSBJZGVudGlmaWVyIFR5cGVzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7
LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48
L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSWRlbnRpZmll
ciBUeXBlIHwgSWRlbnRpZmllciBUeXBlIE51bWJlciB8PG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSVB2NiBBZGRyZXNzJm5ic3A7Jm5ic3A7Jm5ic3A7IHwg
MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHwgSU1TSSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IDMmbmJzcDsmbmJzcDsmbmJzcDsgJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFAtVE1T
SSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8
IDQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB8IEVVSS00OCBhZGRyZXNzJm5ic3A7IHwgNSZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDt8
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwgRVVJLTY0IGFkZHJlc3MmbmJzcDsgfCA2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBHVVRJJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwgNyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw
OyZuYnNwOyZuYnNwOyYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+UmVnYXJkczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNyaTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPlBTOiBHb29kIHRvIHNlZSBWaWpheSBiYWNrPG86cD48L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+T24gOS85LzE0IDE6MjggUE0sICZxdW90O0NoYXJsaWUgUGVya2lucyZx
dW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpjaGFybGVzLnBlcmtp
bnNAZWFydGhsaW5rLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtjaGFybGVzLnBlcmtpbnNAZWFy
dGhsaW5rLm5ldCZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+d3JvdGU6PG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5IZWxsbyBmb2xr
cyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5I
ZXJlJ3MgdGhlIGxhc3QgSW50ZXJuZXQgRHJhZnQgdGhhdCB3ZSBkaWQsIGxvbmcgYWdvIGV4cGly
ZWQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXBlcmtpbnMtbWV4
dC00MjgzbW5pZHMtMDEudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9h
cmNoaXZlL2lkL2RyYWZ0LXBlcmtpbnMtbWV4dC00MjgzbW5pZHMtMDEudHh0PC9hPjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkknbGwgcmVzdWJt
aXQgaXQgd2l0aCBhIGZldyB1cGRhdGVzIGFzIGEgcGVyc29uYWwgZHJhZnQgdG8gZG1tLjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMs
PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2hhcmxpZSBQLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Js
b2NrcXVvdGU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+ZG1tIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5kbW1AaWV0Zi5vcmc8L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RtbTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPmRtbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBo
cmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9h
PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L2E+
PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx
dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5kbW0gbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEg
aHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwv
YT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFy
Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9h
PjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+ZG1t
IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpkbW1A
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vZG1tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pi0tIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFraW1hIENoYW91Y2hpPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcm9mZXNzb3I8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlbGVj
b20gU3VkIFBhcmlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JbnN0aXR1dCBNaW5lcyBUZWxlY29tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj45IHJ1ZSBDaGFybGVzIEZvdXJpZXI8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjkxMDExIEV2cnk8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjAxNjA3NjQ0
NDM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w
Pg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkNoYXJsaWUgUC48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
Ym9keT4NCjwvaHRtbD4NCg==

--_000_2134F8430051B64F815C691A62D9831832D27B1EXCHBLV504nwnosb_--


From nobody Thu Sep 25 14:08:50 2014
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 C4D5E1A87C4 for ; Thu, 25 Sep 2014 14:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 Lkm2gk8K1sKa for ; Thu, 25 Sep 2014 14:08:44 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4203A1A886C for ; Thu, 25 Sep 2014 14:08:35 -0700 (PDT)
Received: from [107.1.141.74] (helo=[192.168.254.194]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XXGH9-0003DK-RX; Thu, 25 Sep 2014 17:08:32 -0400
Message-ID: <5424844C.1020101@computer.org>
Date: Thu, 25 Sep 2014 14:08:28 -0700
From: "Charles E. Perkins" 
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Templin, Fred L" ,  "Sri Gundavelli (sgundave)" 
References:  <54247E3C.7050800@computer.org> <2134F8430051B64F815C691A62D9831832D27B1E@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832D27B1E@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: multipart/alternative; boundary="------------050108050101000304040401"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac76e227c87dc667b68fd8babae06113d7d350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/FyovMqC7TAnZ34rJoyMKzS_UIOs
Cc: Vijay Devarapalli , dmm@ietf.org
Subject: Re: [DMM] MNID Types
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, 25 Sep 2014 21:08:48 -0000

This is a multi-part message in MIME format.
--------------050108050101000304040401
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


Hello Fred,

I can include DUID-UUID as an identifier type, and cite RFC 4122. Is this
sufficient, or do I need to also do something related to DHCPv6 DUID?

I did not see any specific connection between this type of identifier and
the RFID discussion.  Is there something that relates the two types?

Regards,
Charlie P.



On 9/25/2014 2:00 PM, Templin, Fred L wrote:
>
> Hi Charlie,
>
> I am interested in node IDs that can be represented in a DHCPv6 DUID. 
> There is
>
> RFC6355 which encodes a node ID based on DUID-UUID (Universally Unique
>
> IDentifier). AFAICT, the UUID is a 128-bit container formatted per RFC4122
>
> specifications that includes a time portion and a node ID portion. Any 
> chance
>
> this would satisfy what you are looking for?
>
> Thanks - Fred
>
> *From:*dmm [mailto:dmm-bounces@ietf.org] *On Behalf Of *Charles E. Perkins
> *Sent:* Thursday, September 25, 2014 1:43 PM
> *To:* Sri Gundavelli (sgundave)
> *Cc:* Vijay Devarapalli; dmm@ietf.org
> *Subject:* Re: [DMM] MNID Types
>
>
> Hello Sri,
>
> Is the DoD-96 identifier for a special kind of RFID, or is it
> valid for all the RFID devices that would be of interest?
>
> Regards,
> Charlie P.
>
> On 9/21/2014 9:59 AM, Sri Gundavelli (sgundave) wrote:
>
>     Hi Hakima,
>
>     That is a good idea. We should register a type for the Dod-96
>     identifier as well.
>
>     Regards
>
>     Sri
>
>     *From: *Hakima Chaouchi      >
>     *Date: *Sunday, September 21, 2014 8:11 AM
>     *To: *Sri Gundavelli >
>     *Cc: *Charlie Perkins      >, Marco Liebsch
>     >,
>     "dmm@ietf.org "      >, Vijay Devarapalli      >
>     *Subject: *Re: [DMM] MNID Types
>
>     Hello Folks,
>
>     Do you think that considering specific but needed technologies for
>     moving objects in  Internet of Things  such as RFID (Radio
>     Frequency Identifier) with 96 bits identifiers will be also
>     relevent to Charlie's current draft and the efforts related to MNID?
>
>     Regards,
>
>     Hakima
>
>     ------------------------------------------------------------------------
>
>     *De: *"Sri Gundavelli (sgundave)"      >
>     *À: *"Charlie Perkins"      >, "Marco Liebsch"
>     >,
>     dmm@ietf.org , "Vijay Devarapalli"
>     >
>     *Envoyé: *Jeudi 11 Septembre 2014 23:57:11
>     *Objet: *Re: [DMM] MNID Types
>
>     Hi Charlie,
>
>     Few more reviews/discussions and capturing the consensus in the
>     base version will help. But, I'm ok either way …
>
>     Regards
>
>     Sri
>
>     *From: *Charlie Perkins      >
>     *Date: *Thursday, September 11, 2014 2:46 PM
>     *To: *Sri Gundavelli      >, Marco Liebsch
>     >,
>     "dmm@ietf.org "      >, Vijay Devarapalli      >
>     *Subject: *Re: [DMM] MNID Types
>
>
>     Hello folks,
>
>     I propose to submit the ....-00.txt document as it is to the Internet
>     Drafts directory, and then to go about making updates according to
>     the discussion on this list.  Do you think this is reasonable?
>
>     Regards,
>     Charlie P.
>
>
>     On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:
>
>         
>
>           
>
>           
>
>         Marco,
>
>           
>
>           
>
>         Thinking further on the complementary identifier option.
>
>           
>
>         - There is already the link-layer identifier option that can be used for
>
>         carrying the Mac address
>
>         - IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's
>
>           
>
>         In some sense, the complementary identifiers are already present.
>
>           
>
>         Sri
>
>           
>
>           
>
>           
>
>           
>
>           
>
>         On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)"    wrote:
>
>             I do not see a reason why multiple MN-Id instances need to be present in a
>
>             single message ? In my experience, this is strictly a deployment
>
>             consideration, when to use what type of identifiers.
>
>               
>
>             Assuming the backend system can tie all the MN-Id's to a single
>
>             subscription, any presented identifier can be sufficient for the gateway
>
>             to do the BCE lookup.
>
>               
>
>             If multiple instances can be present, then we need to deal with more error
>
>             cases. Is that really needed ?
>
>               
>
>               
>
>                 I am wondering if it would not be more appropriate to go for a different
>
>                 container option to carry such information. Something like a
>
>                 complementary identifier option.
>
>             Sounds interesting. Are you suggesting we leave the current MN-ID as it
>
>             is, but use a new complementary option ? But, if the requirement is for a
>
>             Mac based identifiers, what will be there in the current MN-Id option ? We
>
>             still need to have identifier there ?
>
>               
>
>               
>
>               
>
>               
>
>             Sri
>
>               
>
>               
>
>               
>
>               
>
>               
>
>             On 9/11/14 2:03 AM, "Marco Liebsch"    wrote:
>
>               
>
>                 No issue with logical vs. physical ID. But I am wondering about two
>
>                 things:
>
>                   
>
>                 Operation is clear to me in case a single MNID is present in a message
>
>                 and I see the value in being
>
>                 flexible to choose from different sub-types. If multiple MNIDs with
>
>                 different sub-types are present in
>
>                 a single message, which one should e.g. the LMA take for the BC lookup..
>
>                 No big problem to solve, but
>
>                 to be considered in implementations.
>
>                   
>
>                 If the reason for multiple present MNIDs with different sub-types is to
>
>                 do other things than identifying
>
>                 the node or using the ID as key for a lookup, I am wondering if it would
>
>                 not be more appropriate
>
>                 to go for a different container option to carry such information.
>
>                 Something like a complementary
>
>                 identifier option.
>
>                   
>
>                 marco
>
>                   
>
>                     -----Original Message-----
>
>                     From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>
>                     Sent: Donnerstag, 11. September 2014 00:42
>
>                     To: Charlie Perkins; Marco Liebsch;dmm@ietf.org  
>
>                     Cc: Vijay Devarapalli
>
>                     Subject: Re: [DMM] regarding the re-chartering..
>
>                       
>
>                     Hello Charlie,
>
>                       
>
>                     Agree with that. MN-Id as its defined today is a logical identifier. It
>
>                     does not
>
>                     require the identifier to be bound to a physical device or a interface
>
>                     identity.
>
>                     But, we have clearly seen requirements where the need is for generating
>
>                     identifiers based on some physical identifiers. Those physical
>
>                     identifiers include
>
>                     IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
>
>                     source
>
>                     and the rules for generating MN-ID based using those sources, the sender
>
>                     and
>
>                     receiver will have clear guidance on how to use the spec. Some pointers,
>
>                     explanation and examples for each of those identifiers will greatly help
>
>                     avoid
>
>                     inter-op issues.
>
>                       
>
>                       
>
>                     Regards
>
>                     Sri
>
>                       
>
>                       
>
>                       
>
>                       
>
>                       
>
>                       
>
>                       
>
>                     On 9/10/14 3:21 PM, "Charlie Perkins"  
>
>                     wrote:
>
>                       
>
>                         Hello folks,
>
>                           
>
>                         I think it's best to consider the MNID as simply living in a space of
>
>                         identifiers, and not worry too much about whether it's a logical
>
>                         identifier or a physical identifier.  If the former, then somewhere
>
>                         (perhaps below the network layer) the logical identifier has been bound
>
>                         to something in the physical interface, but that's not our problem.
>
>                           
>
>                         The number space for types of MNIDs is likely to stay pretty empty, so
>
>                         I'd say we could add as many types as would be convenient for the
>
>                         software designers.  So, we could conceivably have several MNIDs
>
>                         defined that all "looked like" NAIs (which, themselves, "look like"
>
>                         FQDNs).
>
>                           
>
>                         Regards,
>
>                         Charlie P.
>
>                           
>
>                           
>
>                           
>
>                         On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:
>
>                             Yes. Currently, the MNID is if the nai format and is overloaded. The
>
>                             MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
>
>                             IMSI. Ex:
>
>                             "@epc.mnc.mcc.3gppnetwork.org²
>
>                               
>
>                             We also have MAC48@REALM;
>
>                               
>
>                             We also have approaches to transform MAC to Pseudo IMSI, and then
>
>                             carry IMSI-NAI as the MN-ID.
>
>                               
>
>                               
>
>                             So, we need unique sub-types for each of the types/sources.
>
>                               
>
>                             MN-Id based on IMSI, MSISDN, IMEI, MAC ..
>
>                               
>
>                             Also, do we need to distinguish between IMSI and IMSI-NAI ?
>
>                               
>
>                             Sri
>
>                               
>
>                               
>
>                               
>
>                             On 9/10/14 6:29 AM, "Marco Liebsch"    wrote:
>
>                               
>
>                                 It seems the MNID is somehow overloaded to carry both, node-specific
>
>                                 IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
>
>                                 There may be value in adding the IMEI to the list of possible types
>
>                                 of  node-specific IDs.
>
>                                   
>
>                                 marco
>
>                                   
>
>                                     -----Original Message-----
>
>                                     From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
>
>                                     (sgundave)
>
>                                     Sent: Dienstag, 9. September 2014 23:30
>
>                                     To: Sri Gundavelli (sgundave); Charlie Perkins;dmm@ietf.org  
>
>                                     Cc: Vijay Devarapalli
>
>                                     Subject: Re: [DMM] regarding the re-chartering..
>
>                                       
>
>                                     Two more comments.
>
>                                       
>
>                                       
>
>                                       
>
>                                     4.) I'd also use sub-type value of (2) for IMSI. Just to align with
>
>                                     the  sub-types  defined for MN Id defined for ICMP. I suspect there
>
>                                     are some  implementations  already using sub-type (2). Please see
>
>                                     the other thread.
>
>                                       
>
>                                       
>
>                                     5.) For each of the sub-types, we need text including examples and
>
>                                     some
>
>                                     explanation on how they are used.
>
>                                       
>
>                                       
>
>                                     Sri
>
>                                       
>
>                                       
>
>                                       
>
>                                     On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)"  
>
>                                     wrote:
>
>                                       
>
>                                         Hi Charlie,
>
>                                           
>
>                                         This is good. Thanks.
>
>                                           
>
>                                           
>
>                                         1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
>
>                                         802.2
>
>                                         address, why do we need to two sub-types ? Why not have just one
>
>                                         sub-type for mac based identifiers ?
>
>                                           
>
>                                         2.) Sub type value (1) is currently used. Its currently overloaded
>
>                                         for
>
>                                         IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
>
>                                         definition of new sub-types, we need some text explaining the
>
>                                         motivation
>
>                                           
>
>                                         3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
>
>                                         is
>
>                                         this ? Are these CGA-based IPv6 addresses ?
>
>                                           
>
>                                           
>
>                                           
>
>                                           
>
>                                                               New Mobile Node Identifier Types
>
>                                           
>
>                                                         +-----------------+------------------------+
>
>                                                         | Identifier Type | Identifier Type Number |
>
>                                                         +-----------------+------------------------+
>
>                                                         | IPv6 Address    | 2                      |
>
>                                                         |                 |                        |
>
>                                                         | IMSI            | 3                      |
>
>                                                         |                 |                        |
>
>                                                         | P-TMSI          | 4                      |
>
>                                                         |                 |                        |
>
>                                                         | EUI-48 address  | 5                      |
>
>                                                         |                 |                        |
>
>                                                         | EUI-64 address  | 6                      |
>
>                                                         |                 |                        |
>
>                                                         | GUTI            | 7                      |
>
>                                                         +-----------------+------------------------+
>
>                                           
>
>                                           
>
>                                           
>
>                                           
>
>                                           
>
>                                           
>
>                                           
>
>                                         Regards
>
>                                         Sri
>
>                                         PS: Good to see Vijay back
>
>                                           
>
>                                           
>
>                                         On 9/9/14 1:28 PM, "Charlie Perkins"
>
>                                           
>
>                                         wrote:
>
>                                           
>
>                                             Hello folks,
>
>                                               
>
>                                             Here's the last Internet Draft that we did, long ago expired:
>
>                                               
>
>                                             http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt
>
>                                               
>
>                                             I'll resubmit it with a few updates as a personal draft to dmm.
>
>                                               
>
>                                             Regards,
>
>                                             Charlie P.
>
>                                         _______________________________________________
>
>                                         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
>
>     -- 
>
>     ---------------------------------
>
>     Hakima Chaouchi
>
>     Professor
>
>     Telecom Sud Paris
>
>     Institut Mines Telecom
>
>     9 rue Charles Fourier
>
>     91011 Evry
>
>     0160764443
>
>
>
>
> -- 
> Regards,
> Charlie P.

-- 
Regards,
Charlie P.


--------------050108050101000304040401
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    Hello Fred,

    

    I can include DUID-UUID as an identifier type, and cite RFC 4122. 
    Is this

    sufficient, or do I need to also do something related to DHCPv6
    DUID?

    

    I did not see any specific connection between this type of
    identifier and

    the RFID discussion.  Is there something that relates the two types?

    

    Regards,

    Charlie P.

    

    

    

    
On 9/25/2014 2:00 PM, Templin, Fred L
      wrote:

    

    

      
      
      
      
      

        
Hi
            Charlie,

        
 

        
I
            am interested in node IDs that can be represented in a
            DHCPv6 DUID. There is

        
RFC6355
            which encodes a node ID based on DUID-UUID (Universally
            Unique

        
IDentifier).
            AFAICT, the UUID is a 128-bit container formatted per
            RFC4122

        
specifications
            that includes a time portion and a node ID portion. Any
            chance

        
this
            would satisfy what you are looking for?

        
 

        
Thanks
            - Fred

        
 

        

          

            

              
From:
                  dmm [mailto:dmm-bounces@ietf.org]
                  On Behalf Of Charles E. Perkins

                  Sent: Thursday, September 25, 2014 1:43 PM

                  To: Sri Gundavelli (sgundave)

                  Cc: Vijay Devarapalli; dmm@ietf.org

                  Subject: Re: [DMM] MNID Types

            

          

          
 

          


            Hello Sri,

            

            Is the DoD-96 identifier for a special kind of RFID, or is
            it

            valid for all the RFID devices that would be of interest?

            

            Regards,

            Charlie P.

            

            

          

            
On 9/21/2014 9:59 AM, Sri Gundavelli
              (sgundave) wrote:

          

          

            

              
Hi Hakima,

            

            

              
 

            

            

              
That is a good idea. We should
                register a type for the Dod-96 identifier as well.

            

            

              
 

            

            

              
 

            

            

              
Regards

            

            

              
Sri

            

            

              
 

            

            

              
 

            

            

              
From:
                  Hakima
                  Chaouchi <hakima.chaouchi@telecom-sudparis.eu>

                  Date: Sunday, September 21, 2014 8:11 AM

                  To: Sri Gundavelli <sgundave@cisco.com>

                  Cc: Charlie Perkins <charles.perkins@earthlink.net>,
                  Marco Liebsch <Marco.Liebsch@neclab.eu>,
                  "dmm@ietf.org"
                  <dmm@ietf.org>,
                  Vijay Devarapalli <dvijay@rocketmail.com>

                  Subject: Re: [DMM] MNID Types

            

            

              
 

            

            

              

                

                  

                    
Hello Folks,

                  

                  

                    
 

                  

                  

                    
Do you think that considering
                      specific but needed technologies for moving
                      objects in  Internet of Things  such as RFID
                      (Radio Frequency Identifier) with 96 bits
                      identifiers will be also relevent to Charlie's
                      current draft and the efforts related to MNID?  

                  

                  

                    
 

                  

                  

                    
Regards,

                  

                  

                    
 

                  

                  

                    
Hakima

                  

                  

                    
 

                  

                  

                    
 

                  

                  

                    

                  

                  

                    
De:
                        
                      "Sri
                        Gundavelli (sgundave)" <sgundave@cisco.com>

                        À: "Charlie Perkins" <charles.perkins@earthlink.net>,
                        "Marco Liebsch" <Marco.Liebsch@neclab.eu>,
                        dmm@ietf.org,
                        "Vijay Devarapalli" <dvijay@rocketmail.com>

                        Envoyé: Jeudi 11 Septembre 2014 23:57:11

                        Objet: Re: [DMM] MNID Types

                    

                      
 

                    

                    

                      
Hi
                          Charlie,

                    

                    

                      
 

                    

                    

                      
Few
                          more reviews/discussions and capturing the
                          consensus in the base version will help. But,
                          I'm ok either way …

                    

                    

                      
 

                    

                    

                      
 

                    

                    

                      
Regards

                    

                    

                      
Sri

                    

                    

                      
 

                    

                    

                      
From:
                          Charlie
                          Perkins <charles.perkins@earthlink.net>

                          Date: Thursday, September 11, 2014
                          2:46 PM

                          To: Sri Gundavelli <sgundave@cisco.com>,
                          Marco Liebsch <Marco.Liebsch@neclab.eu>,
                          "dmm@ietf.org"
                          <dmm@ietf.org>,
                          Vijay Devarapalli <dvijay@rocketmail.com>

                          Subject: Re: [DMM] MNID Types

                    

                    

                      
 

                    

                    

                      

                        


                          Hello
                            folks,

                            

                            I propose to submit the ....-00.txt document
                            as it is to the Internet

                            Drafts directory, and then to go about
                            making updates according to

                            the discussion on this list.  Do you think
                            this is reasonable?

                            

                            Regards,

                            Charlie P.

                            

                            

                          

                        

                          
On
                              9/11/2014 7:21 AM, Sri Gundavelli
                              (sgundave) wrote:

                        

                        

                          
<Changing the subject line to reflect the MNId discussion>

                          
 

                          
 

                          
Marco,

                          
 

                          
 

                          
Thinking further on the complementary identifier option.

                          
 

                          
- There is already the link-layer identifier option that can be used for

                          
carrying the Mac address

                          
- IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's

                          
 

                          
In some sense, the complementary identifiers are already present.

                          
 

                          
Sri

                          
 

                          
 

                          
 

                          
 

                          
 

                          
On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com> wrote:

                          

                            
I do not see a reason why multiple MN-Id instances need to be present in a

                            
single message ? In my experience, this is strictly a deployment

                            
consideration, when to use what type of identifiers.

                            
 

                            
Assuming the backend system can tie all the MN-Id's to a single

                            
subscription, any presented identifier can be sufficient for the gateway

                            
to do the BCE lookup.

                            
 

                            
If multiple instances can be present, then we need to deal with more error

                            
cases. Is that really needed ?

                            
 

                            
 

                            

                              
I am wondering if it would not be more appropriate to go for a different

                              
container option to carry such information. Something like a

                              
complementary identifier option.

                            

                            
Sounds interesting. Are you suggesting we leave the current MN-ID as it

                            
is, but use a new complementary option ? But, if the requirement is for a

                            
Mac based identifiers, what will be there in the current MN-Id option ? We

                            
still need to have identifier there ?

                            
 

                            
 

                            
 

                            
 

                            
Sri

                            
 

                            
 

                            
 

                            
 

                            
 

                            
On 9/11/14 2:03 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:

                            
 

                            

                              
No issue with logical vs. physical ID. But I am wondering about two

                              
things:

                              
 

                              
Operation is clear to me in case a single MNID is present in a message

                              
and I see the value in being

                              
flexible to choose from different sub-types. If multiple MNIDs with

                              
different sub-types are present in

                              
a single message, which one should e.g. the LMA take for the BC lookup..

                              
No big problem to solve, but

                              
to be considered in implementations.

                              
 

                              
If the reason for multiple present MNIDs with different sub-types is to

                              
do other things than identifying

                              
the node or using the ID as key for a lookup, I am wondering if it would

                              
not be more appropriate

                              
to go for a different container option to carry such information.

                              
Something like a complementary

                              
identifier option.

                              
 

                              
marco

                              
 

                              

                                
-----Original Message-----

                                
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]

                                
Sent: Donnerstag, 11. September 2014 00:42

                                
To: Charlie Perkins; Marco Liebsch; dmm@ietf.org

                                
Cc: Vijay Devarapalli

                                
Subject: Re: [DMM] regarding the re-chartering..

                                
 

                                
Hello Charlie,

                                
 

                                
Agree with that. MN-Id as its defined today is a logical identifier. It

                                
does not

                                
require the identifier to be bound to a physical device or a interface

                                
identity.

                                
But, we have clearly seen requirements where the need is for generating

                                
identifiers based on some physical identifiers. Those physical

                                
identifiers include

                                
IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the

                                
source

                                
and the rules for generating MN-ID based using those sources, the sender

                                
and

                                
receiver will have clear guidance on how to use the spec. Some pointers,

                                
explanation and examples for each of those identifiers will greatly help

                                
avoid

                                
inter-op issues.

                                
 

                                
 

                                
Regards

                                
Sri

                                
 

                                
 

                                
 

                                
 

                                
 

                                
 

                                
 

                                
On 9/10/14 3:21 PM, "Charlie Perkins" <charles.perkins@earthlink.net>

                                
wrote:

                                
 

                                

                                  
Hello folks,

                                  
 

                                  
I think it's best to consider the MNID as simply living in a space of

                                  
identifiers, and not worry too much about whether it's a logical

                                  
identifier or a physical identifier.  If the former, then somewhere

                                  
(perhaps below the network layer) the logical identifier has been bound

                                  
to something in the physical interface, but that's not our problem.

                                  
 

                                  
The number space for types of MNIDs is likely to stay pretty empty, so

                                  
I'd say we could add as many types as would be convenient for the

                                  
software designers.  So, we could conceivably have several MNIDs

                                  
defined that all "looked like" NAIs (which, themselves, "look like"

                                  
FQDNs).

                                  
 

                                  
Regards,

                                  
Charlie P.

                                  
 

                                  
 

                                  
 

                                  
On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:

                                  

                                    
Yes. Currently, the MNID is if the nai format and is overloaded. The

                                    
MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the

                                    
IMSI. Ex:

                                    
"<IMSI>@epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org²

                                    
 

                                    
We also have MAC48@REALM;

                                    
 

                                    
We also have approaches to transform MAC to Pseudo IMSI, and then

                                    
carry IMSI-NAI as the MN-ID.

                                    
 

                                    
 

                                    
So, we need unique sub-types for each of the types/sources.

                                    
 

                                    
MN-Id based on IMSI, MSISDN, IMEI, MAC ..

                                    
 

                                    
Also, do we need to distinguish between IMSI and IMSI-NAI ?

                                    
 

                                    
Sri

                                    
 

                                    
 

                                    
 

                                    
On 9/10/14 6:29 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:

                                    
 

                                    

                                      
It seems the MNID is somehow overloaded to carry both, node-specific

                                      
IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.

                                      
There may be value in adding the IMEI to the list of possible types

                                      
of  node-specific IDs.

                                      
 

                                      
marco

                                      
 

                                      

                                        
-----Original Message-----

                                        
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli

                                        
(sgundave)

                                        
Sent: Dienstag, 9. September 2014 23:30

                                        
To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org

                                        
Cc: Vijay Devarapalli

                                        
Subject: Re: [DMM] regarding the re-chartering..

                                        
 

                                        
Two more comments.

                                        
 

                                        
 

                                        
 

                                        
4.) I'd also use sub-type value of (2) for IMSI. Just to align with

                                        
the  sub-types  defined for MN Id defined for ICMP. I suspect there

                                        
are some  implementations  already using sub-type (2). Please see

                                        
the other thread.

                                        
 

                                        
 

                                        
5.) For each of the sub-types, we need text including examples and

                                        
some

                                        
explanation on how they are used.

                                        
 

                                        
 

                                        
Sri

                                        
 

                                        
 

                                        
 

                                        
On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>

                                        
wrote:

                                        
 

                                        

                                          
Hi Charlie,

                                          
 

                                          
This is good. Thanks.

                                          
 

                                          
 

                                          
1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE

                                          
802.2

                                          
address, why do we need to two sub-types ? Why not have just one

                                          
sub-type for mac based identifiers ?

                                          
 

                                          
2.) Sub type value (1) is currently used. Its currently overloaded

                                          
for

                                          
IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the

                                          
definition of new sub-types, we need some text explaining the

                                          
motivation

                                          
 

                                          
3.) Proposed Sub-type value of (2) for IPv6 address. What exactly

                                          
is

                                          
this ? Are these CGA-based IPv6 addresses ?

                                          
 

                                          
 

                                          
 

                                          
 

                                          
                     New Mobile Node Identifier Types

                                          
 

                                          
               +-----------------+------------------------+

                                          
               | Identifier Type | Identifier Type Number |

                                          
               +-----------------+------------------------+

                                          
               | IPv6 Address    | 2                      |

                                          
               |                 |                        |

                                          
               | IMSI            | 3                      |

                                          
               |                 |                        |

                                          
               | P-TMSI          | 4                      |

                                          
               |                 |                        |

                                          
               | EUI-48 address  | 5                      |

                                          
               |                 |                        |

                                          
               | EUI-64 address  | 6                      |

                                          
               |                 |                        |

                                          
               | GUTI            | 7                      |

                                          
               +-----------------+------------------------+

                                          
 

                                          
 

                                          
 

                                          
 

                                          
 

                                          
 

                                          
 

                                          
Regards

                                          
Sri

                                          
PS: Good to see Vijay back

                                          
 

                                          
 

                                          
On 9/9/14 1:28 PM, "Charlie Perkins"

                                          
<charles.perkins@earthlink.net>

                                          
wrote:

                                          
 

                                          

                                            
Hello folks,

                                            
 

                                            
Here's the last Internet Draft that we did, long ago expired:

                                            
 

                                            
http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt

                                            
 

                                            
I'll resubmit it with a few updates as a personal draft to dmm.

                                            
 

                                            
Regards,

                                            
Charlie P.

                                          

                                          
_______________________________________________

                                          
dmm mailing list

                                          
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm

                                        

                                        
_______________________________________________

                                        
dmm mailing list

                                        
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm

                                      

                                    

                                  

                                

                              

                            

                            
_______________________________________________

                            
dmm mailing list

                            
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm

                          

                          
_______________________________________________

                          
dmm mailing list

                          
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm

                        

                        
 

                      

                    

                    


                        _______________________________________________

                        dmm mailing list

                        dmm@ietf.org

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

                  

                  

                    
 

                  

                  

                    
 

                  

                  

                    
-- 

                  

                  

                    

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

                    

                    

                      
Hakima Chaouchi

                    

                    

                      
Professor

                    

                    

                      
Telecom Sud Paris

                    

                    

                      
Institut Mines Telecom

                    

                    

                      
9 rue Charles Fourier

                    

                    

                      
91011 Evry

                    

                    

                      
0160764443

                    

                    
 

                  

                

              

            

          

          


            

            

            

          
-- 

          
Regards,

          
Charlie P.

        

      

    

    

    
-- 
Regards,
Charlie P.

  


--------------050108050101000304040401--


From nobody Thu Sep 25 14:13:17 2014
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 ED2AF1A0376 for ; Thu, 25 Sep 2014 14:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 xwV8bB9LJ_pi for ; Thu, 25 Sep 2014 14:13:11 -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 838EC1A0371 for ; Thu, 25 Sep 2014 14:13:11 -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 s8PLDBcT011553; Thu, 25 Sep 2014 14:13:11 -0700
Received: from XCH-BLV-401.nw.nos.boeing.com (xch-blv-401.nw.nos.boeing.com [130.247.25.18]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8PLD42S011459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 25 Sep 2014 14:13:05 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-401.nw.nos.boeing.com ([169.254.1.253]) with mapi id 14.03.0181.006; Thu, 25 Sep 2014 14:13:03 -0700
From: "Templin, Fred L" 
To: "Charles E. Perkins" , "Sri Gundavelli (sgundave)" 
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHP2QFRBFXGK7SLlEqDWEHLMXPWTJwSUuCwgAB6KgD//4tscA==
Date: Thu, 25 Sep 2014 21:13:03 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D27B99@XCH-BLV-504.nw.nos.boeing.com>
References:  <54247E3C.7050800@computer.org> <2134F8430051B64F815C691A62D9831832D27B1E@XCH-BLV-504.nw.nos.boeing.com> <5424844C.1020101@computer.org>
In-Reply-To: <5424844C.1020101@computer.org>
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_2134F8430051B64F815C691A62D9831832D27B99XCHBLV504nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/PDz5rZL_PO_1F0OugG-bO7NKfjU
Cc: Vijay Devarapalli , "dmm@ietf.org" 
Subject: Re: [DMM] MNID Types
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, 25 Sep 2014 21:13:15 -0000

--_000_2134F8430051B64F815C691A62D9831832D27B99XCHBLV504nwnosb_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQ2hhcmxpZSwNCg0KSSBndWVzcyBJIGhhdmUgdG8gc2F5IOKAnEkgZG9u4oCZdCBrbm934oCd
IHRvIGJvdGggcXVlc3Rpb25zLiBNTklEcyBhcmUgYSBmYWlybHkgbmV3IHN1YmplY3QNCmZvciBt
ZSwgYW5kIEkgdGhpbmsgb3RoZXJzIHdvdWxkIGJlIGJldHRlciBxdWFsaWZpZWQgdG8gYW5zd2Vy
LiBKdXN0IHRob3VnaHQgSSB3b3VsZA0Kb2ZmZXIgd2hhdCBJIGRvIGtub3cgaW4gY2FzZSBpdCBt
aWdodCBiZSBvZiBzb21lIGhlbHAuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogQ2hhcmxlcyBF
LiBQZXJraW5zIFttYWlsdG86Y2hhcmxpZXBAY29tcHV0ZXIub3JnXQ0KU2VudDogVGh1cnNkYXks
IFNlcHRlbWJlciAyNSwgMjAxNCAyOjA4IFBNDQpUbzogVGVtcGxpbiwgRnJlZCBMOyBTcmkgR3Vu
ZGF2ZWxsaSAoc2d1bmRhdmUpDQpDYzogVmlqYXkgRGV2YXJhcGFsbGk7IGRtbUBpZXRmLm9yZw0K
U3ViamVjdDogUmU6IFtETU1dIE1OSUQgVHlwZXMNCg0KDQpIZWxsbyBGcmVkLA0KDQpJIGNhbiBp
bmNsdWRlIERVSUQtVVVJRCBhcyBhbiBpZGVudGlmaWVyIHR5cGUsIGFuZCBjaXRlIFJGQyA0MTIy
LiAgSXMgdGhpcw0Kc3VmZmljaWVudCwgb3IgZG8gSSBuZWVkIHRvIGFsc28gZG8gc29tZXRoaW5n
IHJlbGF0ZWQgdG8gREhDUHY2IERVSUQ/DQoNCkkgZGlkIG5vdCBzZWUgYW55IHNwZWNpZmljIGNv
bm5lY3Rpb24gYmV0d2VlbiB0aGlzIHR5cGUgb2YgaWRlbnRpZmllciBhbmQNCnRoZSBSRklEIGRp
c2N1c3Npb24uICBJcyB0aGVyZSBzb21ldGhpbmcgdGhhdCByZWxhdGVzIHRoZSB0d28gdHlwZXM/
DQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCg0KT24gOS8yNS8yMDE0IDI6MDAgUE0sIFRlbXBs
aW4sIEZyZWQgTCB3cm90ZToNCkhpIENoYXJsaWUsDQoNCkkgYW0gaW50ZXJlc3RlZCBpbiBub2Rl
IElEcyB0aGF0IGNhbiBiZSByZXByZXNlbnRlZCBpbiBhIERIQ1B2NiBEVUlELiBUaGVyZSBpcw0K
UkZDNjM1NSB3aGljaCBlbmNvZGVzIGEgbm9kZSBJRCBiYXNlZCBvbiBEVUlELVVVSUQgKFVuaXZl
cnNhbGx5IFVuaXF1ZQ0KSURlbnRpZmllcikuIEFGQUlDVCwgdGhlIFVVSUQgaXMgYSAxMjgtYml0
IGNvbnRhaW5lciBmb3JtYXR0ZWQgcGVyIFJGQzQxMjINCnNwZWNpZmljYXRpb25zIHRoYXQgaW5j
bHVkZXMgYSB0aW1lIHBvcnRpb24gYW5kIGEgbm9kZSBJRCBwb3J0aW9uLiBBbnkgY2hhbmNlDQp0
aGlzIHdvdWxkIHNhdGlzZnkgd2hhdCB5b3UgYXJlIGxvb2tpbmcgZm9yPw0KDQpUaGFua3MgLSBG
cmVkDQoNCkZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgQ2hhcmxlcyBFLiBQZXJraW5zDQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0
IDE6NDMgUE0NClRvOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpDQpDYzogVmlqYXkgRGV2YXJh
cGFsbGk7IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtE
TU1dIE1OSUQgVHlwZXMNCg0KDQpIZWxsbyBTcmksDQoNCklzIHRoZSBEb0QtOTYgaWRlbnRpZmll
ciBmb3IgYSBzcGVjaWFsIGtpbmQgb2YgUkZJRCwgb3IgaXMgaXQNCnZhbGlkIGZvciBhbGwgdGhl
IFJGSUQgZGV2aWNlcyB0aGF0IHdvdWxkIGJlIG9mIGludGVyZXN0Pw0KDQpSZWdhcmRzLA0KQ2hh
cmxpZSBQLg0KDQoNCk9uIDkvMjEvMjAxNCA5OjU5IEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRh
dmUpIHdyb3RlOg0KSGkgSGFraW1hLA0KDQpUaGF0IGlzIGEgZ29vZCBpZGVhLiBXZSBzaG91bGQg
cmVnaXN0ZXIgYSB0eXBlIGZvciB0aGUgRG9kLTk2IGlkZW50aWZpZXIgYXMgd2VsbC4NCg0KDQpS
ZWdhcmRzDQpTcmkNCg0KDQpGcm9tOiBIYWtpbWEgQ2hhb3VjaGkgPGhha2ltYS5jaGFvdWNoaUB0
ZWxlY29tLXN1ZHBhcmlzLmV1PG1haWx0bzpoYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJp
cy5ldT4+DQpEYXRlOiBTdW5kYXksIFNlcHRlbWJlciAyMSwgMjAxNCA4OjExIEFNDQpUbzogU3Jp
IEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29t
Pj4NCkNjOiBDaGFybGllIFBlcmtpbnMgPGNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PG1h
aWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4+LCBNYXJjbyBMaWVic2NoIDxNYXJj
by5MaWVic2NoQG5lY2xhYi5ldTxtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PiwgImRt
bUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiIgPGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1t
QGlldGYub3JnPj4sIFZpamF5IERldmFyYXBhbGxpIDxkdmlqYXlAcm9ja2V0bWFpbC5jb208bWFp
bHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogW0RNTV0gTU5JRCBUeXBl
cw0KDQpIZWxsbyBGb2xrcywNCg0KRG8geW91IHRoaW5rIHRoYXQgY29uc2lkZXJpbmcgc3BlY2lm
aWMgYnV0IG5lZWRlZCB0ZWNobm9sb2dpZXMgZm9yIG1vdmluZyBvYmplY3RzIGluICBJbnRlcm5l
dCBvZiBUaGluZ3MgIHN1Y2ggYXMgUkZJRCAoUmFkaW8gRnJlcXVlbmN5IElkZW50aWZpZXIpIHdp
dGggOTYgYml0cyBpZGVudGlmaWVycyB3aWxsIGJlIGFsc28gcmVsZXZlbnQgdG8gQ2hhcmxpZSdz
IGN1cnJlbnQgZHJhZnQgYW5kIHRoZSBlZmZvcnRzIHJlbGF0ZWQgdG8gTU5JRD8NCg0KUmVnYXJk
cywNCg0KSGFraW1hDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRlOiAi
U3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSIgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1
bmRhdmVAY2lzY28uY29tPj4NCsOAOiAiQ2hhcmxpZSBQZXJraW5zIiA8Y2hhcmxlcy5wZXJraW5z
QGVhcnRobGluay5uZXQ8bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pj4sICJN
YXJjbyBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8bWFpbHRvOk1hcmNvLkxpZWJz
Y2hAbmVjbGFiLmV1Pj4sIGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiwgIlZpamF5
IERldmFyYXBhbGxpIiA8ZHZpamF5QHJvY2tldG1haWwuY29tPG1haWx0bzpkdmlqYXlAcm9ja2V0
bWFpbC5jb20+Pg0KRW52b3nDqTogSmV1ZGkgMTEgU2VwdGVtYnJlIDIwMTQgMjM6NTc6MTENCk9i
amV0OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0KDQpIaSBDaGFybGllLA0KDQpGZXcgbW9yZSByZXZp
ZXdzL2Rpc2N1c3Npb25zIGFuZCBjYXB0dXJpbmcgdGhlIGNvbnNlbnN1cyBpbiB0aGUgYmFzZSB2
ZXJzaW9uIHdpbGwgaGVscC4gQnV0LCBJJ20gb2sgZWl0aGVyIHdheSDigKYNCg0KDQpSZWdhcmRz
DQpTcmkNCg0KRnJvbTogQ2hhcmxpZSBQZXJraW5zIDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5r
Lm5ldDxtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+Pg0KRGF0ZTogVGh1cnNk
YXksIFNlcHRlbWJlciAxMSwgMjAxNCAyOjQ2IFBNDQpUbzogU3JpIEd1bmRhdmVsbGkgPHNndW5k
YXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4sIE1hcmNvIExpZWJzY2gg
PE1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PG1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldT4+
LCAiZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+IiA8ZG1tQGlldGYub3JnPG1haWx0
bzpkbW1AaWV0Zi5vcmc+PiwgVmlqYXkgRGV2YXJhcGFsbGkgPGR2aWpheUByb2NrZXRtYWlsLmNv
bTxtYWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29tPj4NClN1YmplY3Q6IFJlOiBbRE1NXSBNTklE
IFR5cGVzDQoNCg0KSGVsbG8gZm9sa3MsDQoNCkkgcHJvcG9zZSB0byBzdWJtaXQgdGhlIC4uLi4t
MDAudHh0IGRvY3VtZW50IGFzIGl0IGlzIHRvIHRoZSBJbnRlcm5ldA0KRHJhZnRzIGRpcmVjdG9y
eSwgYW5kIHRoZW4gdG8gZ28gYWJvdXQgbWFraW5nIHVwZGF0ZXMgYWNjb3JkaW5nIHRvDQp0aGUg
ZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3QuICBEbyB5b3UgdGhpbmsgdGhpcyBpcyByZWFzb25hYmxl
Pw0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCg0KT24gOS8xMS8yMDE0IDc6MjEgQU0sIFNy
aSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6DQoNCjxDaGFuZ2luZyB0aGUgc3ViamVjdCBs
aW5lIHRvIHJlZmxlY3QgdGhlIE1OSWQgZGlzY3Vzc2lvbj4NCg0KDQoNCg0KDQpNYXJjbywNCg0K
DQoNCg0KDQpUaGlua2luZyBmdXJ0aGVyIG9uIHRoZSBjb21wbGVtZW50YXJ5IGlkZW50aWZpZXIg
b3B0aW9uLg0KDQoNCg0KLSBUaGVyZSBpcyBhbHJlYWR5IHRoZSBsaW5rLWxheWVyIGlkZW50aWZp
ZXIgb3B0aW9uIHRoYXQgY2FuIGJlIHVzZWQgZm9yDQoNCmNhcnJ5aW5nIHRoZSBNYWMgYWRkcmVz
cw0KDQotIElNRUkgYW5kIE1TSVNETiBhcmUgYWxyZWFkeSBkZWZpbmVkIGluIDI5LjI3NSBhcyBh
IDNHUFAgVlNFJ3MNCg0KDQoNCkluIHNvbWUgc2Vuc2UsIHRoZSBjb21wbGVtZW50YXJ5IGlkZW50
aWZpZXJzIGFyZSBhbHJlYWR5IHByZXNlbnQuDQoNCg0KDQpTcmkNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQpPbiA5LzExLzE0IDY6NTggQU0sICJTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIiA8c2d1
bmRhdmVAY2lzY28uY29tPjxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPiB3cm90ZToNCg0KSSBk
byBub3Qgc2VlIGEgcmVhc29uIHdoeSBtdWx0aXBsZSBNTi1JZCBpbnN0YW5jZXMgbmVlZCB0byBi
ZSBwcmVzZW50IGluIGENCg0Kc2luZ2xlIG1lc3NhZ2UgPyBJbiBteSBleHBlcmllbmNlLCB0aGlz
IGlzIHN0cmljdGx5IGEgZGVwbG95bWVudA0KDQpjb25zaWRlcmF0aW9uLCB3aGVuIHRvIHVzZSB3
aGF0IHR5cGUgb2YgaWRlbnRpZmllcnMuDQoNCg0KDQpBc3N1bWluZyB0aGUgYmFja2VuZCBzeXN0
ZW0gY2FuIHRpZSBhbGwgdGhlIE1OLUlkJ3MgdG8gYSBzaW5nbGUNCg0Kc3Vic2NyaXB0aW9uLCBh
bnkgcHJlc2VudGVkIGlkZW50aWZpZXIgY2FuIGJlIHN1ZmZpY2llbnQgZm9yIHRoZSBnYXRld2F5
DQoNCnRvIGRvIHRoZSBCQ0UgbG9va3VwLg0KDQoNCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIGNh
biBiZSBwcmVzZW50LCB0aGVuIHdlIG5lZWQgdG8gZGVhbCB3aXRoIG1vcmUgZXJyb3INCg0KY2Fz
ZXMuIElzIHRoYXQgcmVhbGx5IG5lZWRlZCA/DQoNCg0KDQoNCg0KSSBhbSB3b25kZXJpbmcgaWYg
aXQgd291bGQgbm90IGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gZ28gZm9yIGEgZGlmZmVyZW50DQoN
CmNvbnRhaW5lciBvcHRpb24gdG8gY2Fycnkgc3VjaCBpbmZvcm1hdGlvbi4gU29tZXRoaW5nIGxp
a2UgYQ0KDQpjb21wbGVtZW50YXJ5IGlkZW50aWZpZXIgb3B0aW9uLg0KDQpTb3VuZHMgaW50ZXJl
c3RpbmcuIEFyZSB5b3Ugc3VnZ2VzdGluZyB3ZSBsZWF2ZSB0aGUgY3VycmVudCBNTi1JRCBhcyBp
dA0KDQppcywgYnV0IHVzZSBhIG5ldyBjb21wbGVtZW50YXJ5IG9wdGlvbiA/IEJ1dCwgaWYgdGhl
IHJlcXVpcmVtZW50IGlzIGZvciBhDQoNCk1hYyBiYXNlZCBpZGVudGlmaWVycywgd2hhdCB3aWxs
IGJlIHRoZXJlIGluIHRoZSBjdXJyZW50IE1OLUlkIG9wdGlvbiA/IFdlDQoNCnN0aWxsIG5lZWQg
dG8gaGF2ZSBpZGVudGlmaWVyIHRoZXJlID8NCg0KDQoNCg0KDQoNCg0KDQoNClNyaQ0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCk9uIDkvMTEvMTQgMjowMyBBTSwgIk1hcmNvIExpZWJzY2giIDxNYXJj
by5MaWVic2NoQG5lY2xhYi5ldT48bWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PiB3cm90
ZToNCg0KDQoNCk5vIGlzc3VlIHdpdGggbG9naWNhbCB2cy4gcGh5c2ljYWwgSUQuIEJ1dCBJIGFt
IHdvbmRlcmluZyBhYm91dCB0d28NCg0KdGhpbmdzOg0KDQoNCg0KT3BlcmF0aW9uIGlzIGNsZWFy
IHRvIG1lIGluIGNhc2UgYSBzaW5nbGUgTU5JRCBpcyBwcmVzZW50IGluIGEgbWVzc2FnZQ0KDQph
bmQgSSBzZWUgdGhlIHZhbHVlIGluIGJlaW5nDQoNCmZsZXhpYmxlIHRvIGNob29zZSBmcm9tIGRp
ZmZlcmVudCBzdWItdHlwZXMuIElmIG11bHRpcGxlIE1OSURzIHdpdGgNCg0KZGlmZmVyZW50IHN1
Yi10eXBlcyBhcmUgcHJlc2VudCBpbg0KDQphIHNpbmdsZSBtZXNzYWdlLCB3aGljaCBvbmUgc2hv
dWxkIGUuZy4gdGhlIExNQSB0YWtlIGZvciB0aGUgQkMgbG9va3VwLi4NCg0KTm8gYmlnIHByb2Js
ZW0gdG8gc29sdmUsIGJ1dA0KDQp0byBiZSBjb25zaWRlcmVkIGluIGltcGxlbWVudGF0aW9ucy4N
Cg0KDQoNCklmIHRoZSByZWFzb24gZm9yIG11bHRpcGxlIHByZXNlbnQgTU5JRHMgd2l0aCBkaWZm
ZXJlbnQgc3ViLXR5cGVzIGlzIHRvDQoNCmRvIG90aGVyIHRoaW5ncyB0aGFuIGlkZW50aWZ5aW5n
DQoNCnRoZSBub2RlIG9yIHVzaW5nIHRoZSBJRCBhcyBrZXkgZm9yIGEgbG9va3VwLCBJIGFtIHdv
bmRlcmluZyBpZiBpdCB3b3VsZA0KDQpub3QgYmUgbW9yZSBhcHByb3ByaWF0ZQ0KDQp0byBnbyBm
b3IgYSBkaWZmZXJlbnQgY29udGFpbmVyIG9wdGlvbiB0byBjYXJyeSBzdWNoIGluZm9ybWF0aW9u
Lg0KDQpTb21ldGhpbmcgbGlrZSBhIGNvbXBsZW1lbnRhcnkNCg0KaWRlbnRpZmllciBvcHRpb24u
DQoNCg0KDQptYXJjbw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTog
U3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSBbbWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbV0NCg0K
U2VudDogRG9ubmVyc3RhZywgMTEuIFNlcHRlbWJlciAyMDE0IDAwOjQyDQoNClRvOiBDaGFybGll
IFBlcmtpbnM7IE1hcmNvIExpZWJzY2g7IGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3Jn
Pg0KDQpDYzogVmlqYXkgRGV2YXJhcGFsbGkNCg0KU3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGlu
ZyB0aGUgcmUtY2hhcnRlcmluZy4uDQoNCg0KDQpIZWxsbyBDaGFybGllLA0KDQoNCg0KQWdyZWUg
d2l0aCB0aGF0LiBNTi1JZCBhcyBpdHMgZGVmaW5lZCB0b2RheSBpcyBhIGxvZ2ljYWwgaWRlbnRp
Zmllci4gSXQNCg0KZG9lcyBub3QNCg0KcmVxdWlyZSB0aGUgaWRlbnRpZmllciB0byBiZSBib3Vu
ZCB0byBhIHBoeXNpY2FsIGRldmljZSBvciBhIGludGVyZmFjZQ0KDQppZGVudGl0eS4NCg0KQnV0
LCB3ZSBoYXZlIGNsZWFybHkgc2VlbiByZXF1aXJlbWVudHMgd2hlcmUgdGhlIG5lZWQgaXMgZm9y
IGdlbmVyYXRpbmcNCg0KaWRlbnRpZmllcnMgYmFzZWQgb24gc29tZSBwaHlzaWNhbCBpZGVudGlm
aWVycy4gVGhvc2UgcGh5c2ljYWwNCg0KaWRlbnRpZmllcnMgaW5jbHVkZQ0KDQpJTVNJLCBNU0lT
RE4sIElNRUksIE1BQyAuLmV0Yy4gSWYgd2UgY2FuIGRlZmluZSBhIHR5cGUgZm9yIGVhY2ggb2Yg
dGhlDQoNCnNvdXJjZQ0KDQphbmQgdGhlIHJ1bGVzIGZvciBnZW5lcmF0aW5nIE1OLUlEIGJhc2Vk
IHVzaW5nIHRob3NlIHNvdXJjZXMsIHRoZSBzZW5kZXINCg0KYW5kDQoNCnJlY2VpdmVyIHdpbGwg
aGF2ZSBjbGVhciBndWlkYW5jZSBvbiBob3cgdG8gdXNlIHRoZSBzcGVjLiBTb21lIHBvaW50ZXJz
LA0KDQpleHBsYW5hdGlvbiBhbmQgZXhhbXBsZXMgZm9yIGVhY2ggb2YgdGhvc2UgaWRlbnRpZmll
cnMgd2lsbCBncmVhdGx5IGhlbHANCg0KYXZvaWQNCg0KaW50ZXItb3AgaXNzdWVzLg0KDQoNCg0K
DQoNClJlZ2FyZHMNCg0KU3JpDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiA5LzEw
LzE0IDM6MjEgUE0sICJDaGFybGllIFBlcmtpbnMiIDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5r
Lm5ldD48bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pg0KDQp3cm90ZToNCg0K
DQoNCkhlbGxvIGZvbGtzLA0KDQoNCg0KSSB0aGluayBpdCdzIGJlc3QgdG8gY29uc2lkZXIgdGhl
IE1OSUQgYXMgc2ltcGx5IGxpdmluZyBpbiBhIHNwYWNlIG9mDQoNCmlkZW50aWZpZXJzLCBhbmQg
bm90IHdvcnJ5IHRvbyBtdWNoIGFib3V0IHdoZXRoZXIgaXQncyBhIGxvZ2ljYWwNCg0KaWRlbnRp
ZmllciBvciBhIHBoeXNpY2FsIGlkZW50aWZpZXIuICBJZiB0aGUgZm9ybWVyLCB0aGVuIHNvbWV3
aGVyZQ0KDQoocGVyaGFwcyBiZWxvdyB0aGUgbmV0d29yayBsYXllcikgdGhlIGxvZ2ljYWwgaWRl
bnRpZmllciBoYXMgYmVlbiBib3VuZA0KDQp0byBzb21ldGhpbmcgaW4gdGhlIHBoeXNpY2FsIGlu
dGVyZmFjZSwgYnV0IHRoYXQncyBub3Qgb3VyIHByb2JsZW0uDQoNCg0KDQpUaGUgbnVtYmVyIHNw
YWNlIGZvciB0eXBlcyBvZiBNTklEcyBpcyBsaWtlbHkgdG8gc3RheSBwcmV0dHkgZW1wdHksIHNv
DQoNCkknZCBzYXkgd2UgY291bGQgYWRkIGFzIG1hbnkgdHlwZXMgYXMgd291bGQgYmUgY29udmVu
aWVudCBmb3IgdGhlDQoNCnNvZnR3YXJlIGRlc2lnbmVycy4gIFNvLCB3ZSBjb3VsZCBjb25jZWl2
YWJseSBoYXZlIHNldmVyYWwgTU5JRHMNCg0KZGVmaW5lZCB0aGF0IGFsbCAibG9va2VkIGxpa2Ui
IE5BSXMgKHdoaWNoLCB0aGVtc2VsdmVzLCAibG9vayBsaWtlIg0KDQpGUUROcykuDQoNCg0KDQpS
ZWdhcmRzLA0KDQpDaGFybGllIFAuDQoNCg0KDQoNCg0KDQoNCk9uIDkvMTAvMjAxNCA4OjExIEFN
LCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0KDQpZZXMuIEN1cnJlbnRseSwgdGhl
IE1OSUQgaXMgaWYgdGhlIG5haSBmb3JtYXQgYW5kIGlzIG92ZXJsb2FkZWQuIFRoZQ0KDQpNTklE
ICBpbiAzR1BQIHNwZWNzIGlzIHRoZSBJTVNJLU5BSSAoSU1TSUBSRUFMTSksIGl0cyBiYXNlZCBv
biB0aGUNCg0KSU1TSS4gRXg6DQoNCiI8SU1TST5AZXBjLm1uYzxNTkM+Lm1jYzxNQ0M+LjNncHBu
ZXR3b3JrLm9yZ8KyDQoNCg0KDQpXZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07DQoNCg0KDQpXZSBh
bHNvIGhhdmUgYXBwcm9hY2hlcyB0byB0cmFuc2Zvcm0gTUFDIHRvIFBzZXVkbyBJTVNJLCBhbmQg
dGhlbg0KDQpjYXJyeSBJTVNJLU5BSSBhcyB0aGUgTU4tSUQuDQoNCg0KDQoNCg0KU28sIHdlIG5l
ZWQgdW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBvZiB0aGUgdHlwZXMvc291cmNlcy4NCg0KDQoN
Ck1OLUlkIGJhc2VkIG9uIElNU0ksIE1TSVNETiwgSU1FSSwgTUFDIC4uDQoNCg0KDQpBbHNvLCBk
byB3ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gSU1TSSBhbmQgSU1TSS1OQUkgPw0KDQoN
Cg0KU3JpDQoNCg0KDQoNCg0KDQoNCk9uIDkvMTAvMTQgNjoyOSBBTSwgIk1hcmNvIExpZWJzY2gi
IDxNYXJjby5MaWVic2NoQG5lY2xhYi5ldT48bWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1
PiB3cm90ZToNCg0KDQoNCkl0IHNlZW1zIHRoZSBNTklEIGlzIHNvbWVob3cgb3ZlcmxvYWRlZCB0
byBjYXJyeSBib3RoLCBub2RlLXNwZWNpZmljDQoNCklEcywgIGUuZy4gTUFDLCBhcyB3ZWxsIGFz
IHN1YnNjcmliZXIgSURzLCB3aGljaCBpcyB0aGUgSU1TSS4NCg0KVGhlcmUgbWF5IGJlIHZhbHVl
IGluIGFkZGluZyB0aGUgSU1FSSB0byB0aGUgbGlzdCBvZiBwb3NzaWJsZSB0eXBlcw0KDQpvZiAg
bm9kZS1zcGVjaWZpYyBJRHMuDQoNCg0KDQptYXJjbw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCg0KRnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBTcmkgR3VuZGF2ZWxsaQ0KDQooc2d1bmRhdmUpDQoNClNlbnQ6IERpZW5zdGFnLCA5
LiBTZXB0ZW1iZXIgMjAxNCAyMzozMA0KDQpUbzogU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKTsg
Q2hhcmxpZSBQZXJraW5zOyBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCg0KQ2M6
IFZpamF5IERldmFyYXBhbGxpDQoNClN1YmplY3Q6IFJlOiBbRE1NXSByZWdhcmRpbmcgdGhlIHJl
LWNoYXJ0ZXJpbmcuLg0KDQoNCg0KVHdvIG1vcmUgY29tbWVudHMuDQoNCg0KDQoNCg0KDQoNCjQu
KSBJJ2QgYWxzbyB1c2Ugc3ViLXR5cGUgdmFsdWUgb2YgKDIpIGZvciBJTVNJLiBKdXN0IHRvIGFs
aWduIHdpdGgNCg0KdGhlICBzdWItdHlwZXMgIGRlZmluZWQgZm9yIE1OIElkIGRlZmluZWQgZm9y
IElDTVAuIEkgc3VzcGVjdCB0aGVyZQ0KDQphcmUgc29tZSAgaW1wbGVtZW50YXRpb25zICBhbHJl
YWR5IHVzaW5nIHN1Yi10eXBlICgyKS4gUGxlYXNlIHNlZQ0KDQp0aGUgb3RoZXIgdGhyZWFkLg0K
DQoNCg0KDQoNCjUuKSBGb3IgZWFjaCBvZiB0aGUgc3ViLXR5cGVzLCB3ZSBuZWVkIHRleHQgaW5j
bHVkaW5nIGV4YW1wbGVzIGFuZA0KDQpzb21lDQoNCmV4cGxhbmF0aW9uIG9uIGhvdyB0aGV5IGFy
ZSB1c2VkLg0KDQoNCg0KDQoNClNyaQ0KDQoNCg0KDQoNCg0KDQpPbiA5LzkvMTQgMjoyMCBQTSwg
IlNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb20+PG1haWx0bzpz
Z3VuZGF2ZUBjaXNjby5jb20+DQoNCndyb3RlOg0KDQoNCg0KSGkgQ2hhcmxpZSwNCg0KDQoNClRo
aXMgaXMgZ29vZC4gVGhhbmtzLg0KDQoNCg0KDQoNCjEuKSBJZiBFVUktNDggYW5kIEVVSS02NCBh
ZGRyZXNzZXMgYXJlIGRlcml2ZWQgb2YgYSA0OC1iaXQgSUVFRQ0KDQo4MDIuMg0KDQphZGRyZXNz
LCB3aHkgZG8gd2UgbmVlZCB0byB0d28gc3ViLXR5cGVzID8gV2h5IG5vdCBoYXZlIGp1c3Qgb25l
DQoNCnN1Yi10eXBlIGZvciBtYWMgYmFzZWQgaWRlbnRpZmllcnMgPw0KDQoNCg0KMi4pIFN1YiB0
eXBlIHZhbHVlICgxKSBpcyBjdXJyZW50bHkgdXNlZC4gSXRzIGN1cnJlbnRseSBvdmVybG9hZGVk
DQoNCmZvcg0KDQpJTVNJLU5BSSAoM0dQUCBzcGVjcykgYW5kIGdlbmVyaWMgTkFJIGJhc2VkIGlk
ZW50aWZpZXJzLiBHaXZlbiB0aGUNCg0KZGVmaW5pdGlvbiBvZiBuZXcgc3ViLXR5cGVzLCB3ZSBu
ZWVkIHNvbWUgdGV4dCBleHBsYWluaW5nIHRoZQ0KDQptb3RpdmF0aW9uDQoNCg0KDQozLikgUHJv
cG9zZWQgU3ViLXR5cGUgdmFsdWUgb2YgKDIpIGZvciBJUHY2IGFkZHJlc3MuIFdoYXQgZXhhY3Rs
eQ0KDQppcw0KDQp0aGlzID8gQXJlIHRoZXNlIENHQS1iYXNlZCBJUHY2IGFkZHJlc3NlcyA/DQoN
Cg0KDQoNCg0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICBOZXcgTW9iaWxlIE5vZGUgSWRl
bnRpZmllciBUeXBlcw0KDQoNCg0KICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgICAgfCBJZGVudGlmaWVyIFR5
cGUgfCBJZGVudGlmaWVyIFR5cGUgTnVtYmVyIHwNCg0KICAgICAgICAgICAgICAgKy0tLS0tLS0t
LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgICAgfCBJ
UHY2IEFkZHJlc3MgICAgfCAyICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAg
ICAgICAgICAgfCBJTVNJICAgICAgICAgICAgfCAzICAgICAgICAgICAgICAgICAgICAgIHwNCg0K
ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg
IHwNCg0KICAgICAgICAgICAgICAgfCBQLVRNU0kgICAgICAgICAgfCA0ICAgICAgICAgICAgICAg
ICAgICAgIHwNCg0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg
ICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgfCBFVUktNDggYWRkcmVzcyAgfCA1ICAg
ICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg
fCAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgfCBFVUktNjQgYWRk
cmVzcyAgfCA2ICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgfCAgICAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAg
fCBHVVRJICAgICAgICAgICAgfCA3ICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAg
ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMNCg0KU3JpDQoNClBTOiBHb29kIHRvIHNl
ZSBWaWpheSBiYWNrDQoNCg0KDQoNCg0KT24gOS85LzE0IDE6MjggUE0sICJDaGFybGllIFBlcmtp
bnMiDQoNCjxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD48bWFpbHRvOmNoYXJsZXMucGVy
a2luc0BlYXJ0aGxpbmsubmV0Pg0KDQp3cm90ZToNCg0KDQoNCkhlbGxvIGZvbGtzLA0KDQoNCg0K
SGVyZSdzIHRoZSBsYXN0IEludGVybmV0IERyYWZ0IHRoYXQgd2UgZGlkLCBsb25nIGFnbyBleHBp
cmVkOg0KDQoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXBlcmtpbnMt
bWV4dC00MjgzbW5pZHMtMDEudHh0DQoNCg0KDQpJJ2xsIHJlc3VibWl0IGl0IHdpdGggYSBmZXcg
dXBkYXRlcyBhcyBhIHBlcnNvbmFsIGRyYWZ0IHRvIGRtbS4NCg0KDQoNClJlZ2FyZHMsDQoNCkNo
YXJsaWUgUC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCg0KZG1tIG1haWxpbmcgbGlzdA0KDQpkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9y
Zz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpkbW0gbWFpbGluZyBsaXN0
DQoNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vZG1tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNCmRtbSBtYWlsaW5nIGxpc3QNCg0KZG1tQGlldGYub3JnPG1haWx0
bzpkbW1AaWV0Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0N
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KZG1t
IG1haWxpbmcgbGlzdA0KDQpkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0
Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZG1tDQoNCg0KLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
SGFraW1hIENoYW91Y2hpDQpQcm9mZXNzb3INClRlbGVjb20gU3VkIFBhcmlzDQpJbnN0aXR1dCBN
aW5lcyBUZWxlY29tDQo5IHJ1ZSBDaGFybGVzIEZvdXJpZXINCjkxMDExIEV2cnkNCjAxNjA3NjQ0
NDMNCg0KDQoNCg0KDQoNCi0tDQoNClJlZ2FyZHMsDQoNCkNoYXJsaWUgUC4NCg0KDQoNCi0tDQoN
ClJlZ2FyZHMsDQoNCkNoYXJsaWUgUC4NCg==

--_000_2134F8430051B64F815C691A62D9831832D27B99XCHBLV504nwnosb_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x
OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp
Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi
Ow0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnBy
ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y
bWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj
azt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K
CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN
Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh
bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0
ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M
IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0K
c3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFy
IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4
dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30N
CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls
U3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn
ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu
IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K
LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl
eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6
ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t
Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkg
Q2hhcmxpZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZ3Vlc3MgSSBoYXZlIHRvIHNheSDigJxJIGRvbuKAmXQga25v
d+KAnSB0byBib3RoIHF1ZXN0aW9ucy4gTU5JRHMgYXJlIGEgZmFpcmx5IG5ldyBzdWJqZWN0PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmZvciBtZSwgYW5kIEkgdGhpbmsgb3RoZXJzIHdv
dWxkIGJlIGJldHRlciBxdWFsaWZpZWQgdG8gYW5zd2VyLiBKdXN0IHRob3VnaHQgSSB3b3VsZDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5vZmZlciB3aGF0IEkgZG8ga25vdyBpbiBjYXNl
IGl0IG1pZ2h0IGJlIG9mIHNvbWUgaGVscC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3
aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6d2luZG93dGV4dCI+IENoYXJsZXMgRS4gUGVya2lucyBbbWFpbHRvOmNoYXJsaWVwQGNvbXB1
dGVyLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0
IDI6MDggUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQgTDsgU3JpIEd1bmRhdmVsbGkg
KHNndW5kYXZlKTxicj4NCjxiPkNjOjwvYj4gVmlqYXkgRGV2YXJhcGFsbGk7IGRtbUBpZXRmLm9y
Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0RNTV0gTU5JRCBUeXBlczxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdCI+PGJyPg0KSGVsbG8gRnJlZCw8YnI+DQo8YnI+DQpJIGNhbiBpbmNsdWRlIERVSUQtVVVJ
RCBhcyBhbiBpZGVudGlmaWVyIHR5cGUsIGFuZCBjaXRlIFJGQyA0MTIyLiZuYnNwOyBJcyB0aGlz
PGJyPg0Kc3VmZmljaWVudCwgb3IgZG8gSSBuZWVkIHRvIGFsc28gZG8gc29tZXRoaW5nIHJlbGF0
ZWQgdG8gREhDUHY2IERVSUQ/PGJyPg0KPGJyPg0KSSBkaWQgbm90IHNlZSBhbnkgc3BlY2lmaWMg
Y29ubmVjdGlvbiBiZXR3ZWVuIHRoaXMgdHlwZSBvZiBpZGVudGlmaWVyIGFuZDxicj4NCnRoZSBS
RklEIGRpc2N1c3Npb24uJm5ic3A7IElzIHRoZXJlIHNvbWV0aGluZyB0aGF0IHJlbGF0ZXMgdGhl
IHR3byB0eXBlcz88YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCkNoYXJsaWUgUC48YnI+DQo8YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA5
LzI1LzIwMTQgMjowMCBQTSwgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5IaSBDaGFybGllLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBpbnRlcmVzdGVkIGlu
IG5vZGUgSURzIHRoYXQgY2FuIGJlIHJlcHJlc2VudGVkIGluIGEgREhDUHY2IERVSUQuIFRoZXJl
IGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJGQzYzNTUgd2hpY2ggZW5jb2RlcyBh
IG5vZGUgSUQgYmFzZWQgb24gRFVJRC1VVUlEIChVbml2ZXJzYWxseSBVbmlxdWU8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+SURlbnRpZmllcikuIEFGQUlDVCwgdGhlIFVVSUQgaXMgYSAx
MjgtYml0IGNvbnRhaW5lciBmb3JtYXR0ZWQgcGVyIFJGQzQxMjI8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+c3BlY2lmaWNhdGlvbnMgdGhhdCBpbmNsdWRlcyBhIHRpbWUgcG9ydGlvbiBh
bmQgYSBub2RlIElEIHBvcnRpb24uIEFueSBjaGFuY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+dGhpcyB3b3VsZCBzYXRpc2Z5IHdoYXQgeW91IGFyZSBsb29raW5nIGZvcj88L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPlRoYW5rcyAtIEZyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IGRtbSBbPGEgaHJlZj0ibWFp
bHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L2E+
XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaGFybGVzIEUuIFBlcmtpbnM8YnI+DQo8Yj5TZW50Ojwv
Yj4gVGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAxNCAxOjQzIFBNPGJyPg0KPGI+VG86PC9iPiBT
cmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpPGJyPg0KPGI+Q2M6PC9iPiBWaWpheSBEZXZhcmFwYWxs
aTsgPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPjxicj4NCjxi
PlN1YmplY3Q6PC9iPiBSZTogW0RNTV0gTU5JRCBUeXBlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy
Pg0KSGVsbG8gU3JpLDxicj4NCjxicj4NCklzIHRoZSBEb0QtOTYgaWRlbnRpZmllciBmb3IgYSBz
cGVjaWFsIGtpbmQgb2YgUkZJRCwgb3IgaXMgaXQ8YnI+DQp2YWxpZCBmb3IgYWxsIHRoZSBSRklE
IGRldmljZXMgdGhhdCB3b3VsZCBiZSBvZiBpbnRlcmVzdD88YnI+DQo8YnI+DQpSZWdhcmRzLDxi
cj4NCkNoYXJsaWUgUC48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA5LzIxLzIwMTQgOTo1OSBBTSwgU3JpIEd1bmRhdmVsbGkg
KHNndW5kYXZlKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SGkgSGFraW1hLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIGEgZ29vZCBpZGVhLiBXZSBzaG91bGQgcmVn
aXN0ZXIgYSB0eXBlIGZvciB0aGUgRG9kLTk2IGlkZW50aWZpZXIgYXMgd2VsbC48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tcmk8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10
b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbToNCjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IYWtpbWEgQ2hhb3VjaGkgJmx0
OzxhIGhyZWY9Im1haWx0bzpoYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJpcy5ldSI+aGFr
aW1hLmNoYW91Y2hpQHRlbGVjb20tc3VkcGFyaXMuZXU8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv
Yj5TdW5kYXksIFNlcHRlbWJlciAyMSwgMjAxNCA4OjExIEFNPGJyPg0KPGI+VG86IDwvYj5Tcmkg
R3VuZGF2ZWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSI+c2d1bmRh
dmVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPkNoYXJsaWUgUGVya2lucyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Ij5jaGFybGVzLnBl
cmtpbnNAZWFydGhsaW5rLm5ldDwvYT4mZ3Q7LCBNYXJjbyBMaWVic2NoICZsdDs8YSBocmVmPSJt
YWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXUiPk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PC9h
PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwv
YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwv
YT4mZ3Q7LA0KIFZpamF5IERldmFyYXBhbGxpICZsdDs8YSBocmVmPSJtYWlsdG86ZHZpamF5QHJv
Y2tldG1haWwuY29tIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1Ympl
Y3Q6IDwvYj5SZTogW0RNTV0gTU5JRCBUeXBlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVs
bG8gRm9sa3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkRvIHlvdSB0aGluayB0aGF0IGNvbnNpZGVyaW5nIHNwZWNpZmljIGJ1dCBuZWVkZWQg
dGVjaG5vbG9naWVzIGZvciBtb3Zpbmcgb2JqZWN0cyBpbiZuYnNwOyBJbnRlcm5ldCBvZiBUaGlu
Z3MmbmJzcDsgc3VjaCBhcyBSRklEIChSYWRpbyBGcmVxdWVuY3kgSWRlbnRpZmllcikgd2l0aCA5
NiBiaXRzIGlkZW50aWZpZXJzIHdpbGwgYmUgYWxzbyByZWxldmVudCB0byBDaGFybGllJ3MgY3Vy
cmVudCBkcmFmdCBhbmQgdGhlIGVmZm9ydHMNCiByZWxhdGVkIHRvIE1OSUQ/Jm5ic3A7IDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRz
LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I
YWtpbWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg
YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3
aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m
cXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86
c2d1bmRhdmVAY2lzY28uY29tIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPsOA
OiA8L2I+JnF1b3Q7Q2hhcmxpZSBQZXJraW5zJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hh
cmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQiPmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0
PC9hPiZndDssICZxdW90O01hcmNvIExpZWJzY2gmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpN
YXJjby5MaWVic2NoQG5lY2xhYi5ldSI+TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8L2E+Jmd0OywN
CjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT4sICZxdW90O1Zp
amF5IERldmFyYXBhbGxpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHZpamF5QHJvY2tldG1h
aWwuY29tIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkVudm95w6k6IDwv
Yj5KZXVkaSAxMSBTZXB0ZW1icmUgMjAxNCAyMzo1NzoxMTxicj4NCjxiPk9iamV0OiA8L2I+UmU6
IFtETU1dIE1OSUQgVHlwZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIENoYXJs
aWUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZldyBtb3JlIHJldmll
d3MvZGlzY3Vzc2lvbnMgYW5kIGNhcHR1cmluZyB0aGUgY29uc2Vuc3VzIGluIHRoZSBiYXNlIHZl
cnNpb24gd2lsbCBoZWxwLiBCdXQsIEknbSBvayBlaXRoZXIgd2F5IOKApjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHM8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPlNyaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2
ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206DQo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hhcmxpZSBQZXJraW5zICZsdDs8YSBocmVm
PSJtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQiIHRhcmdldD0iX2JsYW5rIj5j
aGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRo
dXJzZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMTQgMjo0NiBQTTxicj4NCjxiPlRvOiA8L2I+U3JpIEd1
bmRhdmVsbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iIHRhcmdldD0i
X2JsYW5rIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0OywgTWFyY28gTGllYnNjaCAmbHQ7PGEg
aHJlZj0ibWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1IiB0YXJnZXQ9Il9ibGFuayI+TWFy
Y28uTGllYnNjaEBuZWNsYWIuZXU8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRtbUBp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwv
YT4mZ3Q7LCBWaWpheSBEZXZhcmFwYWxsaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR2aWpheUByb2Nr
ZXRtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR2aWpheUByb2NrZXRtYWlsLmNvbTwvYT4mZ3Q7
PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbRE1NXSBNTklEIFR5cGVzPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5IZWxsbyBmb2xrcyw8YnI+DQo8YnI+DQpJIHByb3Bvc2UgdG8gc3Vi
bWl0IHRoZSAuLi4uLTAwLnR4dCBkb2N1bWVudCBhcyBpdCBpcyB0byB0aGUgSW50ZXJuZXQ8YnI+
DQpEcmFmdHMgZGlyZWN0b3J5LCBhbmQgdGhlbiB0byBnbyBhYm91dCBtYWtpbmcgdXBkYXRlcyBh
Y2NvcmRpbmcgdG88YnI+DQp0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3QuJm5ic3A7IERvIHlv
dSB0aGluayB0aGlzIGlzIHJlYXNvbmFibGU/PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpDaGFy
bGllIFAuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gOS8xMS8yMDE0IDc6MjEg
QU0sIFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwcmU+Jmx0O0NoYW5naW5nIHRoZSBzdWJqZWN0IGxpbmUgdG8gcmVmbGVj
dCB0aGUgTU5JZCBkaXNjdXNzaW9uJmd0OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk1hcmNv
LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaW5raW5nIGZ1cnRoZXIgb24gdGhlIGNvbXBs
ZW1lbnRhcnkgaWRlbnRpZmllciBvcHRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
PG86cD48L286cD48L3ByZT4NCjxwcmU+LSBUaGVyZSBpcyBhbHJlYWR5IHRoZSBsaW5rLWxheWVy
IGlkZW50aWZpZXIgb3B0aW9uIHRoYXQgY2FuIGJlIHVzZWQgZm9yPG86cD48L286cD48L3ByZT4N
CjxwcmU+Y2FycnlpbmcgdGhlIE1hYyBhZGRyZXNzPG86cD48L286cD48L3ByZT4NCjxwcmU+LSBJ
TUVJIGFuZCBNU0lTRE4gYXJlIGFscmVhZHkgZGVmaW5lZCBpbiAyOS4yNzUgYXMgYSAzR1BQIFZT
RSdzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+
SW4gc29tZSBzZW5zZSwgdGhlIGNvbXBsZW1lbnRhcnkgaWRlbnRpZmllcnMgYXJlIGFscmVhZHkg
cHJlc2VudC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5Tcmk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5PbiA5LzExLzE0IDY6NTggQU0sICZxdW90O1NyaSBHdW5kYXZlbGxpIChzZ3Vu
ZGF2ZSkmcXVvdDsgPGEgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPiZsdDtzZ3VuZGF2ZUBjaXNjby5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwv
cHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cHJlPkkgZG8gbm90IHNlZSBhIHJlYXNvbiB3aHkgbXVsdGlwbGUgTU4tSWQgaW5z
dGFuY2VzIG5lZWQgdG8gYmUgcHJlc2VudCBpbiBhPG86cD48L286cD48L3ByZT4NCjxwcmU+c2lu
Z2xlIG1lc3NhZ2UgPyBJbiBteSBleHBlcmllbmNlLCB0aGlzIGlzIHN0cmljdGx5IGEgZGVwbG95
bWVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvbnNpZGVyYXRpb24sIHdoZW4gdG8gdXNlIHdo
YXQgdHlwZSBvZiBpZGVudGlmaWVycy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5Bc3N1bWluZyB0aGUgYmFja2VuZCBzeXN0ZW0gY2FuIHRpZSBh
bGwgdGhlIE1OLUlkJ3MgdG8gYSBzaW5nbGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdWJzY3Jp
cHRpb24sIGFueSBwcmVzZW50ZWQgaWRlbnRpZmllciBjYW4gYmUgc3VmZmljaWVudCBmb3IgdGhl
IGdhdGV3YXk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50byBkbyB0aGUgQkNFIGxvb2t1cC48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiBtdWx0
aXBsZSBpbnN0YW5jZXMgY2FuIGJlIHByZXNlbnQsIHRoZW4gd2UgbmVlZCB0byBkZWFsIHdpdGgg
bW9yZSBlcnJvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNhc2VzLiBJcyB0aGF0IHJlYWxseSBu
ZWVkZWQgPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SSBhbSB3b25kZXJpbmcgaWYgaXQg
d291bGQgbm90IGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gZ28gZm9yIGEgZGlmZmVyZW50PG86cD48
L286cD48L3ByZT4NCjxwcmU+Y29udGFpbmVyIG9wdGlvbiB0byBjYXJyeSBzdWNoIGluZm9ybWF0
aW9uLiBTb21ldGhpbmcgbGlrZSBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Y29tcGxlbWVudGFy
eSBpZGVudGlmaWVyIG9wdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHBy
ZT5Tb3VuZHMgaW50ZXJlc3RpbmcuIEFyZSB5b3Ugc3VnZ2VzdGluZyB3ZSBsZWF2ZSB0aGUgY3Vy
cmVudCBNTi1JRCBhcyBpdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlzLCBidXQgdXNlIGEgbmV3
IGNvbXBsZW1lbnRhcnkgb3B0aW9uID8gQnV0LCBpZiB0aGUgcmVxdWlyZW1lbnQgaXMgZm9yIGE8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5NYWMgYmFzZWQgaWRlbnRpZmllcnMsIHdoYXQgd2lsbCBi
ZSB0aGVyZSBpbiB0aGUgY3VycmVudCBNTi1JZCBvcHRpb24gPyBXZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPnN0aWxsIG5lZWQgdG8gaGF2ZSBpZGVudGlmaWVyIHRoZXJlID88bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5Tcmk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PbiA5LzExLzE0IDI6MDMgQU0sICZxdW90O01hcmNvIExp
ZWJzY2gmcXVvdDsgPGEgaHJlZj0ibWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1IiB0YXJn
ZXQ9Il9ibGFuayI+Jmx0O01hcmNvLkxpZWJzY2hAbmVjbGFiLmV1Jmd0OzwvYT4gd3JvdGU6PG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5ObyBp
c3N1ZSB3aXRoIGxvZ2ljYWwgdnMuIHBoeXNpY2FsIElELiBCdXQgSSBhbSB3b25kZXJpbmcgYWJv
dXQgdHdvPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhpbmdzOjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9wZXJhdGlvbiBpcyBjbGVhciB0byBt
ZSBpbiBjYXNlIGEgc2luZ2xlIE1OSUQgaXMgcHJlc2VudCBpbiBhIG1lc3NhZ2U8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5hbmQgSSBzZWUgdGhlIHZhbHVlIGluIGJlaW5nPG86cD48L286cD48L3By
ZT4NCjxwcmU+ZmxleGlibGUgdG8gY2hvb3NlIGZyb20gZGlmZmVyZW50IHN1Yi10eXBlcy4gSWYg
bXVsdGlwbGUgTU5JRHMgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRpZmZlcmVudCBzdWIt
dHlwZXMgYXJlIHByZXNlbnQgaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hIHNpbmdsZSBtZXNz
YWdlLCB3aGljaCBvbmUgc2hvdWxkIGUuZy4gdGhlIExNQSB0YWtlIGZvciB0aGUgQkMgbG9va3Vw
Li48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ObyBiaWcgcHJvYmxlbSB0byBzb2x2ZSwgYnV0PG86
cD48L286cD48L3ByZT4NCjxwcmU+dG8gYmUgY29uc2lkZXJlZCBpbiBpbXBsZW1lbnRhdGlvbnMu
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SWYg
dGhlIHJlYXNvbiBmb3IgbXVsdGlwbGUgcHJlc2VudCBNTklEcyB3aXRoIGRpZmZlcmVudCBzdWIt
dHlwZXMgaXMgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kbyBvdGhlciB0aGluZ3MgdGhhbiBp
ZGVudGlmeWluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSBub2RlIG9yIHVzaW5nIHRoZSBJ
RCBhcyBrZXkgZm9yIGEgbG9va3VwLCBJIGFtIHdvbmRlcmluZyBpZiBpdCB3b3VsZDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPm5vdCBiZSBtb3JlIGFwcHJvcHJpYXRlPG86cD48L286cD48L3ByZT4N
CjxwcmU+dG8gZ28gZm9yIGEgZGlmZmVyZW50IGNvbnRhaW5lciBvcHRpb24gdG8gY2Fycnkgc3Vj
aCBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Tb21ldGhpbmcgbGlrZSBhIGNv
bXBsZW1lbnRhcnk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pZGVudGlmaWVyIG9wdGlvbi48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5tYXJjbzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+LS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9tOiBTcmkg
R3VuZGF2ZWxsaSAoc2d1bmRhdmUpIFs8YSBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29t
IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbTwvYT5dPG86cD48L286
cD48L3ByZT4NCjxwcmU+U2VudDogRG9ubmVyc3RhZywgMTEuIFNlcHRlbWJlciAyMDE0IDAwOjQy
PG86cD48L286cD48L3ByZT4NCjxwcmU+VG86IENoYXJsaWUgUGVya2luczsgTWFyY28gTGllYnNj
aDsgPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRm
Lm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzogVmlqYXkgRGV2YXJhcGFsbGk8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSZTogW0RNTV0gcmVnYXJkaW5nIHRoZSByZS1j
aGFydGVyaW5nLi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5IZWxsbyBDaGFybGllLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkFncmVlIHdpdGggdGhhdC4gTU4tSWQgYXMgaXRzIGRlZmluZWQg
dG9kYXkgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIuIEl0PG86cD48L286cD48L3ByZT4NCjxwcmU+
ZG9lcyBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXF1aXJlIHRoZSBpZGVudGlmaWVyIHRv
IGJlIGJvdW5kIHRvIGEgcGh5c2ljYWwgZGV2aWNlIG9yIGEgaW50ZXJmYWNlPG86cD48L286cD48
L3ByZT4NCjxwcmU+aWRlbnRpdHkuPG86cD48L286cD48L3ByZT4NCjxwcmU+QnV0LCB3ZSBoYXZl
IGNsZWFybHkgc2VlbiByZXF1aXJlbWVudHMgd2hlcmUgdGhlIG5lZWQgaXMgZm9yIGdlbmVyYXRp
bmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pZGVudGlmaWVycyBiYXNlZCBvbiBzb21lIHBoeXNp
Y2FsIGlkZW50aWZpZXJzLiBUaG9zZSBwaHlzaWNhbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlk
ZW50aWZpZXJzIGluY2x1ZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JTVNJLCBNU0lTRE4sIElN
RUksIE1BQyAuLmV0Yy4gSWYgd2UgY2FuIGRlZmluZSBhIHR5cGUgZm9yIGVhY2ggb2YgdGhlPG86
cD48L286cD48L3ByZT4NCjxwcmU+c291cmNlPG86cD48L286cD48L3ByZT4NCjxwcmU+YW5kIHRo
ZSBydWxlcyBmb3IgZ2VuZXJhdGluZyBNTi1JRCBiYXNlZCB1c2luZyB0aG9zZSBzb3VyY2VzLCB0
aGUgc2VuZGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YW5kPG86cD48L286cD48L3ByZT4NCjxw
cmU+cmVjZWl2ZXIgd2lsbCBoYXZlIGNsZWFyIGd1aWRhbmNlIG9uIGhvdyB0byB1c2UgdGhlIHNw
ZWMuIFNvbWUgcG9pbnRlcnMsPG86cD48L286cD48L3ByZT4NCjxwcmU+ZXhwbGFuYXRpb24gYW5k
IGV4YW1wbGVzIGZvciBlYWNoIG9mIHRob3NlIGlkZW50aWZpZXJzIHdpbGwgZ3JlYXRseSBoZWxw
PG86cD48L286cD48L3ByZT4NCjxwcmU+YXZvaWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbnRl
ci1vcCBpc3N1ZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+UmVnYXJkczxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPlNyaTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9uIDkvMTAvMTQgMzoyMSBQTSwgJnF1b3Q7Q2hhcmxpZSBQ
ZXJraW5zJnF1b3Q7IDxhIGhyZWY9Im1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5l
dCIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCZndDs8
L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+d3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5IZWxsbyBmb2xrcyw8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIHRoaW5rIGl0J3MgYmVz
dCB0byBjb25zaWRlciB0aGUgTU5JRCBhcyBzaW1wbHkgbGl2aW5nIGluIGEgc3BhY2Ugb2Y8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5pZGVudGlmaWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVjaCBh
Ym91dCB3aGV0aGVyIGl0J3MgYSBsb2dpY2FsPG86cD48L286cD48L3ByZT4NCjxwcmU+aWRlbnRp
ZmllciBvciBhIHBoeXNpY2FsIGlkZW50aWZpZXIuJm5ic3A7IElmIHRoZSBmb3JtZXIsIHRoZW4g
c29tZXdoZXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+KHBlcmhhcHMgYmVsb3cgdGhlIG5ldHdv
cmsgbGF5ZXIpIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIgaGFzIGJlZW4gYm91bmQ8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT50byBzb21ldGhpbmcgaW4gdGhlIHBoeXNpY2FsIGludGVyZmFjZSwgYnV0
IHRoYXQncyBub3Qgb3VyIHByb2JsZW0uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86
cD48L286cD48L3ByZT4NCjxwcmU+VGhlIG51bWJlciBzcGFjZSBmb3IgdHlwZXMgb2YgTU5JRHMg
aXMgbGlrZWx5IHRvIHN0YXkgcHJldHR5IGVtcHR5LCBzbzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PkknZCBzYXkgd2UgY291bGQgYWRkIGFzIG1hbnkgdHlwZXMgYXMgd291bGQgYmUgY29udmVuaWVu
dCBmb3IgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+c29mdHdhcmUgZGVzaWduZXJzLiZuYnNw
OyBTbywgd2UgY291bGQgY29uY2VpdmFibHkgaGF2ZSBzZXZlcmFsIE1OSURzPG86cD48L286cD48
L3ByZT4NCjxwcmU+ZGVmaW5lZCB0aGF0IGFsbCAmcXVvdDtsb29rZWQgbGlrZSZxdW90OyBOQUlz
ICh3aGljaCwgdGhlbXNlbHZlcywgJnF1b3Q7bG9vayBsaWtlJnF1b3Q7PG86cD48L286cD48L3By
ZT4NCjxwcmU+RlFETnMpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPlJlZ2FyZHMsPG86cD48L286cD48L3ByZT4NCjxwcmU+Q2hhcmxpZSBQLjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9u
IDkvMTAvMjAxNCA4OjExIEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOjxvOnA+
PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwcmU+WWVzLiBDdXJyZW50bHksIHRoZSBNTklEIGlzIGlmIHRoZSBu
YWkgZm9ybWF0IGFuZCBpcyBvdmVybG9hZGVkLiBUaGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5N
TklEJm5ic3A7IGluIDNHUFAgc3BlY3MgaXMgdGhlIElNU0ktTkFJIChJTVNJQFJFQUxNKSwgaXRz
IGJhc2VkIG9uIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklNU0kuIEV4OjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZxdW90OyZsdDtJTVNJJmd0O0BlcGMubW5jJmx0O01OQyZndDsubWNjJmx0
O01DQyZndDsuM2dwcG5ldHdvcmsub3JnwrI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07PG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+V2UgYWxzbyBoYXZl
IGFwcHJvYWNoZXMgdG8gdHJhbnNmb3JtIE1BQyB0byBQc2V1ZG8gSU1TSSwgYW5kIHRoZW48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5jYXJyeSBJTVNJLU5BSSBhcyB0aGUgTU4tSUQuPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48
L286cD48L3ByZT4NCjxwcmU+U28sIHdlIG5lZWQgdW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBv
ZiB0aGUgdHlwZXMvc291cmNlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5NTi1JZCBiYXNlZCBvbiBJTVNJLCBNU0lTRE4sIElNRUksIE1BQyAu
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFs
c28sIGRvIHdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBJTVNJIGFuZCBJTVNJLU5BSSA/
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+U3Jp
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+
T24gOS8xMC8xNCA2OjI5IEFNLCAmcXVvdDtNYXJjbyBMaWVic2NoJnF1b3Q7IDxhIGhyZWY9Im1h
aWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtNYXJjby5M
aWVic2NoQG5lY2xhYi5ldSZndDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu
YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SXQgc2VlbXMgdGhlIE1OSUQgaXMgc29tZWhv
dyBvdmVybG9hZGVkIHRvIGNhcnJ5IGJvdGgsIG5vZGUtc3BlY2lmaWM8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5JRHMsJm5ic3A7IGUuZy4gTUFDLCBhcyB3ZWxsIGFzIHN1YnNjcmliZXIgSURzLCB3
aGljaCBpcyB0aGUgSU1TSS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGVyZSBtYXkgYmUgdmFs
dWUgaW4gYWRkaW5nIHRoZSBJTUVJIHRvIHRoZSBsaXN0IG9mIHBvc3NpYmxlIHR5cGVzPG86cD48
L286cD48L3ByZT4NCjxwcmU+b2YmbmJzcDsgbm9kZS1zcGVjaWZpYyBJRHMuPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+bWFyY288bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogZG1tIFs8YSBocmVm
PSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86ZG1t
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3JpIEd1bmRhdmVsbGk8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4oc2d1bmRhdmUpPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VudDog
RGllbnN0YWcsIDkuIFNlcHRlbWJlciAyMDE0IDIzOjMwPG86cD48L286cD48L3ByZT4NCjxwcmU+
VG86IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSk7IENoYXJsaWUgUGVya2luczsgPGEgaHJlZj0i
bWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5DYzogVmlqYXkgRGV2YXJhcGFsbGk8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5TdWJqZWN0OiBSZTogW0RNTV0gcmVnYXJkaW5nIHRoZSByZS1jaGFydGVyaW5nLi48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ud28g
bW9yZSBjb21tZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT40LikgSSdkIGFsc28gdXNlIHN1Yi10eXBlIHZhbHVlIG9mICgyKSBmb3Ig
SU1TSS4gSnVzdCB0byBhbGlnbiB3aXRoPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlJm5ic3A7
IHN1Yi10eXBlcyZuYnNwOyBkZWZpbmVkIGZvciBNTiBJZCBkZWZpbmVkIGZvciBJQ01QLiBJIHN1
c3BlY3QgdGhlcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hcmUgc29tZSZuYnNwOyBpbXBsZW1l
bnRhdGlvbnMmbmJzcDsgYWxyZWFkeSB1c2luZyBzdWItdHlwZSAoMikuIFBsZWFzZSBzZWU8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT50aGUgb3RoZXIgdGhyZWFkLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjUuKSBGb3IgZWFjaCBvZiB0aGUgc3ViLXR5cGVzLCB3ZSBuZWVkIHRleHQgaW5jbHVk
aW5nIGV4YW1wbGVzIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNvbWU8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5leHBsYW5hdGlvbiBvbiBob3cgdGhleSBhcmUgdXNlZC48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5Tcmk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5PbiA5LzkvMTQgMjoyMCBQTSwgJnF1b3Q7U3JpIEd1bmRhdmVsbGkg
KHNndW5kYXZlKSZxdW90OyA8YSBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIiB0YXJn
ZXQ9Il9ibGFuayI+Jmx0O3NndW5kYXZlQGNpc2NvLmNvbSZndDs8L2E+PG86cD48L286cD48L3By
ZT4NCjxwcmU+d3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48
L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT5IaSBDaGFybGllLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgaXMgZ29vZC4gVGhhbmtzLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjEuKSBJZiBFVUktNDggYW5kIEVVSS02NCBhZGRyZXNzZXMgYXJlIGRlcml2
ZWQgb2YgYSA0OC1iaXQgSUVFRTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjgwMi4yPG86cD48L286
cD48L3ByZT4NCjxwcmU+YWRkcmVzcywgd2h5IGRvIHdlIG5lZWQgdG8gdHdvIHN1Yi10eXBlcyA/
IFdoeSBub3QgaGF2ZSBqdXN0IG9uZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnN1Yi10eXBlIGZv
ciBtYWMgYmFzZWQgaWRlbnRpZmllcnMgPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjIuKSBTdWIgdHlwZSB2YWx1ZSAoMSkgaXMgY3VycmVudGx5
IHVzZWQuIEl0cyBjdXJyZW50bHkgb3ZlcmxvYWRlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmZv
cjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPklNU0ktTkFJICgzR1BQIHNwZWNzKSBhbmQgZ2VuZXJp
YyBOQUkgYmFzZWQgaWRlbnRpZmllcnMuIEdpdmVuIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PmRlZmluaXRpb24gb2YgbmV3IHN1Yi10eXBlcywgd2UgbmVlZCBzb21lIHRleHQgZXhwbGFpbmlu
ZyB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5tb3RpdmF0aW9uPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+My4pIFByb3Bvc2VkIFN1Yi10eXBl
IHZhbHVlIG9mICgyKSBmb3IgSVB2NiBhZGRyZXNzLiBXaGF0IGV4YWN0bHk8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5pczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoaXMgPyBBcmUgdGhlc2UgQ0dB
LWJhc2VkIElQdjYgYWRkcmVzc2VzID88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgTmV3IE1vYmlsZSBOb2RlIElkZW50aWZpZXIgVHlwZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0
Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBJ
ZGVudGlmaWVyIFR5cGUgfCBJZGVudGlmaWVyIFR5cGUgTnVtYmVyIHw8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0t
LSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBJUHY2IEFkZHJlc3MmbmJzcDsmbmJzcDsm
bmJzcDsgfCAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBJTVNJJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgMyZuYnNwOyZuYnNwOyZu
YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwgUC1UTVNJJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHwgNCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgRVVJLTQ4IGFkZHJlc3MmbmJzcDsgfCA1Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw
OyZuYnNwO3w8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfCBFVUktNjQgYWRkcmVzcyZuYnNwOyB8IDYmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IEdVVEkm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfCA3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzPG86cD48L286cD48L3ByZT4NCjxwcmU+
U3JpPG86cD48L286cD48L3ByZT4NCjxwcmU+UFM6IEdvb2QgdG8gc2VlIFZpamF5IGJhY2s8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PbiA5LzkvMTQgMToyOCBQTSwgJnF1b3Q7Q2hhcmxpZSBQ
ZXJraW5zJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOmNoYXJs
ZXMucGVya2luc0BlYXJ0aGxpbmsubmV0IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2NoYXJsZXMucGVy
a2luc0BlYXJ0aGxpbmsubmV0Jmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53cm90ZTo8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhl
bGxvIGZvbGtzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPkhlcmUncyB0aGUgbGFzdCBJbnRlcm5ldCBEcmFmdCB0aGF0IHdlIGRpZCwgbG9uZyBh
Z28gZXhwaXJlZDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVy
a2lucy1tZXh0LTQyODNtbmlkcy0wMS50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lmll
dGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVya2lucy1tZXh0LTQyODNtbmlkcy0wMS50eHQ8L2E+
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SSds
bCByZXN1Ym1pdCBpdCB3aXRoIGEgZmV3IHVwZGF0ZXMgYXMgYSBwZXJzb25hbCBkcmFmdCB0byBk
bW0uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+
UmVnYXJkcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DaGFybGllIFAuPG86cD48L286cD48L3By
ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kbW0gbWFpbGluZyBsaXN0PG86
cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86
cD48L286cD48L3ByZT4NCjxwcmU+ZG1tIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0
Zi5vcmc8L2E+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k
bW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2RtbTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K
PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl
Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRtbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGll
dGYub3JnPC9hPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZG1tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9kbW08L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5kbW0gbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFp
bHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT48YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxh
bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjxvOnA+PC9v
OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZG1tIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy
ZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYWtpbWEgQ2hhb3Vj
aGk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBy
b2Zlc3NvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+VGVsZWNvbSBTdWQgUGFyaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkluc3RpdHV0IE1pbmVzIFRlbGVjb208bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjkgcnVlIENoYXJsZXMgRm91cmllcjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OTEwMTEg
RXZyeTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
MDE2MDc2NDQ0MzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K
PG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMs
PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2hhcmxpZSBQLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+
PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkNoYXJsaWUgUC48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_2134F8430051B64F815C691A62D9831832D27B99XCHBLV504nwnosb_--


From nobody Thu Sep 25 14:22:42 2014
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 61B081A038C for ; Thu, 25 Sep 2014 14:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] 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 HbvA9HvdyfXN for ; Thu, 25 Sep 2014 14:22:35 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 490431A0376 for ; Thu, 25 Sep 2014 14:22:35 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZH0gDbCO1qqxjS+AgQCAXVG4F8xGnfrZ0RVZwx33yE84IJQYN2VjZluKq9unhnvv; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [107.1.141.74] (helo=[192.168.254.194]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XXGUi-0003SN-UW; Thu, 25 Sep 2014 17:22:33 -0400
Message-ID: <54248798.7030701@earthlink.net>
Date: Thu, 25 Sep 2014 14:22:32 -0700
From: Charlie Perkins 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Sri Gundavelli (sgundave)" 
References:  <542466BC.6020702@computer.org>
In-Reply-To: <542466BC.6020702@computer.org>
Content-Type: multipart/alternative; boundary="------------030006050208040705020505"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac709f8c6577cafdce14a81f1a136c70a59350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/CBPBz60XzjDtLfBjr5aagAYUODg
Cc: Vijay Devarapalli , dmm@ietf.org
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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, 25 Sep 2014 21:22:40 -0000

This is a multi-part message in MIME format.
--------------030006050208040705020505
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit


Hello again folks,

Here is a proposed text for a new paragraph in the Security Considerations:

>
>    Some identifiers (e.g., IMSI) are considered to be private
>    information.  If used in the MNID extension as defined in this
>    document, the packet including the MNID extension should be encrypted
>    so that personal information or trackable identifiers would not be
>    inadvertently disclosed to passive observers.  Moreover, MNIDs
>    containing sensitive identifiers might only be used for signaling
>    during initial network entry.  Subsequent binding update exchanges
>    would then rely on a temporary identifier allocated during the
>    initial network entry.

Comments will be appreciated.

Regards,
Charlie P.



On 9/25/2014 12:02 PM, Charles E. Perkins wrote:
>
> Hello folks,
>
> I think the best solution for this would be a section in the Security
> Considerations explaining the need.   I will fashion some text for the
> upcoming revision ....-01.txt
>
> Regards,
> Charlie P.
>
>
> On 9/24/2014 10:48 AM, Sri Gundavelli (sgundave) wrote:
>> Hi Pierrick,
>>
>> The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 
>> 3GPP TS 23.003. It is sent in PBU/PBA messages. Not sure, if IMSI 
>> information is seen as a confidential IE. But, I agree on the need to 
>> include some text on how the signaling message can be protected with 
>> privacy / confidentiality service set, when the identifier is based 
>> on some confidential data.
>>
>>
>> Regards
>> Sri
>>
>> From: "pierrick.seite@orange.com " 
>> >
>> Date: Wednesday, September 24, 2014 8:56 AM
>> To: "Charles E. Perkins" > >, "dmm@ietf.org " 
>> >
>> Subject: Re: [DMM] Fwd: New Version Notification for 
>> draft-perkins-dmm-4283mnids-00.txt
>>
>> Hi Charlie,
>>
>> Thanks for the list... it looks good. I'm just wondering about 
>> security considerations... Actually, from 3GPP standpoint, security 
>> constrains on IMSI and GPRSS/LTE temporary identifiers (P-TMSI, 
>> GUTI). AFAIK, IMSI is very rarely sent on the air (maybe only one 
>> time at the beginning of the 3GPP authentication process) for 
>> security reasons. So, I'm wondering if adding IMSI to the list of 
>> IDs, without any warnings, is somehow introducing security weakness 
>> to the 3GPP security process.   Consequently, I'm not sure about the 
>> following statement "This document does not introduce any security 
>> mechanisms, and does not have any impact on existing security 
>> mechanisms." It's maybe not so true from the 3GPP point of view...
>>
>> Maybe we should state that the ID option MUST be used in a way that 
>> it does not harm existing security mechanisms (i.e. use the option 
>> with caution J). For example, to address the issue above (maybe there 
>> are other examples... I don't know...), we could state that the IMSI 
>> should be transmitted only during first binding update, and not 
>> transmitted anymore as long as the association IMSI/HoA/HNP is 
>> done.... Or... simpler way to address the issue:  if nobody has 
>> use-case for transmitting the IMSI, we can simply remove the IMSI 
>> from the list J
>>
>> BR,
>>
>> Pierrick
>>
>> *De :*dmm [mailto:dmm-bounces@ietf.org] *De la part de* Charles E. 
>> Perkins
>> *Envoyé :* mardi 23 septembre 2014 21:10
>> *À :* dmm@ietf.org 
>> *Objet :* [DMM] Fwd: New Version Notification for 
>> draft-perkins-dmm-4283mnids-00.txt
>>
>> Hello folks,
>>
>> We have published a ...-00 version of the MNIDs draft.  This is 
>> mainly for
>> reference purposes.  A new version should be out within a week or so,
>> incorporating the suggestions and comments from people who responded
>> to the earlier suggestion to revisit this work.
>>
>> Regards,
>> Charlie P.
>>
>>
>>
>> -------- Original Message --------
>>
>> *Subject: *
>>
>> 	
>>
>> New Version Notification for draft-perkins-dmm-4283mnids-00.txt
>>
>> *Date: *
>>
>> 	
>>
>> Tue, 23 Sep 2014 10:43:12 -0700
>>
>> *From: *
>>
>> 	
>>
>>  
>>
>> *To: *
>>
>> 	
>>
>> Charles E. Perkins  
>> , Vijay Devarapalli 
>>  
>> , Charles 
>> E.Perkins  
>>
>> A new version of I-D, draft-perkins-dmm-4283mnids-00.txt
>> has been successfully submitted by Charles E. Perkins and posted to the
>> IETF repository.
>>   
>> Name:         draft-perkins-dmm-4283mnids
>> Revision:     00
>> Title:        MN Identifier Types for RFC 4283 Mobile Node Identifier Option
>> Document date: 2014-09-23
>> Group:        Individual Submission
>> Pages:        4
>> URL:http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt
>> Status:https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/
>> Htmlized:http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00
>>   
>>   
>> Abstract:
>>     Additional Identifier Types are proposed for use with the Mobile Node
>>     Identifier Option for MIPv6 (RFC 4283).
>>   
>>                                                                                    
>>   
>>   
>> 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.
>>   
>> The IETF Secretariat
>>   
>>   
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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.
>>
>> 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.
>
> -- 
> Regards,
> Charlie P.
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


--------------030006050208040705020505
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    Hello again folks,

    

    Here is a proposed text for a new paragraph in the Security
    Considerations:

    

    


         Some identifiers (e.g., IMSI) are considered to be private

         information.  If used in the MNID extension as defined in this

         document, the packet including the MNID extension should be
      encrypted

         so that personal information or trackable identifiers would not
      be

         inadvertently disclosed to passive observers.  Moreover, MNIDs

         containing sensitive identifiers might only be used for
      signaling

         during initial network entry.  Subsequent binding update
      exchanges

         would then rely on a temporary identifier allocated during the

         initial network entry.

    

    

    Comments will be appreciated.

    

    Regards,

    Charlie P.

    

    

    

    
On 9/25/2014 12:02 PM, Charles E.
      Perkins wrote:

    

    

      
      

      Hello folks,

      

      I think the best solution for this would be a section in the
      Security

      Considerations explaining the need.   I will fashion some text for
      the

      upcoming revision ....-01.txt

      

      Regards,

      Charlie P.

      

      

      
On 9/24/2014 10:48 AM, Sri Gundavelli
        (sgundave) wrote:

      

      

        
        
Hi Pierrick,

        


        

        
The NAI that is used in S2a/S5 procedures is a IMSI-NAI,
          based on 3GPP TS 23.003. It is sent in PBU/PBA messages. Not
          sure, if IMSI information is seen as a confidential IE. But, I
          agree on the need to include some text on how the signaling
          message can be protected with privacy / confidentiality
          service set, when the identifier is based on some confidential
          data.

        


        

        


        

        
Regards

        
Sri

        


        

        
          
 From: "pierrick.seite@orange.com"
            <pierrick.seite@orange.com>

            Date: Wednesday,
            September 24, 2014 8:56 AM

            To: "Charles E.
            Perkins" <charliep@computer.org>,

            "dmm@ietf.org"
            <dmm@ietf.org>

            Subject: Re: [DMM]
            Fwd: New Version Notification for
            draft-perkins-dmm-4283mnids-00.txt

          

          


          

          

            
            
            

              

                
Hi Charlie,

                
 

                
Thanks for the list… it
                    looks good. I’m just wondering about security
                    considerations… Actually, from 3GPP standpoint,
                    security constrains on IMSI and GPRSS/LTE temporary
                    identifiers (P-TMSI, GUTI). AFAIK, IMSI is very
                    rarely sent on the air (maybe only one time at the
                    beginning of the 3GPP authentication process) for
                    security reasons. So, I’m wondering if adding IMSI
                    to the list of IDs, without any warnings, is somehow
                    introducing security weakness to the 3GPP security
                    process.   Consequently, I’m not sure about the
                    following statement “This document does not introduce any
                    security mechanisms, and does not have any impact on
                    existing security mechanisms.” It’s

                    maybe not so true from the 3GPP point of view…

                
 

                
Maybe we should state
                    that the ID option MUST be used in a way that it
                    does not harm existing security mechanisms (i.e. use
                    the option with caution J). For example, to
                    address the issue above (maybe there are other
                    examples… I don’t know…), we could state that the
                    IMSI should be transmitted only during first binding
                    update, and not transmitted anymore as long as the
                    association IMSI/HoA/HNP is done…. Or... simpler way
                    to address the issue:  if nobody has use-case for
                    transmitting the IMSI, we can simply remove the IMSI
                    from the list J

                
 

                
BR,

                
Pierrick

                
 

                
 

                

                  

                    

                      
De : dmm [mailto:dmm-bounces@ietf.org]
                          De la part de Charles E. Perkins

                          Envoyé : mardi 23 septembre 2014 21:10

                          À : dmm@ietf.org

                          Objet : [DMM] Fwd: New Version
                          Notification for
                          draft-perkins-dmm-4283mnids-00.txt

                    

                  

                  
 

                  
Hello

                    folks,

                    

                    We have published a ...-00 version of the MNIDs
                    draft.  This is mainly for

                    reference purposes.  A new version should be out
                    within a week or so,

                    incorporating the suggestions and comments from
                    people who responded

                    to the earlier suggestion to revisit this work.

                    

                    Regards,

                    Charlie P.

                  

                    


                      

                      -------- Original Message -------- 

                    

                      
                        

                          
                            
Subject:
                                

                          		
                          
                            
New Version
                              Notification for
                              draft-perkins-dmm-4283mnids-00.txt

                          		
                        

                        

                          
                            
Date:
                                

                          		
                          
                            
Tue, 23 Sep 2014
                              10:43:12 -0700

                          		
                        

                        

                          
                            
From:
                                

                          		
                          
                            
<internet-drafts@ietf.org>

                          		
                        

                        

                          
                            
To:
                                

                          		
                          
                            
Charles E. Perkins <charliep@computer.org>,
                              Vijay Devarapalli <unknown-email-Vijay-Devarapalli@ietfa.amsl.com>,
                              Charles E.Perkins <charliep@computer.org>

                          		
                        

                      
                    

                    
 

                    
A new version of I-D, draft-perkins-dmm-4283mnids-00.txt

                    
has been successfully submitted by Charles E. Perkins and posted to the

                    
IETF repository.

                    
 

                    
Name:         draft-perkins-dmm-4283mnids

                    
Revision:     00

                    
Title:        MN Identifier Types for RFC 4283 Mobile Node Identifier Option

                    
Document date: 2014-09-23

                    
Group:        Individual Submission

                    
Pages:        4

                    
URL:            http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt

                    
Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/

                    
Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00

                    
 

                    
 

                    
Abstract:

                    
   Additional Identifier Types are proposed for use with the Mobile Node

                    
   Identifier Option for MIPv6 (RFC 4283).

                    
 

                    
                                                                                  

                    
 

                    
 

                    
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.

                    
 

                    
The IETF Secretariat

                    
 

                    
 

                    
 

                  

                  
 

                

              

              
_________________________________________________________________________________________________________________________

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.

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.


            

          

         

      

      
-- 
Regards,
Charlie P.

      

      

      

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


    

    

  


--------------030006050208040705020505--


From nobody Thu Sep 25 18:36:08 2014
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 14D5D1A0180 for ; Thu, 25 Sep 2014 18:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 ofpNlhp5yWd9 for ; Thu, 25 Sep 2014 18:36:03 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1A81A0169 for ; Thu, 25 Sep 2014 18:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43842; q=dns/txt; s=iport; t=1411695363; x=1412904963; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=C11xRyVT4tVawA6qkrB1fFHXT+tgEYMwZ1lGNho9BoA=; b=YLLHrBCuUV63M0s29ugWx5PlMEM295kEqZ+XOS7RduMULOYA8mGQoa8X 6gA4DVBZkrbgzOLpkN9dGBsrL+yL+OrvsSrjXqmhmXs43Nh7APDtP3RFx PSSU6KnLAKZ1GmjopmfuNLTWUUclFQmcKd76qbmO5Sb+ulJiRw6FlAzhU U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkUFAJzCJFStJV2b/2dsb2JhbABXCYJIRlNXBIJ9xyoBCYdOAhhrFgF7hAMBAQEDAQEBARcJSwsFBwYBCBEDAQEBDhMHAwIEJQsUCQgCBA4FCYghAwkIDatdjmAbhxYBF41eEIFVMAEIBwoHCgYBAgSCcoFTBYYmiSKCGItDlVaDY2wBgUeBAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,601,1406592000";  d="scan'208,217";a="355207785"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 26 Sep 2014 01:36:02 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q1a2H4016750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 01:36:02 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 20:36:01 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Charles E. Perkins" 
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHP2So6Gycpijr5yUOAYD95te6ztA==
Date: Fri, 26 Sep 2014 01:36:01 +0000
Message-ID: 
In-Reply-To: <54247E3C.7050800@computer.org>
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.217]
Content-Type: multipart/alternative; boundary="_000_D04A103F166DDCsgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/94pMe-8VE0vkmEyW0nUu4SFSPls
Cc: Vijay Devarapalli , "dmm@ietf.org" 
Subject: Re: [DMM] MNID Types
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, 26 Sep 2014 01:36:07 -0000

--_000_D04A103F166DDCsgundaveciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQ2hhcmxpZSwNCg0KPiBJcyB0aGUgRG9ELTk2IGlkZW50aWZpZXIgZm9yIGEgc3BlY2lhbCBr
aW5kIG9mIFJGSUQsIG9yIGlzIGl0IHZhbGlkIGZvciBhbGwgdGhlIFJGSUQgZGV2aWNlcyB0aGF0
IHdvdWxkIGJlIG9mIGludGVyZXN0Pw0KDQpJIGRvIG5vdCBrbm93IHRoZSBhbnN3ZXIgZm9yIHRo
aXMgcXVlc3Rpb24uIEkgYXNzdW1lZCBET0QtOTYgaXMgYSBtYW5kYXRlZCBzdGFuZGFyZCBmb3Ig
UkZJRCBlbmNvZGluZywgYnV0IGxvb2tzIGxpa2UgdGhlcmUgYXJlIG90aGVyIGZvcm1hdHMgbGlr
ZSBHSUQtOTYgLi5ldGMuIE1heSBiZSB0aGlzIG1heSBlbmQgdXAgbmVlZGluZyBzdWJ0eXBlcy4g
V2UgY2FuIGRlZmVyIHRoaXMgcXVlc3Rpb24gdG8gSGFraW1hIGFuZCBsZWFybiBzb21lIGRldGFp
bHMgb24gdGhpcywgc2hlIHNlZW1zIHRvIGhhdmUgd3JpdHRlbiBtYW55IGJvb2tzIG9uIFJGSUQu
DQoNCg0KUmVnYXJkcw0KU3JpDQoNCg0KDQpGcm9tOiAiQ2hhcmxlcyBFLiBQZXJraW5zIiA8Y2hh
cmxpZXBAY29tcHV0ZXIub3JnPG1haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmc+Pg0KT3JnYW5p
emF0aW9uOiBCbHVlIFNraWVzDQpEYXRlOiBUaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0IDE6
NDIgUE0NClRvOiBTcmkgR3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPG1haWx0bzpzZ3Vu
ZGF2ZUBjaXNjby5jb20+Pg0KQ2M6ICJkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4i
IDxkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4+LCBWaWpheSBEZXZhcmFwYWxsaSA8
ZHZpamF5QHJvY2tldG1haWwuY29tPG1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20+Pg0KU3Vi
amVjdDogUmU6IFtETU1dIE1OSUQgVHlwZXMNCg0KDQpIZWxsbyBTcmksDQoNCklzIHRoZSBEb0Qt
OTYgaWRlbnRpZmllciBmb3IgYSBzcGVjaWFsIGtpbmQgb2YgUkZJRCwgb3IgaXMgaXQNCnZhbGlk
IGZvciBhbGwgdGhlIFJGSUQgZGV2aWNlcyB0aGF0IHdvdWxkIGJlIG9mIGludGVyZXN0Pw0KDQpS
ZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCk9uIDkvMjEvMjAxNCA5OjU5IEFNLCBTcmkgR3VuZGF2
ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0KSGkgSGFraW1hLA0KDQpUaGF0IGlzIGEgZ29vZCBpZGVh
LiBXZSBzaG91bGQgcmVnaXN0ZXIgYSB0eXBlIGZvciB0aGUgRG9kLTk2IGlkZW50aWZpZXIgYXMg
d2VsbC4NCg0KDQpSZWdhcmRzDQpTcmkNCg0KDQpGcm9tOiBIYWtpbWEgQ2hhb3VjaGkgPGhha2lt
YS5jaGFvdWNoaUB0ZWxlY29tLXN1ZHBhcmlzLmV1PG1haWx0bzpoYWtpbWEuY2hhb3VjaGlAdGVs
ZWNvbS1zdWRwYXJpcy5ldT4+DQpEYXRlOiBTdW5kYXksIFNlcHRlbWJlciAyMSwgMjAxNCA4OjEx
IEFNDQpUbzogU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRh
dmVAY2lzY28uY29tPj4NCkNjOiBDaGFybGllIFBlcmtpbnMgPGNoYXJsZXMucGVya2luc0BlYXJ0
aGxpbmsubmV0PG1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4+LCBNYXJjbyBM
aWVic2NoIDxNYXJjby5MaWVic2NoQG5lY2xhYi5ldTxtYWlsdG86TWFyY28uTGllYnNjaEBuZWNs
YWIuZXU+PiwgImRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiIgPGRtbUBpZXRmLm9y
ZzxtYWlsdG86ZG1tQGlldGYub3JnPj4sIFZpamF5IERldmFyYXBhbGxpIDxkdmlqYXlAcm9ja2V0
bWFpbC5jb208bWFpbHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogW0RN
TV0gTU5JRCBUeXBlcw0KDQpIZWxsbyBGb2xrcywNCg0KRG8geW91IHRoaW5rIHRoYXQgY29uc2lk
ZXJpbmcgc3BlY2lmaWMgYnV0IG5lZWRlZCB0ZWNobm9sb2dpZXMgZm9yIG1vdmluZyBvYmplY3Rz
IGluICBJbnRlcm5ldCBvZiBUaGluZ3MgIHN1Y2ggYXMgUkZJRCAoUmFkaW8gRnJlcXVlbmN5IElk
ZW50aWZpZXIpIHdpdGggOTYgYml0cyBpZGVudGlmaWVycyB3aWxsIGJlIGFsc28gcmVsZXZlbnQg
dG8gQ2hhcmxpZSdzIGN1cnJlbnQgZHJhZnQgYW5kIHRoZSBlZmZvcnRzIHJlbGF0ZWQgdG8gTU5J
RD8NCg0KUmVnYXJkcywNCg0KSGFraW1hDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCkRlOiAiU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSIgPHNndW5kYXZlQGNpc2NvLmNv
bTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4NCsOAOiAiQ2hhcmxpZSBQZXJraW5zIiA8Y2hh
cmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxp
bmsubmV0Pj4sICJNYXJjbyBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8bWFpbHRv
Ok1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1Pj4sIGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYu
b3JnPiwgIlZpamF5IERldmFyYXBhbGxpIiA8ZHZpamF5QHJvY2tldG1haWwuY29tPG1haWx0bzpk
dmlqYXlAcm9ja2V0bWFpbC5jb20+Pg0KRW52b3nDqTogSmV1ZGkgMTEgU2VwdGVtYnJlIDIwMTQg
MjM6NTc6MTENCk9iamV0OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0KDQpIaSBDaGFybGllLA0KDQpG
ZXcgbW9yZSByZXZpZXdzL2Rpc2N1c3Npb25zIGFuZCBjYXB0dXJpbmcgdGhlIGNvbnNlbnN1cyBp
biB0aGUgYmFzZSB2ZXJzaW9uIHdpbGwgaGVscC4gQnV0LCBJJ20gb2sgZWl0aGVyIHdheSDigKYN
Cg0KDQpSZWdhcmRzDQpTcmkNCg0KRnJvbTogQ2hhcmxpZSBQZXJraW5zIDxjaGFybGVzLnBlcmtp
bnNAZWFydGhsaW5rLm5ldDxtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+Pg0K
RGF0ZTogVGh1cnNkYXksIFNlcHRlbWJlciAxMSwgMjAxNCAyOjQ2IFBNDQpUbzogU3JpIEd1bmRh
dmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4sIE1h
cmNvIExpZWJzY2ggPE1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PG1haWx0bzpNYXJjby5MaWVic2No
QG5lY2xhYi5ldT4+LCAiZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+IiA8ZG1tQGll
dGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+PiwgVmlqYXkgRGV2YXJhcGFsbGkgPGR2aWpheUBy
b2NrZXRtYWlsLmNvbTxtYWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29tPj4NClN1YmplY3Q6IFJl
OiBbRE1NXSBNTklEIFR5cGVzDQoNCg0KSGVsbG8gZm9sa3MsDQoNCkkgcHJvcG9zZSB0byBzdWJt
aXQgdGhlIC4uLi4tMDAudHh0IGRvY3VtZW50IGFzIGl0IGlzIHRvIHRoZSBJbnRlcm5ldA0KRHJh
ZnRzIGRpcmVjdG9yeSwgYW5kIHRoZW4gdG8gZ28gYWJvdXQgbWFraW5nIHVwZGF0ZXMgYWNjb3Jk
aW5nIHRvDQp0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3QuICBEbyB5b3UgdGhpbmsgdGhpcyBp
cyByZWFzb25hYmxlPw0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCk9uIDkvMTEvMjAxNCA3
OjIxIEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0KDQo8Q2hhbmdpbmcgdGhl
IHN1YmplY3QgbGluZSB0byByZWZsZWN0IHRoZSBNTklkIGRpc2N1c3Npb24+DQoNCg0KTWFyY28s
DQoNCg0KVGhpbmtpbmcgZnVydGhlciBvbiB0aGUgY29tcGxlbWVudGFyeSBpZGVudGlmaWVyIG9w
dGlvbi4NCg0KLSBUaGVyZSBpcyBhbHJlYWR5IHRoZSBsaW5rLWxheWVyIGlkZW50aWZpZXIgb3B0
aW9uIHRoYXQgY2FuIGJlIHVzZWQgZm9yDQpjYXJyeWluZyB0aGUgTWFjIGFkZHJlc3MNCi0gSU1F
SSBhbmQgTVNJU0ROIGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gMjkuMjc1IGFzIGEgM0dQUCBWU0Un
cw0KDQpJbiBzb21lIHNlbnNlLCB0aGUgY29tcGxlbWVudGFyeSBpZGVudGlmaWVycyBhcmUgYWxy
ZWFkeSBwcmVzZW50Lg0KDQpTcmkNCg0KDQoNCg0KDQpPbiA5LzExLzE0IDY6NTggQU0sICJTcmkg
R3VuZGF2ZWxsaSAoc2d1bmRhdmUpIiA8c2d1bmRhdmVAY2lzY28uY29tPjxtYWlsdG86c2d1bmRh
dmVAY2lzY28uY29tPiB3cm90ZToNCg0KDQpJIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5IG11bHRp
cGxlIE1OLUlkIGluc3RhbmNlcyBuZWVkIHRvIGJlIHByZXNlbnQgaW4gYQ0Kc2luZ2xlIG1lc3Nh
Z2UgPyBJbiBteSBleHBlcmllbmNlLCB0aGlzIGlzIHN0cmljdGx5IGEgZGVwbG95bWVudA0KY29u
c2lkZXJhdGlvbiwgd2hlbiB0byB1c2Ugd2hhdCB0eXBlIG9mIGlkZW50aWZpZXJzLg0KDQpBc3N1
bWluZyB0aGUgYmFja2VuZCBzeXN0ZW0gY2FuIHRpZSBhbGwgdGhlIE1OLUlkJ3MgdG8gYSBzaW5n
bGUNCnN1YnNjcmlwdGlvbiwgYW55IHByZXNlbnRlZCBpZGVudGlmaWVyIGNhbiBiZSBzdWZmaWNp
ZW50IGZvciB0aGUgZ2F0ZXdheQ0KdG8gZG8gdGhlIEJDRSBsb29rdXAuDQoNCklmIG11bHRpcGxl
IGluc3RhbmNlcyBjYW4gYmUgcHJlc2VudCwgdGhlbiB3ZSBuZWVkIHRvIGRlYWwgd2l0aCBtb3Jl
IGVycm9yDQpjYXNlcy4gSXMgdGhhdCByZWFsbHkgbmVlZGVkID8NCg0KDQoNCg0KSSBhbSB3b25k
ZXJpbmcgaWYgaXQgd291bGQgbm90IGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gZ28gZm9yIGEgZGlm
ZmVyZW50DQpjb250YWluZXIgb3B0aW9uIHRvIGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24uIFNvbWV0
aGluZyBsaWtlIGENCmNvbXBsZW1lbnRhcnkgaWRlbnRpZmllciBvcHRpb24uDQoNCg0KU291bmRz
IGludGVyZXN0aW5nLiBBcmUgeW91IHN1Z2dlc3Rpbmcgd2UgbGVhdmUgdGhlIGN1cnJlbnQgTU4t
SUQgYXMgaXQNCmlzLCBidXQgdXNlIGEgbmV3IGNvbXBsZW1lbnRhcnkgb3B0aW9uID8gQnV0LCBp
ZiB0aGUgcmVxdWlyZW1lbnQgaXMgZm9yIGENCk1hYyBiYXNlZCBpZGVudGlmaWVycywgd2hhdCB3
aWxsIGJlIHRoZXJlIGluIHRoZSBjdXJyZW50IE1OLUlkIG9wdGlvbiA/IFdlDQpzdGlsbCBuZWVk
IHRvIGhhdmUgaWRlbnRpZmllciB0aGVyZSA/DQoNCg0KDQoNClNyaQ0KDQoNCg0KDQoNCk9uIDkv
MTEvMTQgMjowMyBBTSwgIk1hcmNvIExpZWJzY2giIDxNYXJjby5MaWVic2NoQG5lY2xhYi5ldT48
bWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PiB3cm90ZToNCg0KDQoNCk5vIGlzc3VlIHdp
dGggbG9naWNhbCB2cy4gcGh5c2ljYWwgSUQuIEJ1dCBJIGFtIHdvbmRlcmluZyBhYm91dCB0d28N
CnRoaW5nczoNCg0KT3BlcmF0aW9uIGlzIGNsZWFyIHRvIG1lIGluIGNhc2UgYSBzaW5nbGUgTU5J
RCBpcyBwcmVzZW50IGluIGEgbWVzc2FnZQ0KYW5kIEkgc2VlIHRoZSB2YWx1ZSBpbiBiZWluZw0K
ZmxleGlibGUgdG8gY2hvb3NlIGZyb20gZGlmZmVyZW50IHN1Yi10eXBlcy4gSWYgbXVsdGlwbGUg
TU5JRHMgd2l0aA0KZGlmZmVyZW50IHN1Yi10eXBlcyBhcmUgcHJlc2VudCBpbg0KYSBzaW5nbGUg
bWVzc2FnZSwgd2hpY2ggb25lIHNob3VsZCBlLmcuIHRoZSBMTUEgdGFrZSBmb3IgdGhlIEJDIGxv
b2t1cC4uDQpObyBiaWcgcHJvYmxlbSB0byBzb2x2ZSwgYnV0DQp0byBiZSBjb25zaWRlcmVkIGlu
IGltcGxlbWVudGF0aW9ucy4NCg0KSWYgdGhlIHJlYXNvbiBmb3IgbXVsdGlwbGUgcHJlc2VudCBN
TklEcyB3aXRoIGRpZmZlcmVudCBzdWItdHlwZXMgaXMgdG8NCmRvIG90aGVyIHRoaW5ncyB0aGFu
IGlkZW50aWZ5aW5nDQp0aGUgbm9kZSBvciB1c2luZyB0aGUgSUQgYXMga2V5IGZvciBhIGxvb2t1
cCwgSSBhbSB3b25kZXJpbmcgaWYgaXQgd291bGQNCm5vdCBiZSBtb3JlIGFwcHJvcHJpYXRlDQp0
byBnbyBmb3IgYSBkaWZmZXJlbnQgY29udGFpbmVyIG9wdGlvbiB0byBjYXJyeSBzdWNoIGluZm9y
bWF0aW9uLg0KU29tZXRoaW5nIGxpa2UgYSBjb21wbGVtZW50YXJ5DQppZGVudGlmaWVyIG9wdGlv
bi4NCg0KbWFyY28NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTcmkg
R3VuZGF2ZWxsaSAoc2d1bmRhdmUpIFttYWlsdG86c2d1bmRhdmVAY2lzY28uY29tXQ0KU2VudDog
RG9ubmVyc3RhZywgMTEuIFNlcHRlbWJlciAyMDE0IDAwOjQyDQpUbzogQ2hhcmxpZSBQZXJraW5z
OyBNYXJjbyBMaWVic2NoOyBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCkNjOiBW
aWpheSBEZXZhcmFwYWxsaQ0KU3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hh
cnRlcmluZy4uDQoNCkhlbGxvIENoYXJsaWUsDQoNCkFncmVlIHdpdGggdGhhdC4gTU4tSWQgYXMg
aXRzIGRlZmluZWQgdG9kYXkgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIuIEl0DQpkb2VzIG5vdA0K
cmVxdWlyZSB0aGUgaWRlbnRpZmllciB0byBiZSBib3VuZCB0byBhIHBoeXNpY2FsIGRldmljZSBv
ciBhIGludGVyZmFjZQ0KaWRlbnRpdHkuDQpCdXQsIHdlIGhhdmUgY2xlYXJseSBzZWVuIHJlcXVp
cmVtZW50cyB3aGVyZSB0aGUgbmVlZCBpcyBmb3IgZ2VuZXJhdGluZw0KaWRlbnRpZmllcnMgYmFz
ZWQgb24gc29tZSBwaHlzaWNhbCBpZGVudGlmaWVycy4gVGhvc2UgcGh5c2ljYWwNCmlkZW50aWZp
ZXJzIGluY2x1ZGUNCklNU0ksIE1TSVNETiwgSU1FSSwgTUFDIC4uZXRjLiBJZiB3ZSBjYW4gZGVm
aW5lIGEgdHlwZSBmb3IgZWFjaCBvZiB0aGUNCnNvdXJjZQ0KYW5kIHRoZSBydWxlcyBmb3IgZ2Vu
ZXJhdGluZyBNTi1JRCBiYXNlZCB1c2luZyB0aG9zZSBzb3VyY2VzLCB0aGUgc2VuZGVyDQphbmQN
CnJlY2VpdmVyIHdpbGwgaGF2ZSBjbGVhciBndWlkYW5jZSBvbiBob3cgdG8gdXNlIHRoZSBzcGVj
LiBTb21lIHBvaW50ZXJzLA0KZXhwbGFuYXRpb24gYW5kIGV4YW1wbGVzIGZvciBlYWNoIG9mIHRo
b3NlIGlkZW50aWZpZXJzIHdpbGwgZ3JlYXRseSBoZWxwDQphdm9pZA0KaW50ZXItb3AgaXNzdWVz
Lg0KDQoNClJlZ2FyZHMNClNyaQ0KDQoNCg0KDQoNCg0KDQpPbiA5LzEwLzE0IDM6MjEgUE0sICJD
aGFybGllIFBlcmtpbnMiIDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD48bWFpbHRvOmNo
YXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pg0Kd3JvdGU6DQoNCg0KDQpIZWxsbyBmb2xrcywN
Cg0KSSB0aGluayBpdCdzIGJlc3QgdG8gY29uc2lkZXIgdGhlIE1OSUQgYXMgc2ltcGx5IGxpdmlu
ZyBpbiBhIHNwYWNlIG9mDQppZGVudGlmaWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVjaCBhYm91
dCB3aGV0aGVyIGl0J3MgYSBsb2dpY2FsDQppZGVudGlmaWVyIG9yIGEgcGh5c2ljYWwgaWRlbnRp
Zmllci4gIElmIHRoZSBmb3JtZXIsIHRoZW4gc29tZXdoZXJlDQoocGVyaGFwcyBiZWxvdyB0aGUg
bmV0d29yayBsYXllcikgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciBoYXMgYmVlbiBib3VuZA0KdG8g
c29tZXRoaW5nIGluIHRoZSBwaHlzaWNhbCBpbnRlcmZhY2UsIGJ1dCB0aGF0J3Mgbm90IG91ciBw
cm9ibGVtLg0KDQpUaGUgbnVtYmVyIHNwYWNlIGZvciB0eXBlcyBvZiBNTklEcyBpcyBsaWtlbHkg
dG8gc3RheSBwcmV0dHkgZW1wdHksIHNvDQpJJ2Qgc2F5IHdlIGNvdWxkIGFkZCBhcyBtYW55IHR5
cGVzIGFzIHdvdWxkIGJlIGNvbnZlbmllbnQgZm9yIHRoZQ0Kc29mdHdhcmUgZGVzaWduZXJzLiAg
U28sIHdlIGNvdWxkIGNvbmNlaXZhYmx5IGhhdmUgc2V2ZXJhbCBNTklEcw0KZGVmaW5lZCB0aGF0
IGFsbCAibG9va2VkIGxpa2UiIE5BSXMgKHdoaWNoLCB0aGVtc2VsdmVzLCAibG9vayBsaWtlIg0K
RlFETnMpLg0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCg0KT24gOS8xMC8yMDE0IDg6MTEg
QU0sIFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6DQoNCg0KWWVzLiBDdXJyZW50bHks
IHRoZSBNTklEIGlzIGlmIHRoZSBuYWkgZm9ybWF0IGFuZCBpcyBvdmVybG9hZGVkLiBUaGUNCk1O
SUQgIGluIDNHUFAgc3BlY3MgaXMgdGhlIElNU0ktTkFJIChJTVNJQFJFQUxNKSwgaXRzIGJhc2Vk
IG9uIHRoZQ0KSU1TSS4gRXg6DQoiPElNU0k+QGVwYy5tbmM8TU5DPi5tY2M8TUNDPi4zZ3BwbmV0
d29yay5vcmfCsg0KDQpXZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07DQoNCldlIGFsc28gaGF2ZSBh
cHByb2FjaGVzIHRvIHRyYW5zZm9ybSBNQUMgdG8gUHNldWRvIElNU0ksIGFuZCB0aGVuDQpjYXJy
eSBJTVNJLU5BSSBhcyB0aGUgTU4tSUQuDQoNCg0KU28sIHdlIG5lZWQgdW5pcXVlIHN1Yi10eXBl
cyBmb3IgZWFjaCBvZiB0aGUgdHlwZXMvc291cmNlcy4NCg0KTU4tSWQgYmFzZWQgb24gSU1TSSwg
TVNJU0ROLCBJTUVJLCBNQUMgLi4NCg0KQWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBi
ZXR3ZWVuIElNU0kgYW5kIElNU0ktTkFJID8NCg0KU3JpDQoNCg0KDQpPbiA5LzEwLzE0IDY6Mjkg
QU0sICJNYXJjbyBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PG1haWx0bzpNYXJj
by5MaWVic2NoQG5lY2xhYi5ldT4gd3JvdGU6DQoNCg0KDQpJdCBzZWVtcyB0aGUgTU5JRCBpcyBz
b21laG93IG92ZXJsb2FkZWQgdG8gY2FycnkgYm90aCwgbm9kZS1zcGVjaWZpYw0KSURzLCAgZS5n
LiBNQUMsIGFzIHdlbGwgYXMgc3Vic2NyaWJlciBJRHMsIHdoaWNoIGlzIHRoZSBJTVNJLg0KVGhl
cmUgbWF5IGJlIHZhbHVlIGluIGFkZGluZyB0aGUgSU1FSSB0byB0aGUgbGlzdCBvZiBwb3NzaWJs
ZSB0eXBlcw0Kb2YgIG5vZGUtc3BlY2lmaWMgSURzLg0KDQptYXJjbw0KDQoNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3Jn
XSBPbiBCZWhhbGYgT2YgU3JpIEd1bmRhdmVsbGkNCihzZ3VuZGF2ZSkNClNlbnQ6IERpZW5zdGFn
LCA5LiBTZXB0ZW1iZXIgMjAxNCAyMzozMA0KVG86IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSk7
IENoYXJsaWUgUGVya2luczsgZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpDYzog
VmlqYXkgRGV2YXJhcGFsbGkNClN1YmplY3Q6IFJlOiBbRE1NXSByZWdhcmRpbmcgdGhlIHJlLWNo
YXJ0ZXJpbmcuLg0KDQpUd28gbW9yZSBjb21tZW50cy4NCg0KDQoNCjQuKSBJJ2QgYWxzbyB1c2Ug
c3ViLXR5cGUgdmFsdWUgb2YgKDIpIGZvciBJTVNJLiBKdXN0IHRvIGFsaWduIHdpdGgNCnRoZSAg
c3ViLXR5cGVzICBkZWZpbmVkIGZvciBNTiBJZCBkZWZpbmVkIGZvciBJQ01QLiBJIHN1c3BlY3Qg
dGhlcmUNCmFyZSBzb21lICBpbXBsZW1lbnRhdGlvbnMgIGFscmVhZHkgdXNpbmcgc3ViLXR5cGUg
KDIpLiBQbGVhc2Ugc2VlDQp0aGUgb3RoZXIgdGhyZWFkLg0KDQoNCjUuKSBGb3IgZWFjaCBvZiB0
aGUgc3ViLXR5cGVzLCB3ZSBuZWVkIHRleHQgaW5jbHVkaW5nIGV4YW1wbGVzIGFuZA0Kc29tZQ0K
ZXhwbGFuYXRpb24gb24gaG93IHRoZXkgYXJlIHVzZWQuDQoNCg0KU3JpDQoNCg0KDQpPbiA5Lzkv
MTQgMjoyMCBQTSwgIlNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5j
b20+PG1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20+DQp3cm90ZToNCg0KDQoNCkhpIENoYXJsaWUs
DQoNClRoaXMgaXMgZ29vZC4gVGhhbmtzLg0KDQoNCjEuKSBJZiBFVUktNDggYW5kIEVVSS02NCBh
ZGRyZXNzZXMgYXJlIGRlcml2ZWQgb2YgYSA0OC1iaXQgSUVFRQ0KODAyLjINCmFkZHJlc3MsIHdo
eSBkbyB3ZSBuZWVkIHRvIHR3byBzdWItdHlwZXMgPyBXaHkgbm90IGhhdmUganVzdCBvbmUNCnN1
Yi10eXBlIGZvciBtYWMgYmFzZWQgaWRlbnRpZmllcnMgPw0KDQoyLikgU3ViIHR5cGUgdmFsdWUg
KDEpIGlzIGN1cnJlbnRseSB1c2VkLiBJdHMgY3VycmVudGx5IG92ZXJsb2FkZWQNCmZvcg0KSU1T
SS1OQUkgKDNHUFAgc3BlY3MpIGFuZCBnZW5lcmljIE5BSSBiYXNlZCBpZGVudGlmaWVycy4gR2l2
ZW4gdGhlDQpkZWZpbml0aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4
cGxhaW5pbmcgdGhlDQptb3RpdmF0aW9uDQoNCjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1ZSBv
ZiAoMikgZm9yIElQdjYgYWRkcmVzcy4gV2hhdCBleGFjdGx5DQppcw0KdGhpcyA/IEFyZSB0aGVz
ZSBDR0EtYmFzZWQgSVB2NiBhZGRyZXNzZXMgPw0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAg
ICBOZXcgTW9iaWxlIE5vZGUgSWRlbnRpZmllciBUeXBlcw0KDQogICAgICAgICAgICAgICArLS0t
LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAg
fCBJZGVudGlmaWVyIFR5cGUgfCBJZGVudGlmaWVyIFR5cGUgTnVtYmVyIHwNCiAgICAgICAgICAg
ICAgICstLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAg
ICAgICAgICB8IElQdjYgQWRkcmVzcyAgICB8IDIgICAgICAgICAgICAgICAgICAgICAgfA0KICAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgICAgICAgICAgICAgIHwgSU1TSSAgICAgICAgICAgIHwgMyAgICAgICAgICAgICAgICAgICAg
ICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg
ICAgICAgfA0KICAgICAgICAgICAgICAgfCBQLVRNU0kgICAgICAgICAgfCA0ICAgICAgICAgICAg
ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAg
ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8IEVVSS00OCBhZGRyZXNzICB8IDUgICAg
ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAg
ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgRVVJLTY0IGFkZHJlc3Mg
IHwgNiAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAg
ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBHVVRJICAg
ICAgICAgICAgfCA3ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICstLS0t
LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCg0KDQoNCg0KDQoNClJl
Z2FyZHMNClNyaQ0KUFM6IEdvb2QgdG8gc2VlIFZpamF5IGJhY2sNCg0KDQpPbiA5LzkvMTQgMToy
OCBQTSwgIkNoYXJsaWUgUGVya2lucyINCjxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD48
bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pg0Kd3JvdGU6DQoNCg0KDQpIZWxs
byBmb2xrcywNCg0KSGVyZSdzIHRoZSBsYXN0IEludGVybmV0IERyYWZ0IHRoYXQgd2UgZGlkLCBs
b25nIGFnbyBleHBpcmVkOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt
cGVya2lucy1tZXh0LTQyODNtbmlkcy0wMS50eHQNCg0KSSdsbCByZXN1Ym1pdCBpdCB3aXRoIGEg
ZmV3IHVwZGF0ZXMgYXMgYSBwZXJzb25hbCBkcmFmdCB0byBkbW0uDQoNClJlZ2FyZHMsDQpDaGFy
bGllIFAuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1A
aWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RtbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5v
cmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QN
CmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vZG1tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1t
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0K
DQoNCi0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkhha2ltYSBDaGFvdWNo
aQ0KUHJvZmVzc29yDQpUZWxlY29tIFN1ZCBQYXJpcw0KSW5zdGl0dXQgTWluZXMgVGVsZWNvbQ0K
OSBydWUgQ2hhcmxlcyBGb3VyaWVyDQo5MTAxMSBFdnJ5DQowMTYwNzY0NDQzDQoNCg0KDQoNCi0t
DQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0K

--_000_D04A103F166DDCsgundaveciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <73824B1B236E2C4086E8C907B96260C0@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+SGkgQ2hhcmxp
ZSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDtJcyB0aGUgRG9ELTk2
IGlkZW50aWZpZXIgZm9yIGEgc3BlY2lhbCBraW5kIG9mIFJGSUQsIG9yIGlzIGl0Jm5ic3A7dmFs
aWQgZm9yIGFsbCB0aGUgUkZJRCBkZXZpY2VzIHRoYXQgd291bGQgYmUgb2YgaW50ZXJlc3Q/PC9k
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGRvIG5vdCBrbm93IHRoZSBhbnN3ZXIgZm9y
IHRoaXMgcXVlc3Rpb24uIEkgYXNzdW1lZCBET0QtOTYgaXMgYSBtYW5kYXRlZCBzdGFuZGFyZCBm
b3IgUkZJRCBlbmNvZGluZywgYnV0IGxvb2tzIGxpa2UgdGhlcmUgYXJlIG90aGVyIGZvcm1hdHMg
bGlrZSBHSUQtOTYgLi5ldGMuIE1heSBiZSB0aGlzIG1heSBlbmQgdXAgbmVlZGluZyBzdWJ0eXBl
cy4gV2UgY2FuIGRlZmVyIHRoaXMgcXVlc3Rpb24gdG8gSGFraW1hIGFuZCBsZWFybiBzb21lDQog
ZGV0YWlscyBvbiB0aGlzLCBzaGUgc2VlbXMgdG8gaGF2ZSB3cml0dGVuIG1hbnkgYm9va3Mgb24g
UkZJRC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5S
ZWdhcmRzPC9kaXY+DQo8ZGl2PlNyaTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU
SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0
ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg
Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF
RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp
ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz
dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90O0NoYXJsZXMgRS4gUGVy
a2lucyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNoYXJsaWVwQGNvbXB1dGVyLm9yZyI+Y2hh
cmxpZXBAY29tcHV0ZXIub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6
Ym9sZCI+T3JnYW5pemF0aW9uOiA8L3NwYW4+Qmx1ZSBTa2llczxicj4NCjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAx
NCAxOjQyIFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+
U3JpIEd1bmRhdmVsbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iPnNn
dW5kYXZlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv
bGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGll
dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGll
dGYub3JnPC9hPiZndDssIFZpamF5IERldmFyYXBhbGxpICZsdDs8YSBocmVmPSJtYWlsdG86ZHZp
amF5QHJvY2tldG1haWwuY29tIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxz
cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtETU1dIE1O
SUQgVHlwZXM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBiZ2Nv
bG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj48YnI+DQpIZWxsbyBTcmksPGJyPg0KPGJyPg0K
SXMgdGhlIERvRC05NiBpZGVudGlmaWVyIGZvciBhIHNwZWNpYWwga2luZCBvZiBSRklELCBvciBp
cyBpdDxicj4NCnZhbGlkIGZvciBhbGwgdGhlIFJGSUQgZGV2aWNlcyB0aGF0IHdvdWxkIGJlIG9m
IGludGVyZXN0Pzxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KQ2hhcmxpZSBQLjxicj4NCjxicj4N
Cjxicj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gOS8yMS8yMDE0IDk6NTkgQU0s
IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBjaXRlPSJtaWQ6RDA0NDUwRTUuMTY2MDhGJTI1c2d1bmRhdmVAY2lzY28uY29tIiB0eXBlPSJj
aXRlIj4NCjxkaXY+SGkgSGFraW1hLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhh
dCBpcyBhIGdvb2QgaWRlYS4gV2Ugc2hvdWxkIHJlZ2lzdGVyIGEgdHlwZSBmb3IgdGhlIERvZC05
NiBpZGVudGlmaWVyIGFzIHdlbGwuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+UmVnYXJkczwvZGl2Pg0KPGRpdj5Tcmk8L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O
Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0Ow0KICAg
ICAgICAgIHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1
bSBub25lOw0KICAgICAgICAgIEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RU
T006IDBpbjsgUEFERElORy1MRUZUOg0KICAgICAgICAgIDBpbjsgUEFERElORy1SSUdIVDogMGlu
OyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsNCiAgICAgICAgICBCT1JERVItUklHSFQ6
IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5Gcm9tOiA8L3NwYW4+SGFraW1hIENoYW91Y2hpICZsdDs8YSBtb3otZG8tbm90LXNl
bmQ9InRydWUiIGhyZWY9Im1haWx0bzpoYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJpcy5l
dSI+aGFraW1hLmNoYW91Y2hpQHRlbGVjb20tc3VkcGFyaXMuZXU8L2E+Jmd0Ozxicj4NCjxzcGFu
IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+U3VuZGF5LCBTZXB0ZW1iZXIg
MjEsIDIwMTQgODoxMSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzog
PC9zcGFuPlNyaSBHdW5kYXZlbGxpICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9
Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iPnNndW5kYXZlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+Q2hhcmxpZSBQZXJr
aW5zICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpjaGFybGVzLnBl
cmtpbnNAZWFydGhsaW5rLm5ldCI+Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8L2E+Jmd0
OywgTWFyY28gTGllYnNjaCAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWls
dG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXUiPk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PC9hPiZn
dDssDQogJnF1b3Q7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86ZG1tQGll
dGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRy
dWUiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT4mZ3Q7LCBWaWph
eSBEZXZhcmFwYWxsaSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86
ZHZpamF5QHJvY2tldG1haWwuY29tIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0Ozxicj4N
CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtETU1d
IE1OSUQgVHlwZXM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1l
cywNCiAgICAgICAgICAgICAgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAi
Pg0KPGRpdj5IZWxsbyBGb2xrcyw8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
PkRvIHlvdSB0aGluayB0aGF0IGNvbnNpZGVyaW5nIHNwZWNpZmljIGJ1dCBuZWVkZWQgdGVjaG5v
bG9naWVzIGZvciBtb3Zpbmcgb2JqZWN0cyBpbiZuYnNwOyBJbnRlcm5ldCBvZiBUaGluZ3MmbmJz
cDsgc3VjaCBhcyBSRklEIChSYWRpbyBGcmVxdWVuY3kgSWRlbnRpZmllcikgd2l0aCA5NiBiaXRz
IGlkZW50aWZpZXJzIHdpbGwgYmUgYWxzbyByZWxldmVudCB0byBDaGFybGllJ3MgY3VycmVudCBk
cmFmdCBhbmQgdGhlIGVmZm9ydHMgcmVsYXRlZCB0byBNTklEPyZuYnNwOw0KPGJyPg0KPC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+SGFraW1hPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxociBpZD0iendjaHIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IzAwMDtm
b250LXdlaWdodDpub3JtYWw7Zm9udC1zdHlsZTpub3JtYWw7dGV4dC1kZWNvcmF0aW9uOm5vbmU7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEycHQ7Ij4N
CjxiPkRlOiA8L2I+JnF1b3Q7U3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSZxdW90OyAmbHQ7PGEg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIj5z
Z3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPsOAOiA8L2I+JnF1b3Q7Q2hhcmxpZSBQ
ZXJraW5zJnF1b3Q7ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpj
aGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCI+Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5u
ZXQ8L2E+Jmd0OywgJnF1b3Q7TWFyY28gTGllYnNjaCZxdW90OyAmbHQ7PGEgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXUiPk1hcmNvLkxp
ZWJzY2hAbmVjbGFiLmV1PC9hPiZndDssDQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9
Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT4sICZxdW90O1ZpamF5IERldmFy
YXBhbGxpJnF1b3Q7ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpk
dmlqYXlAcm9ja2V0bWFpbC5jb20iPmR2aWpheUByb2NrZXRtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0K
PGI+RW52b3nDqTogPC9iPkpldWRpIDExIFNlcHRlbWJyZSAyMDE0IDIzOjU3OjExPGJyPg0KPGI+
T2JqZXQ6IDwvYj5SZTogW0RNTV0gTU5JRCBUeXBlczxicj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
ZGl2PkhpIENoYXJsaWUsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5GZXcgbW9yZSBy
ZXZpZXdzL2Rpc2N1c3Npb25zIGFuZCBjYXB0dXJpbmcgdGhlIGNvbnNlbnN1cyBpbiB0aGUgYmFz
ZSB2ZXJzaW9uIHdpbGwgaGVscC4gQnV0LCBJJ20gb2sgZWl0aGVyIHdheSDigKY8L2Rpdj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzPC9kaXY+DQo8
ZGl2PlNyaTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf
U0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFw
dDsNCiAgICAgICAgICAgICAgICAgICAgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9S
REVSLUJPVFRPTTogbWVkaXVtDQogICAgICAgICAgICAgICAgICAgIG5vbmU7IEJPUkRFUi1MRUZU
OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsNCiAgICAgICAgICAgICAgICAgICAg
UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDoNCiAgICAg
ICAgICAgICAgICAgICAgI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v
bmU7DQogICAgICAgICAgICAgICAgICAgIFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5DaGFybGllIFBlcmtpbnMgJmx0OzxhIG1v
ei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxp
bmsubmV0IiB0YXJnZXQ9Il9ibGFuayI+Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8L2E+
Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1
cnNkYXksIFNlcHRlbWJlciAxMSwgMjAxNCAyOjQ2IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt
d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+U3JpIEd1bmRhdmVsbGkgJmx0OzxhIG1vei1kby1ub3Qt
c2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh
bmsiPnNndW5kYXZlQGNpc2NvLmNvbTwvYT4mZ3Q7LCBNYXJjbyBMaWVic2NoICZsdDs8YSBtb3ot
ZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldSIg
dGFyZ2V0PSJfYmxhbmsiPk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PC9hPiZndDssDQogJnF1b3Q7
PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5k
PSJ0cnVlIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGll
dGYub3JnPC9hPiZndDssIFZpamF5IERldmFyYXBhbGxpICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9
InRydWUiIGhyZWY9Im1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20iIHRhcmdldD0iX2JsYW5r
Ij5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtETU1dIE1OSUQgVHlwZXM8YnI+DQo8L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6IENhbGlicmk7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7
IiBmYWNlPSJDYWxpYnJpIj48YmlnPkhlbGxvIGZvbGtzLDxicj4NCjxicj4NCkkgcHJvcG9zZSB0
byBzdWJtaXQgdGhlIC4uLi4tMDAudHh0IGRvY3VtZW50IGFzIGl0IGlzIHRvIHRoZSBJbnRlcm5l
dDxicj4NCkRyYWZ0cyBkaXJlY3RvcnksIGFuZCB0aGVuIHRvIGdvIGFib3V0IG1ha2luZyB1cGRh
dGVzIGFjY29yZGluZyB0bzxicj4NCnRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgbGlzdC4mbmJzcDsg
RG8geW91IHRoaW5rIHRoaXMgaXMgcmVhc29uYWJsZT88YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4N
CkNoYXJsaWUgUC48YnI+DQo8YnI+DQo8L2JpZz48L3NwYW4+PGJyPg0KPGRpdiBjbGFzcz0ibW96
LWNpdGUtcHJlZml4Ij5PbiA5LzExLzIwMTQgNzoyMSBBTSwgU3JpIEd1bmRhdmVsbGkgKHNndW5k
YXZlKSB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNpdGU9Im1pZDpEMDM2RkI1Ri4x
NjNDOUQlMjVzZ3VuZGF2ZUBjaXNjby5jb20iPg0KPHByZT4mbHQ7Q2hhbmdpbmcgdGhlIHN1Ympl
Y3QgbGluZSB0byByZWZsZWN0IHRoZSBNTklkIGRpc2N1c3Npb24mZ3Q7DQoNCg0KTWFyY28sDQoN
Cg0KVGhpbmtpbmcgZnVydGhlciBvbiB0aGUgY29tcGxlbWVudGFyeSBpZGVudGlmaWVyIG9wdGlv
bi4NCg0KLSBUaGVyZSBpcyBhbHJlYWR5IHRoZSBsaW5rLWxheWVyIGlkZW50aWZpZXIgb3B0aW9u
IHRoYXQgY2FuIGJlIHVzZWQgZm9yDQpjYXJyeWluZyB0aGUgTWFjIGFkZHJlc3MNCi0gSU1FSSBh
bmQgTVNJU0ROIGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gMjkuMjc1IGFzIGEgM0dQUCBWU0Uncw0K
DQpJbiBzb21lIHNlbnNlLCB0aGUgY29tcGxlbWVudGFyeSBpZGVudGlmaWVycyBhcmUgYWxyZWFk
eSBwcmVzZW50Lg0KDQpTcmkNCg0KDQoNCg0KDQpPbiA5LzExLzE0IDY6NTggQU0sICZxdW90O1Ny
aSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkmcXVvdDsgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBj
bGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28u
Y29tIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O3NndW5kYXZlQGNpc2NvLmNvbSZndDs8L2E+IHdyb3Rl
Og0KPC9wcmU+DQo8YmxvY2txdW90ZT4NCjxwcmU+SSBkbyBub3Qgc2VlIGEgcmVhc29uIHdoeSBt
dWx0aXBsZSBNTi1JZCBpbnN0YW5jZXMgbmVlZCB0byBiZSBwcmVzZW50IGluIGENCnNpbmdsZSBt
ZXNzYWdlID8gSW4gbXkgZXhwZXJpZW5jZSwgdGhpcyBpcyBzdHJpY3RseSBhIGRlcGxveW1lbnQN
CmNvbnNpZGVyYXRpb24sIHdoZW4gdG8gdXNlIHdoYXQgdHlwZSBvZiBpZGVudGlmaWVycy4NCg0K
QXNzdW1pbmcgdGhlIGJhY2tlbmQgc3lzdGVtIGNhbiB0aWUgYWxsIHRoZSBNTi1JZCdzIHRvIGEg
c2luZ2xlDQpzdWJzY3JpcHRpb24sIGFueSBwcmVzZW50ZWQgaWRlbnRpZmllciBjYW4gYmUgc3Vm
ZmljaWVudCBmb3IgdGhlIGdhdGV3YXkNCnRvIGRvIHRoZSBCQ0UgbG9va3VwLg0KDQpJZiBtdWx0
aXBsZSBpbnN0YW5jZXMgY2FuIGJlIHByZXNlbnQsIHRoZW4gd2UgbmVlZCB0byBkZWFsIHdpdGgg
bW9yZSBlcnJvcg0KY2FzZXMuIElzIHRoYXQgcmVhbGx5IG5lZWRlZCA/DQoNCg0KPC9wcmU+DQo8
YmxvY2txdW90ZT4NCjxwcmU+SSBhbSB3b25kZXJpbmcgaWYgaXQgd291bGQgbm90IGJlIG1vcmUg
YXBwcm9wcmlhdGUgdG8gZ28gZm9yIGEgZGlmZmVyZW50DQpjb250YWluZXIgb3B0aW9uIHRvIGNh
cnJ5IHN1Y2ggaW5mb3JtYXRpb24uIFNvbWV0aGluZyBsaWtlIGENCmNvbXBsZW1lbnRhcnkgaWRl
bnRpZmllciBvcHRpb24uDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+U291bmRzIGludGVy
ZXN0aW5nLiBBcmUgeW91IHN1Z2dlc3Rpbmcgd2UgbGVhdmUgdGhlIGN1cnJlbnQgTU4tSUQgYXMg
aXQNCmlzLCBidXQgdXNlIGEgbmV3IGNvbXBsZW1lbnRhcnkgb3B0aW9uID8gQnV0LCBpZiB0aGUg
cmVxdWlyZW1lbnQgaXMgZm9yIGENCk1hYyBiYXNlZCBpZGVudGlmaWVycywgd2hhdCB3aWxsIGJl
IHRoZXJlIGluIHRoZSBjdXJyZW50IE1OLUlkIG9wdGlvbiA/IFdlDQpzdGlsbCBuZWVkIHRvIGhh
dmUgaWRlbnRpZmllciB0aGVyZSA/DQoNCg0KDQoNClNyaQ0KDQoNCg0KDQoNCk9uIDkvMTEvMTQg
MjowMyBBTSwgJnF1b3Q7TWFyY28gTGllYnNjaCZxdW90OyA8YSBtb3otZG8tbm90LXNlbmQ9InRy
dWUiIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpNYXJjby5MaWVi
c2NoQG5lY2xhYi5ldSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtNYXJjby5MaWVic2NoQG5lY2xhYi5l
dSZndDs8L2E+IHdyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlPg0KPHByZT5ObyBpc3N1ZSB3
aXRoIGxvZ2ljYWwgdnMuIHBoeXNpY2FsIElELiBCdXQgSSBhbSB3b25kZXJpbmcgYWJvdXQgdHdv
DQp0aGluZ3M6DQoNCk9wZXJhdGlvbiBpcyBjbGVhciB0byBtZSBpbiBjYXNlIGEgc2luZ2xlIE1O
SUQgaXMgcHJlc2VudCBpbiBhIG1lc3NhZ2UNCmFuZCBJIHNlZSB0aGUgdmFsdWUgaW4gYmVpbmcN
CmZsZXhpYmxlIHRvIGNob29zZSBmcm9tIGRpZmZlcmVudCBzdWItdHlwZXMuIElmIG11bHRpcGxl
IE1OSURzIHdpdGgNCmRpZmZlcmVudCBzdWItdHlwZXMgYXJlIHByZXNlbnQgaW4NCmEgc2luZ2xl
IG1lc3NhZ2UsIHdoaWNoIG9uZSBzaG91bGQgZS5nLiB0aGUgTE1BIHRha2UgZm9yIHRoZSBCQyBs
b29rdXAuLg0KTm8gYmlnIHByb2JsZW0gdG8gc29sdmUsIGJ1dA0KdG8gYmUgY29uc2lkZXJlZCBp
biBpbXBsZW1lbnRhdGlvbnMuDQoNCklmIHRoZSByZWFzb24gZm9yIG11bHRpcGxlIHByZXNlbnQg
TU5JRHMgd2l0aCBkaWZmZXJlbnQgc3ViLXR5cGVzIGlzIHRvDQpkbyBvdGhlciB0aGluZ3MgdGhh
biBpZGVudGlmeWluZw0KdGhlIG5vZGUgb3IgdXNpbmcgdGhlIElEIGFzIGtleSBmb3IgYSBsb29r
dXAsIEkgYW0gd29uZGVyaW5nIGlmIGl0IHdvdWxkDQpub3QgYmUgbW9yZSBhcHByb3ByaWF0ZQ0K
dG8gZ28gZm9yIGEgZGlmZmVyZW50IGNvbnRhaW5lciBvcHRpb24gdG8gY2Fycnkgc3VjaCBpbmZv
cm1hdGlvbi4NClNvbWV0aGluZyBsaWtlIGEgY29tcGxlbWVudGFyeQ0KaWRlbnRpZmllciBvcHRp
b24uDQoNCm1hcmNvDQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIFs8YSBtb3otZG8t
bm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Im1haWx0
bzpzZ3VuZGF2ZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c2d1bmRhdmVAY2lz
Y28uY29tPC9hPl0NClNlbnQ6IERvbm5lcnN0YWcsIDExLiBTZXB0ZW1iZXIgMjAxNCAwMDo0Mg0K
VG86IENoYXJsaWUgUGVya2luczsgTWFyY28gTGllYnNjaDsgPGEgbW96LWRvLW5vdC1zZW5kPSJ0
cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86ZG1tQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPg0KQ2M6IFZpamF5IERldmFy
YXBhbGxpDQpTdWJqZWN0OiBSZTogW0RNTV0gcmVnYXJkaW5nIHRoZSByZS1jaGFydGVyaW5nLi4N
Cg0KSGVsbG8gQ2hhcmxpZSwNCg0KQWdyZWUgd2l0aCB0aGF0LiBNTi1JZCBhcyBpdHMgZGVmaW5l
ZCB0b2RheSBpcyBhIGxvZ2ljYWwgaWRlbnRpZmllci4gSXQNCmRvZXMgbm90DQpyZXF1aXJlIHRo
ZSBpZGVudGlmaWVyIHRvIGJlIGJvdW5kIHRvIGEgcGh5c2ljYWwgZGV2aWNlIG9yIGEgaW50ZXJm
YWNlDQppZGVudGl0eS4NCkJ1dCwgd2UgaGF2ZSBjbGVhcmx5IHNlZW4gcmVxdWlyZW1lbnRzIHdo
ZXJlIHRoZSBuZWVkIGlzIGZvciBnZW5lcmF0aW5nDQppZGVudGlmaWVycyBiYXNlZCBvbiBzb21l
IHBoeXNpY2FsIGlkZW50aWZpZXJzLiBUaG9zZSBwaHlzaWNhbA0KaWRlbnRpZmllcnMgaW5jbHVk
ZQ0KSU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi5ldGMuIElmIHdlIGNhbiBkZWZpbmUgYSB0eXBl
IGZvciBlYWNoIG9mIHRoZQ0Kc291cmNlDQphbmQgdGhlIHJ1bGVzIGZvciBnZW5lcmF0aW5nIE1O
LUlEIGJhc2VkIHVzaW5nIHRob3NlIHNvdXJjZXMsIHRoZSBzZW5kZXINCmFuZA0KcmVjZWl2ZXIg
d2lsbCBoYXZlIGNsZWFyIGd1aWRhbmNlIG9uIGhvdyB0byB1c2UgdGhlIHNwZWMuIFNvbWUgcG9p
bnRlcnMsDQpleHBsYW5hdGlvbiBhbmQgZXhhbXBsZXMgZm9yIGVhY2ggb2YgdGhvc2UgaWRlbnRp
ZmllcnMgd2lsbCBncmVhdGx5IGhlbHANCmF2b2lkDQppbnRlci1vcCBpc3N1ZXMuDQoNCg0KUmVn
YXJkcw0KU3JpDQoNCg0KDQoNCg0KDQoNCk9uIDkvMTAvMTQgMzoyMSBQTSwgJnF1b3Q7Q2hhcmxp
ZSBQZXJraW5zJnF1b3Q7IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQt
bGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0
IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2NoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Jmd0Ozwv
YT4NCndyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlPg0KPHByZT5IZWxsbyBmb2xrcywNCg0K
SSB0aGluayBpdCdzIGJlc3QgdG8gY29uc2lkZXIgdGhlIE1OSUQgYXMgc2ltcGx5IGxpdmluZyBp
biBhIHNwYWNlIG9mDQppZGVudGlmaWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVjaCBhYm91dCB3
aGV0aGVyIGl0J3MgYSBsb2dpY2FsDQppZGVudGlmaWVyIG9yIGEgcGh5c2ljYWwgaWRlbnRpZmll
ci4gIElmIHRoZSBmb3JtZXIsIHRoZW4gc29tZXdoZXJlDQoocGVyaGFwcyBiZWxvdyB0aGUgbmV0
d29yayBsYXllcikgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciBoYXMgYmVlbiBib3VuZA0KdG8gc29t
ZXRoaW5nIGluIHRoZSBwaHlzaWNhbCBpbnRlcmZhY2UsIGJ1dCB0aGF0J3Mgbm90IG91ciBwcm9i
bGVtLg0KDQpUaGUgbnVtYmVyIHNwYWNlIGZvciB0eXBlcyBvZiBNTklEcyBpcyBsaWtlbHkgdG8g
c3RheSBwcmV0dHkgZW1wdHksIHNvDQpJJ2Qgc2F5IHdlIGNvdWxkIGFkZCBhcyBtYW55IHR5cGVz
IGFzIHdvdWxkIGJlIGNvbnZlbmllbnQgZm9yIHRoZQ0Kc29mdHdhcmUgZGVzaWduZXJzLiAgU28s
IHdlIGNvdWxkIGNvbmNlaXZhYmx5IGhhdmUgc2V2ZXJhbCBNTklEcw0KZGVmaW5lZCB0aGF0IGFs
bCAmcXVvdDtsb29rZWQgbGlrZSZxdW90OyBOQUlzICh3aGljaCwgdGhlbXNlbHZlcywgJnF1b3Q7
bG9vayBsaWtlJnF1b3Q7DQpGUUROcykuDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCg0KDQpP
biA5LzEwLzIwMTQgODoxMSBBTSwgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSB3cm90ZToNCjwv
cHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPlllcy4gQ3VycmVudGx5LCB0aGUgTU5JRCBpcyBpZiB0
aGUgbmFpIGZvcm1hdCBhbmQgaXMgb3ZlcmxvYWRlZC4gVGhlDQpNTklEICBpbiAzR1BQIHNwZWNz
IGlzIHRoZSBJTVNJLU5BSSAoSU1TSUBSRUFMTSksIGl0cyBiYXNlZCBvbiB0aGUNCklNU0kuIEV4
Og0KJnF1b3Q7Jmx0O0lNU0kmZ3Q7QGVwYy5tbmMmbHQ7TU5DJmd0Oy5tY2MmbHQ7TUNDJmd0Oy4z
Z3BwbmV0d29yay5vcmfCsg0KDQpXZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07DQoNCldlIGFsc28g
aGF2ZSBhcHByb2FjaGVzIHRvIHRyYW5zZm9ybSBNQUMgdG8gUHNldWRvIElNU0ksIGFuZCB0aGVu
DQpjYXJyeSBJTVNJLU5BSSBhcyB0aGUgTU4tSUQuDQoNCg0KU28sIHdlIG5lZWQgdW5pcXVlIHN1
Yi10eXBlcyBmb3IgZWFjaCBvZiB0aGUgdHlwZXMvc291cmNlcy4NCg0KTU4tSWQgYmFzZWQgb24g
SU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi4NCg0KQWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5n
dWlzaCBiZXR3ZWVuIElNU0kgYW5kIElNU0ktTkFJID8NCg0KU3JpDQoNCg0KDQpPbiA5LzEwLzE0
IDY6MjkgQU0sICZxdW90O01hcmNvIExpZWJzY2gmcXVvdDsgPGEgbW96LWRvLW5vdC1zZW5kPSJ0
cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86TWFyY28uTGll
YnNjaEBuZWNsYWIuZXUiIHRhcmdldD0iX2JsYW5rIj4mbHQ7TWFyY28uTGllYnNjaEBuZWNsYWIu
ZXUmZ3Q7PC9hPiB3cm90ZToNCg0KPC9wcmU+DQo8YmxvY2txdW90ZT4NCjxwcmU+SXQgc2VlbXMg
dGhlIE1OSUQgaXMgc29tZWhvdyBvdmVybG9hZGVkIHRvIGNhcnJ5IGJvdGgsIG5vZGUtc3BlY2lm
aWMNCklEcywgIGUuZy4gTUFDLCBhcyB3ZWxsIGFzIHN1YnNjcmliZXIgSURzLCB3aGljaCBpcyB0
aGUgSU1TSS4NClRoZXJlIG1heSBiZSB2YWx1ZSBpbiBhZGRpbmcgdGhlIElNRUkgdG8gdGhlIGxp
c3Qgb2YgcG9zc2libGUgdHlwZXMNCm9mICBub2RlLXNwZWNpZmljIElEcy4NCg0KbWFyY28NCg0K
PC9wcmU+DQo8YmxvY2txdW90ZT4NCjxwcmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IGRtbSBbPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZy
ZWV0ZXh0IiBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij5tYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3JpIEd1bmRh
dmVsbGkNCihzZ3VuZGF2ZSkNClNlbnQ6IERpZW5zdGFnLCA5LiBTZXB0ZW1iZXIgMjAxNCAyMzoz
MA0KVG86IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSk7IENoYXJsaWUgUGVya2luczsgPGEgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVm
PSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPg0K
Q2M6IFZpamF5IERldmFyYXBhbGxpDQpTdWJqZWN0OiBSZTogW0RNTV0gcmVnYXJkaW5nIHRoZSBy
ZS1jaGFydGVyaW5nLi4NCg0KVHdvIG1vcmUgY29tbWVudHMuDQoNCg0KDQo0LikgSSdkIGFsc28g
dXNlIHN1Yi10eXBlIHZhbHVlIG9mICgyKSBmb3IgSU1TSS4gSnVzdCB0byBhbGlnbiB3aXRoDQp0
aGUgIHN1Yi10eXBlcyAgZGVmaW5lZCBmb3IgTU4gSWQgZGVmaW5lZCBmb3IgSUNNUC4gSSBzdXNw
ZWN0IHRoZXJlDQphcmUgc29tZSAgaW1wbGVtZW50YXRpb25zICBhbHJlYWR5IHVzaW5nIHN1Yi10
eXBlICgyKS4gUGxlYXNlIHNlZQ0KdGhlIG90aGVyIHRocmVhZC4NCg0KDQo1LikgRm9yIGVhY2gg
b2YgdGhlIHN1Yi10eXBlcywgd2UgbmVlZCB0ZXh0IGluY2x1ZGluZyBleGFtcGxlcyBhbmQNCnNv
bWUNCmV4cGxhbmF0aW9uIG9uIGhvdyB0aGV5IGFyZSB1c2VkLg0KDQoNClNyaQ0KDQoNCg0KT24g
OS85LzE0IDI6MjAgUE0sICZxdW90O1NyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkmcXVvdDsgPGEg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVm
PSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Jmx0O3NndW5kYXZl
QGNpc2NvLmNvbSZndDs8L2E+DQp3cm90ZToNCg0KPC9wcmU+DQo8YmxvY2txdW90ZT4NCjxwcmU+
SGkgQ2hhcmxpZSwNCg0KVGhpcyBpcyBnb29kLiBUaGFua3MuDQoNCg0KMS4pIElmIEVVSS00OCBh
bmQgRVVJLTY0IGFkZHJlc3NlcyBhcmUgZGVyaXZlZCBvZiBhIDQ4LWJpdCBJRUVFDQo4MDIuMg0K
YWRkcmVzcywgd2h5IGRvIHdlIG5lZWQgdG8gdHdvIHN1Yi10eXBlcyA/IFdoeSBub3QgaGF2ZSBq
dXN0IG9uZQ0Kc3ViLXR5cGUgZm9yIG1hYyBiYXNlZCBpZGVudGlmaWVycyA/DQoNCjIuKSBTdWIg
dHlwZSB2YWx1ZSAoMSkgaXMgY3VycmVudGx5IHVzZWQuIEl0cyBjdXJyZW50bHkgb3ZlcmxvYWRl
ZA0KZm9yDQpJTVNJLU5BSSAoM0dQUCBzcGVjcykgYW5kIGdlbmVyaWMgTkFJIGJhc2VkIGlkZW50
aWZpZXJzLiBHaXZlbiB0aGUNCmRlZmluaXRpb24gb2YgbmV3IHN1Yi10eXBlcywgd2UgbmVlZCBz
b21lIHRleHQgZXhwbGFpbmluZyB0aGUNCm1vdGl2YXRpb24NCg0KMy4pIFByb3Bvc2VkIFN1Yi10
eXBlIHZhbHVlIG9mICgyKSBmb3IgSVB2NiBhZGRyZXNzLiBXaGF0IGV4YWN0bHkNCmlzDQp0aGlz
ID8gQXJlIHRoZXNlIENHQS1iYXNlZCBJUHY2IGFkZHJlc3NlcyA/DQoNCg0KDQoNCiAgICAgICAg
ICAgICAgICAgICAgIE5ldyBNb2JpbGUgTm9kZSBJZGVudGlmaWVyIFR5cGVzDQoNCiAgICAgICAg
ICAgICAgICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LSYjNDM7DQogICAgICAgICAgICAgICB8IElkZW50aWZpZXIgVHlwZSB8IElkZW50aWZpZXIgVHlw
ZSBOdW1iZXIgfA0KICAgICAgICAgICAgICAgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsNCiAgICAgICAgICAgICAgIHwgSVB2NiBBZGRyZXNz
ICAgIHwgMiAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBJTVNJ
ICAgICAgICAgICAgfCAzICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwg
ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg
ICB8IFAtVE1TSSAgICAgICAgICB8IDQgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg
ICAgICAgICAgIHwgRVVJLTQ4IGFkZHJlc3MgIHwgNSAgICAgICAgICAgICAgICAgICAgICB8DQog
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg
fA0KICAgICAgICAgICAgICAgfCBFVUktNjQgYWRkcmVzcyAgfCA2ICAgICAgICAgICAgICAgICAg
ICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAg
ICAgICAgICB8DQogICAgICAgICAgICAgICB8IEdVVEkgICAgICAgICAgICB8IDcgICAgICAgICAg
ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgJiM0MzstLS0tLS0tLS0tLS0tLS0tLSYjNDM7
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsNCg0KDQoNCg0KDQoNCg0KUmVnYXJkcw0KU3Jp
DQpQUzogR29vZCB0byBzZWUgVmlqYXkgYmFjaw0KDQoNCk9uIDkvOS8xNCAxOjI4IFBNLCAmcXVv
dDtDaGFybGllIFBlcmtpbnMmcXVvdDsNCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9
Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0
aGxpbmsubmV0IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2NoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsu
bmV0Jmd0OzwvYT4NCndyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlPg0KPHByZT5IZWxsbyBm
b2xrcywNCg0KSGVyZSdzIHRoZSBsYXN0IEludGVybmV0IERyYWZ0IHRoYXQgd2UgZGlkLCBsb25n
IGFnbyBleHBpcmVkOg0KDQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0
LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFm
dC1wZXJraW5zLW1leHQtNDI4M21uaWRzLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93
d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1wZXJraW5zLW1leHQtNDI4M21uaWRzLTAxLnR4
dDwvYT4NCg0KSSdsbCByZXN1Ym1pdCBpdCB3aXRoIGEgZmV3IHVwZGF0ZXMgYXMgYSBwZXJzb25h
bCBkcmFmdCB0byBkbW0uDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQo8L3ByZT4NCjwvYmxvY2tx
dW90ZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCmRtbSBtYWlsaW5nIGxpc3QNCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1v
ei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNz
PSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZG1tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9kbW08L2E+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0
DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0
ZWQiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5v
cmc8L2E+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0
ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFy
Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9h
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i
bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1haWxpbmcgbGlzdA0K
PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVk
IiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3Jn
PC9hPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4
dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iIHRhcmdl
dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbTwvYT48
L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCjxhIG1vei1kby1ub3Qtc2VuZD0i
dHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmRtbUBp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT48YSBtb3otZG8tbm90LXNl
bmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L2E+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjxicj4NCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZG1tIG1haWxpbmcgbGlzdDxicj4NCjxh
IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGll
dGYub3JnPC9hPjxicj4NCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vZG1tPC9hPjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8YnI+DQo8L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0tIDxicj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBu
YW1lPSJ4Ij48L3NwYW4+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwv
ZGl2Pg0KPGRpdj5IYWtpbWEgQ2hhb3VjaGk8L2Rpdj4NCjxkaXY+UHJvZmVzc29yPC9kaXY+DQo8
ZGl2PlRlbGVjb20gU3VkIFBhcmlzPC9kaXY+DQo8ZGl2Pkluc3RpdHV0IE1pbmVzIFRlbGVjb208
L2Rpdj4NCjxkaXY+OSBydWUgQ2hhcmxlcyBGb3VyaWVyPC9kaXY+DQo8ZGl2PjkxMDExIEV2cnk8
L2Rpdj4NCjxkaXY+MDE2MDc2NDQ0MzwvZGl2Pg0KPHNwYW4gbmFtZT0ieCI+PC9zcGFuPjxicj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvYmxvY2txdW90ZT4NCjxi
cj4NCjxicj4NCjxwcmUgY2xhc3M9Im1vei1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSANClJlZ2Fy
ZHMsDQpDaGFybGllIFAuPC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_D04A103F166DDCsgundaveciscocom_--


From nobody Thu Sep 25 18:41:09 2014
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 7D7C31A0264 for ; Thu, 25 Sep 2014 18:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 cWNx41QaXxoC for ; Thu, 25 Sep 2014 18:40:53 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6478F1A0181 for ; Thu, 25 Sep 2014 18:40:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27273; q=dns/txt; s=iport; t=1411695655; x=1412905255; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=YavvXCo6kftowY/1FUFh0ek7HSrN6P0tkfxmEL4mItU=; b=RLcfFnwvpu6Q338/L+obcum6V7BsgAd6SNAxBsIPTEvZ/9jrt+X7/oPA DNZp6qrIsHqJryCDDV8vi96Fo6l5fYU+2ZyrUL8enb0rm8FkGhoYr0anJ ouGS4z+Uqnw0cSOOwiNef659OManr3WuXUEeWoWgXc3eZ9WF0MqO5Px30 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj4FAEPDJFStJV2Z/2dsb2JhbABggkhGU1cEyicBCYdOAoEDFgF7hAMBAQEDAQEBASpBCQIFBwYBCA4DAwECIQcuCxQJCAIEDgUJEogPAwkIDbo9G4cWAReNXhCBThEBPwwFBgEGA4RCBY9IghiEOocJgWKTdINjbAGBBQkXBB6BAgEBAQ
X-IronPort-AV: E=Sophos;i="5.04,601,1406592000";  d="scan'208,217";a="358104463"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 26 Sep 2014 01:40:54 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q1eq8a018750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 01:40:52 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 20:40:51 -0500
From: "Sri Gundavelli (sgundave)" 
To: Charlie Perkins 
Thread-Topic: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt
Thread-Index: AQHP2SrnrQg1JZelOEaXcrIdtCoeOw==
Date: Fri, 26 Sep 2014 01:40:51 +0000
Message-ID: 
In-Reply-To: <54248798.7030701@earthlink.net>
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.217]
Content-Type: multipart/alternative; boundary="_000_D04A112D166DE6sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/n9dmo2lgmLpx9e1QB8m4SlY5Hgs
Cc: Vijay Devarapalli , "dmm@ietf.org" 
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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: Fri, 26 Sep 2014 01:40:58 -0000

--_000_D04A112D166DE6sgundaveciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Charlie,

> Moreover, MNIDs  containing sensitive identifiers might only be used for =
signaling during initial network entry.

The below text looks good. I assume the "initial entry" below refers to the=
 Authentication phase, where we allow temporary identifiers such as Chargea=
ble user identifier to be used in all PBU/PBA messages. As you are aware, w=
e currently do not have mechanisms to use different MN-Id's one for the ini=
tial BU/PBU exchange and a different identifier for the subsequent lifetime=
 updates.


Regards
Sri

From: Charlie Perkins >
Date: Thursday, September 25, 2014 2:22 PM
To: Sri Gundavelli >
Cc: Vijay Devarapalli >=
, "dmm@ietf.org" >
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283=
mnids-00.txt


Hello again folks,

Here is a proposed text for a new paragraph in the Security Considerations:


   Some identifiers (e.g., IMSI) are considered to be private
   information.  If used in the MNID extension as defined in this
   document, the packet including the MNID extension should be encrypted
   so that personal information or trackable identifiers would not be
   inadvertently disclosed to passive observers.  Moreover, MNIDs
   containing sensitive identifiers might only be used for signaling
   during initial network entry.  Subsequent binding update exchanges
   would then rely on a temporary identifier allocated during the
   initial network entry.

Comments will be appreciated.

Regards,
Charlie P.



On 9/25/2014 12:02 PM, Charles E. Perkins wrote:

Hello folks,

I think the best solution for this would be a section in the Security
Considerations explaining the need.   I will fashion some text for the
upcoming revision ....-01.txt

Regards,
Charlie P.


On 9/24/2014 10:48 AM, Sri Gundavelli (sgundave) wrote:
Hi Pierrick,

The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP TS 2=
3.003. It is sent in PBU/PBA messages. Not sure, if IMSI information is see=
n as a confidential IE. But, I agree on the need to include some text on ho=
w the signaling message can be protected with privacy / confidentiality ser=
vice set, when the identifier is based on some confidential data.


Regards
Sri

From: "pierrick.seite@orange.com" >
Date: Wednesday, September 24, 2014 8:56 AM
To: "Charles E. Perkins" >, "dmm@ietf.org" =
>
Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283=
mnids-00.txt

Hi Charlie,

Thanks for the list=85 it looks good. I=92m just wondering about security c=
onsiderations=85 Actually, from 3GPP standpoint, security constrains on IMS=
I and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI is very r=
arely sent on the air (maybe only one time at the beginning of the 3GPP aut=
hentication process) for security reasons. So, I=92m wondering if adding IM=
SI to the list of IDs, without any warnings, is somehow introducing securit=
y weakness to the 3GPP security process.   Consequently, I=92m not sure abo=
ut the following statement =93This document does not introduce any security=
 mechanisms, and does not have any impact on existing security mechanisms.=
=94 It=92s maybe not so true from the 3GPP point of view=85

Maybe we should state that the ID option MUST be used in a way that it does=
 not harm existing security mechanisms (i.e. use the option with caution :)=
). For example, to address the issue above (maybe there are other examples=
=85 I don=92t know=85), we could state that the IMSI should be transmitted =
only during first binding update, and not transmitted anymore as long as th=
e association IMSI/HoA/HNP is done=85. Or... simpler way to address the iss=
ue:  if nobody has use-case for transmitting the IMSI, we can simply remove=
 the IMSI from the list :)

BR,
Pierrick


De : dmm [mailto:dmm-bounces@ietf.org] De la part de Charles E. Perkins
Envoy=E9 : mardi 23 septembre 2014 21:10
=C0 : dmm@ietf.org
Objet : [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids=
-00.txt

Hello folks,

We have published a ...-00 version of the MNIDs draft.  This is mainly for
reference purposes.  A new version should be out within a week or so,
incorporating the suggestions and comments from people who responded
to the earlier suggestion to revisit this work.

Regards,
Charlie P.


-------- Original Message --------
Subject:

New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Date:

Tue, 23 Sep 2014 10:43:12 -0700

From:



To:

Charles E. Perkins , V=
ijay Devarapalli , Charles E.Perkins 



A new version of I-D, draft-perkins-dmm-4283mnids-00.txt

has been successfully submitted by Charles E. Perkins and posted to the

IETF repository.



Name:         draft-perkins-dmm-4283mnids

Revision:     00

Title:        MN Identifier Types for RFC 4283 Mobile Node Identifier Optio=
n

Document date: 2014-09-23

Group:        Individual Submission

Pages:        4

URL:            http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283m=
nids-00.txt

Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnid=
s/

Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00





Abstract:

   Additional Identifier Types are proposed for use with the Mobile Node

   Identifier Option for MIPv6 (RFC 4283).









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat







___________________________________________________________________________=
______________________________________________

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.



--
Regards,
Charlie P.



_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


--_000_D04A112D166DE6sgundaveciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <4CB7B8310079E74BB519D59909102712@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi Charlie,







> Moreover, MNIDs  containing sensitive identifiers might=
 only be used for signaling during initial network entry.







The below text looks good. I assume the "initial entry" belo=
w refers to the Authentication phase, where we allow temporary identifiers =
such as Chargeable user identifier to be used in all PBU/PBA messages. As y=
ou are aware, we currently do not have mechanisms
 to use different MN-Id's one for the initial BU/PBU exchange and a differe=
nt identifier for the subsequent lifetime updates. 












Regards


Sri









From: Charlie Perkins <charles.perkins@earthlink.net=
>

Date: Thursday, September 25, 2014 =
2:22 PM

To: Sri Gundavelli <sgundave@cisco.com>

Cc: Vijay Devarapalli <dvijay@rocketmail.com>, "dmm@ietf.org" <dmm@ietf.org>

Subject: Re: [DMM] Fwd: New Version=
 Notification for draft-perkins-dmm-4283mnids-00.txt













Hello again folks,



Here is a proposed text for a new paragraph in the Security Considerations:=







   Some identifiers (e.g., IMSI) are considered to be private

   information.  If used in the MNID extension as defined in=
 this

   document, the packet including the MNID extension should be en=
crypted

   so that personal information or trackable identifiers would no=
t be

   inadvertently disclosed to passive observers.  Moreover, =
MNIDs

   containing sensitive identifiers might only be used for signal=
ing

   during initial network entry.  Subsequent binding update =
exchanges

   would then rely on a temporary identifier allocated during the=


   initial network entry.





Comments will be appreciated.



Regards,

Charlie P.








On 9/25/2014 12:02 PM, Charles E. Perkins wr=
ote:






Hello folks,



I think the best solution for this would be a section in the Security

Considerations explaining the need.   I will fashion some text fo=
r the

upcoming revision ....-01.txt



Regards,

Charlie P.






On 9/24/2014 10:48 AM, Sri Gundavelli (sgund=
ave) wrote:






Hi Pierrick,







The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP=
 TS 23.003. It is sent in PBU/PBA messages. Not sure, if IMSI information i=
s seen as a confidential IE. But, I agree on the need to include some text =
on how the signaling message can
 be protected with privacy / confidentiality service set, when the identifi=
er is based on some confidential data.












Regards


Sri









From: "pierrick.seite@orange.com" <pierrick.seite@orange.com>

Date: Wednesday, September 24, 2014=
 8:56 AM

To: "Charles E. Perkins" =
<charl=
iep@computer.org>, "dmm@ietf.org" <dmm@ietf.org>

Subject: Re: [DMM] Fwd: New Version=
 Notification for draft-perkins-dmm-4283mnids-00.txt

















Hi Charlie,


 


Thanks for the list=
=85 it looks good. I=92m just wondering about security considerations=85 Ac=
tually, from 3GPP standpoint, security constrains
 on IMSI and GPRSS/LTE temporary identifiers (P-TMSI, GUTI). AFAIK, IMSI is=
 very rarely sent on the air (maybe only one time at the beginning of the 3=
GPP authentication process) for security reasons. So, I=92m wondering if ad=
ding IMSI to the list of IDs, without
 any warnings, is somehow introducing security weakness to the 3GPP securit=
y process.   Consequently, I=92m not sure about the following sta=
tement =93This document
 does not introduce any security mechanisms, and does not have any impact o=
n existing security mechanisms.=94
It=92s maybe not so true from the 3=
GPP point of view=85


 


Maybe we should sta=
te that the ID option MUST be used in a way that it does not harm existing =
security mechanisms (i.e. use the option
 with caution J). F=
or example, to address the issue above (maybe
 there are other examples=85 I don=92t know=85), we could state that the IM=
SI should be transmitted only during first binding update, and not transmit=
ted anymore as long as the association IMSI/HoA/HNP is done=85. Or... simpl=
er way to address the issue:  if nobody
 has use-case for transmitting the IMSI, we can simply remove the IMSI from=
 the list
J=



 


BR,


Pierrick=



 


 








De : dmm [<=
a moz-do-not-send=3D"true" href=3D"mailto:dmm-bounces@ietf.org">mailto:dmm-=
bounces@ietf.org]
De la part de Charles E. Perkins

Envoy=E9 : mardi 23 septembre 2014 21:10

=C0 : =
dmm@ietf.org

Objet : [DMM] Fwd: New Version Notification for draft-perkins-d=
mm-4283mnids-00.txt






 


Hello folks,



We have published a ...-00 version of the MNIDs draft.  This is mainly=
 for

reference purposes.  A new version should be out within a week or so,<=
br>
incorporating the suggestions and comments from people who responded

to the earlier suggestion to revisit this work.



Regards,

Charlie P.








-------- Original Message -------- 








Subjec=
t: 




New Version Notification for draft-perkins-dmm-4283m=
nids-00.txt








Date: =





Tue, 23 Sep 2014 10:43:12 -0700








From: =





<internet-drafts@ietf.org>








To: 




Charles E. Perkins 
<charliep@computer.org>, Vijay Devarapalli 
<unknown-email-Vijay-Devarapalli@ietfa.amsl.com>, Charles E.Perki=
ns 
<charliep@computer.org>








 


A new version of I-D, draft-perkins-dmm-4283mnids-00.txt

has been successfully submitted by Charles E. Perkins and posted to th=
e


IETF repository.


 


Name:         draft-perkins-dm=
m-4283mnids


Revision:     00


Title:        MN Identifier Types f=
or RFC 4283 Mobile Node Identifier Option


Document date: 2014-09-23


Group:        Individual Submission=



Pages:        4


URL:           =
 http://www.ietf.org/internet-drafts/draft=
-perkins-dmm-4283mnids-00.txt


Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/=



Htmlized:       http=
://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00


 


 


Abstract:


   Additional Identifier Types are proposed for use with the=
 Mobile Node


   Identifier Option for MIPv6 (RFC 4283).


 


            &nb=
sp;            =
            &nb=
sp;            =
            &nb=
sp;            =
       


 


 


Please note that it may take a couple of minutes from the time of subm=
ission


until the htmlized version and diff are available at tools.ietf.org.


 


The IETF Secretariat


 


 


 




 






______________________________________________________________________=
___________________________________________________

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.











--=20
Regards,
Charlie P.




 


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













--_000_D04A112D166DE6sgundaveciscocom_--


From nobody Thu Sep 25 19:01:41 2014
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 0CF571A0273 for ; Thu, 25 Sep 2014 19:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 l8kSvZK96VoH for ; Thu, 25 Sep 2014 19:01:35 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D5C1A0217 for ; Thu, 25 Sep 2014 19:01:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69026; q=dns/txt; s=iport; t=1411696895; x=1412906495; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=/rf+NJJkFBWkeXYA6G0hwJ8tPSnLGtfzBPH+MqfBAGg=; b=GUtcdGgkPqoGKSyNsh/omx34Q/uepKUocJ3g5AZeBbjIe/mwp565/u/G 3zLw2N43BTqHnpsD6IEvJVyq6ln4nnmWDZ2wh7ujqA5HBhaIxbXEu4EM7 SeXGWuN9DS9oaqBwRZLFwiLdJkkd2YV4v8Oe1xfKM7LeE5f9OYzdjueCk Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkUFADbIJFStJV2P/2dsb2JhbABXCYJIRlNXBIJ9xykBCYdOAhhrFgF7hAMBAQEEAQEBFwkKQQsMBgEIEQMBAQEOEwEGAwIEJQsUCQgCBA4FCYghAxENq0WOXBuHFgEXjV4QgVUuAgEGAgcKBwoGAQIEgnKBUwWGJokighiLQ5VWg2NsAYFHgQIBAQE
X-IronPort-AV: E=Sophos; i="5.04,601,1406592000"; d="scan'208,217"; a="81392502"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 26 Sep 2014 02:01:34 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q21X93024443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 02:01:33 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 21:01:33 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Charles E. Perkins" , "Templin, Fred L" 
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHP2S3LkDTQ4jBnSUOOVT5rfmYm0Q==
Date: Fri, 26 Sep 2014 02:01:32 +0000
Message-ID: 
In-Reply-To: <5424844C.1020101@computer.org>
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.217]
Content-Type: multipart/alternative; boundary="_000_D04A1522166DF8sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/tw9lN_ZpfYMWKycD2TNG5Lmf3UM
Cc: Vijay Devarapalli , "dmm@ietf.org" 
Subject: Re: [DMM] MNID Types
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, 26 Sep 2014 02:01:39 -0000

--_000_D04A1522166DF8sgundaveciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBhc3N1bWVkIERIQ1AtVVVJRCBpcyBvbmx5IG9uZSBvZiB0aGUgc3VidHlwZXMgKHR5cGUgNCkg
b2YgRFVJRCBkZWZpbml0aW9uIHNwZWNpZmllZCBpbiBSRkMzMzE1LkRlZmluaW5nIG9uZSB0eXBl
IHZhbHVlIGluIE1OLU5BSSBmb3IgRFVJRCBzaG91bGQgY292ZXIgRFVJLUxMVCwgRFVJRC1FTiAu
LkRVSS1VVUlEIC4uZXRj4oCmDQoNCkl0IG1heSBhcHBlYXIgd2UgYXJlIGJvaWxpbmcgdGhlIG9j
ZWFuIGhlcmUsIGJ1dCBkZWZpbmluZyBhIHR5cGUgdmFsdWUgZm9yIGFsbCBjb21tb24gaWRlbnRp
ZmllcnMgd2lsbCBoZWxwLg0KDQoNClJlZ2FyZHMNClNyaQ0KDQoNCg0KRnJvbTogIkNoYXJsZXMg
RS4gUGVya2lucyIgPGNoYXJsaWVwQGNvbXB1dGVyLm9yZzxtYWlsdG86Y2hhcmxpZXBAY29tcHV0
ZXIub3JnPj4NCk9yZ2FuaXphdGlvbjogQmx1ZSBTa2llcw0KRGF0ZTogVGh1cnNkYXksIFNlcHRl
bWJlciAyNSwgMjAxNCAyOjA4IFBNDQpUbzogIlRlbXBsaW4sIEZyZWQgTCIgPEZyZWQuTC5UZW1w
bGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiwgU3JpIEd1
bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4N
CkNjOiBWaWpheSBEZXZhcmFwYWxsaSA8ZHZpamF5QHJvY2tldG1haWwuY29tPG1haWx0bzpkdmlq
YXlAcm9ja2V0bWFpbC5jb20+PiwgImRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiIg
PGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbRE1NXSBN
TklEIFR5cGVzDQoNCg0KSGVsbG8gRnJlZCwNCg0KSSBjYW4gaW5jbHVkZSBEVUlELVVVSUQgYXMg
YW4gaWRlbnRpZmllciB0eXBlLCBhbmQgY2l0ZSBSRkMgNDEyMi4gIElzIHRoaXMNCnN1ZmZpY2ll
bnQsIG9yIGRvIEkgbmVlZCB0byBhbHNvIGRvIHNvbWV0aGluZyByZWxhdGVkIHRvIERIQ1B2NiBE
VUlEPw0KDQpJIGRpZCBub3Qgc2VlIGFueSBzcGVjaWZpYyBjb25uZWN0aW9uIGJldHdlZW4gdGhp
cyB0eXBlIG9mIGlkZW50aWZpZXIgYW5kDQp0aGUgUkZJRCBkaXNjdXNzaW9uLiAgSXMgdGhlcmUg
c29tZXRoaW5nIHRoYXQgcmVsYXRlcyB0aGUgdHdvIHR5cGVzPw0KDQpSZWdhcmRzLA0KQ2hhcmxp
ZSBQLg0KDQoNCg0KT24gOS8yNS8yMDE0IDI6MDAgUE0sIFRlbXBsaW4sIEZyZWQgTCB3cm90ZToN
CkhpIENoYXJsaWUsDQoNCkkgYW0gaW50ZXJlc3RlZCBpbiBub2RlIElEcyB0aGF0IGNhbiBiZSBy
ZXByZXNlbnRlZCBpbiBhIERIQ1B2NiBEVUlELiBUaGVyZSBpcw0KUkZDNjM1NSB3aGljaCBlbmNv
ZGVzIGEgbm9kZSBJRCBiYXNlZCBvbiBEVUlELVVVSUQgKFVuaXZlcnNhbGx5IFVuaXF1ZQ0KSURl
bnRpZmllcikuIEFGQUlDVCwgdGhlIFVVSUQgaXMgYSAxMjgtYml0IGNvbnRhaW5lciBmb3JtYXR0
ZWQgcGVyIFJGQzQxMjINCnNwZWNpZmljYXRpb25zIHRoYXQgaW5jbHVkZXMgYSB0aW1lIHBvcnRp
b24gYW5kIGEgbm9kZSBJRCBwb3J0aW9uLiBBbnkgY2hhbmNlDQp0aGlzIHdvdWxkIHNhdGlzZnkg
d2hhdCB5b3UgYXJlIGxvb2tpbmcgZm9yPw0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IGRtbSBb
bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hhcmxlcyBFLiBQZXJr
aW5zDQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0IDE6NDMgUE0NClRvOiBTcmkg
R3VuZGF2ZWxsaSAoc2d1bmRhdmUpDQpDYzogVmlqYXkgRGV2YXJhcGFsbGk7IGRtbUBpZXRmLm9y
ZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtETU1dIE1OSUQgVHlwZXMNCg0K
DQpIZWxsbyBTcmksDQoNCklzIHRoZSBEb0QtOTYgaWRlbnRpZmllciBmb3IgYSBzcGVjaWFsIGtp
bmQgb2YgUkZJRCwgb3IgaXMgaXQNCnZhbGlkIGZvciBhbGwgdGhlIFJGSUQgZGV2aWNlcyB0aGF0
IHdvdWxkIGJlIG9mIGludGVyZXN0Pw0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQpPbiA5LzIx
LzIwMTQgOTo1OSBBTSwgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSB3cm90ZToNCkhpIEhha2lt
YSwNCg0KVGhhdCBpcyBhIGdvb2QgaWRlYS4gV2Ugc2hvdWxkIHJlZ2lzdGVyIGEgdHlwZSBmb3Ig
dGhlIERvZC05NiBpZGVudGlmaWVyIGFzIHdlbGwuDQoNCg0KUmVnYXJkcw0KU3JpDQoNCg0KRnJv
bTogSGFraW1hIENoYW91Y2hpIDxoYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJpcy5ldTxt
YWlsdG86aGFraW1hLmNoYW91Y2hpQHRlbGVjb20tc3VkcGFyaXMuZXU+Pg0KRGF0ZTogU3VuZGF5
LCBTZXB0ZW1iZXIgMjEsIDIwMTQgODoxMSBBTQ0KVG86IFNyaSBHdW5kYXZlbGxpIDxzZ3VuZGF2
ZUBjaXNjby5jb208bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbT4+DQpDYzogQ2hhcmxpZSBQZXJr
aW5zIDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldDxtYWlsdG86Y2hhcmxlcy5wZXJraW5z
QGVhcnRobGluay5uZXQ+PiwgTWFyY28gTGllYnNjaCA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8
bWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1Pj4sICJkbW1AaWV0Zi5vcmc8bWFpbHRvOmRt
bUBpZXRmLm9yZz4iIDxkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4+LCBWaWpheSBE
ZXZhcmFwYWxsaSA8ZHZpamF5QHJvY2tldG1haWwuY29tPG1haWx0bzpkdmlqYXlAcm9ja2V0bWFp
bC5jb20+Pg0KU3ViamVjdDogUmU6IFtETU1dIE1OSUQgVHlwZXMNCg0KSGVsbG8gRm9sa3MsDQoN
CkRvIHlvdSB0aGluayB0aGF0IGNvbnNpZGVyaW5nIHNwZWNpZmljIGJ1dCBuZWVkZWQgdGVjaG5v
bG9naWVzIGZvciBtb3Zpbmcgb2JqZWN0cyBpbiAgSW50ZXJuZXQgb2YgVGhpbmdzICBzdWNoIGFz
IFJGSUQgKFJhZGlvIEZyZXF1ZW5jeSBJZGVudGlmaWVyKSB3aXRoIDk2IGJpdHMgaWRlbnRpZmll
cnMgd2lsbCBiZSBhbHNvIHJlbGV2ZW50IHRvIENoYXJsaWUncyBjdXJyZW50IGRyYWZ0IGFuZCB0
aGUgZWZmb3J0cyByZWxhdGVkIHRvIE1OSUQ/DQoNClJlZ2FyZHMsDQoNCkhha2ltYQ0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZTogIlNyaSBHdW5kYXZlbGxpIChzZ3Vu
ZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb208bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbT4+DQrD
gDogIkNoYXJsaWUgUGVya2lucyIgPGNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PG1haWx0
bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4+LCAiTWFyY28gTGllYnNjaCIgPE1hcmNv
LkxpZWJzY2hAbmVjbGFiLmV1PG1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldT4+LCBkbW1A
aWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4sICJWaWpheSBEZXZhcmFwYWxsaSIgPGR2aWph
eUByb2NrZXRtYWlsLmNvbTxtYWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29tPj4NCkVudm95w6k6
IEpldWRpIDExIFNlcHRlbWJyZSAyMDE0IDIzOjU3OjExDQpPYmpldDogUmU6IFtETU1dIE1OSUQg
VHlwZXMNCg0KSGkgQ2hhcmxpZSwNCg0KRmV3IG1vcmUgcmV2aWV3cy9kaXNjdXNzaW9ucyBhbmQg
Y2FwdHVyaW5nIHRoZSBjb25zZW5zdXMgaW4gdGhlIGJhc2UgdmVyc2lvbiB3aWxsIGhlbHAuIEJ1
dCwgSSdtIG9rIGVpdGhlciB3YXkg4oCmDQoNCg0KUmVnYXJkcw0KU3JpDQoNCkZyb206IENoYXJs
aWUgUGVya2lucyA8Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8bWFpbHRvOmNoYXJsZXMu
cGVya2luc0BlYXJ0aGxpbmsubmV0Pj4NCkRhdGU6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTEsIDIw
MTQgMjo0NiBQTQ0KVG86IFNyaSBHdW5kYXZlbGxpIDxzZ3VuZGF2ZUBjaXNjby5jb208bWFpbHRv
OnNndW5kYXZlQGNpc2NvLmNvbT4+LCBNYXJjbyBMaWVic2NoIDxNYXJjby5MaWVic2NoQG5lY2xh
Yi5ldTxtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PiwgImRtbUBpZXRmLm9yZzxtYWls
dG86ZG1tQGlldGYub3JnPiIgPGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPj4sIFZp
amF5IERldmFyYXBhbGxpIDxkdmlqYXlAcm9ja2V0bWFpbC5jb208bWFpbHRvOmR2aWpheUByb2Nr
ZXRtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0KDQoNCkhlbGxvIGZv
bGtzLA0KDQpJIHByb3Bvc2UgdG8gc3VibWl0IHRoZSAuLi4uLTAwLnR4dCBkb2N1bWVudCBhcyBp
dCBpcyB0byB0aGUgSW50ZXJuZXQNCkRyYWZ0cyBkaXJlY3RvcnksIGFuZCB0aGVuIHRvIGdvIGFi
b3V0IG1ha2luZyB1cGRhdGVzIGFjY29yZGluZyB0bw0KdGhlIGRpc2N1c3Npb24gb24gdGhpcyBs
aXN0LiAgRG8geW91IHRoaW5rIHRoaXMgaXMgcmVhc29uYWJsZT8NCg0KUmVnYXJkcywNCkNoYXJs
aWUgUC4NCg0KDQpPbiA5LzExLzIwMTQgNzoyMSBBTSwgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZl
KSB3cm90ZToNCg0KPENoYW5naW5nIHRoZSBzdWJqZWN0IGxpbmUgdG8gcmVmbGVjdCB0aGUgTU5J
ZCBkaXNjdXNzaW9uPg0KDQoNCg0KDQoNCk1hcmNvLA0KDQoNCg0KDQoNClRoaW5raW5nIGZ1cnRo
ZXIgb24gdGhlIGNvbXBsZW1lbnRhcnkgaWRlbnRpZmllciBvcHRpb24uDQoNCg0KDQotIFRoZXJl
IGlzIGFscmVhZHkgdGhlIGxpbmstbGF5ZXIgaWRlbnRpZmllciBvcHRpb24gdGhhdCBjYW4gYmUg
dXNlZCBmb3INCg0KY2FycnlpbmcgdGhlIE1hYyBhZGRyZXNzDQoNCi0gSU1FSSBhbmQgTVNJU0RO
IGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gMjkuMjc1IGFzIGEgM0dQUCBWU0Uncw0KDQoNCg0KSW4g
c29tZSBzZW5zZSwgdGhlIGNvbXBsZW1lbnRhcnkgaWRlbnRpZmllcnMgYXJlIGFscmVhZHkgcHJl
c2VudC4NCg0KDQoNClNyaQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIDkvMTEvMTQgNjo1OCBB
TSwgIlNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb20+PG1haWx0
bzpzZ3VuZGF2ZUBjaXNjby5jb20+IHdyb3RlOg0KDQpJIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5
IG11bHRpcGxlIE1OLUlkIGluc3RhbmNlcyBuZWVkIHRvIGJlIHByZXNlbnQgaW4gYQ0KDQpzaW5n
bGUgbWVzc2FnZSA/IEluIG15IGV4cGVyaWVuY2UsIHRoaXMgaXMgc3RyaWN0bHkgYSBkZXBsb3lt
ZW50DQoNCmNvbnNpZGVyYXRpb24sIHdoZW4gdG8gdXNlIHdoYXQgdHlwZSBvZiBpZGVudGlmaWVy
cy4NCg0KDQoNCkFzc3VtaW5nIHRoZSBiYWNrZW5kIHN5c3RlbSBjYW4gdGllIGFsbCB0aGUgTU4t
SWQncyB0byBhIHNpbmdsZQ0KDQpzdWJzY3JpcHRpb24sIGFueSBwcmVzZW50ZWQgaWRlbnRpZmll
ciBjYW4gYmUgc3VmZmljaWVudCBmb3IgdGhlIGdhdGV3YXkNCg0KdG8gZG8gdGhlIEJDRSBsb29r
dXAuDQoNCg0KDQpJZiBtdWx0aXBsZSBpbnN0YW5jZXMgY2FuIGJlIHByZXNlbnQsIHRoZW4gd2Ug
bmVlZCB0byBkZWFsIHdpdGggbW9yZSBlcnJvcg0KDQpjYXNlcy4gSXMgdGhhdCByZWFsbHkgbmVl
ZGVkID8NCg0KDQoNCg0KDQpJIGFtIHdvbmRlcmluZyBpZiBpdCB3b3VsZCBub3QgYmUgbW9yZSBh
cHByb3ByaWF0ZSB0byBnbyBmb3IgYSBkaWZmZXJlbnQNCg0KY29udGFpbmVyIG9wdGlvbiB0byBj
YXJyeSBzdWNoIGluZm9ybWF0aW9uLiBTb21ldGhpbmcgbGlrZSBhDQoNCmNvbXBsZW1lbnRhcnkg
aWRlbnRpZmllciBvcHRpb24uDQoNClNvdW5kcyBpbnRlcmVzdGluZy4gQXJlIHlvdSBzdWdnZXN0
aW5nIHdlIGxlYXZlIHRoZSBjdXJyZW50IE1OLUlEIGFzIGl0DQoNCmlzLCBidXQgdXNlIGEgbmV3
IGNvbXBsZW1lbnRhcnkgb3B0aW9uID8gQnV0LCBpZiB0aGUgcmVxdWlyZW1lbnQgaXMgZm9yIGEN
Cg0KTWFjIGJhc2VkIGlkZW50aWZpZXJzLCB3aGF0IHdpbGwgYmUgdGhlcmUgaW4gdGhlIGN1cnJl
bnQgTU4tSWQgb3B0aW9uID8gV2UNCg0Kc3RpbGwgbmVlZCB0byBoYXZlIGlkZW50aWZpZXIgdGhl
cmUgPw0KDQoNCg0KDQoNCg0KDQoNCg0KU3JpDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gOS8x
MS8xNCAyOjAzIEFNLCAiTWFyY28gTGllYnNjaCIgPE1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1Pjxt
YWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+IHdyb3RlOg0KDQoNCg0KTm8gaXNzdWUgd2l0
aCBsb2dpY2FsIHZzLiBwaHlzaWNhbCBJRC4gQnV0IEkgYW0gd29uZGVyaW5nIGFib3V0IHR3bw0K
DQp0aGluZ3M6DQoNCg0KDQpPcGVyYXRpb24gaXMgY2xlYXIgdG8gbWUgaW4gY2FzZSBhIHNpbmds
ZSBNTklEIGlzIHByZXNlbnQgaW4gYSBtZXNzYWdlDQoNCmFuZCBJIHNlZSB0aGUgdmFsdWUgaW4g
YmVpbmcNCg0KZmxleGlibGUgdG8gY2hvb3NlIGZyb20gZGlmZmVyZW50IHN1Yi10eXBlcy4gSWYg
bXVsdGlwbGUgTU5JRHMgd2l0aA0KDQpkaWZmZXJlbnQgc3ViLXR5cGVzIGFyZSBwcmVzZW50IGlu
DQoNCmEgc2luZ2xlIG1lc3NhZ2UsIHdoaWNoIG9uZSBzaG91bGQgZS5nLiB0aGUgTE1BIHRha2Ug
Zm9yIHRoZSBCQyBsb29rdXAuLg0KDQpObyBiaWcgcHJvYmxlbSB0byBzb2x2ZSwgYnV0DQoNCnRv
IGJlIGNvbnNpZGVyZWQgaW4gaW1wbGVtZW50YXRpb25zLg0KDQoNCg0KSWYgdGhlIHJlYXNvbiBm
b3IgbXVsdGlwbGUgcHJlc2VudCBNTklEcyB3aXRoIGRpZmZlcmVudCBzdWItdHlwZXMgaXMgdG8N
Cg0KZG8gb3RoZXIgdGhpbmdzIHRoYW4gaWRlbnRpZnlpbmcNCg0KdGhlIG5vZGUgb3IgdXNpbmcg
dGhlIElEIGFzIGtleSBmb3IgYSBsb29rdXAsIEkgYW0gd29uZGVyaW5nIGlmIGl0IHdvdWxkDQoN
Cm5vdCBiZSBtb3JlIGFwcHJvcHJpYXRlDQoNCnRvIGdvIGZvciBhIGRpZmZlcmVudCBjb250YWlu
ZXIgb3B0aW9uIHRvIGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24uDQoNClNvbWV0aGluZyBsaWtlIGEg
Y29tcGxlbWVudGFyeQ0KDQppZGVudGlmaWVyIG9wdGlvbi4NCg0KDQoNCm1hcmNvDQoNCg0KDQot
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRh
dmUpIFttYWlsdG86c2d1bmRhdmVAY2lzY28uY29tXQ0KDQpTZW50OiBEb25uZXJzdGFnLCAxMS4g
U2VwdGVtYmVyIDIwMTQgMDA6NDINCg0KVG86IENoYXJsaWUgUGVya2luczsgTWFyY28gTGllYnNj
aDsgZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQoNCkNjOiBWaWpheSBEZXZhcmFw
YWxsaQ0KDQpTdWJqZWN0OiBSZTogW0RNTV0gcmVnYXJkaW5nIHRoZSByZS1jaGFydGVyaW5nLi4N
Cg0KDQoNCkhlbGxvIENoYXJsaWUsDQoNCg0KDQpBZ3JlZSB3aXRoIHRoYXQuIE1OLUlkIGFzIGl0
cyBkZWZpbmVkIHRvZGF5IGlzIGEgbG9naWNhbCBpZGVudGlmaWVyLiBJdA0KDQpkb2VzIG5vdA0K
DQpyZXF1aXJlIHRoZSBpZGVudGlmaWVyIHRvIGJlIGJvdW5kIHRvIGEgcGh5c2ljYWwgZGV2aWNl
IG9yIGEgaW50ZXJmYWNlDQoNCmlkZW50aXR5Lg0KDQpCdXQsIHdlIGhhdmUgY2xlYXJseSBzZWVu
IHJlcXVpcmVtZW50cyB3aGVyZSB0aGUgbmVlZCBpcyBmb3IgZ2VuZXJhdGluZw0KDQppZGVudGlm
aWVycyBiYXNlZCBvbiBzb21lIHBoeXNpY2FsIGlkZW50aWZpZXJzLiBUaG9zZSBwaHlzaWNhbA0K
DQppZGVudGlmaWVycyBpbmNsdWRlDQoNCklNU0ksIE1TSVNETiwgSU1FSSwgTUFDIC4uZXRjLiBJ
ZiB3ZSBjYW4gZGVmaW5lIGEgdHlwZSBmb3IgZWFjaCBvZiB0aGUNCg0Kc291cmNlDQoNCmFuZCB0
aGUgcnVsZXMgZm9yIGdlbmVyYXRpbmcgTU4tSUQgYmFzZWQgdXNpbmcgdGhvc2Ugc291cmNlcywg
dGhlIHNlbmRlcg0KDQphbmQNCg0KcmVjZWl2ZXIgd2lsbCBoYXZlIGNsZWFyIGd1aWRhbmNlIG9u
IGhvdyB0byB1c2UgdGhlIHNwZWMuIFNvbWUgcG9pbnRlcnMsDQoNCmV4cGxhbmF0aW9uIGFuZCBl
eGFtcGxlcyBmb3IgZWFjaCBvZiB0aG9zZSBpZGVudGlmaWVycyB3aWxsIGdyZWF0bHkgaGVscA0K
DQphdm9pZA0KDQppbnRlci1vcCBpc3N1ZXMuDQoNCg0KDQoNCg0KUmVnYXJkcw0KDQpTcmkNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIDkvMTAvMTQgMzoyMSBQTSwgIkNoYXJsaWUg
UGVya2lucyIgPGNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PjxtYWlsdG86Y2hhcmxlcy5w
ZXJraW5zQGVhcnRobGluay5uZXQ+DQoNCndyb3RlOg0KDQoNCg0KSGVsbG8gZm9sa3MsDQoNCg0K
DQpJIHRoaW5rIGl0J3MgYmVzdCB0byBjb25zaWRlciB0aGUgTU5JRCBhcyBzaW1wbHkgbGl2aW5n
IGluIGEgc3BhY2Ugb2YNCg0KaWRlbnRpZmllcnMsIGFuZCBub3Qgd29ycnkgdG9vIG11Y2ggYWJv
dXQgd2hldGhlciBpdCdzIGEgbG9naWNhbA0KDQppZGVudGlmaWVyIG9yIGEgcGh5c2ljYWwgaWRl
bnRpZmllci4gIElmIHRoZSBmb3JtZXIsIHRoZW4gc29tZXdoZXJlDQoNCihwZXJoYXBzIGJlbG93
IHRoZSBuZXR3b3JrIGxheWVyKSB0aGUgbG9naWNhbCBpZGVudGlmaWVyIGhhcyBiZWVuIGJvdW5k
DQoNCnRvIHNvbWV0aGluZyBpbiB0aGUgcGh5c2ljYWwgaW50ZXJmYWNlLCBidXQgdGhhdCdzIG5v
dCBvdXIgcHJvYmxlbS4NCg0KDQoNClRoZSBudW1iZXIgc3BhY2UgZm9yIHR5cGVzIG9mIE1OSURz
IGlzIGxpa2VseSB0byBzdGF5IHByZXR0eSBlbXB0eSwgc28NCg0KSSdkIHNheSB3ZSBjb3VsZCBh
ZGQgYXMgbWFueSB0eXBlcyBhcyB3b3VsZCBiZSBjb252ZW5pZW50IGZvciB0aGUNCg0Kc29mdHdh
cmUgZGVzaWduZXJzLiAgU28sIHdlIGNvdWxkIGNvbmNlaXZhYmx5IGhhdmUgc2V2ZXJhbCBNTklE
cw0KDQpkZWZpbmVkIHRoYXQgYWxsICJsb29rZWQgbGlrZSIgTkFJcyAod2hpY2gsIHRoZW1zZWx2
ZXMsICJsb29rIGxpa2UiDQoNCkZRRE5zKS4NCg0KDQoNClJlZ2FyZHMsDQoNCkNoYXJsaWUgUC4N
Cg0KDQoNCg0KDQoNCg0KT24gOS8xMC8yMDE0IDg6MTEgQU0sIFNyaSBHdW5kYXZlbGxpIChzZ3Vu
ZGF2ZSkgd3JvdGU6DQoNClllcy4gQ3VycmVudGx5LCB0aGUgTU5JRCBpcyBpZiB0aGUgbmFpIGZv
cm1hdCBhbmQgaXMgb3ZlcmxvYWRlZC4gVGhlDQoNCk1OSUQgIGluIDNHUFAgc3BlY3MgaXMgdGhl
IElNU0ktTkFJIChJTVNJQFJFQUxNKSwgaXRzIGJhc2VkIG9uIHRoZQ0KDQpJTVNJLiBFeDoNCg0K
IjxJTVNJPkBlcGMubW5jPE1OQz4ubWNjPE1DQz4uM2dwcG5ldHdvcmsub3JnwrINCg0KDQoNCldl
IGFsc28gaGF2ZSBNQUM0OEBSRUFMTTsNCg0KDQoNCldlIGFsc28gaGF2ZSBhcHByb2FjaGVzIHRv
IHRyYW5zZm9ybSBNQUMgdG8gUHNldWRvIElNU0ksIGFuZCB0aGVuDQoNCmNhcnJ5IElNU0ktTkFJ
IGFzIHRoZSBNTi1JRC4NCg0KDQoNCg0KDQpTbywgd2UgbmVlZCB1bmlxdWUgc3ViLXR5cGVzIGZv
ciBlYWNoIG9mIHRoZSB0eXBlcy9zb3VyY2VzLg0KDQoNCg0KTU4tSWQgYmFzZWQgb24gSU1TSSwg
TVNJU0ROLCBJTUVJLCBNQUMgLi4NCg0KDQoNCkFsc28sIGRvIHdlIG5lZWQgdG8gZGlzdGluZ3Vp
c2ggYmV0d2VlbiBJTVNJIGFuZCBJTVNJLU5BSSA/DQoNCg0KDQpTcmkNCg0KDQoNCg0KDQoNCg0K
T24gOS8xMC8xNCA2OjI5IEFNLCAiTWFyY28gTGllYnNjaCIgPE1hcmNvLkxpZWJzY2hAbmVjbGFi
LmV1PjxtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+IHdyb3RlOg0KDQoNCg0KSXQgc2Vl
bXMgdGhlIE1OSUQgaXMgc29tZWhvdyBvdmVybG9hZGVkIHRvIGNhcnJ5IGJvdGgsIG5vZGUtc3Bl
Y2lmaWMNCg0KSURzLCAgZS5nLiBNQUMsIGFzIHdlbGwgYXMgc3Vic2NyaWJlciBJRHMsIHdoaWNo
IGlzIHRoZSBJTVNJLg0KDQpUaGVyZSBtYXkgYmUgdmFsdWUgaW4gYWRkaW5nIHRoZSBJTUVJIHRv
IHRoZSBsaXN0IG9mIHBvc3NpYmxlIHR5cGVzDQoNCm9mICBub2RlLXNwZWNpZmljIElEcy4NCg0K
DQoNCm1hcmNvDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBkbW0g
W21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNyaSBHdW5kYXZlbGxp
DQoNCihzZ3VuZGF2ZSkNCg0KU2VudDogRGllbnN0YWcsIDkuIFNlcHRlbWJlciAyMDE0IDIzOjMw
DQoNClRvOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpOyBDaGFybGllIFBlcmtpbnM7IGRtbUBp
ZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KDQpDYzogVmlqYXkgRGV2YXJhcGFsbGkNCg0K
U3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hhcnRlcmluZy4uDQoNCg0KDQpU
d28gbW9yZSBjb21tZW50cy4NCg0KDQoNCg0KDQoNCg0KNC4pIEknZCBhbHNvIHVzZSBzdWItdHlw
ZSB2YWx1ZSBvZiAoMikgZm9yIElNU0kuIEp1c3QgdG8gYWxpZ24gd2l0aA0KDQp0aGUgIHN1Yi10
eXBlcyAgZGVmaW5lZCBmb3IgTU4gSWQgZGVmaW5lZCBmb3IgSUNNUC4gSSBzdXNwZWN0IHRoZXJl
DQoNCmFyZSBzb21lICBpbXBsZW1lbnRhdGlvbnMgIGFscmVhZHkgdXNpbmcgc3ViLXR5cGUgKDIp
LiBQbGVhc2Ugc2VlDQoNCnRoZSBvdGhlciB0aHJlYWQuDQoNCg0KDQoNCg0KNS4pIEZvciBlYWNo
IG9mIHRoZSBzdWItdHlwZXMsIHdlIG5lZWQgdGV4dCBpbmNsdWRpbmcgZXhhbXBsZXMgYW5kDQoN
CnNvbWUNCg0KZXhwbGFuYXRpb24gb24gaG93IHRoZXkgYXJlIHVzZWQuDQoNCg0KDQoNCg0KU3Jp
DQoNCg0KDQoNCg0KDQoNCk9uIDkvOS8xNCAyOjIwIFBNLCAiU3JpIEd1bmRhdmVsbGkgKHNndW5k
YXZlKSIgPHNndW5kYXZlQGNpc2NvLmNvbT48bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbT4NCg0K
d3JvdGU6DQoNCg0KDQpIaSBDaGFybGllLA0KDQoNCg0KVGhpcyBpcyBnb29kLiBUaGFua3MuDQoN
Cg0KDQoNCg0KMS4pIElmIEVVSS00OCBhbmQgRVVJLTY0IGFkZHJlc3NlcyBhcmUgZGVyaXZlZCBv
ZiBhIDQ4LWJpdCBJRUVFDQoNCjgwMi4yDQoNCmFkZHJlc3MsIHdoeSBkbyB3ZSBuZWVkIHRvIHR3
byBzdWItdHlwZXMgPyBXaHkgbm90IGhhdmUganVzdCBvbmUNCg0Kc3ViLXR5cGUgZm9yIG1hYyBi
YXNlZCBpZGVudGlmaWVycyA/DQoNCg0KDQoyLikgU3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJl
bnRseSB1c2VkLiBJdHMgY3VycmVudGx5IG92ZXJsb2FkZWQNCg0KZm9yDQoNCklNU0ktTkFJICgz
R1BQIHNwZWNzKSBhbmQgZ2VuZXJpYyBOQUkgYmFzZWQgaWRlbnRpZmllcnMuIEdpdmVuIHRoZQ0K
DQpkZWZpbml0aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxhaW5p
bmcgdGhlDQoNCm1vdGl2YXRpb24NCg0KDQoNCjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1ZSBv
ZiAoMikgZm9yIElQdjYgYWRkcmVzcy4gV2hhdCBleGFjdGx5DQoNCmlzDQoNCnRoaXMgPyBBcmUg
dGhlc2UgQ0dBLWJhc2VkIElQdjYgYWRkcmVzc2VzID8NCg0KDQoNCg0KDQoNCg0KDQoNCiAgICAg
ICAgICAgICAgICAgICAgIE5ldyBNb2JpbGUgTm9kZSBJZGVudGlmaWVyIFR5cGVzDQoNCg0KDQog
ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
Kw0KDQogICAgICAgICAgICAgICB8IElkZW50aWZpZXIgVHlwZSB8IElkZW50aWZpZXIgVHlwZSBO
dW1iZXIgfA0KDQogICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tKw0KDQogICAgICAgICAgICAgICB8IElQdjYgQWRkcmVzcyAgICB8IDIgICAg
ICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8
ICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICB8IElNU0kgICAgICAg
ICAgICB8IDMgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICB8ICAgICAg
ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICB8
IFAtVE1TSSAgICAgICAgICB8IDQgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAg
ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAg
ICAgICAgICAgICB8IEVVSS00OCBhZGRyZXNzICB8IDUgICAgICAgICAgICAgICAgICAgICAgfA0K
DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg
ICAgfA0KDQogICAgICAgICAgICAgICB8IEVVSS02NCBhZGRyZXNzICB8IDYgICAgICAgICAgICAg
ICAgICAgICAgfA0KDQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICB8IEdVVEkgICAgICAgICAgICB8IDcg
ICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t
LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KUmVnYXJkcw0KDQpTcmkNCg0KUFM6IEdvb2QgdG8gc2VlIFZpamF5IGJhY2sNCg0KDQoNCg0K
DQpPbiA5LzkvMTQgMToyOCBQTSwgIkNoYXJsaWUgUGVya2lucyINCg0KPGNoYXJsZXMucGVya2lu
c0BlYXJ0aGxpbmsubmV0PjxtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+DQoN
Cndyb3RlOg0KDQoNCg0KSGVsbG8gZm9sa3MsDQoNCg0KDQpIZXJlJ3MgdGhlIGxhc3QgSW50ZXJu
ZXQgRHJhZnQgdGhhdCB3ZSBkaWQsIGxvbmcgYWdvIGV4cGlyZWQ6DQoNCg0KDQpodHRwOi8vd3d3
LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVya2lucy1tZXh0LTQyODNtbmlkcy0wMS50eHQN
Cg0KDQoNCkknbGwgcmVzdWJtaXQgaXQgd2l0aCBhIGZldyB1cGRhdGVzIGFzIGEgcGVyc29uYWwg
ZHJhZnQgdG8gZG1tLg0KDQoNCg0KUmVnYXJkcywNCg0KQ2hhcmxpZSBQLg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpkbW0gbWFpbGluZyBsaXN0
DQoNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vZG1tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQoNCmRtbSBtYWlsaW5nIGxpc3QNCg0KZG1tQGlldGYub3JnPG1haWx0
bzpkbW1AaWV0Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0N
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KZG1t
IG1haWxpbmcgbGlzdA0KDQpkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpkbW0gbWFpbGluZyBsaXN0DQoNCmRtbUBp
ZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZG1tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0KDQotLQ0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpIYWtpbWEgQ2hhb3VjaGkNClByb2Zl
c3Nvcg0KVGVsZWNvbSBTdWQgUGFyaXMNCkluc3RpdHV0IE1pbmVzIFRlbGVjb20NCjkgcnVlIENo
YXJsZXMgRm91cmllcg0KOTEwMTEgRXZyeQ0KMDE2MDc2NDQ0Mw0KDQoNCg0KDQoNCi0tDQoNClJl
Z2FyZHMsDQoNCkNoYXJsaWUgUC4NCg0KDQotLQ0KUmVnYXJkcywNCkNoYXJsaWUgUC4NCg==

--_000_D04A1522166DF8sgundaveciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <6858464065A28B4595373B68CE226539@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+SSBhc3N1bWVk
IERIQ1AtVVVJRCBpcyBvbmx5IG9uZSBvZiB0aGUgc3VidHlwZXMgKHR5cGUgNCkgb2YgRFVJRCBk
ZWZpbml0aW9uIHNwZWNpZmllZCBpbiBSRkMzMzE1LkRlZmluaW5nIG9uZSB0eXBlIHZhbHVlIGlu
IE1OLU5BSSBmb3IgRFVJRCBzaG91bGQgY292ZXIgRFVJLUxMVCwgRFVJRC1FTiAuLkRVSS1VVUlE
IC4uZXRj4oCmPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JdCBtYXkgYXBwZWFyIHdl
IGFyZSBib2lsaW5nIHRoZSBvY2VhbiBoZXJlLCBidXQgZGVmaW5pbmcgYSB0eXBlIHZhbHVlIGZv
ciBhbGwgY29tbW9uIGlkZW50aWZpZXJzIHdpbGwgaGVscC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzPC9kaXY+DQo8ZGl2PlNyaTwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt
aWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNr
OyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQ
QURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGlu
OyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9u
ZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJv
bTogPC9zcGFuPiZxdW90O0NoYXJsZXMgRS4gUGVya2lucyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmNoYXJsaWVwQGNvbXB1dGVyLm9yZyI+Y2hhcmxpZXBAY29tcHV0ZXIub3JnPC9hPiZndDs8
YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T3JnYW5pemF0aW9uOiA8L3NwYW4+
Qmx1ZSBTa2llczxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3Nw
YW4+VGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAxNCAyOjA4IFBNPGJyPg0KPHNwYW4gc3R5bGU9
ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7VGVtcGxpbiwgRnJlZCBMJnF1b3Q7
ICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+RnJlZC5MLlRl
bXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7LCBTcmkgR3VuZGF2ZWxsaSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnNndW5kYXZlQGNpc2NvLmNvbSI+c2d1bmRhdmVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5WaWpheSBEZXZhcmFwYWxs
aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbSI+ZHZpamF5QHJvY2tl
dG1haWwuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRt
bUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRt
bUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1
YmplY3Q6IDwvc3Bhbj5SZTogW0RNTV0gTU5JRCBUeXBlczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPjxi
cj4NCkhlbGxvIEZyZWQsPGJyPg0KPGJyPg0KSSBjYW4gaW5jbHVkZSBEVUlELVVVSUQgYXMgYW4g
aWRlbnRpZmllciB0eXBlLCBhbmQgY2l0ZSBSRkMgNDEyMi4mbmJzcDsgSXMgdGhpczxicj4NCnN1
ZmZpY2llbnQsIG9yIGRvIEkgbmVlZCB0byBhbHNvIGRvIHNvbWV0aGluZyByZWxhdGVkIHRvIERI
Q1B2NiBEVUlEPzxicj4NCjxicj4NCkkgZGlkIG5vdCBzZWUgYW55IHNwZWNpZmljIGNvbm5lY3Rp
b24gYmV0d2VlbiB0aGlzIHR5cGUgb2YgaWRlbnRpZmllciBhbmQ8YnI+DQp0aGUgUkZJRCBkaXNj
dXNzaW9uLiZuYnNwOyBJcyB0aGVyZSBzb21ldGhpbmcgdGhhdCByZWxhdGVzIHRoZSB0d28gdHlw
ZXM/PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpDaGFybGllIFAuPGJyPg0KPGJyPg0KPGJyPg0K
PGJyPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiA5LzI1LzIwMTQgMjowMCBQTSwg
VGVtcGxpbiwgRnJlZCBMIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlk
OjIxMzRGODQzMDA1MUI2NEY4MTVDNjkxQTYyRDk4MzE4MzJEMjdCMUVAWENILUJMVi01MDQubncu
bm9zLmJvZWluZy5jb20iIHR5cGU9ImNpdGUiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250
ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQNCiAgICAgICAgbWVkaXVtKSI+DQo8IS0t
W2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq
IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1
bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+
PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQt
ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz
IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h
bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp
ZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm
b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJs
YWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7
DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpz
cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h
dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU
TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9
DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh
bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7
DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox
MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp
bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y
ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd
LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+
DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht
bD48IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3Mywg
MTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+SGkgQ2hhcmxpZSw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGli
cmksIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwg
NzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPkkgYW0gaW50ZXJl
c3RlZCBpbiBub2RlIElEcyB0aGF0IGNhbiBiZSByZXByZXNlbnRlZCBpbiBhIERIQ1B2NiBEVUlE
LiBUaGVyZSBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250
LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5SRkM2MzU1IHdoaWNoIGVuY29kZXMgYSBu
b2RlIElEIGJhc2VkIG9uIERVSUQtVVVJRCAoVW5pdmVyc2FsbHkgVW5pcXVlPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog
MTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOyAiPklEZW50aWZpZXIpLiBBRkFJQ1QsIHRoZSBVVUlEIGlzIGEgMTI4LWJpdCBjb250
YWluZXIgZm9ybWF0dGVkIHBlciBSRkM0MTIyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigz
MSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPnNwZWNpZmlj
YXRpb25zIHRoYXQgaW5jbHVkZXMgYSB0aW1lIHBvcnRpb24gYW5kIGEgbm9kZSBJRCBwb3J0aW9u
LiBBbnkgY2hhbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPnRoaXMgd291bGQgc2F0aXNmeSB3aGF0
IHlvdSBhcmUgbG9va2luZyBmb3I/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMs
IDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwg
c2Fucy1zZXJpZjsgIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigz
MSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4NCiAgICAgICAgICAwaW4gMGluIDQuMHB0Ij4N
CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYN
CiAgICAgICAgICAgICAgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBjb2xvcjogd2lu
ZG93dGV4dDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgY29sb3I6IHdpbmRvd3RleHQ7IGZvbnQt
ZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+IGRtbSBbPGEgY2xhc3M9Im1vei10eHQtbGlu
ay1mcmVldGV4dCIgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZG1t
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaGFybGVzIEUuIFBl
cmtpbnM8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAxNCAxOjQz
IFBNPGJyPg0KPGI+VG86PC9iPiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpPGJyPg0KPGI+Q2M6
PC9iPiBWaWpheSBEZXZhcmFwYWxsaTsgPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRl
ZCIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+DQpkbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbRE1NXSBNTklEIFR5cGVzPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+
DQpIZWxsbyBTcmksPGJyPg0KPGJyPg0KSXMgdGhlIERvRC05NiBpZGVudGlmaWVyIGZvciBhIHNw
ZWNpYWwga2luZCBvZiBSRklELCBvciBpcyBpdDxicj4NCnZhbGlkIGZvciBhbGwgdGhlIFJGSUQg
ZGV2aWNlcyB0aGF0IHdvdWxkIGJlIG9mIGludGVyZXN0Pzxicj4NCjxicj4NClJlZ2FyZHMsPGJy
Pg0KQ2hhcmxpZSBQLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk9uIDkvMjEvMjAxNCA5OjU5IEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRh
dmUpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5IaSBIYWtpbWEsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgYSBnb29kIGlkZWEuIFdlIHNob3VsZCByZWdpc3RlciBh
IHR5cGUgZm9yIHRoZSBEb2QtOTYgaWRlbnRpZmllciBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHM8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNyaTxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjQjVDNERGDQogICAgICAgICAgICAgIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg
Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+RnJvbToNCjwvc3Bhbj48L2I+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy
aWY7ICI+SGFraW1hIENoYW91Y2hpICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9
Im1haWx0bzpoYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJpcy5ldSI+aGFraW1hLmNoYW91
Y2hpQHRlbGVjb20tc3VkcGFyaXMuZXU8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXks
IFNlcHRlbWJlciAyMSwgMjAxNCA4OjExIEFNPGJyPg0KPGI+VG86IDwvYj5TcmkgR3VuZGF2ZWxs
aSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lz
Y28uY29tIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+Q2hhcmxp
ZSBQZXJraW5zICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpjaGFy
bGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCI+Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8
L2E+Jmd0OywgTWFyY28gTGllYnNjaCAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVm
PSJtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXUiPk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1
PC9hPiZndDssICZxdW90OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmRt
bUBpZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBtb3otZG8tbm90LXNl
bmQ9InRydWUiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT4mZ3Q7
LCBWaWpheSBEZXZhcmFwYWxsaSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJt
YWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29tIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0
Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0RNTV0gTU5JRCBUeXBlczxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SGVsbG8gRm9sa3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHlvdSB0aGluayB0aGF0IGNvbnNpZGVyaW5nIHNwZWNp
ZmljIGJ1dCBuZWVkZWQgdGVjaG5vbG9naWVzIGZvciBtb3Zpbmcgb2JqZWN0cyBpbiZuYnNwOyBJ
bnRlcm5ldCBvZiBUaGluZ3MmbmJzcDsgc3VjaCBhcyBSRklEIChSYWRpbyBGcmVxdWVuY3kgSWRl
bnRpZmllcikgd2l0aCA5NiBiaXRzIGlkZW50aWZpZXJzIHdpbGwgYmUgYWxzbyByZWxldmVudCB0
byBDaGFybGllJ3MgY3VycmVudCBkcmFmdCBhbmQgdGhlIGVmZm9ydHMNCiByZWxhdGVkIHRvIE1O
SUQ/Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5IYWtpbWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIiBhbGlnbj0iY2VudGVyIj4N
CjxociBpZD0iendjaHIiIGFsaWduPSJjZW50ZXIiIHNpemU9IjIiIHdpZHRoPSIxMDAlIj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyAiPkRlOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7ICI+JnF1b3Q7U3JpIEd1bmRh
dmVsbGkgKHNndW5kYXZlKSZxdW90OyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVm
PSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxi
cj4NCjxiPsOAOiA8L2I+JnF1b3Q7Q2hhcmxpZSBQZXJraW5zJnF1b3Q7ICZsdDs8YSBtb3otZG8t
bm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5l
dCI+Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ8L2E+Jmd0OywgJnF1b3Q7TWFyY28gTGll
YnNjaCZxdW90OyAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86TWFy
Y28uTGllYnNjaEBuZWNsYWIuZXUiPk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PC9hPiZndDssDQo8
YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPmRtbUBp
ZXRmLm9yZzwvYT4sICZxdW90O1ZpamF5IERldmFyYXBhbGxpJnF1b3Q7ICZsdDs8YSBtb3otZG8t
bm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20iPmR2aWph
eUByb2NrZXRtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RW52b3nDqTogPC9iPkpldWRpIDExIFNl
cHRlbWJyZSAyMDE0IDIzOjU3OjExPGJyPg0KPGI+T2JqZXQ6IDwvYj5SZTogW0RNTV0gTU5JRCBU
eXBlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgIj5IaSBD
aGFybGllLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlm
OyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNl
cmlmOyAiPkZldyBtb3JlIHJldmlld3MvZGlzY3Vzc2lvbnMgYW5kIGNhcHR1cmluZyB0aGUgY29u
c2Vuc3VzIGluIHRoZSBiYXNlIHZlcnNpb24gd2lsbCBoZWxwLiBCdXQsIEknbSBvayBlaXRoZXIg
d2F5IOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlm
OyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNl
cmlmOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5z
LXNlcmlmOyAiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYSwg
c2Fucy1zZXJpZjsgIj5Tcmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYSwg
c2Fucy1zZXJpZjsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERg0KICAgICAgICAgICAg
ICAgICAgICAgIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh
bGlicmksIHNhbnMtc2VyaWY7ICI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+Q2hhcmxpZSBQ
ZXJraW5zICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpjaGFybGVz
LnBlcmtpbnNAZWFydGhsaW5rLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmNoYXJsZXMucGVya2luc0Bl
YXJ0aGxpbmsubmV0PC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIFNlcHRlbWJl
ciAxMSwgMjAxNCAyOjQ2IFBNPGJyPg0KPGI+VG86IDwvYj5TcmkgR3VuZGF2ZWxsaSAmbHQ7PGEg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIiB0
YXJnZXQ9Il9ibGFuayI+c2d1bmRhdmVAY2lzY28uY29tPC9hPiZndDssIE1hcmNvIExpZWJzY2gg
Jmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOk1hcmNvLkxpZWJzY2hA
bmVjbGFiLmV1IiB0YXJnZXQ9Il9ibGFuayI+TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8L2E+Jmd0
OywgJnF1b3Q7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86ZG1tQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBtb3ot
ZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2Js
YW5rIj5kbW1AaWV0Zi5vcmc8L2E+Jmd0OywgVmlqYXkgRGV2YXJhcGFsbGkgJmx0OzxhIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPmR2aWpheUByb2NrZXRtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj
dDogPC9iPlJlOiBbRE1NXSBNTklEIFR5cGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI
ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyAiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOiAxMy41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAi
PkhlbGxvIGZvbGtzLDxicj4NCjxicj4NCkkgcHJvcG9zZSB0byBzdWJtaXQgdGhlIC4uLi4tMDAu
dHh0IGRvY3VtZW50IGFzIGl0IGlzIHRvIHRoZSBJbnRlcm5ldDxicj4NCkRyYWZ0cyBkaXJlY3Rv
cnksIGFuZCB0aGVuIHRvIGdvIGFib3V0IG1ha2luZyB1cGRhdGVzIGFjY29yZGluZyB0bzxicj4N
CnRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgbGlzdC4mbmJzcDsgRG8geW91IHRoaW5rIHRoaXMgaXMg
cmVhc29uYWJsZT88YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCkNoYXJsaWUgUC48YnI+DQo8YnI+
DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMt
c2VyaWY7ICI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyAiPk9u
IDkvMTEvMjAxNCA3OjIxIEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiZsdDtDaGFuZ2luZyB0aGUgc3ViamVj
dCBsaW5lIHRvIHJlZmxlY3QgdGhlIE1OSWQgZGlzY3Vzc2lvbiZndDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5NYXJjbyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlua2luZyBmdXJ0
aGVyIG9uIHRoZSBjb21wbGVtZW50YXJ5IGlkZW50aWZpZXIgb3B0aW9uLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0gVGhlcmUgaXMgYWxyZWFk
eSB0aGUgbGluay1sYXllciBpZGVudGlmaWVyIG9wdGlvbiB0aGF0IGNhbiBiZSB1c2VkIGZvcjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNhcnJ5aW5nIHRoZSBNYWMgYWRkcmVzczxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPi0gSU1FSSBhbmQgTVNJU0ROIGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gMjku
Mjc1IGFzIGEgM0dQUCBWU0UnczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPkluIHNvbWUgc2Vuc2UsIHRoZSBjb21wbGVtZW50YXJ5IGlkZW50aWZp
ZXJzIGFyZSBhbHJlYWR5IHByZXNlbnQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+U3JpPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+T24gOS8xMS8xNCA2OjU4IEFNLCAmcXVvdDtTcmkg
R3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJl
Zj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtzZ3VuZGF2
ZUBjaXNjby5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkkgZG8g
bm90IHNlZSBhIHJlYXNvbiB3aHkgbXVsdGlwbGUgTU4tSWQgaW5zdGFuY2VzIG5lZWQgdG8gYmUg
cHJlc2VudCBpbiBhPG86cD48L286cD48L3ByZT4NCjxwcmU+c2luZ2xlIG1lc3NhZ2UgPyBJbiBt
eSBleHBlcmllbmNlLCB0aGlzIGlzIHN0cmljdGx5IGEgZGVwbG95bWVudDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmNvbnNpZGVyYXRpb24sIHdoZW4gdG8gdXNlIHdoYXQgdHlwZSBvZiBpZGVudGlm
aWVycy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5Bc3N1bWluZyB0aGUgYmFja2VuZCBzeXN0ZW0gY2FuIHRpZSBhbGwgdGhlIE1OLUlkJ3MgdG8g
YSBzaW5nbGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdWJzY3JpcHRpb24sIGFueSBwcmVzZW50
ZWQgaWRlbnRpZmllciBjYW4gYmUgc3VmZmljaWVudCBmb3IgdGhlIGdhdGV3YXk8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT50byBkbyB0aGUgQkNFIGxvb2t1cC48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JZiBtdWx0aXBsZSBpbnN0YW5jZXMgY2Fu
IGJlIHByZXNlbnQsIHRoZW4gd2UgbmVlZCB0byBkZWFsIHdpdGggbW9yZSBlcnJvcjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPmNhc2VzLiBJcyB0aGF0IHJlYWxseSBuZWVkZWQgPzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwcmU+SSBhbSB3b25kZXJpbmcgaWYgaXQgd291bGQgbm90IGJlIG1vcmUg
YXBwcm9wcmlhdGUgdG8gZ28gZm9yIGEgZGlmZmVyZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+
Y29udGFpbmVyIG9wdGlvbiB0byBjYXJyeSBzdWNoIGluZm9ybWF0aW9uLiBTb21ldGhpbmcgbGlr
ZSBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Y29tcGxlbWVudGFyeSBpZGVudGlmaWVyIG9wdGlv
bi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5Tb3VuZHMgaW50ZXJlc3Rp
bmcuIEFyZSB5b3Ugc3VnZ2VzdGluZyB3ZSBsZWF2ZSB0aGUgY3VycmVudCBNTi1JRCBhcyBpdDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlzLCBidXQgdXNlIGEgbmV3IGNvbXBsZW1lbnRhcnkgb3B0
aW9uID8gQnV0LCBpZiB0aGUgcmVxdWlyZW1lbnQgaXMgZm9yIGE8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5NYWMgYmFzZWQgaWRlbnRpZmllcnMsIHdoYXQgd2lsbCBiZSB0aGVyZSBpbiB0aGUgY3Vy
cmVudCBNTi1JZCBvcHRpb24gPyBXZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnN0aWxsIG5lZWQg
dG8gaGF2ZSBpZGVudGlmaWVyIHRoZXJlID88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5T
cmk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT5PbiA5LzExLzE0IDI6MDMgQU0sICZxdW90O01hcmNvIExpZWJzY2gmcXVvdDsgPGEgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXUi
IHRhcmdldD0iX2JsYW5rIj4mbHQ7TWFyY28uTGllYnNjaEBuZWNsYWIuZXUmZ3Q7PC9hPiB3cm90
ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl
Pk5vIGlzc3VlIHdpdGggbG9naWNhbCB2cy4gcGh5c2ljYWwgSUQuIEJ1dCBJIGFtIHdvbmRlcmlu
ZyBhYm91dCB0d288bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGluZ3M6PG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+T3BlcmF0aW9uIGlzIGNsZWFy
IHRvIG1lIGluIGNhc2UgYSBzaW5nbGUgTU5JRCBpcyBwcmVzZW50IGluIGEgbWVzc2FnZTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPmFuZCBJIHNlZSB0aGUgdmFsdWUgaW4gYmVpbmc8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5mbGV4aWJsZSB0byBjaG9vc2UgZnJvbSBkaWZmZXJlbnQgc3ViLXR5cGVz
LiBJZiBtdWx0aXBsZSBNTklEcyB3aXRoPG86cD48L286cD48L3ByZT4NCjxwcmU+ZGlmZmVyZW50
IHN1Yi10eXBlcyBhcmUgcHJlc2VudCBpbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgc2luZ2xl
IG1lc3NhZ2UsIHdoaWNoIG9uZSBzaG91bGQgZS5nLiB0aGUgTE1BIHRha2UgZm9yIHRoZSBCQyBs
b29rdXAuLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5vIGJpZyBwcm9ibGVtIHRvIHNvbHZlLCBi
dXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50byBiZSBjb25zaWRlcmVkIGluIGltcGxlbWVudGF0
aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5JZiB0aGUgcmVhc29uIGZvciBtdWx0aXBsZSBwcmVzZW50IE1OSURzIHdpdGggZGlmZmVyZW50
IHN1Yi10eXBlcyBpcyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRvIG90aGVyIHRoaW5ncyB0
aGFuIGlkZW50aWZ5aW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIG5vZGUgb3IgdXNpbmcg
dGhlIElEIGFzIGtleSBmb3IgYSBsb29rdXAsIEkgYW0gd29uZGVyaW5nIGlmIGl0IHdvdWxkPG86
cD48L286cD48L3ByZT4NCjxwcmU+bm90IGJlIG1vcmUgYXBwcm9wcmlhdGU8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT50byBnbyBmb3IgYSBkaWZmZXJlbnQgY29udGFpbmVyIG9wdGlvbiB0byBjYXJy
eSBzdWNoIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNvbWV0aGluZyBsaWtl
IGEgY29tcGxlbWVudGFyeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlkZW50aWZpZXIgb3B0aW9u
LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPm1h
cmNvPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy
ZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206
IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgWzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJl
Zj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzZ3Vu
ZGF2ZUBjaXNjby5jb208L2E+XTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IERvbm5lcnN0
YWcsIDExLiBTZXB0ZW1iZXIgMjAxNCAwMDo0MjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRvOiBD
aGFybGllIFBlcmtpbnM7IE1hcmNvIExpZWJzY2g7IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIg
aHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwv
YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzogVmlqYXkgRGV2YXJhcGFsbGk8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSZTogW0RNTV0gcmVnYXJkaW5nIHRoZSByZS1jaGFydGVy
aW5nLi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy
ZT5IZWxsbyBDaGFybGllLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPkFncmVlIHdpdGggdGhhdC4gTU4tSWQgYXMgaXRzIGRlZmluZWQgdG9kYXkg
aXMgYSBsb2dpY2FsIGlkZW50aWZpZXIuIEl0PG86cD48L286cD48L3ByZT4NCjxwcmU+ZG9lcyBu
b3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXF1aXJlIHRoZSBpZGVudGlmaWVyIHRvIGJlIGJv
dW5kIHRvIGEgcGh5c2ljYWwgZGV2aWNlIG9yIGEgaW50ZXJmYWNlPG86cD48L286cD48L3ByZT4N
CjxwcmU+aWRlbnRpdHkuPG86cD48L286cD48L3ByZT4NCjxwcmU+QnV0LCB3ZSBoYXZlIGNsZWFy
bHkgc2VlbiByZXF1aXJlbWVudHMgd2hlcmUgdGhlIG5lZWQgaXMgZm9yIGdlbmVyYXRpbmc8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5pZGVudGlmaWVycyBiYXNlZCBvbiBzb21lIHBoeXNpY2FsIGlk
ZW50aWZpZXJzLiBUaG9zZSBwaHlzaWNhbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlkZW50aWZp
ZXJzIGluY2x1ZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JTVNJLCBNU0lTRE4sIElNRUksIE1B
QyAuLmV0Yy4gSWYgd2UgY2FuIGRlZmluZSBhIHR5cGUgZm9yIGVhY2ggb2YgdGhlPG86cD48L286
cD48L3ByZT4NCjxwcmU+c291cmNlPG86cD48L286cD48L3ByZT4NCjxwcmU+YW5kIHRoZSBydWxl
cyBmb3IgZ2VuZXJhdGluZyBNTi1JRCBiYXNlZCB1c2luZyB0aG9zZSBzb3VyY2VzLCB0aGUgc2Vu
ZGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+cmVj
ZWl2ZXIgd2lsbCBoYXZlIGNsZWFyIGd1aWRhbmNlIG9uIGhvdyB0byB1c2UgdGhlIHNwZWMuIFNv
bWUgcG9pbnRlcnMsPG86cD48L286cD48L3ByZT4NCjxwcmU+ZXhwbGFuYXRpb24gYW5kIGV4YW1w
bGVzIGZvciBlYWNoIG9mIHRob3NlIGlkZW50aWZpZXJzIHdpbGwgZ3JlYXRseSBoZWxwPG86cD48
L286cD48L3ByZT4NCjxwcmU+YXZvaWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbnRlci1vcCBp
c3N1ZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UmVnYXJkczxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPlNyaTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPk9uIDkvMTAvMTQgMzoyMSBQTSwgJnF1b3Q7Q2hhcmxpZSBQZXJraW5z
JnF1b3Q7IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVy
a2luc0BlYXJ0aGxpbmsubmV0IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2NoYXJsZXMucGVya2luc0Bl
YXJ0aGxpbmsubmV0Jmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53cm90ZTo8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhlbGxvIGZv
bGtzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PkkgdGhpbmsgaXQncyBiZXN0IHRvIGNvbnNpZGVyIHRoZSBNTklEIGFzIHNpbXBseSBsaXZpbmcg
aW4gYSBzcGFjZSBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlkZW50aWZpZXJzLCBhbmQgbm90
IHdvcnJ5IHRvbyBtdWNoIGFib3V0IHdoZXRoZXIgaXQncyBhIGxvZ2ljYWw8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5pZGVudGlmaWVyIG9yIGEgcGh5c2ljYWwgaWRlbnRpZmllci4mbmJzcDsgSWYg
dGhlIGZvcm1lciwgdGhlbiBzb21ld2hlcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4ocGVyaGFw
cyBiZWxvdyB0aGUgbmV0d29yayBsYXllcikgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciBoYXMgYmVl
biBib3VuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRvIHNvbWV0aGluZyBpbiB0aGUgcGh5c2lj
YWwgaW50ZXJmYWNlLCBidXQgdGhhdCdzIG5vdCBvdXIgcHJvYmxlbS48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgbnVtYmVyIHNwYWNlIGZv
ciB0eXBlcyBvZiBNTklEcyBpcyBsaWtlbHkgdG8gc3RheSBwcmV0dHkgZW1wdHksIHNvPG86cD48
L286cD48L3ByZT4NCjxwcmU+SSdkIHNheSB3ZSBjb3VsZCBhZGQgYXMgbWFueSB0eXBlcyBhcyB3
b3VsZCBiZSBjb252ZW5pZW50IGZvciB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zb2Z0d2Fy
ZSBkZXNpZ25lcnMuJm5ic3A7IFNvLCB3ZSBjb3VsZCBjb25jZWl2YWJseSBoYXZlIHNldmVyYWwg
TU5JRHM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kZWZpbmVkIHRoYXQgYWxsICZxdW90O2xvb2tl
ZCBsaWtlJnF1b3Q7IE5BSXMgKHdoaWNoLCB0aGVtc2VsdmVzLCAmcXVvdDtsb29rIGxpa2UmcXVv
dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5GUUROcykuPG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5DaGFybGllIFAuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+T24gOS8xMC8yMDE0IDg6MTEgQU0sIFNyaSBHdW5kYXZlbGxpIChzZ3Vu
ZGF2ZSkgd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5ZZXMuIEN1cnJlbnRseSwgdGhl
IE1OSUQgaXMgaWYgdGhlIG5haSBmb3JtYXQgYW5kIGlzIG92ZXJsb2FkZWQuIFRoZTxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPk1OSUQmbmJzcDsgaW4gM0dQUCBzcGVjcyBpcyB0aGUgSU1TSS1OQUkg
KElNU0lAUkVBTE0pLCBpdHMgYmFzZWQgb24gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+SU1T
SS4gRXg6PG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7Jmx0O0lNU0kmZ3Q7QGVwYy5tbmMm
bHQ7TU5DJmd0Oy5tY2MmbHQ7TUNDJmd0Oy4zZ3BwbmV0d29yay5vcmfCsjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPldlIGFsc28gaGF2ZSBNQUM0
OEBSRUFMTTs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT5XZSBhbHNvIGhhdmUgYXBwcm9hY2hlcyB0byB0cmFuc2Zvcm0gTUFDIHRvIFBzZXVkbyBJ
TVNJLCBhbmQgdGhlbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNhcnJ5IElNU0ktTkFJIGFzIHRo
ZSBNTi1JRC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Tbywgd2UgbmVlZCB1bmlxdWUgc3Vi
LXR5cGVzIGZvciBlYWNoIG9mIHRoZSB0eXBlcy9zb3VyY2VzLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk1OLUlkIGJhc2VkIG9uIElNU0ksIE1T
SVNETiwgSU1FSSwgTUFDIC4uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+QWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElN
U0kgYW5kIElNU0ktTkFJID88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5Tcmk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5PbiA5LzEwLzE0IDY6MjkgQU0sICZxdW90O01hcmNvIExpZWJzY2gm
cXVvdDsgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86TWFyY28uTGllYnNj
aEBuZWNsYWIuZXUiIHRhcmdldD0iX2JsYW5rIj4mbHQ7TWFyY28uTGllYnNjaEBuZWNsYWIuZXUm
Z3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cHJlPkl0IHNlZW1zIHRoZSBNTklEIGlzIHNvbWVob3cgb3ZlcmxvYWRlZCB0byBj
YXJyeSBib3RoLCBub2RlLXNwZWNpZmljPG86cD48L286cD48L3ByZT4NCjxwcmU+SURzLCZuYnNw
OyBlLmcuIE1BQywgYXMgd2VsbCBhcyBzdWJzY3JpYmVyIElEcywgd2hpY2ggaXMgdGhlIElNU0ku
PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlcmUgbWF5IGJlIHZhbHVlIGluIGFkZGluZyB0aGUg
SU1FSSB0byB0aGUgbGlzdCBvZiBwb3NzaWJsZSB0eXBlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
Pm9mJm5ic3A7IG5vZGUtc3BlY2lmaWMgSURzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPm1hcmNvPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206IGRtbSBbPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
IiBocmVmPSJtYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWls
dG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgU3JpIEd1bmRhdmVsbGk8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4oc2d1bmRhdmUpPG86cD48L286cD48L3ByZT4NCjxwcmU+
U2VudDogRGllbnN0YWcsIDkuIFNlcHRlbWJlciAyMDE0IDIzOjMwPG86cD48L286cD48L3ByZT4N
CjxwcmU+VG86IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSk7IENoYXJsaWUgUGVya2luczsgPGEg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiBWaWph
eSBEZXZhcmFwYWxsaTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1YmplY3Q6IFJlOiBbRE1NXSBy
ZWdhcmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlR3byBtb3JlIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjQuKSBJJ2QgYWxzbyB1
c2Ugc3ViLXR5cGUgdmFsdWUgb2YgKDIpIGZvciBJTVNJLiBKdXN0IHRvIGFsaWduIHdpdGg8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT50aGUmbmJzcDsgc3ViLXR5cGVzJm5ic3A7IGRlZmluZWQgZm9y
IE1OIElkIGRlZmluZWQgZm9yIElDTVAuIEkgc3VzcGVjdCB0aGVyZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPmFyZSBzb21lJm5ic3A7IGltcGxlbWVudGF0aW9ucyZuYnNwOyBhbHJlYWR5IHVzaW5n
IHN1Yi10eXBlICgyKS4gUGxlYXNlIHNlZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSBvdGhl
ciB0aHJlYWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+NS4pIEZvciBlYWNoIG9mIHRoZSBz
dWItdHlwZXMsIHdlIG5lZWQgdGV4dCBpbmNsdWRpbmcgZXhhbXBsZXMgYW5kPG86cD48L286cD48
L3ByZT4NCjxwcmU+c29tZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmV4cGxhbmF0aW9uIG9uIGhv
dyB0aGV5IGFyZSB1c2VkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNyaTxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9uIDkvOS8xNCAy
OjIwIFBNLCAmcXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7IDxhIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPiZsdDtzZ3VuZGF2ZUBjaXNjby5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPndyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwcmU+SGkgQ2hhcmxpZSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5UaGlzIGlzIGdvb2QuIFRoYW5rcy48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT4xLikgSWYgRVVJLTQ4IGFuZCBFVUktNjQgYWRkcmVzc2VzIGFyZSBkZXJpdmVkIG9m
IGEgNDgtYml0IElFRUU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT44MDIuMjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPmFkZHJlc3MsIHdoeSBkbyB3ZSBuZWVkIHRvIHR3byBzdWItdHlwZXMgPyBXaHkg
bm90IGhhdmUganVzdCBvbmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdWItdHlwZSBmb3IgbWFj
IGJhc2VkIGlkZW50aWZpZXJzID88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT4yLikgU3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJlbnRseSB1c2Vk
LiBJdHMgY3VycmVudGx5IG92ZXJsb2FkZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5mb3I8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5JTVNJLU5BSSAoM0dQUCBzcGVjcykgYW5kIGdlbmVyaWMgTkFJ
IGJhc2VkIGlkZW50aWZpZXJzLiBHaXZlbiB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kZWZp
bml0aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxhaW5pbmcgdGhl
PG86cD48L286cD48L3ByZT4NCjxwcmU+bW90aXZhdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1
ZSBvZiAoMikgZm9yIElQdjYgYWRkcmVzcy4gV2hhdCBleGFjdGx5PG86cD48L286cD48L3ByZT4N
CjxwcmU+aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGlzID8gQXJlIHRoZXNlIENHQS1iYXNl
ZCBJUHY2IGFkZHJlc3NlcyA/PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5l
dyBNb2JpbGUgTm9kZSBJZGVudGlmaWVyIFR5cGVzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj
NDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSWRlbnRp
ZmllciBUeXBlIHwgSWRlbnRpZmllciBUeXBlIE51bWJlciB8PG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQz
Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSVB2NiBBZGRyZXNzJm5ic3A7Jm5ic3A7Jm5ic3A7
IHwgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSU1TSSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IDMmbmJzcDsmbmJzcDsmbmJzcDsg
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
fDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFAt
VE1TSSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB8IDQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB8IEVVSS00OCBhZGRyZXNzJm5ic3A7IHwgNSZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz
cDt8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHwgRVVJLTY0IGFkZHJlc3MmbmJzcDsgfCA2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBHVVRJJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHwgNyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu
YnNwOyZuYnNwOyZuYnNwOyYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+UmVnYXJkczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNyaTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBTOiBHb29kIHRvIHNlZSBWaWpheSBiYWNrPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+T24gOS85LzE0IDE6MjggUE0sICZxdW90O0NoYXJsaWUgUGVya2lu
cyZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIg
aHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0IiB0YXJnZXQ9Il9ibGFu
ayI+Jmx0O2NoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Jmd0OzwvYT48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT53cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cHJlPkhlbGxvIGZvbGtzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkhlcmUncyB0aGUgbGFzdCBJbnRlcm5ldCBEcmFmdCB0
aGF0IHdlIGRpZCwgbG9uZyBhZ28gZXhwaXJlZDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9
Imh0dHA6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1wZXJraW5zLW1leHQtNDI4M21u
aWRzLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9p
ZC9kcmFmdC1wZXJraW5zLW1leHQtNDI4M21uaWRzLTAxLnR4dDwvYT48bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JJ2xsIHJlc3VibWl0IGl0IHdp
dGggYSBmZXcgdXBkYXRlcyBhcyBhIHBlcnNvbmFsIGRyYWZ0IHRvIGRtbS48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPkNoYXJsaWUgUC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3Rl
Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRtbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjxv
OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+ZG1tIG1h
aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1
ZSIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9y
ZzwvYT48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vZG1tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kbW08L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx
dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kbW0gbWFpbGluZyBsaXN0
PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJt
YWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPjxhIG1v
ei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RtbTwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPmRtbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBt
b3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjxvOnA+PC9vOnA+
PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7ICI+PGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkbW0gbWFpbGluZyBs
aXN0PGJyPg0KPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86ZG1tQGlldGYu
b3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW08L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206
MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYWtpbWEgQ2hh
b3VjaGk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlByb2Zlc3NvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGVsZWNvbSBTdWQgUGFyaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkluc3RpdHV0IE1pbmVzIFRlbGVjb208bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjkgcnVlIENoYXJsZXMgRm91cmll
cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OTEw
MTEgRXZyeTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+MDE2MDc2NDQ0MzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86
cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMsPG86
cD48L286cD48L3ByZT4NCjxwcmU+Q2hhcmxpZSBQLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPHByZSBjbGFzcz0ibW96LXNpZ25hdHVyZSIg
Y29scz0iNzIiPi0tIA0KUmVnYXJkcywNCkNoYXJsaWUgUC48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+
DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D04A1522166DF8sgundaveciscocom_--


From nobody Thu Sep 25 22:46:34 2014
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 532E61A0218 for ; Thu, 25 Sep 2014 22:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level: 
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 TK_Ja1myDm_L for ; Thu, 25 Sep 2014 22:46:26 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id C6A691A02BA for ; Thu, 25 Sep 2014 22:46:25 -0700 (PDT)
Received: from [99.51.72.196] (helo=[192.168.1.80]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XXOMI-0006Od-VT; Fri, 26 Sep 2014 01:46:23 -0400
Message-ID: <5424FDAD.609@computer.org>
Date: Thu, 25 Sep 2014 22:46:21 -0700
From: "Charles E. Perkins" 
Organization: Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Hakima Chaouchi , dmm@ietf.org
References:  <1478038645.11626223.1411705901240.JavaMail.zimbra@telecom-sudparis.eu>
In-Reply-To: <1478038645.11626223.1411705901240.JavaMail.zimbra@telecom-sudparis.eu>
Content-Type: multipart/alternative; boundary="------------010706010500060108060603"
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac70d7c97b3520082a6932aa9f5a7611eae350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/GUjh_YBVovPTCV48KA2fdEOjNG8
Cc: Vijay Devarapalli 
Subject: Re: [DMM] MNID Types
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, 26 Sep 2014 05:46:29 -0000

This is a multi-part message in MIME format.
--------------010706010500060108060603
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


Hello folks,

Now we have two kinds of identifiers that could reasonably be
grouped as a type plus subtypes.  I could specify this by writing
another section of the new draft that lays out another subtype
field after the MNID subtype field from 4283.  I guess it would
be a "subsubtype" field if we are following the nomenclature for
the fields as shown in RFC 4283.

Or, alternatively, I could specify that for some types (e.g., DUID
and RFID), the first eight bits of the identifier is the a field that
we might call the "identifier subtype".  Maybe that is cleaner.

A third option would be to update RFC 4283, but that seems to
be a bit heavy-handed.

Comments?  Or other options?

Regards,
Charlie P.


On 9/25/2014 9:31 PM, Hakima Chaouchi wrote:
> Hi,
>
> For RFID we refer to the EPC standards.
>
> "The /Electronic Product Code/ (EPC) is an identification scheme for 
> universally identifying physical objects by using Radio Frequency 
> Identification (RFID) tags.
> The standardized EPC tag encoding consists of an EPC Identifier that 
> uniquely identifies an individual object, and may also include a 
> filter value if the filter is needed to enable effective and efficient 
> reading of the EPC tags. The EPC Identifier is a meta-coding scheme 
> designed to support the needs of various industries by accommodating 
> existing coding schemes where possible and by defining new schemes 
> where necessary."
>
> "EPC supports several encoding systems or schemes including GID 
> (Global Identifier), SGTIN (Serialized Global Trade Item Number), SSCC 
> (Serial Shipping Container), GLN (Global Location Number), GRAI 
> (Global Returnable Asset Identifier), DOD (Department of Defense) and 
> GIAI (Global Individual Asset Identifier).
>
> For each scheme except GID, there are two variations—a 64-bit scheme 
> (for example, GLN-64) and a 96-bit scheme (GLN-96). GID has only a 
> 96-bit scheme.
>
> Within each scheme, an EPC identifier can be represented in a binary 
> form or other forms such as URI ..etc".
>
> May be we need some subtyping.
>
> Cheers,
>
> Hakima
>
>
> ------------------------------------------------------------------------
> *De: *"Sri Gundavelli (sgundave)" 
> *À: *"Charles E. Perkins" 
> *Cc: *"Vijay Devarapalli" , dmm@ietf.org
> *Envoyé: *Vendredi 26 Septembre 2014 03:36:01
> *Objet: *Re: [DMM] MNID Types
>
> Hi Charlie,
>
> > Is the DoD-96 identifier for a special kind of RFID, or is it valid 
> for all the RFID devices that would be of interest?
>
> I do not know the answer for this question. I assumed DOD-96 is a 
> mandated standard for RFID encoding, but looks like there are other 
> formats like GID-96 ..etc. May be this may end up needing subtypes. We 
> can defer this question to Hakima and learn some details on this, she 
> seems to have written many books on RFID.
>
>
> Regards
> Sri
>
>
>
> From: "Charles E. Perkins"  >
> Organization: Blue Skies
> Date: Thursday, September 25, 2014 1:42 PM
> To: Sri Gundavelli >
> Cc: "dmm@ietf.org "  >, Vijay Devarapalli  >
> Subject: Re: [DMM] MNID Types
>
>
> Hello Sri,
>
> Is the DoD-96 identifier for a special kind of RFID, or is it
> valid for all the RFID devices that would be of interest?
>
> Regards,
> Charlie P.
>
>
> On 9/21/2014 9:59 AM, Sri Gundavelli (sgundave) wrote:
>
>     Hi Hakima,
>
>     That is a good idea. We should register a type for the Dod-96
>     identifier as well.
>
>
>     Regards
>     Sri
>
>
>     From: Hakima Chaouchi      >
>     Date: Sunday, September 21, 2014 8:11 AM
>     To: Sri Gundavelli >
>     Cc: Charlie Perkins      >, Marco Liebsch
>     >,
>     "dmm@ietf.org "      >, Vijay Devarapalli      >
>     Subject: Re: [DMM] MNID Types
>
>     Hello Folks,
>
>     Do you think that considering specific but needed technologies for
>     moving objects in  Internet of Things  such as RFID (Radio
>     Frequency Identifier) with 96 bits identifiers will be also
>     relevent to Charlie's current draft and the efforts related to MNID?
>
>     Regards,
>
>     Hakima
>
>
>     ------------------------------------------------------------------------
>     *De: *"Sri Gundavelli (sgundave)"      >
>     *À: *"Charlie Perkins"      >, "Marco Liebsch"
>     >,
>     dmm@ietf.org , "Vijay Devarapalli"
>     >
>     *Envoyé: *Jeudi 11 Septembre 2014 23:57:11
>     *Objet: *Re: [DMM] MNID Types
>
>     Hi Charlie,
>
>     Few more reviews/discussions and capturing the consensus in the
>     base version will help. But, I'm ok either way …
>
>
>     Regards
>     Sri
>
>     From: Charlie Perkins      >
>     Date: Thursday, September 11, 2014 2:46 PM
>     To: Sri Gundavelli      >, Marco Liebsch
>     >,
>     "dmm@ietf.org "      >, Vijay Devarapalli      >
>     Subject: Re: [DMM] MNID Types
>
>
>     Hello folks,
>
>     I propose to submit the ....-00.txt document as it is to the Internet
>     Drafts directory, and then to go about making updates according to
>     the discussion on this list.  Do you think this is reasonable?
>
>     Regards,
>     Charlie P.
>
>
>     On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:
>
>         
>
>
>         Marco,
>
>
>         Thinking further on the complementary identifier option.
>
>         - There is already the link-layer identifier option that can be used for
>         carrying the Mac address
>         - IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's
>
>         In some sense, the complementary identifiers are already present.
>
>         Sri
>
>
>
>
>
>         On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)"  wrote:
>
>             I do not see a reason why multiple MN-Id instances need to be present in a
>             single message ? In my experience, this is strictly a deployment
>             consideration, when to use what type of identifiers.
>
>             Assuming the backend system can tie all the MN-Id's to a single
>             subscription, any presented identifier can be sufficient for the gateway
>             to do the BCE lookup.
>
>             If multiple instances can be present, then we need to deal with more error
>             cases. Is that really needed ?
>
>
>                 I am wondering if it would not be more appropriate to go for a different
>                 container option to carry such information. Something like a
>                 complementary identifier option.
>
>             Sounds interesting. Are you suggesting we leave the current MN-ID as it
>             is, but use a new complementary option ? But, if the requirement is for a
>             Mac based identifiers, what will be there in the current MN-Id option ? We
>             still need to have identifier there ?
>
>
>
>
>             Sri
>
>
>
>
>
>             On 9/11/14 2:03 AM, "Marco Liebsch"  wrote:
>
>                 No issue with logical vs. physical ID. But I am wondering about two
>                 things:
>
>                 Operation is clear to me in case a single MNID is present in a message
>                 and I see the value in being
>                 flexible to choose from different sub-types. If multiple MNIDs with
>                 different sub-types are present in
>                 a single message, which one should e.g. the LMA take for the BC lookup..
>                 No big problem to solve, but
>                 to be considered in implementations.
>
>                 If the reason for multiple present MNIDs with different sub-types is to
>                 do other things than identifying
>                 the node or using the ID as key for a lookup, I am wondering if it would
>                 not be more appropriate
>                 to go for a different container option to carry such information.
>                 Something like a complementary
>                 identifier option.
>
>                 marco
>
>                     -----Original Message-----
>                     From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>                     Sent: Donnerstag, 11. September 2014 00:42
>                     To: Charlie Perkins; Marco Liebsch;dmm@ietf.org
>                     Cc: Vijay Devarapalli
>                     Subject: Re: [DMM] regarding the re-chartering..
>
>                     Hello Charlie,
>
>                     Agree with that. MN-Id as its defined today is a logical identifier. It
>                     does not
>                     require the identifier to be bound to a physical device or a interface
>                     identity.
>                     But, we have clearly seen requirements where the need is for generating
>                     identifiers based on some physical identifiers. Those physical
>                     identifiers include
>                     IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
>                     source
>                     and the rules for generating MN-ID based using those sources, the sender
>                     and
>                     receiver will have clear guidance on how to use the spec. Some pointers,
>                     explanation and examples for each of those identifiers will greatly help
>                     avoid
>                     inter-op issues.
>
>
>                     Regards
>                     Sri
>
>
>
>
>
>
>
>                     On 9/10/14 3:21 PM, "Charlie Perkins"
>                     wrote:
>
>                         Hello folks,
>
>                         I think it's best to consider the MNID as simply living in a space of
>                         identifiers, and not worry too much about whether it's a logical
>                         identifier or a physical identifier.  If the former, then somewhere
>                         (perhaps below the network layer) the logical identifier has been bound
>                         to something in the physical interface, but that's not our problem.
>
>                         The number space for types of MNIDs is likely to stay pretty empty, so
>                         I'd say we could add as many types as would be convenient for the
>                         software designers.  So, we could conceivably have several MNIDs
>                         defined that all "looked like" NAIs (which, themselves, "look like"
>                         FQDNs).
>
>                         Regards,
>                         Charlie P.
>
>
>
>                         On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:
>
>                             Yes. Currently, the MNID is if the nai format and is overloaded. The
>                             MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
>                             IMSI. Ex:
>                             "@epc.mnc.mcc.3gppnetwork.org²
>
>                             We also have MAC48@REALM;
>
>                             We also have approaches to transform MAC to Pseudo IMSI, and then
>                             carry IMSI-NAI as the MN-ID.
>
>
>                             So, we need unique sub-types for each of the types/sources.
>
>                             MN-Id based on IMSI, MSISDN, IMEI, MAC ..
>
>                             Also, do we need to distinguish between IMSI and IMSI-NAI ?
>
>                             Sri
>
>
>
>                             On 9/10/14 6:29 AM, "Marco Liebsch"  wrote:
>
>                                 It seems the MNID is somehow overloaded to carry both, node-specific
>                                 IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
>                                 There may be value in adding the IMEI to the list of possible types
>                                 of  node-specific IDs.
>
>                                 marco
>
>                                     -----Original Message-----
>                                     From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
>                                     (sgundave)
>                                     Sent: Dienstag, 9. September 2014 23:30
>                                     To: Sri Gundavelli (sgundave); Charlie Perkins;dmm@ietf.org
>                                     Cc: Vijay Devarapalli
>                                     Subject: Re: [DMM] regarding the re-chartering..
>
>                                     Two more comments.
>
>
>
>                                     4.) I'd also use sub-type value of (2) for IMSI. Just to align with
>                                     the  sub-types  defined for MN Id defined for ICMP. I suspect there
>                                     are some  implementations  already using sub-type (2). Please see
>                                     the other thread.
>
>
>                                     5.) For each of the sub-types, we need text including examples and
>                                     some
>                                     explanation on how they are used.
>
>
>                                     Sri
>
>
>
>                                     On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)"
>                                     wrote:
>
>                                         Hi Charlie,
>
>                                         This is good. Thanks.
>
>
>                                         1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
>                                         802.2
>                                         address, why do we need to two sub-types ? Why not have just one
>                                         sub-type for mac based identifiers ?
>
>                                         2.) Sub type value (1) is currently used. Its currently overloaded
>                                         for
>                                         IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
>                                         definition of new sub-types, we need some text explaining the
>                                         motivation
>
>                                         3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
>                                         is
>                                         this ? Are these CGA-based IPv6 addresses ?
>
>
>
>
>                                                               New Mobile Node Identifier Types
>
>                                                         +-----------------+------------------------+
>                                                         | Identifier Type | Identifier Type Number |
>                                                         +-----------------+------------------------+
>                                                         | IPv6 Address    | 2                      |
>                                                         |                 |                        |
>                                                         | IMSI            | 3                      |
>                                                         |                 |                        |
>                                                         | P-TMSI          | 4                      |
>                                                         |                 |                        |
>                                                         | EUI-48 address  | 5                      |
>                                                         |                 |                        |
>                                                         | EUI-64 address  | 6                      |
>                                                         |                 |                        |
>                                                         | GUTI            | 7                      |
>                                                         +-----------------+------------------------+
>
>
>
>
>
>
>
>                                         Regards
>                                         Sri
>                                         PS: Good to see Vijay back
>
>
>                                         On 9/9/14 1:28 PM, "Charlie Perkins"
>                                         
>                                         wrote:
>
>                                             Hello folks,
>
>                                             Here's the last Internet Draft that we did, long ago expired:
>
>                                             http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt
>
>                                             I'll resubmit it with a few updates as a personal draft to dmm.
>
>                                             Regards,
>                                             Charlie P.
>
>                                         _______________________________________________
>                                         dmm mailing list
>                                         dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>                                     _______________________________________________
>                                     dmm mailing list
>                                     dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>             _______________________________________________
>             dmm mailing list
>             dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>         _______________________________________________
>         dmm mailing list
>         dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
>
>
>
>     _______________________________________________
>     dmm mailing list
>     dmm@ietf.org 
>     https://www.ietf.org/mailman/listinfo/dmm
>
>
>
>     -- 
>     ---------------------------------
>     Hakima Chaouchi
>     Professor
>     Telecom Sud Paris
>     Institut Mines Telecom
>     9 rue Charles Fourier
>     91011 Evry
>     0160764443
>
>
>
> -- 
> Regards,
> Charlie P.
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
> -- 
> ---------------------------------
> Hakima Chaouchi
> Professor
> Telecom Sud Paris
> Institut Mines Telecom
> 9 rue Charles Fourier
> 91011 Evry
> 0160764443
>

-- 
Regards,
Charlie P.


--------------010706010500060108060603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    Hello folks,

    

    Now we have two kinds of identifiers that could reasonably be

    grouped as a type plus subtypes.  I could specify this by writing

    another section of the new draft that lays out another subtype

    field after the MNID subtype field from 4283.  I guess it would

    be a "subsubtype" field if we are following the nomenclature for

    the fields as shown in RFC 4283.

    

    Or, alternatively, I could specify that for some types (e.g., DUID

    and RFID), the first eight bits of the identifier is the a field
    that

    we might call the "identifier subtype".  Maybe that is cleaner.

    

    A third option would be to update RFC 4283, but that seems to

    be a bit heavy-handed.

    

    Comments?  Or other options?

    

    Regards,

    Charlie P.

    

    

    
On 9/25/2014 9:31 PM, Hakima Chaouchi
      wrote:

    

    

      

        
Hi,

        


        

        
For RFID we refer to the EPC standards.

        

        


        

        
"The Electronic Product Code (EPC) is an
          identification scheme for universally identifying physical
          objects by using Radio Frequency Identification (RFID) tags.

        
The standardized EPC tag encoding consists of an EPC
          Identifier that uniquely identifies an individual object, and
          may also include a filter value if the filter is needed to
          enable effective and efficient reading of the EPC tags. The
          EPC Identifier is a meta-coding scheme designed to support the
          needs of various industries by accommodating existing coding
          schemes where possible and by defining new schemes where
          necessary."

        


        

        
"EPC supports several encoding systems or schemes including
          GID (Global Identifier), SGTIN (Serialized Global Trade Item
          Number), SSCC (Serial Shipping Container), GLN (Global
          Location Number), GRAI (Global Returnable Asset Identifier),
          DOD (Department of Defense) and GIAI (Global Individual Asset
          Identifier).
          
For each
            scheme except GID, there are two variations—a 64-bit scheme
            (for example, GLN-64) and a 96-bit scheme (GLN-96). GID has
            only a 96-bit scheme.

          Within each scheme, an EPC identifier can be represented in a
          binary form or other forms such as URI ..etc".

        

        


        

        
May be we need some subtyping.

        

        


        

        
Cheers,

        

        


        

        
Hakima

        

        


        

        


        

        

        
De:
          "Sri Gundavelli (sgundave)" <sgundave@cisco.com>

          À: "Charles E. Perkins" <charliep@computer.org>

          Cc: "Vijay Devarapalli" <dvijay@rocketmail.com>,
          dmm@ietf.org

          Envoyé: Vendredi 26 Septembre 2014 03:36:01

          Objet: Re: [DMM] MNID Types

          


          

          
Hi Charlie,

          


          

          
> Is the DoD-96 identifier for a special kind of RFID,
            or is it valid for all the RFID devices that would be of
            interest?

          


          

          
I do not know the answer for this question. I assumed
            DOD-96 is a mandated standard for RFID encoding, but looks
            like there are other formats like GID-96 ..etc. May be this
            may end up needing subtypes. We can defer this question to
            Hakima and learn some details on this, she seems to have
            written many books on RFID.

          


          

          


          

          
Regards

          
Sri

          


          

          


          

          


          

          
            

              From: "Charles E.
              Perkins" <charliep@computer.org>

              Organization: Blue
              Skies

              Date: Thursday,
              September 25, 2014 1:42 PM

              To: Sri Gundavelli
              <sgundave@cisco.com>

              Cc: "dmm@ietf.org" <dmm@ietf.org>, Vijay Devarapalli
              <dvijay@rocketmail.com>

              Subject: Re: [DMM]
              MNID Types

            

            


            

            

              


                Hello Sri,

                

                Is the DoD-96 identifier for a special kind of RFID, or
                is it

                valid for all the RFID devices that would be of
                interest?

                

                Regards,

                Charlie P.

                

                

                
On 9/21/2014 9:59 AM, Sri
                  Gundavelli (sgundave) wrote:

                

                

                  
Hi Hakima,

                  


                  

                  
That is a good idea. We should register a type
                    for the Dod-96 identifier as well.

                  


                  

                  


                  

                  
Regards

                  
Sri

                  


                  

                  


                  

                  
                    

                      From: Hakima
                      Chaouchi <hakima.chaouchi@telecom-sudparis.eu>

                      Date: Sunday,
                      September 21, 2014 8:11 AM

                      To: Sri
                      Gundavelli <sgundave@cisco.com>

                      Cc: Charlie
                      Perkins <charles.perkins@earthlink.net>,
                      Marco Liebsch <Marco.Liebsch@neclab.eu>,
                      "dmm@ietf.org"
                      <dmm@ietf.org>,
                      Vijay Devarapalli <dvijay@rocketmail.com>

                      Subject: Re:
                      [DMM] MNID Types

                    

                    


                    

                    

                      

                        

                          
Hello Folks,

                          

                          


                          

                          
Do you think that considering specific
                            but needed technologies for moving objects
                            in  Internet of Things  such as RFID (Radio
                            Frequency Identifier) with 96 bits
                            identifiers will be also relevent to
                            Charlie's current draft and the efforts
                            related to MNID? 
                            

                          

                          


                          

                          
Regards,

                          

                          


                          

                          
Hakima

                          

                          


                          

                          


                          

                          

                          
De:
                            "Sri Gundavelli (sgundave)" <sgundave@cisco.com>

                            À: "Charlie Perkins" <charles.perkins@earthlink.net>,
                            "Marco Liebsch" <Marco.Liebsch@neclab.eu>,
                            dmm@ietf.org,
                            "Vijay Devarapalli" <dvijay@rocketmail.com>

                            Envoyé: Jeudi 11 Septembre 2014
                            23:57:11

                            Objet: Re: [DMM] MNID Types

                            


                            

                            
Hi Charlie,

                            


                            

                            
Few more reviews/discussions and
                              capturing the consensus in the base
                              version will help. But, I'm ok either way
                              …

                            


                            

                            


                            

                            
Regards

                            
Sri

                            


                            

                            
                              

                                From: Charlie
                                Perkins <charles.perkins@earthlink.net>

                                Date: Thursday,
                                September 11, 2014 2:46 PM

                                To: Sri
                                Gundavelli <sgundave@cisco.com>,
                                Marco Liebsch <Marco.Liebsch@neclab.eu>,

                                "dmm@ietf.org" <dmm@ietf.org>,
                                Vijay Devarapalli <dvijay@rocketmail.com>

                                Subject:
                                Re: [DMM] MNID Types

                              

                              


                              

                              

                                


                                  Hello
                                      folks,

                                      

                                      I propose to submit the
                                      ....-00.txt document as it is to
                                      the Internet

                                      Drafts directory, and then to go
                                      about making updates according to

                                      the discussion on this list.  Do
                                      you think this is reasonable?

                                      

                                      Regards,

                                      Charlie P.

                                      

                                    

                                  
On
                                    9/11/2014 7:21 AM, Sri Gundavelli
                                    (sgundave) wrote:

                                  

                                  

                                    
<Changing the subject line to reflect the MNId discussion>


Marco,


Thinking further on the complementary identifier option.

- There is already the link-layer identifier option that can be used for
carrying the Mac address
- IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's

In some sense, the complementary identifiers are already present.

Sri





On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com> wrote:


                                    

                                      
I do not see a reason why multiple MN-Id instances need to be present in a
single message ? In my experience, this is strictly a deployment
consideration, when to use what type of identifiers.

Assuming the backend system can tie all the MN-Id's to a single
subscription, any presented identifier can be sufficient for the gateway
to do the BCE lookup.

If multiple instances can be present, then we need to deal with more error
cases. Is that really needed ?




                                      

                                        
I am wondering if it would not be more appropriate to go for a different
container option to carry such information. Something like a
complementary identifier option.


                                      

                                      
Sounds interesting. Are you suggesting we leave the current MN-ID as it
is, but use a new complementary option ? But, if the requirement is for a
Mac based identifiers, what will be there in the current MN-Id option ? We
still need to have identifier there ?




Sri





On 9/11/14 2:03 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:



                                      

                                        
No issue with logical vs. physical ID. But I am wondering about two
things:

Operation is clear to me in case a single MNID is present in a message
and I see the value in being
flexible to choose from different sub-types. If multiple MNIDs with
different sub-types are present in
a single message, which one should e.g. the LMA take for the BC lookup..
No big problem to solve, but
to be considered in implementations.

If the reason for multiple present MNIDs with different sub-types is to
do other things than identifying
the node or using the ID as key for a lookup, I am wondering if it would
not be more appropriate
to go for a different container option to carry such information.
Something like a complementary
identifier option.

marco



                                        

                                          
-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Agree with that. MN-Id as its defined today is a logical identifier. It
does not
require the identifier to be bound to a physical device or a interface
identity.
But, we have clearly seen requirements where the need is for generating
identifiers based on some physical identifiers. Those physical
identifiers include
IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
source
and the rules for generating MN-ID based using those sources, the sender
and
receiver will have clear guidance on how to use the spec. Some pointers,
explanation and examples for each of those identifiers will greatly help
avoid
inter-op issues.


Regards
Sri







On 9/10/14 3:21 PM, "Charlie Perkins" <charles.perkins@earthlink.net>
wrote:



                                          

                                            
Hello folks,

I think it's best to consider the MNID as simply living in a space of
identifiers, and not worry too much about whether it's a logical
identifier or a physical identifier.  If the former, then somewhere
(perhaps below the network layer) the logical identifier has been bound
to something in the physical interface, but that's not our problem.

The number space for types of MNIDs is likely to stay pretty empty, so
I'd say we could add as many types as would be convenient for the
software designers.  So, we could conceivably have several MNIDs
defined that all "looked like" NAIs (which, themselves, "look like"
FQDNs).

Regards,
Charlie P.



On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:


                                            

                                              
Yes. Currently, the MNID is if the nai format and is overloaded. The
MNID  in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the
IMSI. Ex:
"<IMSI>@epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org²

We also have MAC48@REALM;

We also have approaches to transform MAC to Pseudo IMSI, and then
carry IMSI-NAI as the MN-ID.


So, we need unique sub-types for each of the types/sources.

MN-Id based on IMSI, MSISDN, IMEI, MAC ..

Also, do we need to distinguish between IMSI and IMSI-NAI ?

Sri



On 9/10/14 6:29 AM, "Marco Liebsch" <Marco.Liebsch@neclab.eu> wrote:



                                              

                                                
It seems the MNID is somehow overloaded to carry both, node-specific
IDs,  e.g. MAC, as well as subscriber IDs, which is the IMSI.
There may be value in adding the IMEI to the list of possible types
of  node-specific IDs.

marco



                                                

                                                  
-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Dienstag, 9. September 2014 23:30
To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Two more comments.



4.) I'd also use sub-type value of (2) for IMSI. Just to align with
the  sub-types  defined for MN Id defined for ICMP. I suspect there
are some  implementations  already using sub-type (2). Please see
the other thread.


5.) For each of the sub-types, we need text including examples and
some
explanation on how they are used.


Sri



On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
wrote:



                                                  

                                                    
Hi Charlie,

This is good. Thanks.


1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE
802.2
address, why do we need to two sub-types ? Why not have just one
sub-type for mac based identifiers ?

2.) Sub type value (1) is currently used. Its currently overloaded
for
IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
definition of new sub-types, we need some text explaining the
motivation

3.) Proposed Sub-type value of (2) for IPv6 address. What exactly
is
this ? Are these CGA-based IPv6 addresses ?




                     New Mobile Node Identifier Types

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |
               |                 |                        |
               | IMSI            | 3                      |
               |                 |                        |
               | P-TMSI          | 4                      |
               |                 |                        |
               | EUI-48 address  | 5                      |
               |                 |                        |
               | EUI-64 address  | 6                      |
               |                 |                        |
               | GUTI            | 7                      |
               +-----------------+------------------------+







Regards
Sri
PS: Good to see Vijay back


On 9/9/14 1:28 PM, "Charlie Perkins"
<charles.perkins@earthlink.net>
wrote:



                                                    

                                                      
Hello folks,

Here's the last Internet Draft that we did, long ago expired:

http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt

I'll resubmit it with a few updates as a personal draft to dmm.

Regards,
Charlie P.


                                                    

                                                    
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                                                  

                                                  
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                                                

                                              

                                            

                                          

                                        

                                      

                                      
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                                    

                                    
_______________________________________________
dmm mailing list
dmm@ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


                                  

                                  

                                

                              

                            

_______________________________________________

                            dmm mailing list

                            dmm@ietf.org

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

                          

                          


                            

                          

                          


                          

                          
-- 

                          

                          

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

                            
Hakima Chaouchi

                            
Professor

                            
Telecom Sud Paris

                            
Institut Mines Telecom

                            
9 rue Charles Fourier

                            
91011 Evry

                            
0160764443

                            

                          

                        

                      

                    

                  

                

                

                
-- 
Regards,
Charlie P.

              

            

          
          

          _______________________________________________

          dmm mailing list

          dmm@ietf.org

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

        

        


          

        

        


        

        
-- 

        

        

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

          
Hakima Chaouchi

          
Professor

          
Telecom Sud Paris

          
Institut Mines Telecom

          
9 rue Charles Fourier

          
91011 Evry

          
0160764443

          

        

      

    

    

    
-- 
Regards,
Charlie P.

  


--------------010706010500060108060603--


From nobody Thu Sep 25 22:52:03 2014
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 332CE1A1A29 for ; Thu, 25 Sep 2014 22:52:01 -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 xedGr2fTLy2E for ; Thu, 25 Sep 2014 22:51:58 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550191A1A23 for ; Thu, 25 Sep 2014 22:51:58 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id 10so12074059lbg.18 for ; Thu, 25 Sep 2014 22:51: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:cc:subject :content-type:content-transfer-encoding; bh=X5/Hc+3sclWO5OJBCliqsT6jhdLE7wiPMggC6RUNsPQ=; b=lU02YrqWbPMeJCAe3mA4eyHL2QObWIF/4RWhqYo5WOgQyqAf6bh5xTcJQR3UsPGhot FSL2mgZPD2yZrd0Nn2yoWX47R0LLblWhd2YMXJMTqs6MDaJWJ0IMSmGaJw+jGxY/fGAd saL5EzyIpjDJz+cbdfuiRAEZoNkyeWFv3he5HoihC1i53zgaNdQzl0PRre6Ovpapuxku VveH1+cd3gDFEpLH6r5dbAt6SrJMfVPKpJ4ZiXTT78wb/8Ti6blk49RFIvulnxPHALXA q2U3ZJZ1lu2Uh37K9/gIPZS+Ea2mfm8Vuecadf9h6EP7G9lM9KFcIP/513K0qTkKyZQS 2nRg==
X-Received: by 10.152.7.8 with SMTP id f8mr17681197laa.27.1411710716619; Thu, 25 Sep 2014 22:51:56 -0700 (PDT)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id we9sm1523002lbb.10.2014.09.25.22.51.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 22:51:55 -0700 (PDT)
Message-ID: <5424FEFA.2050008@gmail.com>
Date: Fri, 26 Sep 2014 08:51:54 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dmm@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/AyzN6NY-7FL79R50xZOGAJpNBR0
Cc: Dapeng Liu 
Subject: [DMM] Going forward with the DMM work items
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, 26 Sep 2014 05:52:01 -0000

Folks,

In the interim call #2 we agreed to form "working teams". We got three 
volunteers to run up those:

o Alper will take care of coordinating "exposing mobility state.."
o Anthony will take care of coordinating "enhanced mobility anchoring.."
o Marco will take care of coordinating "forwarding path and signaling.."

The above gentlement will arrange calls for brainstorming that are open 
for everyone to participate. The process is open - about equivalent to a 
design team, you just don't need to signup for one. Just keep in mind 
that it is good to concentrate on a limited amount of work items.

The working teams, if they so manage, will produce the solution I-D(s). 
These documents will be equivalent to any individual produced I-D, though.

- Jouni & Dapeng


From nobody Thu Sep 25 22:55:01 2014
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 A23121A1A23 for ; Thu, 25 Sep 2014 22:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 wX-xsEGxnE0r for ; Thu, 25 Sep 2014 22:54:56 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65D41A0158 for ; Thu, 25 Sep 2014 22:54:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53434; q=dns/txt; s=iport; t=1411710895; x=1412920495; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=XVpx7CsHdsTCcwzm0aA77Fmn8ek9y5+bEn/n6iR0Nb8=; b=Tr/8h2AW795Bux0S9PyxfOmhLz4kna/oNkTGp+5/kHNTPbB6kPe6CHos dyYNp0nT32YzOjORDola28l7XucE4wcKMMGI+VOe8UVfyLZrJWegfT2Oe oxkjd3vT7osKAGyCaR4obpA4ptzYej1en98FJnIawKKD3MOUYR8WKfBhy k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkUFAMz+JFStJV2Z/2dsb2JhbABXCYJIRlNXBIJ9xywBCYdOAhhsFgF7hAMBAQEDAQEBARcJSwsFBwYBCBEDAQEBDhMBBgMCBCULFAkIAgQOBQmIIQMJCA2rNo5cG4cWAReNXhCBVTAJBwoHBgQGAQIEgnKBUwWGJokighiLQ5VWg2NsAYFHgQIBAQE
X-IronPort-AV: E=Sophos; i="5.04,603,1406592000"; d="scan'208,217"; a="81383219"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 26 Sep 2014 05:54:54 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q5ssV0030122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 05:54:54 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 00:54:54 -0500
From: "Sri Gundavelli (sgundave)" 
To: Hakima Chaouchi 
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHP2U5kVRllY2Aql0WvU4ZtNAqY9A==
Date: Fri, 26 Sep 2014 05:54:53 +0000
Message-ID: 
In-Reply-To: <1478038645.11626223.1411705901240.JavaMail.zimbra@telecom-sudparis.eu>
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.217]
Content-Type: multipart/alternative; boundary="_000_D04A4C12166E7Asgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/GIDOK1isBR8POVHw7WvjztsJUPA
Cc: Vijay Devarapalli , "dmm@ietf.org" 
Subject: Re: [DMM] MNID Types
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, 26 Sep 2014 05:54:59 -0000

--_000_D04A4C12166E7Asgundaveciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzLg0KDQpUaGlua2luZyBhYm91dCB0aGlzIGZ1cnRoZXIsIGhhdmluZyB0aGUgUkZJRCBz
dWJ0eXBlICBpcyBwcm9iYWJseSBnb2luZyB0byBiZSBleHRyZW1lbHkgdXNlZnVsIGZvciBJT1Qg
YXBwbGljYXRpb25zLiBBIE1BRy9NUiBjYW4gcG90ZW50aWFsbHkgcmVnaXN0ZXIgZGV2aWNlcyBp
ZGVudGlmaWVkIHdpdGggUkZJRCBhcyB0aGUgTkFJOyBBbHNvLCB0aGVyZSBzZWVtcyB0byBiZSBz
b21lIG1hcHBpbmcgYmV0d2VlbiA2NC1iaXQgRVBDIGFuZCBJUHY2IElkZW50aWZpZXIsIGFsbG93
aW5nIGRldmljZSBhZGRyZXNzYWJpbGl0eSBvdmVyIElQdjYgYW5kIHRoYXQgbWFrZXMgdGhpcyBp
bnRlcmVzdGluZyBhbmQgZW5hYmxlIHNvbWUgbmV3IHVzZS1jYXNlcy4NCg0KUmVnYXJkcw0KU3Jp
DQoNCg0KDQoNCkZyb206IEhha2ltYSBDaGFvdWNoaSA8aGFraW1hLmNoYW91Y2hpQHRlbGVjb20t
c3VkcGFyaXMuZXU8bWFpbHRvOmhha2ltYS5jaGFvdWNoaUB0ZWxlY29tLXN1ZHBhcmlzLmV1Pj4N
CkRhdGU6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQgOTozMSBQTQ0KVG86IFNyaSBHdW5k
YXZlbGxpIDxzZ3VuZGF2ZUBjaXNjby5jb208bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbT4+DQpD
YzogIkNoYXJsZXMgRS4gUGVya2lucyIgPGNoYXJsaWVwQGNvbXB1dGVyLm9yZzxtYWlsdG86Y2hh
cmxpZXBAY29tcHV0ZXIub3JnPj4sIFZpamF5IERldmFyYXBhbGxpIDxkdmlqYXlAcm9ja2V0bWFp
bC5jb208bWFpbHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbT4+LCAiZG1tQGlldGYub3JnPG1haWx0
bzpkbW1AaWV0Zi5vcmc+IiA8ZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+Pg0KU3Vi
amVjdDogUmU6IFtETU1dIE1OSUQgVHlwZXMNCg0KSGksDQoNCkZvciBSRklEIHdlIHJlZmVyIHRv
IHRoZSBFUEMgc3RhbmRhcmRzLg0KDQoiVGhlIEVsZWN0cm9uaWMgUHJvZHVjdCBDb2RlIChFUEMp
IGlzIGFuIGlkZW50aWZpY2F0aW9uIHNjaGVtZSBmb3IgdW5pdmVyc2FsbHkgaWRlbnRpZnlpbmcg
cGh5c2ljYWwgb2JqZWN0cyBieSB1c2luZyBSYWRpbyBGcmVxdWVuY3kgSWRlbnRpZmljYXRpb24g
KFJGSUQpIHRhZ3MuDQpUaGUgc3RhbmRhcmRpemVkIEVQQyB0YWcgZW5jb2RpbmcgY29uc2lzdHMg
b2YgYW4gRVBDIElkZW50aWZpZXIgdGhhdCB1bmlxdWVseSBpZGVudGlmaWVzIGFuIGluZGl2aWR1
YWwgb2JqZWN0LCBhbmQgbWF5IGFsc28gaW5jbHVkZSBhIGZpbHRlciB2YWx1ZSBpZiB0aGUgZmls
dGVyIGlzIG5lZWRlZCB0byBlbmFibGUgZWZmZWN0aXZlIGFuZCBlZmZpY2llbnQgcmVhZGluZyBv
ZiB0aGUgRVBDIHRhZ3MuIFRoZSBFUEMgSWRlbnRpZmllciBpcyBhIG1ldGEtY29kaW5nIHNjaGVt
ZSBkZXNpZ25lZCB0byBzdXBwb3J0IHRoZSBuZWVkcyBvZiB2YXJpb3VzIGluZHVzdHJpZXMgYnkg
YWNjb21tb2RhdGluZyBleGlzdGluZyBjb2Rpbmcgc2NoZW1lcyB3aGVyZSBwb3NzaWJsZSBhbmQg
YnkgZGVmaW5pbmcgbmV3IHNjaGVtZXMgd2hlcmUgbmVjZXNzYXJ5LiINCg0KIkVQQyBzdXBwb3J0
cyBzZXZlcmFsIGVuY29kaW5nIHN5c3RlbXMgb3Igc2NoZW1lcyBpbmNsdWRpbmcgR0lEIChHbG9i
YWwgSWRlbnRpZmllciksIFNHVElOIChTZXJpYWxpemVkIEdsb2JhbCBUcmFkZSBJdGVtIE51bWJl
ciksIFNTQ0MgKFNlcmlhbCBTaGlwcGluZyBDb250YWluZXIpLCBHTE4gKEdsb2JhbCBMb2NhdGlv
biBOdW1iZXIpLCBHUkFJIChHbG9iYWwgUmV0dXJuYWJsZSBBc3NldCBJZGVudGlmaWVyKSwgRE9E
IChEZXBhcnRtZW50IG9mIERlZmVuc2UpIGFuZCBHSUFJIChHbG9iYWwgSW5kaXZpZHVhbCBBc3Nl
dCBJZGVudGlmaWVyKS4NCg0KRm9yIGVhY2ggc2NoZW1lIGV4Y2VwdCBHSUQsIHRoZXJlIGFyZSB0
d28gdmFyaWF0aW9uc+KAlGEgNjQtYml0IHNjaGVtZSAoZm9yIGV4YW1wbGUsIEdMTi02NCkgYW5k
IGEgOTYtYml0IHNjaGVtZSAoR0xOLTk2KS4gR0lEIGhhcyBvbmx5IGEgOTYtYml0IHNjaGVtZS4N
Cg0KV2l0aGluIGVhY2ggc2NoZW1lLCBhbiBFUEMgaWRlbnRpZmllciBjYW4gYmUgcmVwcmVzZW50
ZWQgaW4gYSBiaW5hcnkgZm9ybSBvciBvdGhlciBmb3JtcyBzdWNoIGFzIFVSSSAuLmV0YyIuDQoN
Ck1heSBiZSB3ZSBuZWVkIHNvbWUgc3VidHlwaW5nLg0KDQpDaGVlcnMsDQoNCkhha2ltYQ0KDQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZTogIlNyaSBHdW5kYXZlbGxpIChz
Z3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb208bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbT4+
DQrDgDogIkNoYXJsZXMgRS4gUGVya2lucyIgPGNoYXJsaWVwQGNvbXB1dGVyLm9yZzxtYWlsdG86
Y2hhcmxpZXBAY29tcHV0ZXIub3JnPj4NCkNjOiAiVmlqYXkgRGV2YXJhcGFsbGkiIDxkdmlqYXlA
cm9ja2V0bWFpbC5jb208bWFpbHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbT4+LCBkbW1AaWV0Zi5v
cmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCkVudm95w6k6IFZlbmRyZWRpIDI2IFNlcHRlbWJyZSAy
MDE0IDAzOjM2OjAxDQpPYmpldDogUmU6IFtETU1dIE1OSUQgVHlwZXMNCg0KSGkgQ2hhcmxpZSwN
Cg0KPiBJcyB0aGUgRG9ELTk2IGlkZW50aWZpZXIgZm9yIGEgc3BlY2lhbCBraW5kIG9mIFJGSUQs
IG9yIGlzIGl0IHZhbGlkIGZvciBhbGwgdGhlIFJGSUQgZGV2aWNlcyB0aGF0IHdvdWxkIGJlIG9m
IGludGVyZXN0Pw0KDQpJIGRvIG5vdCBrbm93IHRoZSBhbnN3ZXIgZm9yIHRoaXMgcXVlc3Rpb24u
IEkgYXNzdW1lZCBET0QtOTYgaXMgYSBtYW5kYXRlZCBzdGFuZGFyZCBmb3IgUkZJRCBlbmNvZGlu
ZywgYnV0IGxvb2tzIGxpa2UgdGhlcmUgYXJlIG90aGVyIGZvcm1hdHMgbGlrZSBHSUQtOTYgLi5l
dGMuIE1heSBiZSB0aGlzIG1heSBlbmQgdXAgbmVlZGluZyBzdWJ0eXBlcy4gV2UgY2FuIGRlZmVy
IHRoaXMgcXVlc3Rpb24gdG8gSGFraW1hIGFuZCBsZWFybiBzb21lIGRldGFpbHMgb24gdGhpcywg
c2hlIHNlZW1zIHRvIGhhdmUgd3JpdHRlbiBtYW55IGJvb2tzIG9uIFJGSUQuDQoNCg0KUmVnYXJk
cw0KU3JpDQoNCg0KDQpGcm9tOiAiQ2hhcmxlcyBFLiBQZXJraW5zIiA8Y2hhcmxpZXBAY29tcHV0
ZXIub3JnPG1haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmc+Pg0KT3JnYW5pemF0aW9uOiBCbHVl
IFNraWVzDQpEYXRlOiBUaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0IDE6NDIgUE0NClRvOiBT
cmkgR3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPG1haWx0bzpzZ3VuZGF2ZUBjaXNjby5j
b20+Pg0KQ2M6ICJkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4iIDxkbW1AaWV0Zi5v
cmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4+LCBWaWpheSBEZXZhcmFwYWxsaSA8ZHZpamF5QHJvY2tl
dG1haWwuY29tPG1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IFtE
TU1dIE1OSUQgVHlwZXMNCg0KDQpIZWxsbyBTcmksDQoNCklzIHRoZSBEb0QtOTYgaWRlbnRpZmll
ciBmb3IgYSBzcGVjaWFsIGtpbmQgb2YgUkZJRCwgb3IgaXMgaXQNCnZhbGlkIGZvciBhbGwgdGhl
IFJGSUQgZGV2aWNlcyB0aGF0IHdvdWxkIGJlIG9mIGludGVyZXN0Pw0KDQpSZWdhcmRzLA0KQ2hh
cmxpZSBQLg0KDQoNCk9uIDkvMjEvMjAxNCA5OjU5IEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRh
dmUpIHdyb3RlOg0KSGkgSGFraW1hLA0KDQpUaGF0IGlzIGEgZ29vZCBpZGVhLiBXZSBzaG91bGQg
cmVnaXN0ZXIgYSB0eXBlIGZvciB0aGUgRG9kLTk2IGlkZW50aWZpZXIgYXMgd2VsbC4NCg0KDQpS
ZWdhcmRzDQpTcmkNCg0KDQpGcm9tOiBIYWtpbWEgQ2hhb3VjaGkgPGhha2ltYS5jaGFvdWNoaUB0
ZWxlY29tLXN1ZHBhcmlzLmV1PG1haWx0bzpoYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJp
cy5ldT4+DQpEYXRlOiBTdW5kYXksIFNlcHRlbWJlciAyMSwgMjAxNCA4OjExIEFNDQpUbzogU3Jp
IEd1bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29t
Pj4NCkNjOiBDaGFybGllIFBlcmtpbnMgPGNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PG1h
aWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4+LCBNYXJjbyBMaWVic2NoIDxNYXJj
by5MaWVic2NoQG5lY2xhYi5ldTxtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PiwgImRt
bUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiIgPGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1t
QGlldGYub3JnPj4sIFZpamF5IERldmFyYXBhbGxpIDxkdmlqYXlAcm9ja2V0bWFpbC5jb208bWFp
bHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogW0RNTV0gTU5JRCBUeXBl
cw0KDQpIZWxsbyBGb2xrcywNCg0KRG8geW91IHRoaW5rIHRoYXQgY29uc2lkZXJpbmcgc3BlY2lm
aWMgYnV0IG5lZWRlZCB0ZWNobm9sb2dpZXMgZm9yIG1vdmluZyBvYmplY3RzIGluICBJbnRlcm5l
dCBvZiBUaGluZ3MgIHN1Y2ggYXMgUkZJRCAoUmFkaW8gRnJlcXVlbmN5IElkZW50aWZpZXIpIHdp
dGggOTYgYml0cyBpZGVudGlmaWVycyB3aWxsIGJlIGFsc28gcmVsZXZlbnQgdG8gQ2hhcmxpZSdz
IGN1cnJlbnQgZHJhZnQgYW5kIHRoZSBlZmZvcnRzIHJlbGF0ZWQgdG8gTU5JRD8NCg0KUmVnYXJk
cywNCg0KSGFraW1hDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRlOiAi
U3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSIgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1
bmRhdmVAY2lzY28uY29tPj4NCsOAOiAiQ2hhcmxpZSBQZXJraW5zIiA8Y2hhcmxlcy5wZXJraW5z
QGVhcnRobGluay5uZXQ8bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pj4sICJN
YXJjbyBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8bWFpbHRvOk1hcmNvLkxpZWJz
Y2hAbmVjbGFiLmV1Pj4sIGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiwgIlZpamF5
IERldmFyYXBhbGxpIiA8ZHZpamF5QHJvY2tldG1haWwuY29tPG1haWx0bzpkdmlqYXlAcm9ja2V0
bWFpbC5jb20+Pg0KRW52b3nDqTogSmV1ZGkgMTEgU2VwdGVtYnJlIDIwMTQgMjM6NTc6MTENCk9i
amV0OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0KDQpIaSBDaGFybGllLA0KDQpGZXcgbW9yZSByZXZp
ZXdzL2Rpc2N1c3Npb25zIGFuZCBjYXB0dXJpbmcgdGhlIGNvbnNlbnN1cyBpbiB0aGUgYmFzZSB2
ZXJzaW9uIHdpbGwgaGVscC4gQnV0LCBJJ20gb2sgZWl0aGVyIHdheSDigKYNCg0KDQpSZWdhcmRz
DQpTcmkNCg0KRnJvbTogQ2hhcmxpZSBQZXJraW5zIDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5r
Lm5ldDxtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+Pg0KRGF0ZTogVGh1cnNk
YXksIFNlcHRlbWJlciAxMSwgMjAxNCAyOjQ2IFBNDQpUbzogU3JpIEd1bmRhdmVsbGkgPHNndW5k
YXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4sIE1hcmNvIExpZWJzY2gg
PE1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PG1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldT4+
LCAiZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+IiA8ZG1tQGlldGYub3JnPG1haWx0
bzpkbW1AaWV0Zi5vcmc+PiwgVmlqYXkgRGV2YXJhcGFsbGkgPGR2aWpheUByb2NrZXRtYWlsLmNv
bTxtYWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29tPj4NClN1YmplY3Q6IFJlOiBbRE1NXSBNTklE
IFR5cGVzDQoNCg0KSGVsbG8gZm9sa3MsDQoNCkkgcHJvcG9zZSB0byBzdWJtaXQgdGhlIC4uLi4t
MDAudHh0IGRvY3VtZW50IGFzIGl0IGlzIHRvIHRoZSBJbnRlcm5ldA0KRHJhZnRzIGRpcmVjdG9y
eSwgYW5kIHRoZW4gdG8gZ28gYWJvdXQgbWFraW5nIHVwZGF0ZXMgYWNjb3JkaW5nIHRvDQp0aGUg
ZGlzY3Vzc2lvbiBvbiB0aGlzIGxpc3QuICBEbyB5b3UgdGhpbmsgdGhpcyBpcyByZWFzb25hYmxl
Pw0KDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCk9uIDkvMTEvMjAxNCA3OjIxIEFNLCBTcmkg
R3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0KDQo8Q2hhbmdpbmcgdGhlIHN1YmplY3QgbGlu
ZSB0byByZWZsZWN0IHRoZSBNTklkIGRpc2N1c3Npb24+DQoNCg0KTWFyY28sDQoNCg0KVGhpbmtp
bmcgZnVydGhlciBvbiB0aGUgY29tcGxlbWVudGFyeSBpZGVudGlmaWVyIG9wdGlvbi4NCg0KLSBU
aGVyZSBpcyBhbHJlYWR5IHRoZSBsaW5rLWxheWVyIGlkZW50aWZpZXIgb3B0aW9uIHRoYXQgY2Fu
IGJlIHVzZWQgZm9yDQpjYXJyeWluZyB0aGUgTWFjIGFkZHJlc3MNCi0gSU1FSSBhbmQgTVNJU0RO
IGFyZSBhbHJlYWR5IGRlZmluZWQgaW4gMjkuMjc1IGFzIGEgM0dQUCBWU0Uncw0KDQpJbiBzb21l
IHNlbnNlLCB0aGUgY29tcGxlbWVudGFyeSBpZGVudGlmaWVycyBhcmUgYWxyZWFkeSBwcmVzZW50
Lg0KDQpTcmkNCg0KDQoNCg0KDQpPbiA5LzExLzE0IDY6NTggQU0sICJTcmkgR3VuZGF2ZWxsaSAo
c2d1bmRhdmUpIiA8c2d1bmRhdmVAY2lzY28uY29tPjxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29t
PiB3cm90ZToNCg0KDQpJIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5IG11bHRpcGxlIE1OLUlkIGlu
c3RhbmNlcyBuZWVkIHRvIGJlIHByZXNlbnQgaW4gYQ0Kc2luZ2xlIG1lc3NhZ2UgPyBJbiBteSBl
eHBlcmllbmNlLCB0aGlzIGlzIHN0cmljdGx5IGEgZGVwbG95bWVudA0KY29uc2lkZXJhdGlvbiwg
d2hlbiB0byB1c2Ugd2hhdCB0eXBlIG9mIGlkZW50aWZpZXJzLg0KDQpBc3N1bWluZyB0aGUgYmFj
a2VuZCBzeXN0ZW0gY2FuIHRpZSBhbGwgdGhlIE1OLUlkJ3MgdG8gYSBzaW5nbGUNCnN1YnNjcmlw
dGlvbiwgYW55IHByZXNlbnRlZCBpZGVudGlmaWVyIGNhbiBiZSBzdWZmaWNpZW50IGZvciB0aGUg
Z2F0ZXdheQ0KdG8gZG8gdGhlIEJDRSBsb29rdXAuDQoNCklmIG11bHRpcGxlIGluc3RhbmNlcyBj
YW4gYmUgcHJlc2VudCwgdGhlbiB3ZSBuZWVkIHRvIGRlYWwgd2l0aCBtb3JlIGVycm9yDQpjYXNl
cy4gSXMgdGhhdCByZWFsbHkgbmVlZGVkID8NCg0KDQoNCg0KSSBhbSB3b25kZXJpbmcgaWYgaXQg
d291bGQgbm90IGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gZ28gZm9yIGEgZGlmZmVyZW50DQpjb250
YWluZXIgb3B0aW9uIHRvIGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24uIFNvbWV0aGluZyBsaWtlIGEN
CmNvbXBsZW1lbnRhcnkgaWRlbnRpZmllciBvcHRpb24uDQoNCg0KU291bmRzIGludGVyZXN0aW5n
LiBBcmUgeW91IHN1Z2dlc3Rpbmcgd2UgbGVhdmUgdGhlIGN1cnJlbnQgTU4tSUQgYXMgaXQNCmlz
LCBidXQgdXNlIGEgbmV3IGNvbXBsZW1lbnRhcnkgb3B0aW9uID8gQnV0LCBpZiB0aGUgcmVxdWly
ZW1lbnQgaXMgZm9yIGENCk1hYyBiYXNlZCBpZGVudGlmaWVycywgd2hhdCB3aWxsIGJlIHRoZXJl
IGluIHRoZSBjdXJyZW50IE1OLUlkIG9wdGlvbiA/IFdlDQpzdGlsbCBuZWVkIHRvIGhhdmUgaWRl
bnRpZmllciB0aGVyZSA/DQoNCg0KDQoNClNyaQ0KDQoNCg0KDQoNCk9uIDkvMTEvMTQgMjowMyBB
TSwgIk1hcmNvIExpZWJzY2giIDxNYXJjby5MaWVic2NoQG5lY2xhYi5ldT48bWFpbHRvOk1hcmNv
LkxpZWJzY2hAbmVjbGFiLmV1PiB3cm90ZToNCg0KDQoNCk5vIGlzc3VlIHdpdGggbG9naWNhbCB2
cy4gcGh5c2ljYWwgSUQuIEJ1dCBJIGFtIHdvbmRlcmluZyBhYm91dCB0d28NCnRoaW5nczoNCg0K
T3BlcmF0aW9uIGlzIGNsZWFyIHRvIG1lIGluIGNhc2UgYSBzaW5nbGUgTU5JRCBpcyBwcmVzZW50
IGluIGEgbWVzc2FnZQ0KYW5kIEkgc2VlIHRoZSB2YWx1ZSBpbiBiZWluZw0KZmxleGlibGUgdG8g
Y2hvb3NlIGZyb20gZGlmZmVyZW50IHN1Yi10eXBlcy4gSWYgbXVsdGlwbGUgTU5JRHMgd2l0aA0K
ZGlmZmVyZW50IHN1Yi10eXBlcyBhcmUgcHJlc2VudCBpbg0KYSBzaW5nbGUgbWVzc2FnZSwgd2hp
Y2ggb25lIHNob3VsZCBlLmcuIHRoZSBMTUEgdGFrZSBmb3IgdGhlIEJDIGxvb2t1cC4uDQpObyBi
aWcgcHJvYmxlbSB0byBzb2x2ZSwgYnV0DQp0byBiZSBjb25zaWRlcmVkIGluIGltcGxlbWVudGF0
aW9ucy4NCg0KSWYgdGhlIHJlYXNvbiBmb3IgbXVsdGlwbGUgcHJlc2VudCBNTklEcyB3aXRoIGRp
ZmZlcmVudCBzdWItdHlwZXMgaXMgdG8NCmRvIG90aGVyIHRoaW5ncyB0aGFuIGlkZW50aWZ5aW5n
DQp0aGUgbm9kZSBvciB1c2luZyB0aGUgSUQgYXMga2V5IGZvciBhIGxvb2t1cCwgSSBhbSB3b25k
ZXJpbmcgaWYgaXQgd291bGQNCm5vdCBiZSBtb3JlIGFwcHJvcHJpYXRlDQp0byBnbyBmb3IgYSBk
aWZmZXJlbnQgY29udGFpbmVyIG9wdGlvbiB0byBjYXJyeSBzdWNoIGluZm9ybWF0aW9uLg0KU29t
ZXRoaW5nIGxpa2UgYSBjb21wbGVtZW50YXJ5DQppZGVudGlmaWVyIG9wdGlvbi4NCg0KbWFyY28N
Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTcmkgR3VuZGF2ZWxsaSAo
c2d1bmRhdmUpIFttYWlsdG86c2d1bmRhdmVAY2lzY28uY29tXQ0KU2VudDogRG9ubmVyc3RhZywg
MTEuIFNlcHRlbWJlciAyMDE0IDAwOjQyDQpUbzogQ2hhcmxpZSBQZXJraW5zOyBNYXJjbyBMaWVi
c2NoOyBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCkNjOiBWaWpheSBEZXZhcmFw
YWxsaQ0KU3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hhcnRlcmluZy4uDQoN
CkhlbGxvIENoYXJsaWUsDQoNCkFncmVlIHdpdGggdGhhdC4gTU4tSWQgYXMgaXRzIGRlZmluZWQg
dG9kYXkgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIuIEl0DQpkb2VzIG5vdA0KcmVxdWlyZSB0aGUg
aWRlbnRpZmllciB0byBiZSBib3VuZCB0byBhIHBoeXNpY2FsIGRldmljZSBvciBhIGludGVyZmFj
ZQ0KaWRlbnRpdHkuDQpCdXQsIHdlIGhhdmUgY2xlYXJseSBzZWVuIHJlcXVpcmVtZW50cyB3aGVy
ZSB0aGUgbmVlZCBpcyBmb3IgZ2VuZXJhdGluZw0KaWRlbnRpZmllcnMgYmFzZWQgb24gc29tZSBw
aHlzaWNhbCBpZGVudGlmaWVycy4gVGhvc2UgcGh5c2ljYWwNCmlkZW50aWZpZXJzIGluY2x1ZGUN
CklNU0ksIE1TSVNETiwgSU1FSSwgTUFDIC4uZXRjLiBJZiB3ZSBjYW4gZGVmaW5lIGEgdHlwZSBm
b3IgZWFjaCBvZiB0aGUNCnNvdXJjZQ0KYW5kIHRoZSBydWxlcyBmb3IgZ2VuZXJhdGluZyBNTi1J
RCBiYXNlZCB1c2luZyB0aG9zZSBzb3VyY2VzLCB0aGUgc2VuZGVyDQphbmQNCnJlY2VpdmVyIHdp
bGwgaGF2ZSBjbGVhciBndWlkYW5jZSBvbiBob3cgdG8gdXNlIHRoZSBzcGVjLiBTb21lIHBvaW50
ZXJzLA0KZXhwbGFuYXRpb24gYW5kIGV4YW1wbGVzIGZvciBlYWNoIG9mIHRob3NlIGlkZW50aWZp
ZXJzIHdpbGwgZ3JlYXRseSBoZWxwDQphdm9pZA0KaW50ZXItb3AgaXNzdWVzLg0KDQoNClJlZ2Fy
ZHMNClNyaQ0KDQoNCg0KDQoNCg0KDQpPbiA5LzEwLzE0IDM6MjEgUE0sICJDaGFybGllIFBlcmtp
bnMiIDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD48bWFpbHRvOmNoYXJsZXMucGVya2lu
c0BlYXJ0aGxpbmsubmV0Pg0Kd3JvdGU6DQoNCg0KDQpIZWxsbyBmb2xrcywNCg0KSSB0aGluayBp
dCdzIGJlc3QgdG8gY29uc2lkZXIgdGhlIE1OSUQgYXMgc2ltcGx5IGxpdmluZyBpbiBhIHNwYWNl
IG9mDQppZGVudGlmaWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVjaCBhYm91dCB3aGV0aGVyIGl0
J3MgYSBsb2dpY2FsDQppZGVudGlmaWVyIG9yIGEgcGh5c2ljYWwgaWRlbnRpZmllci4gIElmIHRo
ZSBmb3JtZXIsIHRoZW4gc29tZXdoZXJlDQoocGVyaGFwcyBiZWxvdyB0aGUgbmV0d29yayBsYXll
cikgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciBoYXMgYmVlbiBib3VuZA0KdG8gc29tZXRoaW5nIGlu
IHRoZSBwaHlzaWNhbCBpbnRlcmZhY2UsIGJ1dCB0aGF0J3Mgbm90IG91ciBwcm9ibGVtLg0KDQpU
aGUgbnVtYmVyIHNwYWNlIGZvciB0eXBlcyBvZiBNTklEcyBpcyBsaWtlbHkgdG8gc3RheSBwcmV0
dHkgZW1wdHksIHNvDQpJJ2Qgc2F5IHdlIGNvdWxkIGFkZCBhcyBtYW55IHR5cGVzIGFzIHdvdWxk
IGJlIGNvbnZlbmllbnQgZm9yIHRoZQ0Kc29mdHdhcmUgZGVzaWduZXJzLiAgU28sIHdlIGNvdWxk
IGNvbmNlaXZhYmx5IGhhdmUgc2V2ZXJhbCBNTklEcw0KZGVmaW5lZCB0aGF0IGFsbCAibG9va2Vk
IGxpa2UiIE5BSXMgKHdoaWNoLCB0aGVtc2VsdmVzLCAibG9vayBsaWtlIg0KRlFETnMpLg0KDQpS
ZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCg0KT24gOS8xMC8yMDE0IDg6MTEgQU0sIFNyaSBHdW5k
YXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6DQoNCg0KWWVzLiBDdXJyZW50bHksIHRoZSBNTklEIGlz
IGlmIHRoZSBuYWkgZm9ybWF0IGFuZCBpcyBvdmVybG9hZGVkLiBUaGUNCk1OSUQgIGluIDNHUFAg
c3BlY3MgaXMgdGhlIElNU0ktTkFJIChJTVNJQFJFQUxNKSwgaXRzIGJhc2VkIG9uIHRoZQ0KSU1T
SS4gRXg6DQoiPElNU0k+QGVwYy5tbmM8TU5DPi5tY2M8TUNDPi4zZ3BwbmV0d29yay5vcmfCsg0K
DQpXZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07DQoNCldlIGFsc28gaGF2ZSBhcHByb2FjaGVzIHRv
IHRyYW5zZm9ybSBNQUMgdG8gUHNldWRvIElNU0ksIGFuZCB0aGVuDQpjYXJyeSBJTVNJLU5BSSBh
cyB0aGUgTU4tSUQuDQoNCg0KU28sIHdlIG5lZWQgdW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBv
ZiB0aGUgdHlwZXMvc291cmNlcy4NCg0KTU4tSWQgYmFzZWQgb24gSU1TSSwgTVNJU0ROLCBJTUVJ
LCBNQUMgLi4NCg0KQWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElNU0kg
YW5kIElNU0ktTkFJID8NCg0KU3JpDQoNCg0KDQpPbiA5LzEwLzE0IDY6MjkgQU0sICJNYXJjbyBM
aWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PG1haWx0bzpNYXJjby5MaWVic2NoQG5l
Y2xhYi5ldT4gd3JvdGU6DQoNCg0KDQpJdCBzZWVtcyB0aGUgTU5JRCBpcyBzb21laG93IG92ZXJs
b2FkZWQgdG8gY2FycnkgYm90aCwgbm9kZS1zcGVjaWZpYw0KSURzLCAgZS5nLiBNQUMsIGFzIHdl
bGwgYXMgc3Vic2NyaWJlciBJRHMsIHdoaWNoIGlzIHRoZSBJTVNJLg0KVGhlcmUgbWF5IGJlIHZh
bHVlIGluIGFkZGluZyB0aGUgSU1FSSB0byB0aGUgbGlzdCBvZiBwb3NzaWJsZSB0eXBlcw0Kb2Yg
IG5vZGUtc3BlY2lmaWMgSURzLg0KDQptYXJjbw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgU3JpIEd1bmRhdmVsbGkNCihzZ3VuZGF2ZSkNClNlbnQ6IERpZW5zdGFnLCA5LiBTZXB0ZW1i
ZXIgMjAxNCAyMzozMA0KVG86IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSk7IENoYXJsaWUgUGVy
a2luczsgZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpDYzogVmlqYXkgRGV2YXJh
cGFsbGkNClN1YmplY3Q6IFJlOiBbRE1NXSByZWdhcmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLg0K
DQpUd28gbW9yZSBjb21tZW50cy4NCg0KDQoNCjQuKSBJJ2QgYWxzbyB1c2Ugc3ViLXR5cGUgdmFs
dWUgb2YgKDIpIGZvciBJTVNJLiBKdXN0IHRvIGFsaWduIHdpdGgNCnRoZSAgc3ViLXR5cGVzICBk
ZWZpbmVkIGZvciBNTiBJZCBkZWZpbmVkIGZvciBJQ01QLiBJIHN1c3BlY3QgdGhlcmUNCmFyZSBz
b21lICBpbXBsZW1lbnRhdGlvbnMgIGFscmVhZHkgdXNpbmcgc3ViLXR5cGUgKDIpLiBQbGVhc2Ug
c2VlDQp0aGUgb3RoZXIgdGhyZWFkLg0KDQoNCjUuKSBGb3IgZWFjaCBvZiB0aGUgc3ViLXR5cGVz
LCB3ZSBuZWVkIHRleHQgaW5jbHVkaW5nIGV4YW1wbGVzIGFuZA0Kc29tZQ0KZXhwbGFuYXRpb24g
b24gaG93IHRoZXkgYXJlIHVzZWQuDQoNCg0KU3JpDQoNCg0KDQpPbiA5LzkvMTQgMjoyMCBQTSwg
IlNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb20+PG1haWx0bzpz
Z3VuZGF2ZUBjaXNjby5jb20+DQp3cm90ZToNCg0KDQoNCkhpIENoYXJsaWUsDQoNClRoaXMgaXMg
Z29vZC4gVGhhbmtzLg0KDQoNCjEuKSBJZiBFVUktNDggYW5kIEVVSS02NCBhZGRyZXNzZXMgYXJl
IGRlcml2ZWQgb2YgYSA0OC1iaXQgSUVFRQ0KODAyLjINCmFkZHJlc3MsIHdoeSBkbyB3ZSBuZWVk
IHRvIHR3byBzdWItdHlwZXMgPyBXaHkgbm90IGhhdmUganVzdCBvbmUNCnN1Yi10eXBlIGZvciBt
YWMgYmFzZWQgaWRlbnRpZmllcnMgPw0KDQoyLikgU3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJl
bnRseSB1c2VkLiBJdHMgY3VycmVudGx5IG92ZXJsb2FkZWQNCmZvcg0KSU1TSS1OQUkgKDNHUFAg
c3BlY3MpIGFuZCBnZW5lcmljIE5BSSBiYXNlZCBpZGVudGlmaWVycy4gR2l2ZW4gdGhlDQpkZWZp
bml0aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxhaW5pbmcgdGhl
DQptb3RpdmF0aW9uDQoNCjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElQ
djYgYWRkcmVzcy4gV2hhdCBleGFjdGx5DQppcw0KdGhpcyA/IEFyZSB0aGVzZSBDR0EtYmFzZWQg
SVB2NiBhZGRyZXNzZXMgPw0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICBOZXcgTW9iaWxl
IE5vZGUgSWRlbnRpZmllciBUeXBlcw0KDQogICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t
LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgfCBJZGVudGlmaWVy
IFR5cGUgfCBJZGVudGlmaWVyIFR5cGUgTnVtYmVyIHwNCiAgICAgICAgICAgICAgICstLS0tLS0t
LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICB8IElQ
djYgQWRkcmVzcyAgICB8IDIgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg
fCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg
ICAgIHwgSU1TSSAgICAgICAgICAgIHwgMyAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg
ICAgICAgICAgICAgfCBQLVRNU0kgICAgICAgICAgfCA0ICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg
ICB8DQogICAgICAgICAgICAgICB8IEVVSS00OCBhZGRyZXNzICB8IDUgICAgICAgICAgICAgICAg
ICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg
ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgRVVJLTY0IGFkZHJlc3MgIHwgNiAgICAgICAg
ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAg
ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBHVVRJICAgICAgICAgICAgfCA3
ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t
LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMNClNyaQ0K
UFM6IEdvb2QgdG8gc2VlIFZpamF5IGJhY2sNCg0KDQpPbiA5LzkvMTQgMToyOCBQTSwgIkNoYXJs
aWUgUGVya2lucyINCjxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD48bWFpbHRvOmNoYXJs
ZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pg0Kd3JvdGU6DQoNCg0KDQpIZWxsbyBmb2xrcywNCg0K
SGVyZSdzIHRoZSBsYXN0IEludGVybmV0IERyYWZ0IHRoYXQgd2UgZGlkLCBsb25nIGFnbyBleHBp
cmVkOg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVya2lucy1tZXh0
LTQyODNtbmlkcy0wMS50eHQNCg0KSSdsbCByZXN1Ym1pdCBpdCB3aXRoIGEgZmV3IHVwZGF0ZXMg
YXMgYSBwZXJzb25hbCBkcmFmdCB0byBkbW0uDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWls
aW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmc8bWFp
bHRvOmRtbUBpZXRmLm9yZz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rt
bQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1t
IG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9y
ZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZG1tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0KDQoNCi0tDQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkhha2ltYSBDaGFvdWNoaQ0KUHJvZmVzc29y
DQpUZWxlY29tIFN1ZCBQYXJpcw0KSW5zdGl0dXQgTWluZXMgVGVsZWNvbQ0KOSBydWUgQ2hhcmxl
cyBGb3VyaWVyDQo5MTAxMSBFdnJ5DQowMTYwNzY0NDQzDQoNCg0KDQoNCi0tDQpSZWdhcmRzLA0K
Q2hhcmxpZSBQLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQoNCg0KLS0NCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSGFraW1hIENoYW91Y2hpDQpQcm9mZXNz
b3INClRlbGVjb20gU3VkIFBhcmlzDQpJbnN0aXR1dCBNaW5lcyBUZWxlY29tDQo5IHJ1ZSBDaGFy
bGVzIEZvdXJpZXINCjkxMDExIEV2cnkNCjAxNjA3NjQ0NDMNCg0K

--_000_D04A4C12166E7Asgundaveciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+VGhhbmtzLjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpbmtpbmcgYWJvdXQgdGhpcyBmdXJ0aGVy
LCBoYXZpbmcgdGhlIFJGSUQgc3VidHlwZSAmbmJzcDtpcyBwcm9iYWJseSBnb2luZyB0byBiZSBl
eHRyZW1lbHkgdXNlZnVsIGZvciBJT1QgYXBwbGljYXRpb25zLiBBIE1BRy9NUiBjYW4gcG90ZW50
aWFsbHkgcmVnaXN0ZXIgZGV2aWNlcyBpZGVudGlmaWVkIHdpdGggUkZJRCBhcyB0aGUgTkFJOyBB
bHNvLCB0aGVyZSBzZWVtcyB0byBiZSBzb21lIG1hcHBpbmcgYmV0d2VlbiA2NC1iaXQgRVBDIGFu
ZA0KIElQdjYgSWRlbnRpZmllciwgYWxsb3dpbmcgZGV2aWNlIGFkZHJlc3NhYmlsaXR5IG92ZXIg
SVB2NiBhbmQgdGhhdCBtYWtlcyB0aGlzIGludGVyZXN0aW5nIGFuZCBlbmFibGUgc29tZSBuZXcg
dXNlLWNhc2VzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkczwvZGl2Pg0K
PGRpdj5Tcmk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ
X1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEx
cHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu
b25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJ
TkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0
IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxz
cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+SGFraW1hIENoYW91Y2hp
ICZsdDs8YSBocmVmPSJtYWlsdG86aGFraW1hLmNoYW91Y2hpQHRlbGVjb20tc3VkcGFyaXMuZXUi
Pmhha2ltYS5jaGFvdWNoaUB0ZWxlY29tLXN1ZHBhcmlzLmV1PC9hPiZndDs8YnI+DQo8c3BhbiBz
dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5LCBTZXB0ZW1iZXIg
MjUsIDIwMTQgOTozMSBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzog
PC9zcGFuPlNyaSBHdW5kYXZlbGxpICZsdDs8YSBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28u
Y29tIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90O0NoYXJsZXMgRS4gUGVya2lucyZxdW90OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmNoYXJsaWVwQGNvbXB1dGVyLm9yZyI+Y2hhcmxpZXBAY29tcHV0ZXIu
b3JnPC9hPiZndDssIFZpamF5IERldmFyYXBhbGxpICZsdDs8YSBocmVmPSJtYWlsdG86ZHZpamF5
QHJvY2tldG1haWwuY29tIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0OywgJnF1b3Q7PGEg
aHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8
YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz
cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtETU1dIE1O
SUQgVHlwZXM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywg
c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiPg0KPGRpdj5IaSw8L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZvciBSRklEIHdlIHJlZmVyIHRvIHRoZSBFUEMgc3Rh
bmRhcmRzLjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+JnF1b3Q7VGhlIDxl
bT5FbGVjdHJvbmljIFByb2R1Y3QgQ29kZTwvZW0+IChFUEMpIGlzIGFuIGlkZW50aWZpY2F0aW9u
IHNjaGVtZSBmb3IgdW5pdmVyc2FsbHkgaWRlbnRpZnlpbmcgcGh5c2ljYWwgb2JqZWN0cyBieSB1
c2luZyBSYWRpbyBGcmVxdWVuY3kgSWRlbnRpZmljYXRpb24gKFJGSUQpIHRhZ3MuPC9kaXY+DQo8
ZGl2PlRoZSBzdGFuZGFyZGl6ZWQgRVBDIHRhZyBlbmNvZGluZyBjb25zaXN0cyBvZiBhbiBFUEMg
SWRlbnRpZmllciB0aGF0IHVuaXF1ZWx5IGlkZW50aWZpZXMgYW4gaW5kaXZpZHVhbCBvYmplY3Qs
IGFuZCBtYXkgYWxzbyBpbmNsdWRlIGEgZmlsdGVyIHZhbHVlIGlmIHRoZSBmaWx0ZXIgaXMgbmVl
ZGVkIHRvIGVuYWJsZSBlZmZlY3RpdmUgYW5kIGVmZmljaWVudCByZWFkaW5nIG9mIHRoZSBFUEMg
dGFncy4gVGhlIEVQQyBJZGVudGlmaWVyIGlzDQogYSBtZXRhLWNvZGluZyBzY2hlbWUgZGVzaWdu
ZWQgdG8gc3VwcG9ydCB0aGUgbmVlZHMgb2YgdmFyaW91cyBpbmR1c3RyaWVzIGJ5IGFjY29tbW9k
YXRpbmcgZXhpc3RpbmcgY29kaW5nIHNjaGVtZXMgd2hlcmUgcG9zc2libGUgYW5kIGJ5IGRlZmlu
aW5nIG5ldyBzY2hlbWVzIHdoZXJlIG5lY2Vzc2FyeS4mcXVvdDs8L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2PiZxdW90O0VQQyBzdXBwb3J0cyBzZXZlcmFsIGVuY29kaW5nIHN5c3RlbXMg
b3Igc2NoZW1lcyBpbmNsdWRpbmcgR0lEIChHbG9iYWwgSWRlbnRpZmllciksIFNHVElOIChTZXJp
YWxpemVkIEdsb2JhbCBUcmFkZSBJdGVtIE51bWJlciksIFNTQ0MgKFNlcmlhbCBTaGlwcGluZyBD
b250YWluZXIpLCBHTE4gKEdsb2JhbCBMb2NhdGlvbiBOdW1iZXIpLCBHUkFJIChHbG9iYWwgUmV0
dXJuYWJsZSBBc3NldCBJZGVudGlmaWVyKSwgRE9EIChEZXBhcnRtZW50DQogb2YgRGVmZW5zZSkg
YW5kIEdJQUkgKEdsb2JhbCBJbmRpdmlkdWFsIEFzc2V0IElkZW50aWZpZXIpLg0KPHAgc3R5bGU9
Im1hcmdpbjogMHB4OyIgZGF0YS1tY2Utc3R5bGU9Im1hcmdpbjogMHB4OyI+Rm9yIGVhY2ggc2No
ZW1lIGV4Y2VwdCBHSUQsIHRoZXJlIGFyZSB0d28gdmFyaWF0aW9uc+KAlGEgNjQtYml0IHNjaGVt
ZSAoZm9yIGV4YW1wbGUsIEdMTi02NCkgYW5kIGEgOTYtYml0IHNjaGVtZSAoR0xOLTk2KS4gR0lE
IGhhcyBvbmx5IGEgOTYtYml0IHNjaGVtZS48L3A+DQpXaXRoaW4gZWFjaCBzY2hlbWUsIGFuIEVQ
QyBpZGVudGlmaWVyIGNhbiBiZSByZXByZXNlbnRlZCBpbiBhIGJpbmFyeSBmb3JtIG9yIG90aGVy
IGZvcm1zIHN1Y2ggYXMgVVJJIC4uZXRjJnF1b3Q7Ljxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+TWF5IGJlIHdlIG5lZWQgc29tZSBzdWJ0eXBpbmcuPGJyPg0KPC9kaXY+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaGVlcnMsPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5IYWtpbWE8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGhyIGlkPSJ6d2NociI+DQo8ZGl2IHN0eWxlPSJjb2xvcjojMDAwO2ZvbnQt
d2VpZ2h0Om5vcm1hbDtmb250LXN0eWxlOm5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTtmb250
LWZhbWlseTpIZWx2ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTJwdDsiPg0KPGI+
RGU6IDwvYj4mcXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7ICZsdDs8YSBocmVm
PSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxi
cj4NCjxiPsOAOiA8L2I+JnF1b3Q7Q2hhcmxlcyBFLiBQZXJraW5zJnF1b3Q7ICZsdDs8YSBocmVm
PSJtYWlsdG86Y2hhcmxpZXBAY29tcHV0ZXIub3JnIj5jaGFybGllcEBjb21wdXRlci5vcmc8L2E+
Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7VmlqYXkgRGV2YXJhcGFsbGkmcXVvdDsgJmx0Ozxh
IGhyZWY9Im1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20iPmR2aWpheUByb2NrZXRtYWlsLmNv
bTwvYT4mZ3Q7LA0KPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3JnPC9h
Pjxicj4NCjxiPkVudm95w6k6IDwvYj5WZW5kcmVkaSAyNiBTZXB0ZW1icmUgMjAxNCAwMzozNjow
MTxicj4NCjxiPk9iamV0OiA8L2I+UmU6IFtETU1dIE1OSUQgVHlwZXM8YnI+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj5IaSBDaGFybGllLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
Jmd0OyZuYnNwO0lzIHRoZSBEb0QtOTYgaWRlbnRpZmllciBmb3IgYSBzcGVjaWFsIGtpbmQgb2Yg
UkZJRCwgb3IgaXMgaXQmbmJzcDt2YWxpZCBmb3IgYWxsIHRoZSBSRklEIGRldmljZXMgdGhhdCB3
b3VsZCBiZSBvZiBpbnRlcmVzdD88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgZG8g
bm90IGtub3cgdGhlIGFuc3dlciBmb3IgdGhpcyBxdWVzdGlvbi4gSSBhc3N1bWVkIERPRC05NiBp
cyBhIG1hbmRhdGVkIHN0YW5kYXJkIGZvciBSRklEIGVuY29kaW5nLCBidXQgbG9va3MgbGlrZSB0
aGVyZSBhcmUgb3RoZXIgZm9ybWF0cyBsaWtlIEdJRC05NiAuLmV0Yy4gTWF5IGJlIHRoaXMgbWF5
IGVuZCB1cCBuZWVkaW5nIHN1YnR5cGVzLiBXZSBjYW4gZGVmZXIgdGhpcyBxdWVzdGlvbiB0byBI
YWtpbWEgYW5kIGxlYXJuIHNvbWUNCiBkZXRhaWxzIG9uIHRoaXMsIHNoZSBzZWVtcyB0byBoYXZl
IHdyaXR0ZW4gbWFueSBib29rcyBvbiBSRklELjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4NCjxkaXY+U3JpPC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bh
biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs
aWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRF
Ui1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkct
Qk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRF
Ui1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURE
SU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3Nw
YW4+JnF1b3Q7Q2hhcmxlcyBFLiBQZXJraW5zJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hh
cmxpZXBAY29tcHV0ZXIub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2hhcmxpZXBAY29tcHV0ZXIub3Jn
PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T3JnYW5pemF0aW9u
OiA8L3NwYW4+Qmx1ZSBTa2llczxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5E
YXRlOiA8L3NwYW4+VGh1cnNkYXksIFNlcHRlbWJlciAyNSwgMjAxNCAxOjQyIFBNPGJyPg0KPHNw
YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+U3JpIEd1bmRhdmVsbGkgJmx0
OzxhIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5zZ3Vu
ZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk
Ij5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZG1tQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPiZndDssIFZpamF5IERldmFy
YXBhbGxpICZsdDs8YSBocmVmPSJtYWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29tIiB0YXJnZXQ9
Il9ibGFuayI+ZHZpamF5QHJvY2tldG1haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i
Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbRE1NXSBNTklEIFR5cGVzPGJy
Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KSGVsbG8gU3Jp
LDxicj4NCjxicj4NCklzIHRoZSBEb0QtOTYgaWRlbnRpZmllciBmb3IgYSBzcGVjaWFsIGtpbmQg
b2YgUkZJRCwgb3IgaXMgaXQ8YnI+DQp2YWxpZCBmb3IgYWxsIHRoZSBSRklEIGRldmljZXMgdGhh
dCB3b3VsZCBiZSBvZiBpbnRlcmVzdD88YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCkNoYXJsaWUg
UC48YnI+DQo8YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDkvMjEv
MjAxNCA5OjU5IEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOjxicj4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOkQwNDQ1MEU1LjE2NjA4RiUyNXNndW5kYXZlQGNpc2Nv
LmNvbSI+DQo8ZGl2PkhpIEhha2ltYSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRo
YXQgaXMgYSBnb29kIGlkZWEuIFdlIHNob3VsZCByZWdpc3RlciBhIHR5cGUgZm9yIHRoZSBEb2Qt
OTYgaWRlbnRpZmllciBhcyB3ZWxsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4NCjxkaXY+U3JpPC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP
TiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsNCiAg
ICAgICAgICB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRp
dW0gbm9uZTsNCiAgICAgICAgICBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9U
VE9NOiAwaW47IFBBRERJTkctTEVGVDoNCiAgICAgICAgICAwaW47IFBBRERJTkctUklHSFQ6IDBp
bjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7DQogICAgICAgICAgQk9SREVSLVJJR0hU
OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkhha2ltYSBDaGFvdWNoaSAmbHQ7PGEgaHJlZj0ibWFpbHRv
Omhha2ltYS5jaGFvdWNoaUB0ZWxlY29tLXN1ZHBhcmlzLmV1IiB0YXJnZXQ9Il9ibGFuayI+aGFr
aW1hLmNoYW91Y2hpQHRlbGVjb20tc3VkcGFyaXMuZXU8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxl
PSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+U3VuZGF5LCBTZXB0ZW1iZXIgMjEsIDIw
MTQgODoxMSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFu
PlNyaSBHdW5kYXZlbGxpICZsdDs8YSBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIiB0
YXJnZXQ9Il9ibGFuayI+c2d1bmRhdmVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls
ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5DaGFybGllIFBlcmtpbnMgJmx0OzxhIGhy
ZWY9Im1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCIgdGFyZ2V0PSJfYmxhbmsi
PmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PC9hPiZndDssIE1hcmNvIExpZWJzY2ggJmx0
OzxhIGhyZWY9Im1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldSIgdGFyZ2V0PSJfYmxhbmsi
Pk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1PC9hPiZndDssDQogJnF1b3Q7PGEgaHJlZj0ibWFpbHRv
OmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0
OzxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5v
cmc8L2E+Jmd0OywgVmlqYXkgRGV2YXJhcGFsbGkgJmx0OzxhIGhyZWY9Im1haWx0bzpkdmlqYXlA
cm9ja2V0bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+
Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+
UmU6IFtETU1dIE1OSUQgVHlwZXM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5
b3JrLCB0aW1lcywNCiAgICAgICAgICAgICAgc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6
ICMwMDAwMDAiPg0KPGRpdj5IZWxsbyBGb2xrcyw8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2PkRvIHlvdSB0aGluayB0aGF0IGNvbnNpZGVyaW5nIHNwZWNpZmljIGJ1dCBuZWVk
ZWQgdGVjaG5vbG9naWVzIGZvciBtb3Zpbmcgb2JqZWN0cyBpbiZuYnNwOyBJbnRlcm5ldCBvZiBU
aGluZ3MmbmJzcDsgc3VjaCBhcyBSRklEIChSYWRpbyBGcmVxdWVuY3kgSWRlbnRpZmllcikgd2l0
aCA5NiBiaXRzIGlkZW50aWZpZXJzIHdpbGwgYmUgYWxzbyByZWxldmVudCB0byBDaGFybGllJ3Mg
Y3VycmVudCBkcmFmdCBhbmQgdGhlIGVmZm9ydHMgcmVsYXRlZCB0byBNTklEPyZuYnNwOw0KPGJy
Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDxicj4NCjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SGFraW1hPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxociBpZD0iendjaHIiPg0KPGRpdiBzdHlsZT0iY29s
b3I6IzAwMDtmb250LXdlaWdodDpub3JtYWw7Zm9udC1zdHlsZTpub3JtYWw7dGV4dC1kZWNvcmF0
aW9uOm5vbmU7Zm9udC1mYW1pbHk6SGVsdmV0aWNhLEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXpl
OjEycHQ7Ij4NCjxiPkRlOiA8L2I+JnF1b3Q7U3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
PnNndW5kYXZlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+w4A6IDwvYj4mcXVvdDtDaGFybGll
IFBlcmtpbnMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhs
aW5rLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PC9h
PiZndDssICZxdW90O01hcmNvIExpZWJzY2gmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpNYXJj
by5MaWVic2NoQG5lY2xhYi5ldSIgdGFyZ2V0PSJfYmxhbmsiPk1hcmNvLkxpZWJzY2hAbmVjbGFi
LmV1PC9hPiZndDssDQo8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+ZG1tQGlldGYub3JnPC9hPiwgJnF1b3Q7VmlqYXkgRGV2YXJhcGFsbGkmcXVvdDsgJmx0Ozxh
IGhyZWY9Im1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kdmlq
YXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkVudm95w6k6IDwvYj5KZXVkaSAxMSBT
ZXB0ZW1icmUgMjAxNCAyMzo1NzoxMTxicj4NCjxiPk9iamV0OiA8L2I+UmU6IFtETU1dIE1OSUQg
VHlwZXM8YnI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5IaSBDaGFybGllLDwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+RmV3IG1vcmUgcmV2aWV3cy9kaXNjdXNzaW9ucyBhbmQgY2Fw
dHVyaW5nIHRoZSBjb25zZW5zdXMgaW4gdGhlIGJhc2UgdmVyc2lvbiB3aWxsIGhlbHAuIEJ1dCwg
SSdtIG9rIGVpdGhlciB3YXkg4oCmPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+UmVnYXJkczwvZGl2Pg0KPGRpdj5Tcmk8L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9u
dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7DQogICAgICAgICAgICAgICAgICAgIHRl
eHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bQ0KICAgICAg
ICAgICAgICAgICAgICBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9U
VE9NOiAwaW47DQogICAgICAgICAgICAgICAgICAgIFBBRERJTkctTEVGVDogMGluOyBQQURESU5H
LVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6DQogICAgICAgICAgICAgICAgICAgICNiNWM0ZGYgMXB0
IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOw0KICAgICAgICAgICAgICAgICAgICBQ
QURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8
L3NwYW4+Q2hhcmxpZSBQZXJraW5zICZsdDs8YSBocmVmPSJtYWlsdG86Y2hhcmxlcy5wZXJraW5z
QGVhcnRobGluay5uZXQiIHRhcmdldD0iX2JsYW5rIj5jaGFybGVzLnBlcmtpbnNAZWFydGhsaW5r
Lm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv
c3Bhbj5UaHVyc2RheSwgU2VwdGVtYmVyIDExLCAyMDE0IDI6NDYgUE08YnI+DQo8c3BhbiBzdHls
ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5TcmkgR3VuZGF2ZWxsaSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNndW5kYXZlQGNp
c2NvLmNvbTwvYT4mZ3Q7LCBNYXJjbyBMaWVic2NoICZsdDs8YSBocmVmPSJtYWlsdG86TWFyY28u
TGllYnNjaEBuZWNsYWIuZXUiIHRhcmdldD0iX2JsYW5rIj5NYXJjby5MaWVic2NoQG5lY2xhYi5l
dTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+ZG1tQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86ZG1tQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPiZndDssIFZpamF5IERldmFy
YXBhbGxpICZsdDs8YSBocmVmPSJtYWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29tIiB0YXJnZXQ9
Il9ibGFuayI+ZHZpamF5QHJvY2tldG1haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i
Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbRE1NXSBNTklEIFR5cGVzPGJy
Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PGJpZz5IZWxsbyBmb2xrcyw8YnI+DQo8YnI+DQpJ
IHByb3Bvc2UgdG8gc3VibWl0IHRoZSAuLi4uLTAwLnR4dCBkb2N1bWVudCBhcyBpdCBpcyB0byB0
aGUgSW50ZXJuZXQ8YnI+DQpEcmFmdHMgZGlyZWN0b3J5LCBhbmQgdGhlbiB0byBnbyBhYm91dCBt
YWtpbmcgdXBkYXRlcyBhY2NvcmRpbmcgdG88YnI+DQp0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIGxp
c3QuJm5ic3A7IERvIHlvdSB0aGluayB0aGlzIGlzIHJlYXNvbmFibGU/PGJyPg0KPGJyPg0KUmVn
YXJkcyw8YnI+DQpDaGFybGllIFAuPGJyPg0KPGJyPg0KPC9iaWc+PC9zcGFuPjxicj4NCjxkaXYg
Y2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gOS8xMS8yMDE0IDc6MjEgQU0sIFNyaSBHdW5kYXZl
bGxpIChzZ3VuZGF2ZSkgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6
RDAzNkZCNUYuMTYzQzlEJTI1c2d1bmRhdmVAY2lzY28uY29tIj4NCjxwcmU+Jmx0O0NoYW5naW5n
IHRoZSBzdWJqZWN0IGxpbmUgdG8gcmVmbGVjdCB0aGUgTU5JZCBkaXNjdXNzaW9uJmd0Ow0KDQoN
Ck1hcmNvLA0KDQoNClRoaW5raW5nIGZ1cnRoZXIgb24gdGhlIGNvbXBsZW1lbnRhcnkgaWRlbnRp
ZmllciBvcHRpb24uDQoNCi0gVGhlcmUgaXMgYWxyZWFkeSB0aGUgbGluay1sYXllciBpZGVudGlm
aWVyIG9wdGlvbiB0aGF0IGNhbiBiZSB1c2VkIGZvcg0KY2FycnlpbmcgdGhlIE1hYyBhZGRyZXNz
DQotIElNRUkgYW5kIE1TSVNETiBhcmUgYWxyZWFkeSBkZWZpbmVkIGluIDI5LjI3NSBhcyBhIDNH
UFAgVlNFJ3MNCg0KSW4gc29tZSBzZW5zZSwgdGhlIGNvbXBsZW1lbnRhcnkgaWRlbnRpZmllcnMg
YXJlIGFscmVhZHkgcHJlc2VudC4NCg0KU3JpDQoNCg0KDQoNCg0KT24gOS8xMS8xNCA2OjU4IEFN
LCAmcXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7IDxhIGNsYXNzPSJtb3otdHh0
LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iIHRhcmdldD0i
X2JsYW5rIj4mbHQ7c2d1bmRhdmVAY2lzY28uY29tJmd0OzwvYT4gd3JvdGU6DQo8L3ByZT4NCjxi
bG9ja3F1b3RlPg0KPHByZT5JIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5IG11bHRpcGxlIE1OLUlk
IGluc3RhbmNlcyBuZWVkIHRvIGJlIHByZXNlbnQgaW4gYQ0Kc2luZ2xlIG1lc3NhZ2UgPyBJbiBt
eSBleHBlcmllbmNlLCB0aGlzIGlzIHN0cmljdGx5IGEgZGVwbG95bWVudA0KY29uc2lkZXJhdGlv
biwgd2hlbiB0byB1c2Ugd2hhdCB0eXBlIG9mIGlkZW50aWZpZXJzLg0KDQpBc3N1bWluZyB0aGUg
YmFja2VuZCBzeXN0ZW0gY2FuIHRpZSBhbGwgdGhlIE1OLUlkJ3MgdG8gYSBzaW5nbGUNCnN1YnNj
cmlwdGlvbiwgYW55IHByZXNlbnRlZCBpZGVudGlmaWVyIGNhbiBiZSBzdWZmaWNpZW50IGZvciB0
aGUgZ2F0ZXdheQ0KdG8gZG8gdGhlIEJDRSBsb29rdXAuDQoNCklmIG11bHRpcGxlIGluc3RhbmNl
cyBjYW4gYmUgcHJlc2VudCwgdGhlbiB3ZSBuZWVkIHRvIGRlYWwgd2l0aCBtb3JlIGVycm9yDQpj
YXNlcy4gSXMgdGhhdCByZWFsbHkgbmVlZGVkID8NCg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlPg0K
PHByZT5JIGFtIHdvbmRlcmluZyBpZiBpdCB3b3VsZCBub3QgYmUgbW9yZSBhcHByb3ByaWF0ZSB0
byBnbyBmb3IgYSBkaWZmZXJlbnQNCmNvbnRhaW5lciBvcHRpb24gdG8gY2Fycnkgc3VjaCBpbmZv
cm1hdGlvbi4gU29tZXRoaW5nIGxpa2UgYQ0KY29tcGxlbWVudGFyeSBpZGVudGlmaWVyIG9wdGlv
bi4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5Tb3VuZHMgaW50ZXJlc3RpbmcuIEFyZSB5
b3Ugc3VnZ2VzdGluZyB3ZSBsZWF2ZSB0aGUgY3VycmVudCBNTi1JRCBhcyBpdA0KaXMsIGJ1dCB1
c2UgYSBuZXcgY29tcGxlbWVudGFyeSBvcHRpb24gPyBCdXQsIGlmIHRoZSByZXF1aXJlbWVudCBp
cyBmb3IgYQ0KTWFjIGJhc2VkIGlkZW50aWZpZXJzLCB3aGF0IHdpbGwgYmUgdGhlcmUgaW4gdGhl
IGN1cnJlbnQgTU4tSWQgb3B0aW9uID8gV2UNCnN0aWxsIG5lZWQgdG8gaGF2ZSBpZGVudGlmaWVy
IHRoZXJlID8NCg0KDQoNCg0KU3JpDQoNCg0KDQoNCg0KT24gOS8xMS8xNCAyOjAzIEFNLCAmcXVv
dDtNYXJjbyBMaWVic2NoJnF1b3Q7IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhy
ZWY9Im1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtN
YXJjby5MaWVic2NoQG5lY2xhYi5ldSZndDs8L2E+IHdyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1
b3RlPg0KPHByZT5ObyBpc3N1ZSB3aXRoIGxvZ2ljYWwgdnMuIHBoeXNpY2FsIElELiBCdXQgSSBh
bSB3b25kZXJpbmcgYWJvdXQgdHdvDQp0aGluZ3M6DQoNCk9wZXJhdGlvbiBpcyBjbGVhciB0byBt
ZSBpbiBjYXNlIGEgc2luZ2xlIE1OSUQgaXMgcHJlc2VudCBpbiBhIG1lc3NhZ2UNCmFuZCBJIHNl
ZSB0aGUgdmFsdWUgaW4gYmVpbmcNCmZsZXhpYmxlIHRvIGNob29zZSBmcm9tIGRpZmZlcmVudCBz
dWItdHlwZXMuIElmIG11bHRpcGxlIE1OSURzIHdpdGgNCmRpZmZlcmVudCBzdWItdHlwZXMgYXJl
IHByZXNlbnQgaW4NCmEgc2luZ2xlIG1lc3NhZ2UsIHdoaWNoIG9uZSBzaG91bGQgZS5nLiB0aGUg
TE1BIHRha2UgZm9yIHRoZSBCQyBsb29rdXAuLg0KTm8gYmlnIHByb2JsZW0gdG8gc29sdmUsIGJ1
dA0KdG8gYmUgY29uc2lkZXJlZCBpbiBpbXBsZW1lbnRhdGlvbnMuDQoNCklmIHRoZSByZWFzb24g
Zm9yIG11bHRpcGxlIHByZXNlbnQgTU5JRHMgd2l0aCBkaWZmZXJlbnQgc3ViLXR5cGVzIGlzIHRv
DQpkbyBvdGhlciB0aGluZ3MgdGhhbiBpZGVudGlmeWluZw0KdGhlIG5vZGUgb3IgdXNpbmcgdGhl
IElEIGFzIGtleSBmb3IgYSBsb29rdXAsIEkgYW0gd29uZGVyaW5nIGlmIGl0IHdvdWxkDQpub3Qg
YmUgbW9yZSBhcHByb3ByaWF0ZQ0KdG8gZ28gZm9yIGEgZGlmZmVyZW50IGNvbnRhaW5lciBvcHRp
b24gdG8gY2Fycnkgc3VjaCBpbmZvcm1hdGlvbi4NClNvbWV0aGluZyBsaWtlIGEgY29tcGxlbWVu
dGFyeQ0KaWRlbnRpZmllciBvcHRpb24uDQoNCm1hcmNvDQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+
DQo8cHJlPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTcmkgR3VuZGF2ZWxsaSAo
c2d1bmRhdmUpIFs8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJtYWlsdG86
c2d1bmRhdmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnNndW5kYXZlQGNpc2Nv
LmNvbTwvYT5dDQpTZW50OiBEb25uZXJzdGFnLCAxMS4gU2VwdGVtYmVyIDIwMTQgMDA6NDINClRv
OiBDaGFybGllIFBlcmtpbnM7IE1hcmNvIExpZWJzY2g7IDxhIGNsYXNzPSJtb3otdHh0LWxpbmst
YWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5k
bW1AaWV0Zi5vcmc8L2E+DQpDYzogVmlqYXkgRGV2YXJhcGFsbGkNClN1YmplY3Q6IFJlOiBbRE1N
XSByZWdhcmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLg0KDQpIZWxsbyBDaGFybGllLA0KDQpBZ3Jl
ZSB3aXRoIHRoYXQuIE1OLUlkIGFzIGl0cyBkZWZpbmVkIHRvZGF5IGlzIGEgbG9naWNhbCBpZGVu
dGlmaWVyLiBJdA0KZG9lcyBub3QNCnJlcXVpcmUgdGhlIGlkZW50aWZpZXIgdG8gYmUgYm91bmQg
dG8gYSBwaHlzaWNhbCBkZXZpY2Ugb3IgYSBpbnRlcmZhY2UNCmlkZW50aXR5Lg0KQnV0LCB3ZSBo
YXZlIGNsZWFybHkgc2VlbiByZXF1aXJlbWVudHMgd2hlcmUgdGhlIG5lZWQgaXMgZm9yIGdlbmVy
YXRpbmcNCmlkZW50aWZpZXJzIGJhc2VkIG9uIHNvbWUgcGh5c2ljYWwgaWRlbnRpZmllcnMuIFRo
b3NlIHBoeXNpY2FsDQppZGVudGlmaWVycyBpbmNsdWRlDQpJTVNJLCBNU0lTRE4sIElNRUksIE1B
QyAuLmV0Yy4gSWYgd2UgY2FuIGRlZmluZSBhIHR5cGUgZm9yIGVhY2ggb2YgdGhlDQpzb3VyY2UN
CmFuZCB0aGUgcnVsZXMgZm9yIGdlbmVyYXRpbmcgTU4tSUQgYmFzZWQgdXNpbmcgdGhvc2Ugc291
cmNlcywgdGhlIHNlbmRlcg0KYW5kDQpyZWNlaXZlciB3aWxsIGhhdmUgY2xlYXIgZ3VpZGFuY2Ug
b24gaG93IHRvIHVzZSB0aGUgc3BlYy4gU29tZSBwb2ludGVycywNCmV4cGxhbmF0aW9uIGFuZCBl
eGFtcGxlcyBmb3IgZWFjaCBvZiB0aG9zZSBpZGVudGlmaWVycyB3aWxsIGdyZWF0bHkgaGVscA0K
YXZvaWQNCmludGVyLW9wIGlzc3Vlcy4NCg0KDQpSZWdhcmRzDQpTcmkNCg0KDQoNCg0KDQoNCg0K
T24gOS8xMC8xNCAzOjIxIFBNLCAmcXVvdDtDaGFybGllIFBlcmtpbnMmcXVvdDsgPGEgY2xhc3M9
Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0
aGxpbmsubmV0IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2NoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsu
bmV0Jmd0OzwvYT4NCndyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlPg0KPHByZT5IZWxsbyBm
b2xrcywNCg0KSSB0aGluayBpdCdzIGJlc3QgdG8gY29uc2lkZXIgdGhlIE1OSUQgYXMgc2ltcGx5
IGxpdmluZyBpbiBhIHNwYWNlIG9mDQppZGVudGlmaWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVj
aCBhYm91dCB3aGV0aGVyIGl0J3MgYSBsb2dpY2FsDQppZGVudGlmaWVyIG9yIGEgcGh5c2ljYWwg
aWRlbnRpZmllci4gIElmIHRoZSBmb3JtZXIsIHRoZW4gc29tZXdoZXJlDQoocGVyaGFwcyBiZWxv
dyB0aGUgbmV0d29yayBsYXllcikgdGhlIGxvZ2ljYWwgaWRlbnRpZmllciBoYXMgYmVlbiBib3Vu
ZA0KdG8gc29tZXRoaW5nIGluIHRoZSBwaHlzaWNhbCBpbnRlcmZhY2UsIGJ1dCB0aGF0J3Mgbm90
IG91ciBwcm9ibGVtLg0KDQpUaGUgbnVtYmVyIHNwYWNlIGZvciB0eXBlcyBvZiBNTklEcyBpcyBs
aWtlbHkgdG8gc3RheSBwcmV0dHkgZW1wdHksIHNvDQpJJ2Qgc2F5IHdlIGNvdWxkIGFkZCBhcyBt
YW55IHR5cGVzIGFzIHdvdWxkIGJlIGNvbnZlbmllbnQgZm9yIHRoZQ0Kc29mdHdhcmUgZGVzaWdu
ZXJzLiAgU28sIHdlIGNvdWxkIGNvbmNlaXZhYmx5IGhhdmUgc2V2ZXJhbCBNTklEcw0KZGVmaW5l
ZCB0aGF0IGFsbCAmcXVvdDtsb29rZWQgbGlrZSZxdW90OyBOQUlzICh3aGljaCwgdGhlbXNlbHZl
cywgJnF1b3Q7bG9vayBsaWtlJnF1b3Q7DQpGUUROcykuDQoNClJlZ2FyZHMsDQpDaGFybGllIFAu
DQoNCg0KDQpPbiA5LzEwLzIwMTQgODoxMSBBTSwgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSB3
cm90ZToNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPlllcy4gQ3VycmVudGx5LCB0aGUgTU5J
RCBpcyBpZiB0aGUgbmFpIGZvcm1hdCBhbmQgaXMgb3ZlcmxvYWRlZC4gVGhlDQpNTklEICBpbiAz
R1BQIHNwZWNzIGlzIHRoZSBJTVNJLU5BSSAoSU1TSUBSRUFMTSksIGl0cyBiYXNlZCBvbiB0aGUN
CklNU0kuIEV4Og0KJnF1b3Q7Jmx0O0lNU0kmZ3Q7QGVwYy5tbmMmbHQ7TU5DJmd0Oy5tY2MmbHQ7
TUNDJmd0Oy4zZ3BwbmV0d29yay5vcmfCsg0KDQpXZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07DQoN
CldlIGFsc28gaGF2ZSBhcHByb2FjaGVzIHRvIHRyYW5zZm9ybSBNQUMgdG8gUHNldWRvIElNU0ks
IGFuZCB0aGVuDQpjYXJyeSBJTVNJLU5BSSBhcyB0aGUgTU4tSUQuDQoNCg0KU28sIHdlIG5lZWQg
dW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBvZiB0aGUgdHlwZXMvc291cmNlcy4NCg0KTU4tSWQg
YmFzZWQgb24gSU1TSSwgTVNJU0ROLCBJTUVJLCBNQUMgLi4NCg0KQWxzbywgZG8gd2UgbmVlZCB0
byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElNU0kgYW5kIElNU0ktTkFJID8NCg0KU3JpDQoNCg0KDQpP
biA5LzEwLzE0IDY6MjkgQU0sICZxdW90O01hcmNvIExpZWJzY2gmcXVvdDsgPGEgY2xhc3M9Im1v
ei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1
IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O01hcmNvLkxpZWJzY2hAbmVjbGFiLmV1Jmd0OzwvYT4gd3Jv
dGU6DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPkl0IHNlZW1zIHRoZSBNTklEIGlzIHNv
bWVob3cgb3ZlcmxvYWRlZCB0byBjYXJyeSBib3RoLCBub2RlLXNwZWNpZmljDQpJRHMsICBlLmcu
IE1BQywgYXMgd2VsbCBhcyBzdWJzY3JpYmVyIElEcywgd2hpY2ggaXMgdGhlIElNU0kuDQpUaGVy
ZSBtYXkgYmUgdmFsdWUgaW4gYWRkaW5nIHRoZSBJTUVJIHRvIHRoZSBsaXN0IG9mIHBvc3NpYmxl
IHR5cGVzDQpvZiAgbm9kZS1zcGVjaWZpYyBJRHMuDQoNCm1hcmNvDQoNCjwvcHJlPg0KPGJsb2Nr
cXVvdGU+DQo8cHJlPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkbW0gWzxhIGNs
YXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Im1haWx0bzpkbW0tYm91bmNlc0BpZXRm
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u
IEJlaGFsZiBPZiBTcmkgR3VuZGF2ZWxsaQ0KKHNndW5kYXZlKQ0KU2VudDogRGllbnN0YWcsIDku
IFNlcHRlbWJlciAyMDE0IDIzOjMwDQpUbzogU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKTsgQ2hh
cmxpZSBQZXJraW5zOyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJt
YWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPg0KQ2M6
IFZpamF5IERldmFyYXBhbGxpDQpTdWJqZWN0OiBSZTogW0RNTV0gcmVnYXJkaW5nIHRoZSByZS1j
aGFydGVyaW5nLi4NCg0KVHdvIG1vcmUgY29tbWVudHMuDQoNCg0KDQo0LikgSSdkIGFsc28gdXNl
IHN1Yi10eXBlIHZhbHVlIG9mICgyKSBmb3IgSU1TSS4gSnVzdCB0byBhbGlnbiB3aXRoDQp0aGUg
IHN1Yi10eXBlcyAgZGVmaW5lZCBmb3IgTU4gSWQgZGVmaW5lZCBmb3IgSUNNUC4gSSBzdXNwZWN0
IHRoZXJlDQphcmUgc29tZSAgaW1wbGVtZW50YXRpb25zICBhbHJlYWR5IHVzaW5nIHN1Yi10eXBl
ICgyKS4gUGxlYXNlIHNlZQ0KdGhlIG90aGVyIHRocmVhZC4NCg0KDQo1LikgRm9yIGVhY2ggb2Yg
dGhlIHN1Yi10eXBlcywgd2UgbmVlZCB0ZXh0IGluY2x1ZGluZyBleGFtcGxlcyBhbmQNCnNvbWUN
CmV4cGxhbmF0aW9uIG9uIGhvdyB0aGV5IGFyZSB1c2VkLg0KDQoNClNyaQ0KDQoNCg0KT24gOS85
LzE0IDI6MjAgUE0sICZxdW90O1NyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkmcXVvdDsgPGEgY2xh
c3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtzZ3VuZGF2ZUBjaXNjby5jb20mZ3Q7PC9hPg0Kd3JvdGU6
DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPkhpIENoYXJsaWUsDQoNClRoaXMgaXMgZ29v
ZC4gVGhhbmtzLg0KDQoNCjEuKSBJZiBFVUktNDggYW5kIEVVSS02NCBhZGRyZXNzZXMgYXJlIGRl
cml2ZWQgb2YgYSA0OC1iaXQgSUVFRQ0KODAyLjINCmFkZHJlc3MsIHdoeSBkbyB3ZSBuZWVkIHRv
IHR3byBzdWItdHlwZXMgPyBXaHkgbm90IGhhdmUganVzdCBvbmUNCnN1Yi10eXBlIGZvciBtYWMg
YmFzZWQgaWRlbnRpZmllcnMgPw0KDQoyLikgU3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJlbnRs
eSB1c2VkLiBJdHMgY3VycmVudGx5IG92ZXJsb2FkZWQNCmZvcg0KSU1TSS1OQUkgKDNHUFAgc3Bl
Y3MpIGFuZCBnZW5lcmljIE5BSSBiYXNlZCBpZGVudGlmaWVycy4gR2l2ZW4gdGhlDQpkZWZpbml0
aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxhaW5pbmcgdGhlDQpt
b3RpdmF0aW9uDQoNCjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElQdjYg
YWRkcmVzcy4gV2hhdCBleGFjdGx5DQppcw0KdGhpcyA/IEFyZSB0aGVzZSBDR0EtYmFzZWQgSVB2
NiBhZGRyZXNzZXMgPw0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICBOZXcgTW9iaWxlIE5v
ZGUgSWRlbnRpZmllciBUeXBlcw0KDQogICAgICAgICAgICAgICAmIzQzOy0tLS0tLS0tLS0tLS0t
LS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOw0KICAgICAgICAgICAgICAgfCBJ
ZGVudGlmaWVyIFR5cGUgfCBJZGVudGlmaWVyIFR5cGUgTnVtYmVyIHwNCiAgICAgICAgICAgICAg
ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7
DQogICAgICAgICAgICAgICB8IElQdjYgQWRkcmVzcyAgICB8IDIgICAgICAgICAgICAgICAgICAg
ICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgSU1TSSAgICAgICAgICAgIHwgMyAgICAgICAgICAg
ICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBQLVRNU0kgICAgICAgICAgfCA0ICAg
ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwg
ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8IEVVSS00OCBhZGRyZXNz
ICB8IDUgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgRVVJLTY0
IGFkZHJlc3MgIHwgNiAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAg
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAg
fCBHVVRJICAgICAgICAgICAgfCA3ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg
ICAgICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYj
NDM7DQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMNClNyaQ0KUFM6IEdvb2QgdG8gc2VlIFZpamF5IGJh
Y2sNCg0KDQpPbiA5LzkvMTQgMToyOCBQTSwgJnF1b3Q7Q2hhcmxpZSBQZXJraW5zJnF1b3Q7DQo8
YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86Y2hhcmxlcy5wZXJr
aW5zQGVhcnRobGluay5uZXQiIHRhcmdldD0iX2JsYW5rIj4mbHQ7Y2hhcmxlcy5wZXJraW5zQGVh
cnRobGluay5uZXQmZ3Q7PC9hPg0Kd3JvdGU6DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJl
PkhlbGxvIGZvbGtzLA0KDQpIZXJlJ3MgdGhlIGxhc3QgSW50ZXJuZXQgRHJhZnQgdGhhdCB3ZSBk
aWQsIGxvbmcgYWdvIGV4cGlyZWQ6DQoNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQi
IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1wZXJraW5zLW1leHQt
NDI4M21uaWRzLTAxLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvYXJj
aGl2ZS9pZC9kcmFmdC1wZXJraW5zLW1leHQtNDI4M21uaWRzLTAxLnR4dDwvYT4NCg0KSSdsbCBy
ZXN1Ym1pdCBpdCB3aXRoIGEgZmV3IHVwZGF0ZXMgYXMgYSBwZXJzb25hbCBkcmFmdCB0byBkbW0u
DQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5n
IGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpk
bW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGEgY2xhc3M9Im1v
ei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RtbTwvYT48YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KZG1tIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIg
aHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwv
YT48YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQo8YSBj
bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmst
ZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1t
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k
bW08L2E+PGJyIGRhdGEtbWNlLWJvZ3VzPSIxIj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWls
aW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0
bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGEgY2xhc3M9
Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2RtbTwvYT48YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48YnI+DQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGll
dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZG1tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9kbW08L2E+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjxicj4NCjwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+LS0gPGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuPjwvc3Bhbj4N
CjxkaXY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2Pkhha2lt
YSBDaGFvdWNoaTwvZGl2Pg0KPGRpdj5Qcm9mZXNzb3I8L2Rpdj4NCjxkaXY+VGVsZWNvbSBTdWQg
UGFyaXM8L2Rpdj4NCjxkaXY+SW5zdGl0dXQgTWluZXMgVGVsZWNvbTwvZGl2Pg0KPGRpdj45IHJ1
ZSBDaGFybGVzIEZvdXJpZXI8L2Rpdj4NCjxkaXY+OTEwMTEgRXZyeTwvZGl2Pg0KPGRpdj4wMTYw
NzY0NDQzPC9kaXY+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L3NwYW4+PC9ibG9ja3F1b3RlPg0KPGJyPg0KPGJyPg0KPHByZSBjbGFzcz0ibW96
LXNpZ25hdHVyZSI+LS0gDQpSZWdhcmRzLA0KQ2hhcmxpZSBQLjwvcHJlPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvc3Bhbj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCmRtbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZG1tQGll
dGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kbW0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZG1tPC9hPjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2Pi0tIDxicj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBuYW1lPSJ4Ij48
L3NwYW4+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRp
dj5IYWtpbWEgQ2hhb3VjaGk8L2Rpdj4NCjxkaXY+UHJvZmVzc29yPC9kaXY+DQo8ZGl2PlRlbGVj
b20gU3VkIFBhcmlzPC9kaXY+DQo8ZGl2Pkluc3RpdHV0IE1pbmVzIFRlbGVjb208L2Rpdj4NCjxk
aXY+OSBydWUgQ2hhcmxlcyBGb3VyaWVyPC9kaXY+DQo8ZGl2PjkxMDExIEV2cnk8L2Rpdj4NCjxk
aXY+MDE2MDc2NDQ0MzwvZGl2Pg0KPHNwYW4gbmFtZT0ieCI+PC9zcGFuPjxicj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_D04A4C12166E7Asgundaveciscocom_--


From nobody Thu Sep 25 23:07:38 2014
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 0736C1A02D2 for ; Thu, 25 Sep 2014 23:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.286
X-Spam-Level: 
X-Spam-Status: No, score=-15.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 Y096oj8E4GVi for ; Thu, 25 Sep 2014 23:07:32 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4781A02BA for ; Thu, 25 Sep 2014 23:07:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57980; q=dns/txt; s=iport; t=1411711653; x=1412921253; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=UKF4o7wRYzOAcN52Jv1jEcr4Zfra0hCdOcDhzdY3NOw=; b=LuVZtmB26fgw4epaEMM8gOLTue8irYIwDXZ7s9MkbR2vdzdRJdV64hJD 1CLqCxuw+UwLeLrrmqb/XHgwCOZdMtl0GzIEzGE+cmLWu4IHeb23RkXpb 6m0XLtJOuKlCT8dmIQM/Wq7f75sWARIllWi41TWJtq9BZRXIG99ZrtXCS Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkUFAGIBJVStJA2L/2dsb2JhbABXCYJIRlNXBIJ9xywBCYdOAhhsFgF7hAMBAQEDAQEBARcJSwsFBwYBCBEDAQEBDhMBBgMCBCULFAkIAgQBDQUJiCEDCQgNqzmOXhuHFgEXjV4QgVUwAQgHCgcKBgECBIJygVMFhiaJIoIYi0OVVoNjbAGBR4ECAQEB
X-IronPort-AV: E=Sophos;i="5.04,603,1406592000";  d="scan'208,217";a="358316288"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 26 Sep 2014 06:07:32 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q67Utv029420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Sep 2014 06:07:31 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Fri, 26 Sep 2014 01:07:30 -0500
From: "Sri Gundavelli (sgundave)" 
To: "Charles E. Perkins" , Hakima Chaouchi , "dmm@ietf.org" 
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHP2VAnYd6GnobIVkuH1rdqN8s1gA==
Date: Fri, 26 Sep 2014 06:07:30 +0000
Message-ID: 
In-Reply-To: <5424FDAD.609@computer.org>
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.217]
Content-Type: multipart/alternative; boundary="_000_D04A4F48166EAFsgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/3Xeo7NOfVURsMcm3HGLSTxwzk9Q
Cc: Vijay Devarapalli 
Subject: Re: [DMM] MNID Types
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, 26 Sep 2014 06:07:37 -0000

--_000_D04A4F48166EAFsgundaveciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSB0aGluayB1cGRhdGluZyBSRkM0MjgzIGlzIHByb2JhYmx5IG5vdCBhbiBvcHRpb24uIFRoYXQg
d2lsbCBpbXBhY3QgbG90IG9mIGV4aXN0aW5nIHNwZWNzLg0KDQpNeSBwcmVmZXJlbmNlIGlzIGZv
ciAgZGVmaW5pbmcgZXhwbGljaXQgdHlwZSB2YWx1ZSBpbiBNTi1JRCBmb3IgZGlmZmVyZW50IFJG
SUQgdHlwZXMgYW5kIERIQ1AgRFVJRCB0eXBlczsgU3RpbGwga2VlcCB0aGUgUkZDNDI4MyBvcHRp
b24gZm9ybWF0Lg0KDQpFeDoNClN1YnR5cGUgNDogRFVJRC1MTFQNClN1YnR5cGUgNTogRFVJRC1V
VUlEDQpTdWJ0eXBlIDY6IFJGSUQtR0xOLTY2IOKApg0KDQrigKYNCg0KDQpSZWdhcmRzDQpTcmkN
Cg0KDQoNCkZyb206ICJDaGFybGVzIEUuIFBlcmtpbnMiIDxjaGFybGllcEBjb21wdXRlci5vcmc8
bWFpbHRvOmNoYXJsaWVwQGNvbXB1dGVyLm9yZz4+DQpPcmdhbml6YXRpb246IEJsdWUgU2tpZXMN
CkRhdGU6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQgMTA6NDYgUE0NClRvOiBIYWtpbWEg
Q2hhb3VjaGkgPGhha2ltYS5jaGFvdWNoaUB0ZWxlY29tLXN1ZHBhcmlzLmV1PG1haWx0bzpoYWtp
bWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJpcy5ldT4+LCAiZG1tQGlldGYub3JnPG1haWx0bzpk
bW1AaWV0Zi5vcmc+IiA8ZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+Pg0KQ2M6IFZp
amF5IERldmFyYXBhbGxpIDxkdmlqYXlAcm9ja2V0bWFpbC5jb208bWFpbHRvOmR2aWpheUByb2Nr
ZXRtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0KDQoNCkhlbGxvIGZv
bGtzLA0KDQpOb3cgd2UgaGF2ZSB0d28ga2luZHMgb2YgaWRlbnRpZmllcnMgdGhhdCBjb3VsZCBy
ZWFzb25hYmx5IGJlDQpncm91cGVkIGFzIGEgdHlwZSBwbHVzIHN1YnR5cGVzLiAgSSBjb3VsZCBz
cGVjaWZ5IHRoaXMgYnkgd3JpdGluZw0KYW5vdGhlciBzZWN0aW9uIG9mIHRoZSBuZXcgZHJhZnQg
dGhhdCBsYXlzIG91dCBhbm90aGVyIHN1YnR5cGUNCmZpZWxkIGFmdGVyIHRoZSBNTklEIHN1YnR5
cGUgZmllbGQgZnJvbSA0MjgzLiAgSSBndWVzcyBpdCB3b3VsZA0KYmUgYSAic3Vic3VidHlwZSIg
ZmllbGQgaWYgd2UgYXJlIGZvbGxvd2luZyB0aGUgbm9tZW5jbGF0dXJlIGZvcg0KdGhlIGZpZWxk
cyBhcyBzaG93biBpbiBSRkMgNDI4My4NCg0KT3IsIGFsdGVybmF0aXZlbHksIEkgY291bGQgc3Bl
Y2lmeSB0aGF0IGZvciBzb21lIHR5cGVzIChlLmcuLCBEVUlEDQphbmQgUkZJRCksIHRoZSBmaXJz
dCBlaWdodCBiaXRzIG9mIHRoZSBpZGVudGlmaWVyIGlzIHRoZSBhIGZpZWxkIHRoYXQNCndlIG1p
Z2h0IGNhbGwgdGhlICJpZGVudGlmaWVyIHN1YnR5cGUiLiAgTWF5YmUgdGhhdCBpcyBjbGVhbmVy
Lg0KDQpBIHRoaXJkIG9wdGlvbiB3b3VsZCBiZSB0byB1cGRhdGUgUkZDIDQyODMsIGJ1dCB0aGF0
IHNlZW1zIHRvDQpiZSBhIGJpdCBoZWF2eS1oYW5kZWQuDQoNCkNvbW1lbnRzPyAgT3Igb3RoZXIg
b3B0aW9ucz8NCg0KUmVnYXJkcywNCkNoYXJsaWUgUC4NCg0KDQpPbiA5LzI1LzIwMTQgOTozMSBQ
TSwgSGFraW1hIENoYW91Y2hpIHdyb3RlOg0KSGksDQoNCkZvciBSRklEIHdlIHJlZmVyIHRvIHRo
ZSBFUEMgc3RhbmRhcmRzLg0KDQoiVGhlIEVsZWN0cm9uaWMgUHJvZHVjdCBDb2RlIChFUEMpIGlz
IGFuIGlkZW50aWZpY2F0aW9uIHNjaGVtZSBmb3IgdW5pdmVyc2FsbHkgaWRlbnRpZnlpbmcgcGh5
c2ljYWwgb2JqZWN0cyBieSB1c2luZyBSYWRpbyBGcmVxdWVuY3kgSWRlbnRpZmljYXRpb24gKFJG
SUQpIHRhZ3MuDQpUaGUgc3RhbmRhcmRpemVkIEVQQyB0YWcgZW5jb2RpbmcgY29uc2lzdHMgb2Yg
YW4gRVBDIElkZW50aWZpZXIgdGhhdCB1bmlxdWVseSBpZGVudGlmaWVzIGFuIGluZGl2aWR1YWwg
b2JqZWN0LCBhbmQgbWF5IGFsc28gaW5jbHVkZSBhIGZpbHRlciB2YWx1ZSBpZiB0aGUgZmlsdGVy
IGlzIG5lZWRlZCB0byBlbmFibGUgZWZmZWN0aXZlIGFuZCBlZmZpY2llbnQgcmVhZGluZyBvZiB0
aGUgRVBDIHRhZ3MuIFRoZSBFUEMgSWRlbnRpZmllciBpcyBhIG1ldGEtY29kaW5nIHNjaGVtZSBk
ZXNpZ25lZCB0byBzdXBwb3J0IHRoZSBuZWVkcyBvZiB2YXJpb3VzIGluZHVzdHJpZXMgYnkgYWNj
b21tb2RhdGluZyBleGlzdGluZyBjb2Rpbmcgc2NoZW1lcyB3aGVyZSBwb3NzaWJsZSBhbmQgYnkg
ZGVmaW5pbmcgbmV3IHNjaGVtZXMgd2hlcmUgbmVjZXNzYXJ5LiINCg0KIkVQQyBzdXBwb3J0cyBz
ZXZlcmFsIGVuY29kaW5nIHN5c3RlbXMgb3Igc2NoZW1lcyBpbmNsdWRpbmcgR0lEIChHbG9iYWwg
SWRlbnRpZmllciksIFNHVElOIChTZXJpYWxpemVkIEdsb2JhbCBUcmFkZSBJdGVtIE51bWJlciks
IFNTQ0MgKFNlcmlhbCBTaGlwcGluZyBDb250YWluZXIpLCBHTE4gKEdsb2JhbCBMb2NhdGlvbiBO
dW1iZXIpLCBHUkFJIChHbG9iYWwgUmV0dXJuYWJsZSBBc3NldCBJZGVudGlmaWVyKSwgRE9EIChE
ZXBhcnRtZW50IG9mIERlZmVuc2UpIGFuZCBHSUFJIChHbG9iYWwgSW5kaXZpZHVhbCBBc3NldCBJ
ZGVudGlmaWVyKS4NCg0KRm9yIGVhY2ggc2NoZW1lIGV4Y2VwdCBHSUQsIHRoZXJlIGFyZSB0d28g
dmFyaWF0aW9uc+KAlGEgNjQtYml0IHNjaGVtZSAoZm9yIGV4YW1wbGUsIEdMTi02NCkgYW5kIGEg
OTYtYml0IHNjaGVtZSAoR0xOLTk2KS4gR0lEIGhhcyBvbmx5IGEgOTYtYml0IHNjaGVtZS4NCg0K
V2l0aGluIGVhY2ggc2NoZW1lLCBhbiBFUEMgaWRlbnRpZmllciBjYW4gYmUgcmVwcmVzZW50ZWQg
aW4gYSBiaW5hcnkgZm9ybSBvciBvdGhlciBmb3JtcyBzdWNoIGFzIFVSSSAuLmV0YyIuDQoNCk1h
eSBiZSB3ZSBuZWVkIHNvbWUgc3VidHlwaW5nLg0KDQpDaGVlcnMsDQoNCkhha2ltYQ0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZTogIlNyaSBHdW5kYXZlbGxpIChzZ3Vu
ZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb20+PG1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20+DQrD
gDogIkNoYXJsZXMgRS4gUGVya2lucyIgPGNoYXJsaWVwQGNvbXB1dGVyLm9yZz48bWFpbHRvOmNo
YXJsaWVwQGNvbXB1dGVyLm9yZz4NCkNjOiAiVmlqYXkgRGV2YXJhcGFsbGkiIDxkdmlqYXlAcm9j
a2V0bWFpbC5jb20+PG1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20+LCBkbW1AaWV0Zi5vcmc8
bWFpbHRvOmRtbUBpZXRmLm9yZz4NCkVudm95w6k6IFZlbmRyZWRpIDI2IFNlcHRlbWJyZSAyMDE0
IDAzOjM2OjAxDQpPYmpldDogUmU6IFtETU1dIE1OSUQgVHlwZXMNCg0KSGkgQ2hhcmxpZSwNCg0K
PiBJcyB0aGUgRG9ELTk2IGlkZW50aWZpZXIgZm9yIGEgc3BlY2lhbCBraW5kIG9mIFJGSUQsIG9y
IGlzIGl0IHZhbGlkIGZvciBhbGwgdGhlIFJGSUQgZGV2aWNlcyB0aGF0IHdvdWxkIGJlIG9mIGlu
dGVyZXN0Pw0KDQpJIGRvIG5vdCBrbm93IHRoZSBhbnN3ZXIgZm9yIHRoaXMgcXVlc3Rpb24uIEkg
YXNzdW1lZCBET0QtOTYgaXMgYSBtYW5kYXRlZCBzdGFuZGFyZCBmb3IgUkZJRCBlbmNvZGluZywg
YnV0IGxvb2tzIGxpa2UgdGhlcmUgYXJlIG90aGVyIGZvcm1hdHMgbGlrZSBHSUQtOTYgLi5ldGMu
IE1heSBiZSB0aGlzIG1heSBlbmQgdXAgbmVlZGluZyBzdWJ0eXBlcy4gV2UgY2FuIGRlZmVyIHRo
aXMgcXVlc3Rpb24gdG8gSGFraW1hIGFuZCBsZWFybiBzb21lIGRldGFpbHMgb24gdGhpcywgc2hl
IHNlZW1zIHRvIGhhdmUgd3JpdHRlbiBtYW55IGJvb2tzIG9uIFJGSUQuDQoNCg0KUmVnYXJkcw0K
U3JpDQoNCg0KDQpGcm9tOiAiQ2hhcmxlcyBFLiBQZXJraW5zIiA8Y2hhcmxpZXBAY29tcHV0ZXIu
b3JnPG1haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmc+Pg0KT3JnYW5pemF0aW9uOiBCbHVlIFNr
aWVzDQpEYXRlOiBUaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0IDE6NDIgUE0NClRvOiBTcmkg
R3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPG1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20+
Pg0KQ2M6ICJkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4iIDxkbW1AaWV0Zi5vcmc8
bWFpbHRvOmRtbUBpZXRmLm9yZz4+LCBWaWpheSBEZXZhcmFwYWxsaSA8ZHZpamF5QHJvY2tldG1h
aWwuY29tPG1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IFtETU1d
IE1OSUQgVHlwZXMNCg0KDQpIZWxsbyBTcmksDQoNCklzIHRoZSBEb0QtOTYgaWRlbnRpZmllciBm
b3IgYSBzcGVjaWFsIGtpbmQgb2YgUkZJRCwgb3IgaXMgaXQNCnZhbGlkIGZvciBhbGwgdGhlIFJG
SUQgZGV2aWNlcyB0aGF0IHdvdWxkIGJlIG9mIGludGVyZXN0Pw0KDQpSZWdhcmRzLA0KQ2hhcmxp
ZSBQLg0KDQoNCk9uIDkvMjEvMjAxNCA5OjU5IEFNLCBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUp
IHdyb3RlOg0KSGkgSGFraW1hLA0KDQpUaGF0IGlzIGEgZ29vZCBpZGVhLiBXZSBzaG91bGQgcmVn
aXN0ZXIgYSB0eXBlIGZvciB0aGUgRG9kLTk2IGlkZW50aWZpZXIgYXMgd2VsbC4NCg0KDQpSZWdh
cmRzDQpTcmkNCg0KDQpGcm9tOiBIYWtpbWEgQ2hhb3VjaGkgPGhha2ltYS5jaGFvdWNoaUB0ZWxl
Y29tLXN1ZHBhcmlzLmV1PG1haWx0bzpoYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJpcy5l
dT4+DQpEYXRlOiBTdW5kYXksIFNlcHRlbWJlciAyMSwgMjAxNCA4OjExIEFNDQpUbzogU3JpIEd1
bmRhdmVsbGkgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4N
CkNjOiBDaGFybGllIFBlcmtpbnMgPGNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PG1haWx0
bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD4+LCBNYXJjbyBMaWVic2NoIDxNYXJjby5M
aWVic2NoQG5lY2xhYi5ldTxtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PiwgImRtbUBp
ZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiIgPGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGll
dGYub3JnPj4sIFZpamF5IERldmFyYXBhbGxpIDxkdmlqYXlAcm9ja2V0bWFpbC5jb208bWFpbHRv
OmR2aWpheUByb2NrZXRtYWlsLmNvbT4+DQpTdWJqZWN0OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0K
DQpIZWxsbyBGb2xrcywNCg0KRG8geW91IHRoaW5rIHRoYXQgY29uc2lkZXJpbmcgc3BlY2lmaWMg
YnV0IG5lZWRlZCB0ZWNobm9sb2dpZXMgZm9yIG1vdmluZyBvYmplY3RzIGluICBJbnRlcm5ldCBv
ZiBUaGluZ3MgIHN1Y2ggYXMgUkZJRCAoUmFkaW8gRnJlcXVlbmN5IElkZW50aWZpZXIpIHdpdGgg
OTYgYml0cyBpZGVudGlmaWVycyB3aWxsIGJlIGFsc28gcmVsZXZlbnQgdG8gQ2hhcmxpZSdzIGN1
cnJlbnQgZHJhZnQgYW5kIHRoZSBlZmZvcnRzIHJlbGF0ZWQgdG8gTU5JRD8NCg0KUmVnYXJkcywN
Cg0KSGFraW1hDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRlOiAiU3Jp
IEd1bmRhdmVsbGkgKHNndW5kYXZlKSIgPHNndW5kYXZlQGNpc2NvLmNvbTxtYWlsdG86c2d1bmRh
dmVAY2lzY28uY29tPj4NCsOAOiAiQ2hhcmxpZSBQZXJraW5zIiA8Y2hhcmxlcy5wZXJraW5zQGVh
cnRobGluay5uZXQ8bWFpbHRvOmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0Pj4sICJNYXJj
byBMaWVic2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8bWFpbHRvOk1hcmNvLkxpZWJzY2hA
bmVjbGFiLmV1Pj4sIGRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPiwgIlZpamF5IERl
dmFyYXBhbGxpIiA8ZHZpamF5QHJvY2tldG1haWwuY29tPG1haWx0bzpkdmlqYXlAcm9ja2V0bWFp
bC5jb20+Pg0KRW52b3nDqTogSmV1ZGkgMTEgU2VwdGVtYnJlIDIwMTQgMjM6NTc6MTENCk9iamV0
OiBSZTogW0RNTV0gTU5JRCBUeXBlcw0KDQpIaSBDaGFybGllLA0KDQpGZXcgbW9yZSByZXZpZXdz
L2Rpc2N1c3Npb25zIGFuZCBjYXB0dXJpbmcgdGhlIGNvbnNlbnN1cyBpbiB0aGUgYmFzZSB2ZXJz
aW9uIHdpbGwgaGVscC4gQnV0LCBJJ20gb2sgZWl0aGVyIHdheSDigKYNCg0KDQpSZWdhcmRzDQpT
cmkNCg0KRnJvbTogQ2hhcmxpZSBQZXJraW5zIDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5l
dDxtYWlsdG86Y2hhcmxlcy5wZXJraW5zQGVhcnRobGluay5uZXQ+Pg0KRGF0ZTogVGh1cnNkYXks
IFNlcHRlbWJlciAxMSwgMjAxNCAyOjQ2IFBNDQpUbzogU3JpIEd1bmRhdmVsbGkgPHNndW5kYXZl
QGNpc2NvLmNvbTxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPj4sIE1hcmNvIExpZWJzY2ggPE1h
cmNvLkxpZWJzY2hAbmVjbGFiLmV1PG1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xhYi5ldT4+LCAi
ZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+IiA8ZG1tQGlldGYub3JnPG1haWx0bzpk
bW1AaWV0Zi5vcmc+PiwgVmlqYXkgRGV2YXJhcGFsbGkgPGR2aWpheUByb2NrZXRtYWlsLmNvbTxt
YWlsdG86ZHZpamF5QHJvY2tldG1haWwuY29tPj4NClN1YmplY3Q6IFJlOiBbRE1NXSBNTklEIFR5
cGVzDQoNCg0KSGVsbG8gZm9sa3MsDQoNCkkgcHJvcG9zZSB0byBzdWJtaXQgdGhlIC4uLi4tMDAu
dHh0IGRvY3VtZW50IGFzIGl0IGlzIHRvIHRoZSBJbnRlcm5ldA0KRHJhZnRzIGRpcmVjdG9yeSwg
YW5kIHRoZW4gdG8gZ28gYWJvdXQgbWFraW5nIHVwZGF0ZXMgYWNjb3JkaW5nIHRvDQp0aGUgZGlz
Y3Vzc2lvbiBvbiB0aGlzIGxpc3QuICBEbyB5b3UgdGhpbmsgdGhpcyBpcyByZWFzb25hYmxlPw0K
DQpSZWdhcmRzLA0KQ2hhcmxpZSBQLg0KDQoNCk9uIDkvMTEvMjAxNCA3OjIxIEFNLCBTcmkgR3Vu
ZGF2ZWxsaSAoc2d1bmRhdmUpIHdyb3RlOg0KDQo8Q2hhbmdpbmcgdGhlIHN1YmplY3QgbGluZSB0
byByZWZsZWN0IHRoZSBNTklkIGRpc2N1c3Npb24+DQoNCg0KTWFyY28sDQoNCg0KVGhpbmtpbmcg
ZnVydGhlciBvbiB0aGUgY29tcGxlbWVudGFyeSBpZGVudGlmaWVyIG9wdGlvbi4NCg0KLSBUaGVy
ZSBpcyBhbHJlYWR5IHRoZSBsaW5rLWxheWVyIGlkZW50aWZpZXIgb3B0aW9uIHRoYXQgY2FuIGJl
IHVzZWQgZm9yDQpjYXJyeWluZyB0aGUgTWFjIGFkZHJlc3MNCi0gSU1FSSBhbmQgTVNJU0ROIGFy
ZSBhbHJlYWR5IGRlZmluZWQgaW4gMjkuMjc1IGFzIGEgM0dQUCBWU0Uncw0KDQpJbiBzb21lIHNl
bnNlLCB0aGUgY29tcGxlbWVudGFyeSBpZGVudGlmaWVycyBhcmUgYWxyZWFkeSBwcmVzZW50Lg0K
DQpTcmkNCg0KDQoNCg0KDQpPbiA5LzExLzE0IDY6NTggQU0sICJTcmkgR3VuZGF2ZWxsaSAoc2d1
bmRhdmUpIiA8c2d1bmRhdmVAY2lzY28uY29tPjxtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tPiB3
cm90ZToNCg0KDQpJIGRvIG5vdCBzZWUgYSByZWFzb24gd2h5IG11bHRpcGxlIE1OLUlkIGluc3Rh
bmNlcyBuZWVkIHRvIGJlIHByZXNlbnQgaW4gYQ0Kc2luZ2xlIG1lc3NhZ2UgPyBJbiBteSBleHBl
cmllbmNlLCB0aGlzIGlzIHN0cmljdGx5IGEgZGVwbG95bWVudA0KY29uc2lkZXJhdGlvbiwgd2hl
biB0byB1c2Ugd2hhdCB0eXBlIG9mIGlkZW50aWZpZXJzLg0KDQpBc3N1bWluZyB0aGUgYmFja2Vu
ZCBzeXN0ZW0gY2FuIHRpZSBhbGwgdGhlIE1OLUlkJ3MgdG8gYSBzaW5nbGUNCnN1YnNjcmlwdGlv
biwgYW55IHByZXNlbnRlZCBpZGVudGlmaWVyIGNhbiBiZSBzdWZmaWNpZW50IGZvciB0aGUgZ2F0
ZXdheQ0KdG8gZG8gdGhlIEJDRSBsb29rdXAuDQoNCklmIG11bHRpcGxlIGluc3RhbmNlcyBjYW4g
YmUgcHJlc2VudCwgdGhlbiB3ZSBuZWVkIHRvIGRlYWwgd2l0aCBtb3JlIGVycm9yDQpjYXNlcy4g
SXMgdGhhdCByZWFsbHkgbmVlZGVkID8NCg0KDQoNCg0KSSBhbSB3b25kZXJpbmcgaWYgaXQgd291
bGQgbm90IGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gZ28gZm9yIGEgZGlmZmVyZW50DQpjb250YWlu
ZXIgb3B0aW9uIHRvIGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24uIFNvbWV0aGluZyBsaWtlIGENCmNv
bXBsZW1lbnRhcnkgaWRlbnRpZmllciBvcHRpb24uDQoNCg0KU291bmRzIGludGVyZXN0aW5nLiBB
cmUgeW91IHN1Z2dlc3Rpbmcgd2UgbGVhdmUgdGhlIGN1cnJlbnQgTU4tSUQgYXMgaXQNCmlzLCBi
dXQgdXNlIGEgbmV3IGNvbXBsZW1lbnRhcnkgb3B0aW9uID8gQnV0LCBpZiB0aGUgcmVxdWlyZW1l
bnQgaXMgZm9yIGENCk1hYyBiYXNlZCBpZGVudGlmaWVycywgd2hhdCB3aWxsIGJlIHRoZXJlIGlu
IHRoZSBjdXJyZW50IE1OLUlkIG9wdGlvbiA/IFdlDQpzdGlsbCBuZWVkIHRvIGhhdmUgaWRlbnRp
ZmllciB0aGVyZSA/DQoNCg0KDQoNClNyaQ0KDQoNCg0KDQoNCk9uIDkvMTEvMTQgMjowMyBBTSwg
Ik1hcmNvIExpZWJzY2giIDxNYXJjby5MaWVic2NoQG5lY2xhYi5ldT48bWFpbHRvOk1hcmNvLkxp
ZWJzY2hAbmVjbGFiLmV1PiB3cm90ZToNCg0KDQoNCk5vIGlzc3VlIHdpdGggbG9naWNhbCB2cy4g
cGh5c2ljYWwgSUQuIEJ1dCBJIGFtIHdvbmRlcmluZyBhYm91dCB0d28NCnRoaW5nczoNCg0KT3Bl
cmF0aW9uIGlzIGNsZWFyIHRvIG1lIGluIGNhc2UgYSBzaW5nbGUgTU5JRCBpcyBwcmVzZW50IGlu
IGEgbWVzc2FnZQ0KYW5kIEkgc2VlIHRoZSB2YWx1ZSBpbiBiZWluZw0KZmxleGlibGUgdG8gY2hv
b3NlIGZyb20gZGlmZmVyZW50IHN1Yi10eXBlcy4gSWYgbXVsdGlwbGUgTU5JRHMgd2l0aA0KZGlm
ZmVyZW50IHN1Yi10eXBlcyBhcmUgcHJlc2VudCBpbg0KYSBzaW5nbGUgbWVzc2FnZSwgd2hpY2gg
b25lIHNob3VsZCBlLmcuIHRoZSBMTUEgdGFrZSBmb3IgdGhlIEJDIGxvb2t1cC4uDQpObyBiaWcg
cHJvYmxlbSB0byBzb2x2ZSwgYnV0DQp0byBiZSBjb25zaWRlcmVkIGluIGltcGxlbWVudGF0aW9u
cy4NCg0KSWYgdGhlIHJlYXNvbiBmb3IgbXVsdGlwbGUgcHJlc2VudCBNTklEcyB3aXRoIGRpZmZl
cmVudCBzdWItdHlwZXMgaXMgdG8NCmRvIG90aGVyIHRoaW5ncyB0aGFuIGlkZW50aWZ5aW5nDQp0
aGUgbm9kZSBvciB1c2luZyB0aGUgSUQgYXMga2V5IGZvciBhIGxvb2t1cCwgSSBhbSB3b25kZXJp
bmcgaWYgaXQgd291bGQNCm5vdCBiZSBtb3JlIGFwcHJvcHJpYXRlDQp0byBnbyBmb3IgYSBkaWZm
ZXJlbnQgY29udGFpbmVyIG9wdGlvbiB0byBjYXJyeSBzdWNoIGluZm9ybWF0aW9uLg0KU29tZXRo
aW5nIGxpa2UgYSBjb21wbGVtZW50YXJ5DQppZGVudGlmaWVyIG9wdGlvbi4NCg0KbWFyY28NCg0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTcmkgR3VuZGF2ZWxsaSAoc2d1
bmRhdmUpIFttYWlsdG86c2d1bmRhdmVAY2lzY28uY29tXQ0KU2VudDogRG9ubmVyc3RhZywgMTEu
IFNlcHRlbWJlciAyMDE0IDAwOjQyDQpUbzogQ2hhcmxpZSBQZXJraW5zOyBNYXJjbyBMaWVic2No
OyBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NCkNjOiBWaWpheSBEZXZhcmFwYWxs
aQ0KU3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hhcnRlcmluZy4uDQoNCkhl
bGxvIENoYXJsaWUsDQoNCkFncmVlIHdpdGggdGhhdC4gTU4tSWQgYXMgaXRzIGRlZmluZWQgdG9k
YXkgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIuIEl0DQpkb2VzIG5vdA0KcmVxdWlyZSB0aGUgaWRl
bnRpZmllciB0byBiZSBib3VuZCB0byBhIHBoeXNpY2FsIGRldmljZSBvciBhIGludGVyZmFjZQ0K
aWRlbnRpdHkuDQpCdXQsIHdlIGhhdmUgY2xlYXJseSBzZWVuIHJlcXVpcmVtZW50cyB3aGVyZSB0
aGUgbmVlZCBpcyBmb3IgZ2VuZXJhdGluZw0KaWRlbnRpZmllcnMgYmFzZWQgb24gc29tZSBwaHlz
aWNhbCBpZGVudGlmaWVycy4gVGhvc2UgcGh5c2ljYWwNCmlkZW50aWZpZXJzIGluY2x1ZGUNCklN
U0ksIE1TSVNETiwgSU1FSSwgTUFDIC4uZXRjLiBJZiB3ZSBjYW4gZGVmaW5lIGEgdHlwZSBmb3Ig
ZWFjaCBvZiB0aGUNCnNvdXJjZQ0KYW5kIHRoZSBydWxlcyBmb3IgZ2VuZXJhdGluZyBNTi1JRCBi
YXNlZCB1c2luZyB0aG9zZSBzb3VyY2VzLCB0aGUgc2VuZGVyDQphbmQNCnJlY2VpdmVyIHdpbGwg
aGF2ZSBjbGVhciBndWlkYW5jZSBvbiBob3cgdG8gdXNlIHRoZSBzcGVjLiBTb21lIHBvaW50ZXJz
LA0KZXhwbGFuYXRpb24gYW5kIGV4YW1wbGVzIGZvciBlYWNoIG9mIHRob3NlIGlkZW50aWZpZXJz
IHdpbGwgZ3JlYXRseSBoZWxwDQphdm9pZA0KaW50ZXItb3AgaXNzdWVzLg0KDQoNClJlZ2FyZHMN
ClNyaQ0KDQoNCg0KDQoNCg0KDQpPbiA5LzEwLzE0IDM6MjEgUE0sICJDaGFybGllIFBlcmtpbnMi
IDxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD48bWFpbHRvOmNoYXJsZXMucGVya2luc0Bl
YXJ0aGxpbmsubmV0Pg0Kd3JvdGU6DQoNCg0KDQpIZWxsbyBmb2xrcywNCg0KSSB0aGluayBpdCdz
IGJlc3QgdG8gY29uc2lkZXIgdGhlIE1OSUQgYXMgc2ltcGx5IGxpdmluZyBpbiBhIHNwYWNlIG9m
DQppZGVudGlmaWVycywgYW5kIG5vdCB3b3JyeSB0b28gbXVjaCBhYm91dCB3aGV0aGVyIGl0J3Mg
YSBsb2dpY2FsDQppZGVudGlmaWVyIG9yIGEgcGh5c2ljYWwgaWRlbnRpZmllci4gIElmIHRoZSBm
b3JtZXIsIHRoZW4gc29tZXdoZXJlDQoocGVyaGFwcyBiZWxvdyB0aGUgbmV0d29yayBsYXllcikg
dGhlIGxvZ2ljYWwgaWRlbnRpZmllciBoYXMgYmVlbiBib3VuZA0KdG8gc29tZXRoaW5nIGluIHRo
ZSBwaHlzaWNhbCBpbnRlcmZhY2UsIGJ1dCB0aGF0J3Mgbm90IG91ciBwcm9ibGVtLg0KDQpUaGUg
bnVtYmVyIHNwYWNlIGZvciB0eXBlcyBvZiBNTklEcyBpcyBsaWtlbHkgdG8gc3RheSBwcmV0dHkg
ZW1wdHksIHNvDQpJJ2Qgc2F5IHdlIGNvdWxkIGFkZCBhcyBtYW55IHR5cGVzIGFzIHdvdWxkIGJl
IGNvbnZlbmllbnQgZm9yIHRoZQ0Kc29mdHdhcmUgZGVzaWduZXJzLiAgU28sIHdlIGNvdWxkIGNv
bmNlaXZhYmx5IGhhdmUgc2V2ZXJhbCBNTklEcw0KZGVmaW5lZCB0aGF0IGFsbCAibG9va2VkIGxp
a2UiIE5BSXMgKHdoaWNoLCB0aGVtc2VsdmVzLCAibG9vayBsaWtlIg0KRlFETnMpLg0KDQpSZWdh
cmRzLA0KQ2hhcmxpZSBQLg0KDQoNCg0KT24gOS8xMC8yMDE0IDg6MTEgQU0sIFNyaSBHdW5kYXZl
bGxpIChzZ3VuZGF2ZSkgd3JvdGU6DQoNCg0KWWVzLiBDdXJyZW50bHksIHRoZSBNTklEIGlzIGlm
IHRoZSBuYWkgZm9ybWF0IGFuZCBpcyBvdmVybG9hZGVkLiBUaGUNCk1OSUQgIGluIDNHUFAgc3Bl
Y3MgaXMgdGhlIElNU0ktTkFJIChJTVNJQFJFQUxNKSwgaXRzIGJhc2VkIG9uIHRoZQ0KSU1TSS4g
RXg6DQoiPElNU0k+QGVwYy5tbmM8TU5DPi5tY2M8TUNDPi4zZ3BwbmV0d29yay5vcmfCsg0KDQpX
ZSBhbHNvIGhhdmUgTUFDNDhAUkVBTE07DQoNCldlIGFsc28gaGF2ZSBhcHByb2FjaGVzIHRvIHRy
YW5zZm9ybSBNQUMgdG8gUHNldWRvIElNU0ksIGFuZCB0aGVuDQpjYXJyeSBJTVNJLU5BSSBhcyB0
aGUgTU4tSUQuDQoNCg0KU28sIHdlIG5lZWQgdW5pcXVlIHN1Yi10eXBlcyBmb3IgZWFjaCBvZiB0
aGUgdHlwZXMvc291cmNlcy4NCg0KTU4tSWQgYmFzZWQgb24gSU1TSSwgTVNJU0ROLCBJTUVJLCBN
QUMgLi4NCg0KQWxzbywgZG8gd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIElNU0kgYW5k
IElNU0ktTkFJID8NCg0KU3JpDQoNCg0KDQpPbiA5LzEwLzE0IDY6MjkgQU0sICJNYXJjbyBMaWVi
c2NoIiA8TWFyY28uTGllYnNjaEBuZWNsYWIuZXU+PG1haWx0bzpNYXJjby5MaWVic2NoQG5lY2xh
Yi5ldT4gd3JvdGU6DQoNCg0KDQpJdCBzZWVtcyB0aGUgTU5JRCBpcyBzb21laG93IG92ZXJsb2Fk
ZWQgdG8gY2FycnkgYm90aCwgbm9kZS1zcGVjaWZpYw0KSURzLCAgZS5nLiBNQUMsIGFzIHdlbGwg
YXMgc3Vic2NyaWJlciBJRHMsIHdoaWNoIGlzIHRoZSBJTVNJLg0KVGhlcmUgbWF5IGJlIHZhbHVl
IGluIGFkZGluZyB0aGUgSU1FSSB0byB0aGUgbGlzdCBvZiBwb3NzaWJsZSB0eXBlcw0Kb2YgIG5v
ZGUtc3BlY2lmaWMgSURzLg0KDQptYXJjbw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
U3JpIEd1bmRhdmVsbGkNCihzZ3VuZGF2ZSkNClNlbnQ6IERpZW5zdGFnLCA5LiBTZXB0ZW1iZXIg
MjAxNCAyMzozMA0KVG86IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSk7IENoYXJsaWUgUGVya2lu
czsgZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpDYzogVmlqYXkgRGV2YXJhcGFs
bGkNClN1YmplY3Q6IFJlOiBbRE1NXSByZWdhcmRpbmcgdGhlIHJlLWNoYXJ0ZXJpbmcuLg0KDQpU
d28gbW9yZSBjb21tZW50cy4NCg0KDQoNCjQuKSBJJ2QgYWxzbyB1c2Ugc3ViLXR5cGUgdmFsdWUg
b2YgKDIpIGZvciBJTVNJLiBKdXN0IHRvIGFsaWduIHdpdGgNCnRoZSAgc3ViLXR5cGVzICBkZWZp
bmVkIGZvciBNTiBJZCBkZWZpbmVkIGZvciBJQ01QLiBJIHN1c3BlY3QgdGhlcmUNCmFyZSBzb21l
ICBpbXBsZW1lbnRhdGlvbnMgIGFscmVhZHkgdXNpbmcgc3ViLXR5cGUgKDIpLiBQbGVhc2Ugc2Vl
DQp0aGUgb3RoZXIgdGhyZWFkLg0KDQoNCjUuKSBGb3IgZWFjaCBvZiB0aGUgc3ViLXR5cGVzLCB3
ZSBuZWVkIHRleHQgaW5jbHVkaW5nIGV4YW1wbGVzIGFuZA0Kc29tZQ0KZXhwbGFuYXRpb24gb24g
aG93IHRoZXkgYXJlIHVzZWQuDQoNCg0KU3JpDQoNCg0KDQpPbiA5LzkvMTQgMjoyMCBQTSwgIlNy
aSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb20+PG1haWx0bzpzZ3Vu
ZGF2ZUBjaXNjby5jb20+DQp3cm90ZToNCg0KDQoNCkhpIENoYXJsaWUsDQoNClRoaXMgaXMgZ29v
ZC4gVGhhbmtzLg0KDQoNCjEuKSBJZiBFVUktNDggYW5kIEVVSS02NCBhZGRyZXNzZXMgYXJlIGRl
cml2ZWQgb2YgYSA0OC1iaXQgSUVFRQ0KODAyLjINCmFkZHJlc3MsIHdoeSBkbyB3ZSBuZWVkIHRv
IHR3byBzdWItdHlwZXMgPyBXaHkgbm90IGhhdmUganVzdCBvbmUNCnN1Yi10eXBlIGZvciBtYWMg
YmFzZWQgaWRlbnRpZmllcnMgPw0KDQoyLikgU3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJlbnRs
eSB1c2VkLiBJdHMgY3VycmVudGx5IG92ZXJsb2FkZWQNCmZvcg0KSU1TSS1OQUkgKDNHUFAgc3Bl
Y3MpIGFuZCBnZW5lcmljIE5BSSBiYXNlZCBpZGVudGlmaWVycy4gR2l2ZW4gdGhlDQpkZWZpbml0
aW9uIG9mIG5ldyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxhaW5pbmcgdGhlDQpt
b3RpdmF0aW9uDQoNCjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElQdjYg
YWRkcmVzcy4gV2hhdCBleGFjdGx5DQppcw0KdGhpcyA/IEFyZSB0aGVzZSBDR0EtYmFzZWQgSVB2
NiBhZGRyZXNzZXMgPw0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICBOZXcgTW9iaWxlIE5v
ZGUgSWRlbnRpZmllciBUeXBlcw0KDQogICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0r
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgfCBJZGVudGlmaWVyIFR5
cGUgfCBJZGVudGlmaWVyIFR5cGUgTnVtYmVyIHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0t
LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICB8IElQdjYg
QWRkcmVzcyAgICB8IDIgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAg
ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg
IHwgSU1TSSAgICAgICAgICAgIHwgMyAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAg
ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAg
ICAgICAgICAgfCBQLVRNU0kgICAgICAgICAgfCA0ICAgICAgICAgICAgICAgICAgICAgIHwNCiAg
ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICB8
DQogICAgICAgICAgICAgICB8IEVVSS00OCBhZGRyZXNzICB8IDUgICAgICAgICAgICAgICAgICAg
ICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAg
ICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgRVVJLTY0IGFkZHJlc3MgIHwgNiAgICAgICAgICAg
ICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAg
ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBHVVRJICAgICAgICAgICAgfCA3ICAg
ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSst
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCg0KDQoNCg0KDQoNClJlZ2FyZHMNClNyaQ0KUFM6
IEdvb2QgdG8gc2VlIFZpamF5IGJhY2sNCg0KDQpPbiA5LzkvMTQgMToyOCBQTSwgIkNoYXJsaWUg
UGVya2lucyINCjxjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldD48bWFpbHRvOmNoYXJsZXMu
cGVya2luc0BlYXJ0aGxpbmsubmV0Pg0Kd3JvdGU6DQoNCg0KDQpIZWxsbyBmb2xrcywNCg0KSGVy
ZSdzIHRoZSBsYXN0IEludGVybmV0IERyYWZ0IHRoYXQgd2UgZGlkLCBsb25nIGFnbyBleHBpcmVk
Og0KDQpodHRwOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVya2lucy1tZXh0LTQy
ODNtbmlkcy0wMS50eHQNCg0KSSdsbCByZXN1Ym1pdCBpdCB3aXRoIGEgZmV3IHVwZGF0ZXMgYXMg
YSBwZXJzb25hbCBkcmFmdCB0byBkbW0uDQoNClJlZ2FyZHMsDQpDaGFybGllIFAuDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5n
IGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmc8bWFpbHRv
OmRtbUBpZXRmLm9yZz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1tIG1h
aWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxt
YWlsdG86ZG1tQGlldGYub3JnPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZG1tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
CmRtbSBtYWlsaW5nIGxpc3QNCmRtbUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCg0KDQoNCi0tDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkhha2ltYSBDaGFvdWNoaQ0KUHJvZmVzc29yDQpU
ZWxlY29tIFN1ZCBQYXJpcw0KSW5zdGl0dXQgTWluZXMgVGVsZWNvbQ0KOSBydWUgQ2hhcmxlcyBG
b3VyaWVyDQo5MTAxMSBFdnJ5DQowMTYwNzY0NDQzDQoNCg0KDQoNCi0tDQpSZWdhcmRzLA0KQ2hh
cmxpZSBQLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KZG1tIG1haWxpbmcgbGlzdA0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KDQoNCg0KLS0NCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSGFraW1hIENoYW91Y2hpDQpQcm9mZXNzb3IN
ClRlbGVjb20gU3VkIFBhcmlzDQpJbnN0aXR1dCBNaW5lcyBUZWxlY29tDQo5IHJ1ZSBDaGFybGVz
IEZvdXJpZXINCjkxMDExIEV2cnkNCjAxNjA3NjQ0NDMNCg0KDQoNCi0tDQpSZWdhcmRzLA0KQ2hh
cmxpZSBQLg0K

--_000_D04A4F48166EAFsgundaveciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <0760540FA3B689468C7B6E491B3541CC@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+SSB0aGluayB1
cGRhdGluZyBSRkM0MjgzIGlzIHByb2JhYmx5IG5vdCBhbiBvcHRpb24uIFRoYXQgd2lsbCBpbXBh
Y3QgbG90IG9mIGV4aXN0aW5nIHNwZWNzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
TXkgcHJlZmVyZW5jZSBpcyBmb3IgJm5ic3A7ZGVmaW5pbmcgZXhwbGljaXQgdHlwZSB2YWx1ZSBp
biBNTi1JRCBmb3IgZGlmZmVyZW50IFJGSUQgdHlwZXMgYW5kIERIQ1AgRFVJRCB0eXBlczsgU3Rp
bGwga2VlcCB0aGUgUkZDNDI4MyBvcHRpb24gZm9ybWF0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+RXg6PC9kaXY+DQo8ZGl2PlN1YnR5cGUgNDogRFVJRC1MTFQ8L2Rpdj4NCjxkaXY+
U3VidHlwZSA1OiBEVUlELVVVSUQ8L2Rpdj4NCjxkaXY+U3VidHlwZSA2OiBSRklELUdMTi02NiDi
gKY8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PuKApjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4NCjxkaXY+U3JpPC9k
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1m
YW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6Ymxh
Y2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7
IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAw
aW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBu
b25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5G
cm9tOiA8L3NwYW4+JnF1b3Q7Q2hhcmxlcyBFLiBQZXJraW5zJnF1b3Q7ICZsdDs8YSBocmVmPSJt
YWlsdG86Y2hhcmxpZXBAY29tcHV0ZXIub3JnIj5jaGFybGllcEBjb21wdXRlci5vcmc8L2E+Jmd0
Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Pcmdhbml6YXRpb246IDwvc3Bh
bj5CbHVlIFNraWVzPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwv
c3Bhbj5UaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0IDEwOjQ2IFBNPGJyPg0KPHNwYW4gc3R5
bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+SGFraW1hIENoYW91Y2hpICZsdDs8YSBo
cmVmPSJtYWlsdG86aGFraW1hLmNoYW91Y2hpQHRlbGVjb20tc3VkcGFyaXMuZXUiPmhha2ltYS5j
aGFvdWNoaUB0ZWxlY29tLXN1ZHBhcmlzLmV1PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0
bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0
bzpkbW1AaWV0Zi5vcmciPmRtbUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv
bnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+VmlqYXkgRGV2YXJhcGFsbGkgJmx0OzxhIGhyZWY9
Im1haWx0bzpkdmlqYXlAcm9ja2V0bWFpbC5jb20iPmR2aWpheUByb2NrZXRtYWlsLmNvbTwvYT4m
Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5S
ZTogW0RNTV0gTU5JRCBUeXBlczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPjxicj4NCkhlbGxvIGZvbGtz
LDxicj4NCjxicj4NCk5vdyB3ZSBoYXZlIHR3byBraW5kcyBvZiBpZGVudGlmaWVycyB0aGF0IGNv
dWxkIHJlYXNvbmFibHkgYmU8YnI+DQpncm91cGVkIGFzIGEgdHlwZSBwbHVzIHN1YnR5cGVzLiZu
YnNwOyBJIGNvdWxkIHNwZWNpZnkgdGhpcyBieSB3cml0aW5nPGJyPg0KYW5vdGhlciBzZWN0aW9u
IG9mIHRoZSBuZXcgZHJhZnQgdGhhdCBsYXlzIG91dCBhbm90aGVyIHN1YnR5cGU8YnI+DQpmaWVs
ZCBhZnRlciB0aGUgTU5JRCBzdWJ0eXBlIGZpZWxkIGZyb20gNDI4My4mbmJzcDsgSSBndWVzcyBp
dCB3b3VsZDxicj4NCmJlIGEgJnF1b3Q7c3Vic3VidHlwZSZxdW90OyBmaWVsZCBpZiB3ZSBhcmUg
Zm9sbG93aW5nIHRoZSBub21lbmNsYXR1cmUgZm9yPGJyPg0KdGhlIGZpZWxkcyBhcyBzaG93biBp
biBSRkMgNDI4My48YnI+DQo8YnI+DQpPciwgYWx0ZXJuYXRpdmVseSwgSSBjb3VsZCBzcGVjaWZ5
IHRoYXQgZm9yIHNvbWUgdHlwZXMgKGUuZy4sIERVSUQ8YnI+DQphbmQgUkZJRCksIHRoZSBmaXJz
dCBlaWdodCBiaXRzIG9mIHRoZSBpZGVudGlmaWVyIGlzIHRoZSBhIGZpZWxkIHRoYXQ8YnI+DQp3
ZSBtaWdodCBjYWxsIHRoZSAmcXVvdDtpZGVudGlmaWVyIHN1YnR5cGUmcXVvdDsuJm5ic3A7IE1h
eWJlIHRoYXQgaXMgY2xlYW5lci48YnI+DQo8YnI+DQpBIHRoaXJkIG9wdGlvbiB3b3VsZCBiZSB0
byB1cGRhdGUgUkZDIDQyODMsIGJ1dCB0aGF0IHNlZW1zIHRvPGJyPg0KYmUgYSBiaXQgaGVhdnkt
aGFuZGVkLjxicj4NCjxicj4NCkNvbW1lbnRzPyZuYnNwOyBPciBvdGhlciBvcHRpb25zPzxicj4N
Cjxicj4NClJlZ2FyZHMsPGJyPg0KQ2hhcmxpZSBQLjxicj4NCjxicj4NCjxicj4NCjxkaXYgY2xh
c3M9Im1vei1jaXRlLXByZWZpeCI+T24gOS8yNS8yMDE0IDk6MzEgUE0sIEhha2ltYSBDaGFvdWNo
aSB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNpdGU9Im1pZDoxNDc4MDM4NjQ1LjEx
NjI2MjIzLjE0MTE3MDU5MDEyNDAuSmF2YU1haWwuemltYnJhQHRlbGVjb20tc3VkcGFyaXMuZXUi
IHR5cGU9ImNpdGUiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbiwg
bmV3IHlvcmssIHRpbWVzLCBzZXJpZjsNCiAgICAgICAgZm9udC1zaXplOiAxMnB0OyBjb2xvcjog
IzAwMDAwMCI+DQo8ZGl2PkhpLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Rm9yIFJG
SUQgd2UgcmVmZXIgdG8gdGhlIEVQQyBzdGFuZGFyZHMuPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj4mcXVvdDtUaGUgPGVtPkVsZWN0cm9uaWMgUHJvZHVjdCBDb2RlPC9lbT4g
KEVQQykgaXMgYW4gaWRlbnRpZmljYXRpb24gc2NoZW1lIGZvciB1bml2ZXJzYWxseSBpZGVudGlm
eWluZyBwaHlzaWNhbCBvYmplY3RzIGJ5IHVzaW5nIFJhZGlvIEZyZXF1ZW5jeSBJZGVudGlmaWNh
dGlvbiAoUkZJRCkgdGFncy48L2Rpdj4NCjxkaXY+VGhlIHN0YW5kYXJkaXplZCBFUEMgdGFnIGVu
Y29kaW5nIGNvbnNpc3RzIG9mIGFuIEVQQyBJZGVudGlmaWVyIHRoYXQgdW5pcXVlbHkgaWRlbnRp
ZmllcyBhbiBpbmRpdmlkdWFsIG9iamVjdCwgYW5kIG1heSBhbHNvIGluY2x1ZGUgYSBmaWx0ZXIg
dmFsdWUgaWYgdGhlIGZpbHRlciBpcyBuZWVkZWQgdG8gZW5hYmxlIGVmZmVjdGl2ZSBhbmQgZWZm
aWNpZW50IHJlYWRpbmcgb2YgdGhlIEVQQyB0YWdzLiBUaGUgRVBDIElkZW50aWZpZXIgaXMNCiBh
IG1ldGEtY29kaW5nIHNjaGVtZSBkZXNpZ25lZCB0byBzdXBwb3J0IHRoZSBuZWVkcyBvZiB2YXJp
b3VzIGluZHVzdHJpZXMgYnkgYWNjb21tb2RhdGluZyBleGlzdGluZyBjb2Rpbmcgc2NoZW1lcyB3
aGVyZSBwb3NzaWJsZSBhbmQgYnkgZGVmaW5pbmcgbmV3IHNjaGVtZXMgd2hlcmUgbmVjZXNzYXJ5
LiZxdW90OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+JnF1b3Q7RVBDIHN1cHBvcnRz
IHNldmVyYWwgZW5jb2Rpbmcgc3lzdGVtcyBvciBzY2hlbWVzIGluY2x1ZGluZyBHSUQgKEdsb2Jh
bCBJZGVudGlmaWVyKSwgU0dUSU4gKFNlcmlhbGl6ZWQgR2xvYmFsIFRyYWRlIEl0ZW0gTnVtYmVy
KSwgU1NDQyAoU2VyaWFsIFNoaXBwaW5nIENvbnRhaW5lciksIEdMTiAoR2xvYmFsIExvY2F0aW9u
IE51bWJlciksIEdSQUkgKEdsb2JhbCBSZXR1cm5hYmxlIEFzc2V0IElkZW50aWZpZXIpLCBET0Qg
KERlcGFydG1lbnQNCiBvZiBEZWZlbnNlKSBhbmQgR0lBSSAoR2xvYmFsIEluZGl2aWR1YWwgQXNz
ZXQgSWRlbnRpZmllcikuDQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IiBkYXRhLW1jZS1zdHlsZT0i
bWFyZ2luOiAwcHg7Ij5Gb3IgZWFjaCBzY2hlbWUgZXhjZXB0IEdJRCwgdGhlcmUgYXJlIHR3byB2
YXJpYXRpb25z4oCUYSA2NC1iaXQgc2NoZW1lIChmb3IgZXhhbXBsZSwgR0xOLTY0KSBhbmQgYSA5
Ni1iaXQgc2NoZW1lIChHTE4tOTYpLiBHSUQgaGFzIG9ubHkgYSA5Ni1iaXQgc2NoZW1lLjwvcD4N
CldpdGhpbiBlYWNoIHNjaGVtZSwgYW4gRVBDIGlkZW50aWZpZXIgY2FuIGJlIHJlcHJlc2VudGVk
IGluIGEgYmluYXJ5IGZvcm0gb3Igb3RoZXIgZm9ybXMgc3VjaCBhcyBVUkkgLi5ldGMmcXVvdDsu
PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5NYXkgYmUgd2UgbmVlZCBzb21l
IHN1YnR5cGluZy48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNoZWVycyw8
YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkhha2ltYTxicj4NCjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8aHIgaWQ9Inp3Y2hyIj4NCjxk
aXYgc3R5bGU9ImNvbG9yOiMwMDA7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZvbnQtc3R5bGU6bm9ybWFs
O3RleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtZmFtaWx5OkhlbHZldGljYSxBcmlhbCxzYW5zLXNl
cmlmO2ZvbnQtc2l6ZToxMnB0OyI+DQo8Yj5EZTogPC9iPiZxdW90O1NyaSBHdW5kYXZlbGxpIChz
Z3VuZGF2ZSkmcXVvdDsgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFp
bHRvOnNndW5kYXZlQGNpc2NvLmNvbSI+DQombHQ7c2d1bmRhdmVAY2lzY28uY29tJmd0OzwvYT48
YnI+DQo8Yj7DgDogPC9iPiZxdW90O0NoYXJsZXMgRS4gUGVya2lucyZxdW90OyA8YSBjbGFzcz0i
bW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86Y2hhcmxpZXBAY29tcHV0ZXIub3Jn
Ij4NCiZsdDtjaGFybGllcEBjb21wdXRlci5vcmcmZ3Q7PC9hPjxicj4NCjxiPkNjOiA8L2I+JnF1
b3Q7VmlqYXkgRGV2YXJhcGFsbGkmcXVvdDsgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2
RSIgaHJlZj0ibWFpbHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbSI+DQombHQ7ZHZpamF5QHJvY2tl
dG1haWwuY29tJmd0OzwvYT4sIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhy
ZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciPg0KZG1tQGlldGYub3JnPC9hPjxicj4NCjxiPkVudm95
w6k6IDwvYj5WZW5kcmVkaSAyNiBTZXB0ZW1icmUgMjAxNCAwMzozNjowMTxicj4NCjxiPk9iamV0
OiA8L2I+UmU6IFtETU1dIE1OSUQgVHlwZXM8YnI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5I
aSBDaGFybGllLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwO0lzIHRo
ZSBEb0QtOTYgaWRlbnRpZmllciBmb3IgYSBzcGVjaWFsIGtpbmQgb2YgUkZJRCwgb3IgaXMgaXQm
bmJzcDt2YWxpZCBmb3IgYWxsIHRoZSBSRklEIGRldmljZXMgdGhhdCB3b3VsZCBiZSBvZiBpbnRl
cmVzdD88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgZG8gbm90IGtub3cgdGhlIGFu
c3dlciBmb3IgdGhpcyBxdWVzdGlvbi4gSSBhc3N1bWVkIERPRC05NiBpcyBhIG1hbmRhdGVkIHN0
YW5kYXJkIGZvciBSRklEIGVuY29kaW5nLCBidXQgbG9va3MgbGlrZSB0aGVyZSBhcmUgb3RoZXIg
Zm9ybWF0cyBsaWtlIEdJRC05NiAuLmV0Yy4gTWF5IGJlIHRoaXMgbWF5IGVuZCB1cCBuZWVkaW5n
IHN1YnR5cGVzLiBXZSBjYW4gZGVmZXIgdGhpcyBxdWVzdGlvbiB0byBIYWtpbWEgYW5kIGxlYXJu
IHNvbWUNCiBkZXRhaWxzIG9uIHRoaXMsIHNoZSBzZWVtcyB0byBoYXZlIHdyaXR0ZW4gbWFueSBi
b29rcyBvbiBSRklELjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+
DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4NCjxkaXY+U3JpPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C
T0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXpl
OjExcHQ7DQogICAgICAgICAgICAgIHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRF
Ui1CT1RUT006IG1lZGl1bSBub25lOw0KICAgICAgICAgICAgICBCT1JERVItTEVGVDogbWVkaXVt
IG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47DQogICAgICAgICAgICAgIFBBRERJTkctTEVGVDog
MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYNCiAgICAgICAgICAg
ICAgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0
Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7Q2hh
cmxlcyBFLiBQZXJraW5zJnF1b3Q7ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9
Im1haWx0bzpjaGFybGllcEBjb21wdXRlci5vcmciIHRhcmdldD0iX2JsYW5rIj5jaGFybGllcEBj
b21wdXRlci5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5P
cmdhbml6YXRpb246IDwvc3Bhbj5CbHVlIFNraWVzPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp
Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgU2VwdGVtYmVyIDI1LCAyMDE0IDE6NDIg
UE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5TcmkgR3Vu
ZGF2ZWxsaSAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86c2d1bmRh
dmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c2d1bmRhdmVAY2lzY28uY29tPC9hPiZndDs8
YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBt
b3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRy
dWUiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5v
cmc8L2E+Jmd0OywgVmlqYXkgRGV2YXJhcGFsbGkgJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1
ZSIgaHJlZj0ibWFpbHRvOmR2aWpheUByb2NrZXRtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR2
aWpheUByb2NrZXRtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0RNTV0gTU5JRCBUeXBlczxicj4NCjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxicj4NCkhlbGxvIFNyaSw8YnI+DQo8YnI+
DQpJcyB0aGUgRG9ELTk2IGlkZW50aWZpZXIgZm9yIGEgc3BlY2lhbCBraW5kIG9mIFJGSUQsIG9y
IGlzIGl0PGJyPg0KdmFsaWQgZm9yIGFsbCB0aGUgUkZJRCBkZXZpY2VzIHRoYXQgd291bGQgYmUg
b2YgaW50ZXJlc3Q/PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpDaGFybGllIFAuPGJyPg0KPGJy
Pg0KPGJyPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiA5LzIxLzIwMTQgOTo1OSBB
TSwgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKSB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIGNpdGU9Im1pZDpEMDQ0NTBFNS4xNjYwOEYlMjVzZ3VuZGF2ZUBjaXNjby5jb20iPg0KPGRp
dj5IaSBIYWtpbWEsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGF0IGlzIGEgZ29v
ZCBpZGVhLiBXZSBzaG91bGQgcmVnaXN0ZXIgYSB0eXBlIGZvciB0aGUgRG9kLTk2IGlkZW50aWZp
ZXIgYXMgd2VsbC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PGRpdj5SZWdhcmRzPC9kaXY+DQo8ZGl2PlNyaTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBz
dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7DQogICAgICAgICAgICAg
ICAgICAgICAgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTToNCiAg
ICAgICAgICAgICAgICAgICAgICBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25l
Ow0KICAgICAgICAgICAgICAgICAgICAgIFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVG
VDogMGluOw0KICAgICAgICAgICAgICAgICAgICAgIFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS
LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7DQogICAgICAgICAgICAgICAgICAgICAgQk9SREVSLVJJ
R0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13
ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkhha2ltYSBDaGFvdWNoaSAmbHQ7PGEgbW96LWRvLW5v
dC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86aGFraW1hLmNoYW91Y2hpQHRlbGVjb20tc3VkcGFy
aXMuZXUiIHRhcmdldD0iX2JsYW5rIj5oYWtpbWEuY2hhb3VjaGlAdGVsZWNvbS1zdWRwYXJpcy5l
dTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bh
bj5TdW5kYXksIFNlcHRlbWJlciAyMSwgMjAxNCA4OjExIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZv
bnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+U3JpIEd1bmRhdmVsbGkgJmx0OzxhIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPnNndW5kYXZlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt
d2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+Q2hhcmxpZSBQZXJraW5zICZsdDs8YSBtb3otZG8tbm90
LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCIg
dGFyZ2V0PSJfYmxhbmsiPmNoYXJsZXMucGVya2luc0BlYXJ0aGxpbmsubmV0PC9hPiZndDssIE1h
cmNvIExpZWJzY2ggJmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOk1h
cmNvLkxpZWJzY2hAbmVjbGFiLmV1IiB0YXJnZXQ9Il9ibGFuayI+TWFyY28uTGllYnNjaEBuZWNs
YWIuZXU8L2E+Jmd0OywNCiAmcXVvdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1h
aWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+JnF1b3Q7
ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+Jmd0OywgVmlqYXkgRGV2YXJhcGFsbGkg
Jmx0OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmR2aWpheUByb2NrZXRt
YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR2aWpheUByb2NrZXRtYWlsLmNvbTwvYT4mZ3Q7PGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0RN
TV0gTU5JRCBUeXBlczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21hbiwgbmV3DQogICAgICAg
ICAgICAgICAgICAgICAgICAgIHlvcmssIHRpbWVzLCBzZXJpZjsgZm9udC1zaXplOiAxMnB0OyBj
b2xvcjoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIzAwMDAwMCI+DQo8ZGl2PkhlbGxvIEZv
bGtzLDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RG8geW91IHRoaW5rIHRo
YXQgY29uc2lkZXJpbmcgc3BlY2lmaWMgYnV0IG5lZWRlZCB0ZWNobm9sb2dpZXMgZm9yIG1vdmlu
ZyBvYmplY3RzIGluJm5ic3A7IEludGVybmV0IG9mIFRoaW5ncyZuYnNwOyBzdWNoIGFzIFJGSUQg
KFJhZGlvIEZyZXF1ZW5jeSBJZGVudGlmaWVyKSB3aXRoIDk2IGJpdHMgaWRlbnRpZmllcnMgd2ls
bCBiZSBhbHNvIHJlbGV2ZW50IHRvIENoYXJsaWUncyBjdXJyZW50IGRyYWZ0IGFuZCB0aGUgZWZm
b3J0cyByZWxhdGVkIHRvIE1OSUQ/Jm5ic3A7DQo8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2PlJlZ2FyZHMsPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5I
YWtpbWE8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PGhyIGlkPSJ6d2NociI+DQo8ZGl2IHN0eWxlPSJjb2xvcjojMDAwO2ZvbnQtd2VpZ2h0Om5vcm1h
bDtmb250LXN0eWxlOm5vcm1hbDt0ZXh0LWRlY29yYXRpb246bm9uZTtmb250LWZhbWlseTpIZWx2
ZXRpY2EsQXJpYWwsc2Fucy1zZXJpZjtmb250LXNpemU6MTJwdDsiPg0KPGI+RGU6IDwvYj4mcXVv
dDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9
InRydWUiIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5z
Z3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPsOAOiA8L2I+JnF1b3Q7Q2hhcmxpZSBQ
ZXJraW5zJnF1b3Q7ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpj
aGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmNoYXJsZXMucGVy
a2luc0BlYXJ0aGxpbmsubmV0PC9hPiZndDssICZxdW90O01hcmNvIExpZWJzY2gmcXVvdDsgJmx0
OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVj
bGFiLmV1IiB0YXJnZXQ9Il9ibGFuayI+TWFyY28uTGllYnNjaEBuZWNsYWIuZXU8L2E+Jmd0OywN
CjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT4sICZxdW90O1ZpamF5IERldmFyYXBhbGxpJnF1
b3Q7ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkdmlqYXlAcm9j
a2V0bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kdmlqYXlAcm9ja2V0bWFpbC5jb208L2E+Jmd0
Ozxicj4NCjxiPkVudm95w6k6IDwvYj5KZXVkaSAxMSBTZXB0ZW1icmUgMjAxNCAyMzo1NzoxMTxi
cj4NCjxiPk9iamV0OiA8L2I+UmU6IFtETU1dIE1OSUQgVHlwZXM8YnI+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5IaSBDaGFybGllLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RmV3
IG1vcmUgcmV2aWV3cy9kaXNjdXNzaW9ucyBhbmQgY2FwdHVyaW5nIHRoZSBjb25zZW5zdXMgaW4g
dGhlIGJhc2UgdmVyc2lvbiB3aWxsIGhlbHAuIEJ1dCwgSSdtIG9rIGVpdGhlciB3YXkg4oCmPC9k
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkczwv
ZGl2Pg0KPGRpdj5Tcmk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NS
Q19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsNCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVm
dDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29sb3I6YmxhY2s7IEJPUkRFUi1C
T1RUT006IG1lZGl1bSBub25lOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCT1JE
RVItTEVGVDogbWVkaXVtIG5vbmU7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBB
RERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOw0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1l
ZGl1bSBub25lOw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQQURESU5HLVRPUDog
M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Q2hhcmxp
ZSBQZXJraW5zICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpjaGFy
bGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmNoYXJsZXMucGVya2lu
c0BlYXJ0aGxpbmsubmV0PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMTQgMjo0NiBQTTxicj4N
CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPlNyaSBHdW5kYXZlbGxp
ICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNj
by5jb20iIHRhcmdldD0iX2JsYW5rIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0OywgTWFyY28g
TGllYnNjaCAmbHQ7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86TWFyY28u
TGllYnNjaEBuZWNsYWIuZXUiIHRhcmdldD0iX2JsYW5rIj5NYXJjby5MaWVic2NoQG5lY2xhYi5l
dTwvYT4mZ3Q7LA0KICZxdW90OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRv
OmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0
OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT4mZ3Q7LCBWaWpheSBEZXZhcmFwYWxsaSAmbHQ7
PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJtYWlsdG86ZHZpamF5QHJvY2tldG1haWwu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZHZpamF5QHJvY2tldG1haWwuY29tPC9hPiZndDs8YnI+DQo8
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbRE1NXSBN
TklEIFR5cGVzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJy
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PGJpZz5IZWxsbyBmb2xrcyw8
YnI+DQo8YnI+DQpJIHByb3Bvc2UgdG8gc3VibWl0IHRoZSAuLi4uLTAwLnR4dCBkb2N1bWVudCBh
cyBpdCBpcyB0byB0aGUgSW50ZXJuZXQ8YnI+DQpEcmFmdHMgZGlyZWN0b3J5LCBhbmQgdGhlbiB0
byBnbyBhYm91dCBtYWtpbmcgdXBkYXRlcyBhY2NvcmRpbmcgdG88YnI+DQp0aGUgZGlzY3Vzc2lv
biBvbiB0aGlzIGxpc3QuJm5ic3A7IERvIHlvdSB0aGluayB0aGlzIGlzIHJlYXNvbmFibGU/PGJy
Pg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpDaGFybGllIFAuPGJyPg0KPGJyPg0KPC9iaWc+PC9zcGFu
Pjxicj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gOS8xMS8yMDE0IDc6MjEgQU0s
IFNyaSBHdW5kYXZlbGxpIChzZ3VuZGF2ZSkgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBjaXRlPSJtaWQ6RDAzNkZCNUYuMTYzQzlEJTI1c2d1bmRhdmVAY2lzY28uY29tIj4NCjxwcmU+
Jmx0O0NoYW5naW5nIHRoZSBzdWJqZWN0IGxpbmUgdG8gcmVmbGVjdCB0aGUgTU5JZCBkaXNjdXNz
aW9uJmd0Ow0KDQoNCk1hcmNvLA0KDQoNClRoaW5raW5nIGZ1cnRoZXIgb24gdGhlIGNvbXBsZW1l
bnRhcnkgaWRlbnRpZmllciBvcHRpb24uDQoNCi0gVGhlcmUgaXMgYWxyZWFkeSB0aGUgbGluay1s
YXllciBpZGVudGlmaWVyIG9wdGlvbiB0aGF0IGNhbiBiZSB1c2VkIGZvcg0KY2FycnlpbmcgdGhl
IE1hYyBhZGRyZXNzDQotIElNRUkgYW5kIE1TSVNETiBhcmUgYWxyZWFkeSBkZWZpbmVkIGluIDI5
LjI3NSBhcyBhIDNHUFAgVlNFJ3MNCg0KSW4gc29tZSBzZW5zZSwgdGhlIGNvbXBsZW1lbnRhcnkg
aWRlbnRpZmllcnMgYXJlIGFscmVhZHkgcHJlc2VudC4NCg0KU3JpDQoNCg0KDQoNCg0KT24gOS8x
MS8xNCA2OjU4IEFNLCAmcXVvdDtTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpJnF1b3Q7IDxhIG1v
ei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0i
bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtzZ3VuZGF2ZUBj
aXNjby5jb20mZ3Q7PC9hPiB3cm90ZToNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPkkgZG8g
bm90IHNlZSBhIHJlYXNvbiB3aHkgbXVsdGlwbGUgTU4tSWQgaW5zdGFuY2VzIG5lZWQgdG8gYmUg
cHJlc2VudCBpbiBhDQpzaW5nbGUgbWVzc2FnZSA/IEluIG15IGV4cGVyaWVuY2UsIHRoaXMgaXMg
c3RyaWN0bHkgYSBkZXBsb3ltZW50DQpjb25zaWRlcmF0aW9uLCB3aGVuIHRvIHVzZSB3aGF0IHR5
cGUgb2YgaWRlbnRpZmllcnMuDQoNCkFzc3VtaW5nIHRoZSBiYWNrZW5kIHN5c3RlbSBjYW4gdGll
IGFsbCB0aGUgTU4tSWQncyB0byBhIHNpbmdsZQ0Kc3Vic2NyaXB0aW9uLCBhbnkgcHJlc2VudGVk
IGlkZW50aWZpZXIgY2FuIGJlIHN1ZmZpY2llbnQgZm9yIHRoZSBnYXRld2F5DQp0byBkbyB0aGUg
QkNFIGxvb2t1cC4NCg0KSWYgbXVsdGlwbGUgaW5zdGFuY2VzIGNhbiBiZSBwcmVzZW50LCB0aGVu
IHdlIG5lZWQgdG8gZGVhbCB3aXRoIG1vcmUgZXJyb3INCmNhc2VzLiBJcyB0aGF0IHJlYWxseSBu
ZWVkZWQgPw0KDQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPkkgYW0gd29uZGVyaW5nIGlm
IGl0IHdvdWxkIG5vdCBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIGdvIGZvciBhIGRpZmZlcmVudA0K
Y29udGFpbmVyIG9wdGlvbiB0byBjYXJyeSBzdWNoIGluZm9ybWF0aW9uLiBTb21ldGhpbmcgbGlr
ZSBhDQpjb21wbGVtZW50YXJ5IGlkZW50aWZpZXIgb3B0aW9uLg0KPC9wcmU+DQo8L2Jsb2NrcXVv
dGU+DQo8cHJlPlNvdW5kcyBpbnRlcmVzdGluZy4gQXJlIHlvdSBzdWdnZXN0aW5nIHdlIGxlYXZl
IHRoZSBjdXJyZW50IE1OLUlEIGFzIGl0DQppcywgYnV0IHVzZSBhIG5ldyBjb21wbGVtZW50YXJ5
IG9wdGlvbiA/IEJ1dCwgaWYgdGhlIHJlcXVpcmVtZW50IGlzIGZvciBhDQpNYWMgYmFzZWQgaWRl
bnRpZmllcnMsIHdoYXQgd2lsbCBiZSB0aGVyZSBpbiB0aGUgY3VycmVudCBNTi1JZCBvcHRpb24g
PyBXZQ0Kc3RpbGwgbmVlZCB0byBoYXZlIGlkZW50aWZpZXIgdGhlcmUgPw0KDQoNCg0KDQpTcmkN
Cg0KDQoNCg0KDQpPbiA5LzExLzE0IDI6MDMgQU0sICZxdW90O01hcmNvIExpZWJzY2gmcXVvdDsg
PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBo
cmVmPSJtYWlsdG86TWFyY28uTGllYnNjaEBuZWNsYWIuZXUiIHRhcmdldD0iX2JsYW5rIj4mbHQ7
TWFyY28uTGllYnNjaEBuZWNsYWIuZXUmZ3Q7PC9hPiB3cm90ZToNCg0KPC9wcmU+DQo8YmxvY2tx
dW90ZT4NCjxwcmU+Tm8gaXNzdWUgd2l0aCBsb2dpY2FsIHZzLiBwaHlzaWNhbCBJRC4gQnV0IEkg
YW0gd29uZGVyaW5nIGFib3V0IHR3bw0KdGhpbmdzOg0KDQpPcGVyYXRpb24gaXMgY2xlYXIgdG8g
bWUgaW4gY2FzZSBhIHNpbmdsZSBNTklEIGlzIHByZXNlbnQgaW4gYSBtZXNzYWdlDQphbmQgSSBz
ZWUgdGhlIHZhbHVlIGluIGJlaW5nDQpmbGV4aWJsZSB0byBjaG9vc2UgZnJvbSBkaWZmZXJlbnQg
c3ViLXR5cGVzLiBJZiBtdWx0aXBsZSBNTklEcyB3aXRoDQpkaWZmZXJlbnQgc3ViLXR5cGVzIGFy
ZSBwcmVzZW50IGluDQphIHNpbmdsZSBtZXNzYWdlLCB3aGljaCBvbmUgc2hvdWxkIGUuZy4gdGhl
IExNQSB0YWtlIGZvciB0aGUgQkMgbG9va3VwLi4NCk5vIGJpZyBwcm9ibGVtIHRvIHNvbHZlLCBi
dXQNCnRvIGJlIGNvbnNpZGVyZWQgaW4gaW1wbGVtZW50YXRpb25zLg0KDQpJZiB0aGUgcmVhc29u
IGZvciBtdWx0aXBsZSBwcmVzZW50IE1OSURzIHdpdGggZGlmZmVyZW50IHN1Yi10eXBlcyBpcyB0
bw0KZG8gb3RoZXIgdGhpbmdzIHRoYW4gaWRlbnRpZnlpbmcNCnRoZSBub2RlIG9yIHVzaW5nIHRo
ZSBJRCBhcyBrZXkgZm9yIGEgbG9va3VwLCBJIGFtIHdvbmRlcmluZyBpZiBpdCB3b3VsZA0Kbm90
IGJlIG1vcmUgYXBwcm9wcmlhdGUNCnRvIGdvIGZvciBhIGRpZmZlcmVudCBjb250YWluZXIgb3B0
aW9uIHRvIGNhcnJ5IHN1Y2ggaW5mb3JtYXRpb24uDQpTb21ldGhpbmcgbGlrZSBhIGNvbXBsZW1l
bnRhcnkNCmlkZW50aWZpZXIgb3B0aW9uLg0KDQptYXJjbw0KDQo8L3ByZT4NCjxibG9ja3F1b3Rl
Pg0KPHByZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3JpIEd1bmRhdmVsbGkg
KHNndW5kYXZlKSBbPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5r
LWZyZWV0ZXh0IiBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFu
ayI+bWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbTwvYT5dDQpTZW50OiBEb25uZXJzdGFnLCAxMS4g
U2VwdGVtYmVyIDIwMTQgMDA6NDINClRvOiBDaGFybGllIFBlcmtpbnM7IE1hcmNvIExpZWJzY2g7
IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRl
ZCIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9y
ZzwvYT4NCkNjOiBWaWpheSBEZXZhcmFwYWxsaQ0KU3ViamVjdDogUmU6IFtETU1dIHJlZ2FyZGlu
ZyB0aGUgcmUtY2hhcnRlcmluZy4uDQoNCkhlbGxvIENoYXJsaWUsDQoNCkFncmVlIHdpdGggdGhh
dC4gTU4tSWQgYXMgaXRzIGRlZmluZWQgdG9kYXkgaXMgYSBsb2dpY2FsIGlkZW50aWZpZXIuIEl0
DQpkb2VzIG5vdA0KcmVxdWlyZSB0aGUgaWRlbnRpZmllciB0byBiZSBib3VuZCB0byBhIHBoeXNp
Y2FsIGRldmljZSBvciBhIGludGVyZmFjZQ0KaWRlbnRpdHkuDQpCdXQsIHdlIGhhdmUgY2xlYXJs
eSBzZWVuIHJlcXVpcmVtZW50cyB3aGVyZSB0aGUgbmVlZCBpcyBmb3IgZ2VuZXJhdGluZw0KaWRl
bnRpZmllcnMgYmFzZWQgb24gc29tZSBwaHlzaWNhbCBpZGVudGlmaWVycy4gVGhvc2UgcGh5c2lj
YWwNCmlkZW50aWZpZXJzIGluY2x1ZGUNCklNU0ksIE1TSVNETiwgSU1FSSwgTUFDIC4uZXRjLiBJ
ZiB3ZSBjYW4gZGVmaW5lIGEgdHlwZSBmb3IgZWFjaCBvZiB0aGUNCnNvdXJjZQ0KYW5kIHRoZSBy
dWxlcyBmb3IgZ2VuZXJhdGluZyBNTi1JRCBiYXNlZCB1c2luZyB0aG9zZSBzb3VyY2VzLCB0aGUg
c2VuZGVyDQphbmQNCnJlY2VpdmVyIHdpbGwgaGF2ZSBjbGVhciBndWlkYW5jZSBvbiBob3cgdG8g
dXNlIHRoZSBzcGVjLiBTb21lIHBvaW50ZXJzLA0KZXhwbGFuYXRpb24gYW5kIGV4YW1wbGVzIGZv
ciBlYWNoIG9mIHRob3NlIGlkZW50aWZpZXJzIHdpbGwgZ3JlYXRseSBoZWxwDQphdm9pZA0KaW50
ZXItb3AgaXNzdWVzLg0KDQoNClJlZ2FyZHMNClNyaQ0KDQoNCg0KDQoNCg0KDQpPbiA5LzEwLzE0
IDM6MjEgUE0sICZxdW90O0NoYXJsaWUgUGVya2lucyZxdW90OyA8YSBtb3otZG8tbm90LXNlbmQ9
InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpjaGFybGVz
LnBlcmtpbnNAZWFydGhsaW5rLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtjaGFybGVzLnBlcmtp
bnNAZWFydGhsaW5rLm5ldCZndDs8L2E+DQp3cm90ZToNCg0KPC9wcmU+DQo8YmxvY2txdW90ZT4N
CjxwcmU+SGVsbG8gZm9sa3MsDQoNCkkgdGhpbmsgaXQncyBiZXN0IHRvIGNvbnNpZGVyIHRoZSBN
TklEIGFzIHNpbXBseSBsaXZpbmcgaW4gYSBzcGFjZSBvZg0KaWRlbnRpZmllcnMsIGFuZCBub3Qg
d29ycnkgdG9vIG11Y2ggYWJvdXQgd2hldGhlciBpdCdzIGEgbG9naWNhbA0KaWRlbnRpZmllciBv
ciBhIHBoeXNpY2FsIGlkZW50aWZpZXIuICBJZiB0aGUgZm9ybWVyLCB0aGVuIHNvbWV3aGVyZQ0K
KHBlcmhhcHMgYmVsb3cgdGhlIG5ldHdvcmsgbGF5ZXIpIHRoZSBsb2dpY2FsIGlkZW50aWZpZXIg
aGFzIGJlZW4gYm91bmQNCnRvIHNvbWV0aGluZyBpbiB0aGUgcGh5c2ljYWwgaW50ZXJmYWNlLCBi
dXQgdGhhdCdzIG5vdCBvdXIgcHJvYmxlbS4NCg0KVGhlIG51bWJlciBzcGFjZSBmb3IgdHlwZXMg
b2YgTU5JRHMgaXMgbGlrZWx5IHRvIHN0YXkgcHJldHR5IGVtcHR5LCBzbw0KSSdkIHNheSB3ZSBj
b3VsZCBhZGQgYXMgbWFueSB0eXBlcyBhcyB3b3VsZCBiZSBjb252ZW5pZW50IGZvciB0aGUNCnNv
ZnR3YXJlIGRlc2lnbmVycy4gIFNvLCB3ZSBjb3VsZCBjb25jZWl2YWJseSBoYXZlIHNldmVyYWwg
TU5JRHMNCmRlZmluZWQgdGhhdCBhbGwgJnF1b3Q7bG9va2VkIGxpa2UmcXVvdDsgTkFJcyAod2hp
Y2gsIHRoZW1zZWx2ZXMsICZxdW90O2xvb2sgbGlrZSZxdW90Ow0KRlFETnMpLg0KDQpSZWdhcmRz
LA0KQ2hhcmxpZSBQLg0KDQoNCg0KT24gOS8xMC8yMDE0IDg6MTEgQU0sIFNyaSBHdW5kYXZlbGxp
IChzZ3VuZGF2ZSkgd3JvdGU6DQo8L3ByZT4NCjxibG9ja3F1b3RlPg0KPHByZT5ZZXMuIEN1cnJl
bnRseSwgdGhlIE1OSUQgaXMgaWYgdGhlIG5haSBmb3JtYXQgYW5kIGlzIG92ZXJsb2FkZWQuIFRo
ZQ0KTU5JRCAgaW4gM0dQUCBzcGVjcyBpcyB0aGUgSU1TSS1OQUkgKElNU0lAUkVBTE0pLCBpdHMg
YmFzZWQgb24gdGhlDQpJTVNJLiBFeDoNCiZxdW90OyZsdDtJTVNJJmd0O0BlcGMubW5jJmx0O01O
QyZndDsubWNjJmx0O01DQyZndDsuM2dwcG5ldHdvcmsub3JnwrINCg0KV2UgYWxzbyBoYXZlIE1B
QzQ4QFJFQUxNOw0KDQpXZSBhbHNvIGhhdmUgYXBwcm9hY2hlcyB0byB0cmFuc2Zvcm0gTUFDIHRv
IFBzZXVkbyBJTVNJLCBhbmQgdGhlbg0KY2FycnkgSU1TSS1OQUkgYXMgdGhlIE1OLUlELg0KDQoN
ClNvLCB3ZSBuZWVkIHVuaXF1ZSBzdWItdHlwZXMgZm9yIGVhY2ggb2YgdGhlIHR5cGVzL3NvdXJj
ZXMuDQoNCk1OLUlkIGJhc2VkIG9uIElNU0ksIE1TSVNETiwgSU1FSSwgTUFDIC4uDQoNCkFsc28s
IGRvIHdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBJTVNJIGFuZCBJTVNJLU5BSSA/DQoN
ClNyaQ0KDQoNCg0KT24gOS8xMC8xNCA2OjI5IEFNLCAmcXVvdDtNYXJjbyBMaWVic2NoJnF1b3Q7
IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIg
aHJlZj0ibWFpbHRvOk1hcmNvLkxpZWJzY2hAbmVjbGFiLmV1IiB0YXJnZXQ9Il9ibGFuayI+Jmx0
O01hcmNvLkxpZWJzY2hAbmVjbGFiLmV1Jmd0OzwvYT4gd3JvdGU6DQoNCjwvcHJlPg0KPGJsb2Nr
cXVvdGU+DQo8cHJlPkl0IHNlZW1zIHRoZSBNTklEIGlzIHNvbWVob3cgb3ZlcmxvYWRlZCB0byBj
YXJyeSBib3RoLCBub2RlLXNwZWNpZmljDQpJRHMsICBlLmcuIE1BQywgYXMgd2VsbCBhcyBzdWJz
Y3JpYmVyIElEcywgd2hpY2ggaXMgdGhlIElNU0kuDQpUaGVyZSBtYXkgYmUgdmFsdWUgaW4gYWRk
aW5nIHRoZSBJTUVJIHRvIHRoZSBsaXN0IG9mIHBvc3NpYmxlIHR5cGVzDQpvZiAgbm9kZS1zcGVj
aWZpYyBJRHMuDQoNCm1hcmNvDQoNCjwvcHJlPg0KPGJsb2NrcXVvdGU+DQo8cHJlPi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkbW0gWzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIg
Y2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2VzQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPC9hPl0g
T24gQmVoYWxmIE9mIFNyaSBHdW5kYXZlbGxpDQooc2d1bmRhdmUpDQpTZW50OiBEaWVuc3RhZywg
OS4gU2VwdGVtYmVyIDIwMTQgMjM6MzANClRvOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpOyBD
aGFybGllIFBlcmtpbnM7IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQt
bGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiPmRtbUBpZXRmLm9yZzwvYT4NCkNjOiBWaWpheSBEZXZhcmFwYWxsaQ0KU3ViamVjdDogUmU6
IFtETU1dIHJlZ2FyZGluZyB0aGUgcmUtY2hhcnRlcmluZy4uDQoNClR3byBtb3JlIGNvbW1lbnRz
Lg0KDQoNCg0KNC4pIEknZCBhbHNvIHVzZSBzdWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElNU0ku
IEp1c3QgdG8gYWxpZ24gd2l0aA0KdGhlICBzdWItdHlwZXMgIGRlZmluZWQgZm9yIE1OIElkIGRl
ZmluZWQgZm9yIElDTVAuIEkgc3VzcGVjdCB0aGVyZQ0KYXJlIHNvbWUgIGltcGxlbWVudGF0aW9u
cyAgYWxyZWFkeSB1c2luZyBzdWItdHlwZSAoMikuIFBsZWFzZSBzZWUNCnRoZSBvdGhlciB0aHJl
YWQuDQoNCg0KNS4pIEZvciBlYWNoIG9mIHRoZSBzdWItdHlwZXMsIHdlIG5lZWQgdGV4dCBpbmNs
dWRpbmcgZXhhbXBsZXMgYW5kDQpzb21lDQpleHBsYW5hdGlvbiBvbiBob3cgdGhleSBhcmUgdXNl
ZC4NCg0KDQpTcmkNCg0KDQoNCk9uIDkvOS8xNCAyOjIwIFBNLCAmcXVvdDtTcmkgR3VuZGF2ZWxs
aSAoc2d1bmRhdmUpJnF1b3Q7IDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10
eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnNndW5kYXZlQGNpc2NvLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiPiZsdDtzZ3VuZGF2ZUBjaXNjby5jb20mZ3Q7PC9hPg0Kd3JvdGU6DQoNCjwvcHJl
Pg0KPGJsb2NrcXVvdGU+DQo8cHJlPkhpIENoYXJsaWUsDQoNClRoaXMgaXMgZ29vZC4gVGhhbmtz
Lg0KDQoNCjEuKSBJZiBFVUktNDggYW5kIEVVSS02NCBhZGRyZXNzZXMgYXJlIGRlcml2ZWQgb2Yg
YSA0OC1iaXQgSUVFRQ0KODAyLjINCmFkZHJlc3MsIHdoeSBkbyB3ZSBuZWVkIHRvIHR3byBzdWIt
dHlwZXMgPyBXaHkgbm90IGhhdmUganVzdCBvbmUNCnN1Yi10eXBlIGZvciBtYWMgYmFzZWQgaWRl
bnRpZmllcnMgPw0KDQoyLikgU3ViIHR5cGUgdmFsdWUgKDEpIGlzIGN1cnJlbnRseSB1c2VkLiBJ
dHMgY3VycmVudGx5IG92ZXJsb2FkZWQNCmZvcg0KSU1TSS1OQUkgKDNHUFAgc3BlY3MpIGFuZCBn
ZW5lcmljIE5BSSBiYXNlZCBpZGVudGlmaWVycy4gR2l2ZW4gdGhlDQpkZWZpbml0aW9uIG9mIG5l
dyBzdWItdHlwZXMsIHdlIG5lZWQgc29tZSB0ZXh0IGV4cGxhaW5pbmcgdGhlDQptb3RpdmF0aW9u
DQoNCjMuKSBQcm9wb3NlZCBTdWItdHlwZSB2YWx1ZSBvZiAoMikgZm9yIElQdjYgYWRkcmVzcy4g
V2hhdCBleGFjdGx5DQppcw0KdGhpcyA/IEFyZSB0aGVzZSBDR0EtYmFzZWQgSVB2NiBhZGRyZXNz
ZXMgPw0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICBOZXcgTW9iaWxlIE5vZGUgSWRlbnRp
ZmllciBUeXBlcw0KDQogICAgICAgICAgICAgICAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tJiM0Mzst
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOw0KICAgICAgICAgICAgICAgfCBJZGVudGlmaWVy
IFR5cGUgfCBJZGVudGlmaWVyIFR5cGUgTnVtYmVyIHwNCiAgICAgICAgICAgICAgICYjNDM7LS0t
LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7DQogICAgICAg
ICAgICAgICB8IElQdjYgQWRkcmVzcyAgICB8IDIgICAgICAgICAgICAgICAgICAgICAgfA0KICAg
ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgICAgICAgICAgICAgIHwgSU1TSSAgICAgICAgICAgIHwgMyAgICAgICAgICAgICAgICAgICAg
ICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg
ICAgICAgfA0KICAgICAgICAgICAgICAgfCBQLVRNU0kgICAgICAgICAgfCA0ICAgICAgICAgICAg
ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgIHwgICAgICAgICAg
ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8IEVVSS00OCBhZGRyZXNzICB8IDUgICAg
ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgfCAg
ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgRVVJLTY0IGFkZHJlc3Mg
IHwgNiAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICAgICAgICAg
ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCBHVVRJICAg
ICAgICAgICAgfCA3ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICYjNDM7
LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7DQoNCg0K
DQoNCg0KDQoNClJlZ2FyZHMNClNyaQ0KUFM6IEdvb2QgdG8gc2VlIFZpamF5IGJhY2sNCg0KDQpP
biA5LzkvMTQgMToyOCBQTSwgJnF1b3Q7Q2hhcmxpZSBQZXJraW5zJnF1b3Q7DQo8YSBtb3otZG8t
bm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0
bzpjaGFybGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPiZsdDtjaGFy
bGVzLnBlcmtpbnNAZWFydGhsaW5rLm5ldCZndDs8L2E+DQp3cm90ZToNCg0KPC9wcmU+DQo8Ymxv
Y2txdW90ZT4NCjxwcmU+SGVsbG8gZm9sa3MsDQoNCkhlcmUncyB0aGUgbGFzdCBJbnRlcm5ldCBE
cmFmdCB0aGF0IHdlIGRpZCwgbG9uZyBhZ28gZXhwaXJlZDoNCg0KPGEgbW96LWRvLW5vdC1zZW5k
PSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vd3d3Lmll
dGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVya2lucy1tZXh0LTQyODNtbmlkcy0wMS50eHQiIHRh
cmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtcGVya2lu
cy1tZXh0LTQyODNtbmlkcy0wMS50eHQ8L2E+DQoNCkknbGwgcmVzdWJtaXQgaXQgd2l0aCBhIGZl
dyB1cGRhdGVzIGFzIGEgcGVyc29uYWwgZHJhZnQgdG8gZG1tLg0KDQpSZWdhcmRzLA0KQ2hhcmxp
ZSBQLg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQo8YSBtb3otZG8tbm90
LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0
bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGEgbW96LWRv
LW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9hPjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KZG1tIG1haWxpbmcgbGlzdA0KPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0i
bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xh
c3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9kbW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2RtbTwvYT48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90
ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx
dW90ZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCmRtbSBtYWlsaW5nIGxpc3QNCjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1v
ei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNz
PSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZG1tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9kbW08L2E+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0
DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0
ZWQiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5v
cmc8L2E+PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0
ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFy
Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9h
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48YnI+
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRt
bSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0
bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEg
bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZG1tPC9hPjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8YnI+DQo8L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0tIDxicj4NCjwvZGl2Pg0KPGRpdj48c3Bhbj48L3Nw
YW4+DQo8ZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRpdj5I
YWtpbWEgQ2hhb3VjaGk8L2Rpdj4NCjxkaXY+UHJvZmVzc29yPC9kaXY+DQo8ZGl2PlRlbGVjb20g
U3VkIFBhcmlzPC9kaXY+DQo8ZGl2Pkluc3RpdHV0IE1pbmVzIFRlbGVjb208L2Rpdj4NCjxkaXY+
OSBydWUgQ2hhcmxlcyBGb3VyaWVyPC9kaXY+DQo8ZGl2PjkxMDExIEV2cnk8L2Rpdj4NCjxkaXY+
MDE2MDc2NDQ0MzwvZGl2Pg0KPHNwYW4+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9zcGFuPjwvYmxvY2txdW90ZT4NCjxicj4NCjxicj4NCjxwcmUgY2xhc3M9
Im1vei1zaWduYXR1cmUiPi0tIA0KUmVnYXJkcywNCkNoYXJsaWUgUC48L3ByZT4NCjwvZGl2Pg0K
PC9kaXY+DQo8L3NwYW4+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQpkbW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgY2xhc3M9Im1vei10eHQt
bGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+ZG1tQGlldGYub3Jn
PC9hPjxicj4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2RtbTwvYT48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPGJyPg0KPC9k
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tLSA8YnI+DQo8L2Rpdj4NCjxkaXY+PHNwYW4g
bmFtZT0ieCI+PC9zcGFuPg0KPGRpdj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08
L2Rpdj4NCjxkaXY+SGFraW1hIENoYW91Y2hpPC9kaXY+DQo8ZGl2PlByb2Zlc3NvcjwvZGl2Pg0K
PGRpdj5UZWxlY29tIFN1ZCBQYXJpczwvZGl2Pg0KPGRpdj5JbnN0aXR1dCBNaW5lcyBUZWxlY29t
PC9kaXY+DQo8ZGl2PjkgcnVlIENoYXJsZXMgRm91cmllcjwvZGl2Pg0KPGRpdj45MTAxMSBFdnJ5
PC9kaXY+DQo8ZGl2PjAxNjA3NjQ0NDM8L2Rpdj4NCjxzcGFuIG5hbWU9IngiPjwvc3Bhbj48YnI+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPHByZSBjbGFzcz0ibW96LXNp
Z25hdHVyZSIgY29scz0iNzIiPi0tIA0KUmVnYXJkcywNCkNoYXJsaWUgUC48L3ByZT4NCjwvZGl2
Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D04A4F48166EAFsgundaveciscocom_--


From nobody Fri Sep 26 08:14:33 2014
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 7A2BA1A8985 for ; Fri, 26 Sep 2014 08:14:30 -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 CYhkCdeYOSkq for ; Fri, 26 Sep 2014 08:14:28 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084141A8976 for ; Fri, 26 Sep 2014 08:14:27 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id z12so14461366lbi.22 for ; Fri, 26 Sep 2014 08:14:26 -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=l3E05wfYOFHD8wcyQ0FZUOBdRMvoPKm7YcYstGk2lPQ=; b=epWp7yIZG/w5YlNvIVbKxDncyn4kGiQT5ekchGxjnpeFZs5me9U35fTjjLdAplLIaV iRrXU1E0yhF/KHpA1kc9XdY67tSmLZT0zTeVJ7OHLIQCHP19rhBMUD0ePYkJyadiovT1 J4oecaKdWpe4tXALvrzsBlM0Gqph+Jbndnp8WOLxyrnsgnCnb2qkyRoX92cQ5Pq6zlnp 43zHqoRzOgHDp21l/A5pTH3BquIOCmT42KBhWrVKxL2pP09YASC6TWY2/jFfc4ZO48cb HfXD6DIr06KNjA2mF34PsEZaKATqFYHX5r6lBav25oVI5PKJO57ATz4kj6X8/OseDaoZ Xzew==
MIME-Version: 1.0
X-Received: by 10.112.200.134 with SMTP id js6mr19819268lbc.0.1411744466108; Fri, 26 Sep 2014 08:14:26 -0700 (PDT)
Received: by 10.114.77.37 with HTTP; Fri, 26 Sep 2014 08:14:26 -0700 (PDT)
In-Reply-To: <5424FEFA.2050008@gmail.com>
References: <5424FEFA.2050008@gmail.com>
Date: Fri, 26 Sep 2014 10:14:26 -0500
Message-ID: 
From: Behcet Sarikaya 
To: Jouni Korhonen 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ZjTtyi0cCysPJ9o1t4fID0t8l6U
Cc: Dapeng Liu , "dmm@ietf.org" 
Subject: Re: [DMM] Going forward with the DMM work items
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, 26 Sep 2014 15:14:30 -0000

Hi Jouni,

I don't see anything in the charter regarding the design teams or
"working teams". I also mentioned this in the list and there was no
objection.

On what basis you are forming the working teams?

We currently have many solution drafts and I can not see any of them
dividing the solution as exposing mobility state, enhanced mobility
anchoring or forwarding path and signaling.

These three items were mentioned by certain people which I believe do
not constitute the consensus in DMM. Yes the charter had those but my
interpretation was it was for the purpose of abstracting the solution
into some pieces. I have never interpreted them to be the requirements
to divide the final DMM protocol like this.

My question is we do that three four solution drafts and some of them
implemented.
What do we do with them?

My advice to those colleagues wishing to lead the design teams is to
please come up with your own solution and get into the race with
others.
How come they can get the hat of DT lead and produce something and get
priority over others who worked so hard?

Regards,

Behcet

On Fri, Sep 26, 2014 at 12:51 AM, Jouni Korhonen  wrote:
> Folks,
>
> In the interim call #2 we agreed to form "working teams". We got three
> volunteers to run up those:
>
> o Alper will take care of coordinating "exposing mobility state.."
> o Anthony will take care of coordinating "enhanced mobility anchoring.."
> o Marco will take care of coordinating "forwarding path and signaling.."
>
> The above gentlement will arrange calls for brainstorming that are open for
> everyone to participate. The process is open - about equivalent to a design
> team, you just don't need to signup for one. Just keep in mind that it is
> good to concentrate on a limited amount of work items.
>
> The working teams, if they so manage, will produce the solution I-D(s).
> These documents will be equivalent to any individual produced I-D, though.
>
> - Jouni & Dapeng
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Fri Sep 26 09:23:29 2014
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 E57311A701A for ; Fri, 26 Sep 2014 09:23:25 -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 ON489gdvOQJV for ; Fri, 26 Sep 2014 09:23:24 -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 790E51A8F34 for ; Fri, 26 Sep 2014 09:22:29 -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 43C6A88153 for ; Fri, 26 Sep 2014 09:22:29 -0700 (PDT)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D6EE713681B2 for ; Fri, 26 Sep 2014 09:22:28 -0700 (PDT)
Message-ID: <542592C2.7090008@innovationslab.net>
Date: Fri, 26 Sep 2014 12:22:26 -0400
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dmm@ietf.org
References: <5424FEFA.2050008@gmail.com> 
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Op5Oo6C86rhVIftr3vR9ugEcASL3dFSdN"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/mpWzbJRpjzrwLQmuOVNDlh7DpAs
Subject: Re: [DMM] Going forward with the DMM work items
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, 26 Sep 2014 16:23:26 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Op5Oo6C86rhVIftr3vR9ugEcASL3dFSdN
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



On 9/26/14 11:14 AM, Behcet Sarikaya wrote:

>=20
> My question is we do that three four solution drafts and some of them
> implemented.
> What do we do with them?

My expectation, as AD, is that the WG will assess the drafts presented
by these teams for adoption.  People's opinion of those drafts should
not be influenced by the fact they were written by a team.

>=20
> My advice to those colleagues wishing to lead the design teams is to
> please come up with your own solution and get into the race with
> others.

Race?

> How come they can get the hat of DT lead and produce something and get
> priority over others who worked so hard?

First of all, the chairs are well within their right to appoint DT
leads.  They could have appointed all the other slots on the DT as well,
but chose to ask for volunteers.

I do not see anything in Jouni's note that indicates that a team's
output gets any preferential treatment.  The rules of the IETF prevent th=
at.

To re-enforce Jouni's last sentence...

>> These documents will be equivalent to any individual produced I-D, tho=
ugh.

Regards,
Brian



--Op5Oo6C86rhVIftr3vR9ugEcASL3dFSdN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUJZLCAAoJEBOZRqCi7goqD38IAIfhLv11jO5fgX4d+PYyIohY
Oh/pToqbtajsmjaTTYyxV2lahB9HmEA8jhNgM08jy0qoHtat9LtWpAZOA36g/MaU
LqTgjLy3vFfDLw+o9l2b44m8yO2c9UkCTueJWC5zUEln5A2z3qlnasVX60mWcmNi
h8BENnEizp5n2XWCu8Ru1FrYmjf8cMsht28Mfr2ltEiXJ2S/Zj3OTJ/tFRy7bsb7
95Ub7pFCi/lja003AUhuFhNVneQ9vsISrYmBX/lSXzyXAjKN7WWlAYq1ygyIj6O2
UaAzY8lEW+fewOB37fNXGaVnaPUl8mIQu2o4vNHd/ojGwLGYDj/54/WIhNArmhg=
=OksA
-----END PGP SIGNATURE-----

--Op5Oo6C86rhVIftr3vR9ugEcASL3dFSdN--


From nobody Fri Sep 26 11:53:42 2014
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 6AB1F1A1BF4 for ; Fri, 26 Sep 2014 11:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 nSm6Fb1rFxpd for ; Fri, 26 Sep 2014 11:53:37 -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 C1FDC1A1BE9 for ; Fri, 26 Sep 2014 11:53:21 -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 s8QIrLe6013377; Fri, 26 Sep 2014 13:53:21 -0500
Received: from XCH-PHX-310.sw.nos.boeing.com (xch-phx-310.sw.nos.boeing.com [130.247.25.169]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8QIr9q3013275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 26 Sep 2014 13:53:10 -0500
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-PHX-310.sw.nos.boeing.com ([169.254.10.111]) with mapi id 14.03.0181.006;  Fri, 26 Sep 2014 11:53:09 -0700
From: "Templin, Fred L" 
To: Alper Yegin , "dmm@ietf.org" 
Thread-Topic: [DMM] Coordination of mobility solutions
Thread-Index: AQHP1CHY9VuOwKA86U6VCs/LVv9IeZwTyr7Q
Date: Fri, 26 Sep 2014 18:53:08 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D28A5A@XCH-BLV-504.nw.nos.boeing.com>
References: <2F475F09-51A8-414B-B7BD-BCEDB69A58ED@yegin.org>
In-Reply-To: <2F475F09-51A8-414B-B7BD-BCEDB69A58ED@yegin.org>
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: http://mailarchive.ietf.org/arch/msg/dmm/AZN_9SkYq1QdZQ3R38z5K3NufB4
Subject: Re: [DMM] Coordination of mobility solutions
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, 26 Sep 2014 18:53:39 -0000

Hi Alper,

Sorry for the delayed response:

> -----Original Message-----
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
> Sent: Friday, September 19, 2014 8:53 AM
> To: dmm@ietf.org
> Subject: [DMM] Coordination of mobility solutions
>=20
> As promised, let me enumerate the "protocol" worked involved for solution=
s aimed at "discovery,
> selection, and coordinated execution of mobility protocols at multiple la=
yers".
>=20
> - Discovering network's mobility capabilities:
>=20
> Whether it supports PMIP, LISP,  etc.
> Possible approach is to define new DHCP options to deliver this "network =
info" to the terminal.

Another approach is DNS. For example, nodes can discover whether the
network supports AERO by resolving the FQDN "linkupnetworks.domainname".
=20
> - Discovering corresponding node's mobility capabilities:
>=20
> Whether it supports MPTCP, MIP route optimization, etc.
> Possible approach is to use DNS-based discovery.

With AERO, it might be easier to just test the assumption that
the correspondent participates in the service and then make
other arrangements if it does not.

> Discovering the MN's own mobility capabilities does not involve any proto=
col work. It may be based on
> platform-specific methods, API, application profiling, etc.

OK.

> How the terminal selects the mobility protocol(s) to apply to a given flo=
w, and how it coordinates
> execution of them are materials for an "informational" document that'd al=
so refer to the
> aforementioned discovery elements.
>
> Like Danny was suggesting, we can tackle this in the working team that de=
als with the source address
> selection, as there's an interaction  between the two. Whether a flow nee=
ds a fixed or sustained or
> nomadic IP address is influenced by whether the application traffic would=
 need IP-layer mobility or
> not.

It seems like some flows would need to go through the home network
using a stable home network address while others should go through
the visited network using an address specific to the access network.
And somehow, the mobile needs to keep the home and visited domains
separate.

Don't some systems already do that? Or, am I missing the point?

Thanks - Fred
fred.l.templin@boeing.com

> Alper
>=20
>=20
>=20
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Fri Sep 26 12:22:21 2014
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 2CD0B1A023E for ; Fri, 26 Sep 2014 12:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 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, J_CHICKENPOX_81=0.6, 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 SkriLiGp2Sli for ; Fri, 26 Sep 2014 12:22:18 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DCD51A005B for ; Fri, 26 Sep 2014 12:22:17 -0700 (PDT)
Received: by mail-la0-f45.google.com with SMTP id q1so3509582lam.18 for ; Fri, 26 Sep 2014 12:22:16 -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=vroLbQ7OUjJ7nOmVNGP6iNJgcFTUhAXLVp+eF3CeycA=; b=NqmlElpEGjos6+C0BeGTk4GM/FR/f+XFChO7Dil4a2o/t2T/A52xJPzKF4aPdiV1h1 o72qba2+dIwsZKXudeUJySqVX6GhExbm9nbepnFt309IDzixGs7th+cVx01WO4Q21++4 3kYCSdZir+WD2y4r7XJBoBzDUbEvUaxknXPr0i/NjKq4wy8QGgUJieO1kROWd2dAi5eX 0VoS1K5qJ8hyiYlH/Mqy/2aYMuwn7PuiDR44Qil0SP0mDf0d6kkkMQHQMlxbLg8vPOJx vm2Vfe2FTiwJ8rRaie1A9D6iN79vxF9MjSrc3TLc6eBjlC3gy3DZXzHs4ni+DDhA+UXO UpGw==
MIME-Version: 1.0
X-Received: by 10.152.29.100 with SMTP id j4mr21974433lah.47.1411759336258; Fri, 26 Sep 2014 12:22:16 -0700 (PDT)
Received: by 10.114.77.37 with HTTP; Fri, 26 Sep 2014 12:22:16 -0700 (PDT)
In-Reply-To: <542592C2.7090008@innovationslab.net>
References: <5424FEFA.2050008@gmail.com>  <542592C2.7090008@innovationslab.net>
Date: Fri, 26 Sep 2014 14:22:16 -0500
Message-ID: 
From: Behcet Sarikaya 
To: Brian Haberman 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/JlLYbFE3nRyYo4hIV4K7u66gydU
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Going forward with the DMM work items
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, 26 Sep 2014 19:22:20 -0000

Hi Brian,

You deleted maybe by mistake the first three paragraphs of my previous mail.

Let me add to those one more point:

Previously mobility groups in IETF produced single protocols like
Mobile IP or Proxy Mobile IP.
These protocols have seen some operator adoption, of course not much but some.
This time we will be asking the operators to adopt exposing mobility
state protocol, enhanced mobility anchoring protocol and forwarding
path and signaling protocol (maybe forwarding path protocol and
signaling protocol)l.
And maybe deployment models protocol which was in the charter but
somehow got dropped.
How is that going to happen?

Anyway these are my concerns, I could not attend Interim call #2, I
believe many people could not including Jouni.
People should speak up, otherwise it appears like it is only my issue.

Regards,

Behcet

On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman
 wrote:
>
>
> On 9/26/14 11:14 AM, Behcet Sarikaya wrote:
>
>>
>> My question is we do that three four solution drafts and some of them
>> implemented.
>> What do we do with them?
>
> My expectation, as AD, is that the WG will assess the drafts presented
> by these teams for adoption.  People's opinion of those drafts should
> not be influenced by the fact they were written by a team.
>
>>
>> My advice to those colleagues wishing to lead the design teams is to
>> please come up with your own solution and get into the race with
>> others.
>
> Race?
>
>> How come they can get the hat of DT lead and produce something and get
>> priority over others who worked so hard?
>
> First of all, the chairs are well within their right to appoint DT
> leads.  They could have appointed all the other slots on the DT as well,
> but chose to ask for volunteers.
>
> I do not see anything in Jouni's note that indicates that a team's
> output gets any preferential treatment.  The rules of the IETF prevent that.
>
> To re-enforce Jouni's last sentence...
>
>>> These documents will be equivalent to any individual produced I-D, though.
>
> Regards,
> Brian
>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>


From nobody Fri Sep 26 12:34:48 2014
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 85ECE1A1BE6 for ; Fri, 26 Sep 2014 12:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.387
X-Spam-Level: 
X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 2HoQRL6_OR_v for ; Fri, 26 Sep 2014 12:34:44 -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 EA1981A1A80 for ; Fri, 26 Sep 2014 12:34:43 -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 s8QJYhiH022483; Fri, 26 Sep 2014 12:34:43 -0700
Received: from XCH-BLV-304.nw.nos.boeing.com (xch-blv-304.nw.nos.boeing.com [130.247.25.216]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8QJYg0A022373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 26 Sep 2014 12:34:42 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-304.nw.nos.boeing.com ([169.254.4.155]) with mapi id 14.03.0181.006; Fri, 26 Sep 2014 12:34:41 -0700
From: "Templin, Fred L" 
To: "sarikaya@ieee.org" , Brian Haberman 
Thread-Topic: [DMM] Going forward with the DMM work items
Thread-Index: AQHP2b83XpUh8f5HfEmf5Z5P6OIeg5wTy7pg
Date: Fri, 26 Sep 2014 19:34:41 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D28B47@XCH-BLV-504.nw.nos.boeing.com>
References: <5424FEFA.2050008@gmail.com>  <542592C2.7090008@innovationslab.net> 
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/aAcp7DZwQr2ZStsCGxUT9YmKeb8
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Going forward with the DMM work items
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, 26 Sep 2014 19:34:46 -0000

Hi Behcet,

> -----Original Message-----
> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya
> Sent: Friday, September 26, 2014 12:22 PM
> To: Brian Haberman
> Cc: dmm@ietf.org
> Subject: Re: [DMM] Going forward with the DMM work items
>=20
> Hi Brian,
>=20
> You deleted maybe by mistake the first three paragraphs of my previous ma=
il.
>=20
> Let me add to those one more point:
>=20
> Previously mobility groups in IETF produced single protocols like
> Mobile IP or Proxy Mobile IP.
> These protocols have seen some operator adoption, of course not much but =
some.
> This time we will be asking the operators to adopt exposing mobility
> state protocol, enhanced mobility anchoring protocol and forwarding
> path and signaling protocol (maybe forwarding path protocol and
> signaling protocol)l.
> And maybe deployment models protocol which was in the charter but
> somehow got dropped.
> How is that going to happen?
>=20
> Anyway these are my concerns, I could not attend Interim call #2, I
> believe many people could not including Jouni.

Jouni was able to attend the call. I was on the call and asked the
question as to whether non-MIPv6/PMIPv6 solutions could be considered
and the answer I got (I think from Jouni) was "possibly".

> People should speak up, otherwise it appears like it is only my issue.

AERO is a solution alternative that I would like to see taken under
wider consideration within this domain. I think that is starting to
happen through some of the recent list discussions, so others on the
list should now be coming aware of it. I also plan to attend IETF91
where I would ask for another AERO presentation timeslot if it would
please the wg and the chairs.

So, it seems to me that I am already doing all I can. Do you think
I should be doing more?

Thanks - Fred
fred.l.templin@boeing.com

> Regards,
>=20
> Behcet
>=20
> On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman
>  wrote:
> >
> >
> > On 9/26/14 11:14 AM, Behcet Sarikaya wrote:
> >
> >>
> >> My question is we do that three four solution drafts and some of them
> >> implemented.
> >> What do we do with them?
> >
> > My expectation, as AD, is that the WG will assess the drafts presented
> > by these teams for adoption.  People's opinion of those drafts should
> > not be influenced by the fact they were written by a team.
> >
> >>
> >> My advice to those colleagues wishing to lead the design teams is to
> >> please come up with your own solution and get into the race with
> >> others.
> >
> > Race?
> >
> >> How come they can get the hat of DT lead and produce something and get
> >> priority over others who worked so hard?
> >
> > First of all, the chairs are well within their right to appoint DT
> > leads.  They could have appointed all the other slots on the DT as well=
,
> > but chose to ask for volunteers.
> >
> > I do not see anything in Jouni's note that indicates that a team's
> > output gets any preferential treatment.  The rules of the IETF prevent =
that.
> >
> > To re-enforce Jouni's last sentence...
> >
> >>> These documents will be equivalent to any individual produced I-D, th=
ough.
> >
> > Regards,
> > Brian
> >
> >
> >
> > _______________________________________________
> > 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 Sat Sep 27 05:26:40 2014
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 DA8801A1AFF for ; Sat, 27 Sep 2014 05:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 ae7iaJWTNQUf for ; Sat, 27 Sep 2014 05:26:37 -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 501D01A1ADA for ; Sat, 27 Sep 2014 05:26:37 -0700 (PDT)
Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0MfHA4-1XvaCC0Lne-00Op6W; Sat, 27 Sep 2014 14:26:33 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Alper Yegin 
In-Reply-To: <2134F8430051B64F815C691A62D9831832D28A5A@XCH-BLV-504.nw.nos.boeing.com>
Date: Sat, 27 Sep 2014 15:26:28 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CEE3EC9-9FD8-4280-A658-E8F8ADB02DEE@yegin.org>
References: <2F475F09-51A8-414B-B7BD-BCEDB69A58ED@yegin.org> <2134F8430051B64F815C691A62D9831832D28A5A@XCH-BLV-504.nw.nos.boeing.com>
To: "Templin, Fred L" 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:a1J7nt1JBOa1FGPFSPnMk2XpnA3kQz9Bw/RIpuz0REX foVaO76xZZHyJMs7EA7l9WVgjZPd2+Zi1C6QopZIHPE7eNVXFB XQayHLi0m9itIG5Z3p6XH+P3f1gh4NIcYHXblL+txdc9Yiq3S9 8q2aiI0GiYECOPgoxvwrYa/VfsXiekK+18V075lGjFS0KWLtIH Tadp222rHWHOijHzVXRMTxtVWW40eK8ygDEtqNuMurc87+VkPD TbLJqG7HuRlZVHdQYAL3vaPq7nqRs+2E23i/irP7tIVF2/Ls1L jX1lOCnxnr3AAcjP1UubebgfZppClS4v/YCeBec84Dna83HGSA H4zaeVoAGcW6o2nQgS+3a1s0mA/StmvxKKGNjxYiF/Y8ebdwzh g/exDoeTMy1MA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/sHEOjbHJvwxZCNLMnbHZ-XlVm4k
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Coordination of mobility solutions
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, 27 Sep 2014 12:26:39 -0000

Hi Fred,

>> As promised, let me enumerate the "protocol" worked involved for =
solutions aimed at "discovery,
>> selection, and coordinated execution of mobility protocols at =
multiple layers".
>>=20
>> - Discovering network's mobility capabilities:
>>=20
>> Whether it supports PMIP, LISP,  etc.
>> Possible approach is to define new DHCP options to deliver this =
"network info" to the terminal.
>=20
> Another approach is DNS. For example, nodes can discover whether the
> network supports AERO by resolving the FQDN =
"linkupnetworks.domainname".
>=20

Yes, that's possible too.

>> - Discovering corresponding node's mobility capabilities:
>>=20
>> Whether it supports MPTCP, MIP route optimization, etc.
>> Possible approach is to use DNS-based discovery.
>=20
> With AERO, it might be easier to just test the assumption that
> the correspondent participates in the service and then make
> other arrangements if it does not.
>=20

Trial-and-error, when fails, would create additional latency getting in =
the way of starting the e2e communications.

>> Discovering the MN's own mobility capabilities does not involve any =
protocol work. It may be based on
>> platform-specific methods, API, application profiling, etc.
>=20
> OK.
>=20
>> How the terminal selects the mobility protocol(s) to apply to a given =
flow, and how it coordinates
>> execution of them are materials for an "informational" document =
that'd also refer to the
>> aforementioned discovery elements.
>>=20
>> Like Danny was suggesting, we can tackle this in the working team =
that deals with the source address
>> selection, as there's an interaction  between the two. Whether a flow =
needs a fixed or sustained or
>> nomadic IP address is influenced by whether the application traffic =
would need IP-layer mobility or
>> not.
>=20
> It seems like some flows would need to go through the home network
> using a stable home network address while others should go through
> the visited network using an address specific to the access network.
> And somehow, the mobile needs to keep the home and visited domains
> separate.
>=20

Yes.


> Don't some systems already do that? Or, am I missing the point?
>=20

The closest I can think of is:  3GPP systems using, say IMS APN and =
Internet APN, where the Internet APN uses SIPTO at the local network.
Do you have this, or something else in mind?

Alper




> Thanks - Fred
> fred.l.templin@boeing.com
>=20
>> Alper
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm


From nobody Mon Sep 29 04:51:41 2014
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 4AA971A873E for ; Mon, 29 Sep 2014 04:51:39 -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 eQvXAH2KFLq6 for ; Mon, 29 Sep 2014 04:51:38 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DDD1A1A2C for ; Mon, 29 Sep 2014 04:51:37 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id hz20so1280545lab.39 for ; Mon, 29 Sep 2014 04:51: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:cc:subject :content-type:content-transfer-encoding; bh=QEHc8i8kVfpCfF1J2VLCIAhoH0+R0u9zdCj+lPj/mis=; b=pU1lHWu8AOzM1M+e89+OKw6rCOe16H7qH9KutD93ZwicF6DSjAja2lNmOBtmYOvKwP jp/u6KvJGntV+QPmQiLeJ99qeR1HUZiOS+l6IYVXmcivz7uwsiaqCXXvLdo0TkuVKYeE 9TLZpywxBE6wXQ/Txlf0vp1CCKpN67WuL3lUNkzDR02wrZnfmpFoEO3sORX1DOIMPNLF wkd9ZkO/gnNNOTlvuJ81ijr9ufl+wLyF+/unvMzwOye0Fxmat1G+PUbHV61WX13jtjl8 vwv53nowlHG7adx5U80uzBm/EPyQG3tMjWyFwyMqZ4o63Dgm4Hjue64YDs0pYXCdJ76v L1BQ==
X-Received: by 10.112.169.37 with SMTP id ab5mr15438448lbc.27.1411991495963; Mon, 29 Sep 2014 04:51:35 -0700 (PDT)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id nx9sm4824406lbb.23.2014.09.29.04.51.33 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 04:51:34 -0700 (PDT)
Message-ID: <542947C6.8020600@gmail.com>
Date: Mon, 29 Sep 2014 14:51:34 +0300
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "dmm@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/teMX7bHLlfxyvvf0z_9kQqq2Dl8
Cc: H Anthony Chan 
Subject: [DMM] Interim call #3 approaching
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, 29 Sep 2014 11:51:39 -0000

Folks,

The interim call #3 is approaching and it is time for the agenda building.

"Work Team" leads should prepare to give an update on their side. Other 
than that if you have something DMMish to share, let the chairs know.

- Jouni & Dapeng


From nobody Mon Sep 29 08:00:25 2014
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 298ED1A8758; Mon, 29 Sep 2014 08:00:24 -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 NF7oHpLtdseO; Mon, 29 Sep 2014 08:00:23 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9231F1A8723; Mon, 29 Sep 2014 08:00:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140929150021.11695.14097.idtracker@ietfa.amsl.com>
Date: Mon, 29 Sep 2014 08:00:21 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/5Hii4vJ0BVhR4f7Nlh81vE8NZP4
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-best-practices-gap-analysis-08.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: Mon, 29 Sep 2014 15:00:24 -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           : Distributed Mobility Management: Current practices and gap analysis
        Authors         : Dapeng Liu
                          Juan Carlos Zuniga
                          Pierrick Seite
                          H Anthony Chan
                          Carlos J. Bernardos
	Filename        : draft-ietf-dmm-best-practices-gap-analysis-08.txt
	Pages           : 30
	Date            : 2014-09-29

Abstract:
   This document analyzes deployment practices of existing IP mobility
   protocols in a distributed mobility management environment.  It then
   identifies existing limitations when compared to the requirements
   defined for a distributed mobility management solution.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-best-practices-gap-analysis-08


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 Mon Sep 29 08:44:25 2014
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 3E5F21A87EE for ; Mon, 29 Sep 2014 08:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 xTtYmJ60mTAj for ; Mon, 29 Sep 2014 08:44:22 -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 365D91A8822 for ; Mon, 29 Sep 2014 08:44:22 -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 s8TFiLIk003630; Mon, 29 Sep 2014 08:44:21 -0700
Received: from XCH-BLV-305.nw.nos.boeing.com (xch-blv-305.nw.nos.boeing.com [130.247.25.217]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8TFiBqX003489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 29 Sep 2014 08:44:11 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-305.nw.nos.boeing.com ([169.254.5.16]) with mapi id 14.03.0181.006; Mon, 29 Sep 2014 08:44:10 -0700
From: "Templin, Fred L" 
To: Alper Yegin 
Thread-Topic: [DMM] Coordination of mobility solutions
Thread-Index: AQHP1CHY9VuOwKA86U6VCs/LVv9IeZwTyr7QgAGe3ACAAtkLgA==
Date: Mon, 29 Sep 2014 15:44:09 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D2A2B8@XCH-BLV-504.nw.nos.boeing.com>
References: <2F475F09-51A8-414B-B7BD-BCEDB69A58ED@yegin.org> <2134F8430051B64F815C691A62D9831832D28A5A@XCH-BLV-504.nw.nos.boeing.com> <1CEE3EC9-9FD8-4280-A658-E8F8ADB02DEE@yegin.org>
In-Reply-To: <1CEE3EC9-9FD8-4280-A658-E8F8ADB02DEE@yegin.org>
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: http://mailarchive.ietf.org/arch/msg/dmm/8zEfQmg0iVumysFdhasSbfUNymw
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Coordination of mobility solutions
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, 29 Sep 2014 15:44:24 -0000

Hi Alper,

> -----Original Message-----
> From: Alper Yegin [mailto:alper.yegin@yegin.org]
> Sent: Saturday, September 27, 2014 5:26 AM
> To: Templin, Fred L
> Cc: dmm@ietf.org
> Subject: Re: [DMM] Coordination of mobility solutions
>=20
> Hi Fred,
>=20
> >> As promised, let me enumerate the "protocol" worked involved for solut=
ions aimed at "discovery,
> >> selection, and coordinated execution of mobility protocols at multiple=
 layers".
> >>
> >> - Discovering network's mobility capabilities:
> >>
> >> Whether it supports PMIP, LISP,  etc.
> >> Possible approach is to define new DHCP options to deliver this "netwo=
rk info" to the terminal.
> >
> > Another approach is DNS. For example, nodes can discover whether the
> > network supports AERO by resolving the FQDN "linkupnetworks.domainname"=
.
> >
>=20
> Yes, that's possible too.

OK. While not a mobility solution, ISATAP has been doing that for over
a decade now. ISATAP and AERO both use an NBMA tunnel virtual interface
model, and FQDN resolution is the most frequently used means of discovery
supported in both cases. (Other means such as DHCP option are also
possible, but less frequently used.)

> >> - Discovering corresponding node's mobility capabilities:
> >>
> >> Whether it supports MPTCP, MIP route optimization, etc.
> >> Possible approach is to use DNS-based discovery.
> >
> > With AERO, it might be easier to just test the assumption that
> > the correspondent participates in the service and then make
> > other arrangements if it does not.
> >
>=20
> Trial-and-error, when fails, would create additional latency getting in t=
he way of starting the e2e
> communications.

OK. In terms of discovery of whether a potential correspondent supports
route optimization, DNS resolution is certainly possible by resolving a
FQDN based on the prospective correspondent's IPv6 prefix. For example,
if the IPv6 destination address is 2001:db8:1:2::1 then the source can
resolve the FQDN:

'2.0.0.0.1.0.0.0.8.d.b.0.1.0.0.2.linkupnetworks.com'

If name resolution succeeds, then the source has assurance that the
destination is behind a mobile router that supports route optimization.
This means that the owner of the FQDN "linkupnetworks.com" would need
to add resource records for all AERO Service Prefixes (ASPs) from
which individual AERO Client Prefixes (ACPs) are taken.

I first described this in Section 6.4 of VET:

http://www.ietf.org/archive/id/draft-templin-intarea-vet-40.txt

> >> Discovering the MN's own mobility capabilities does not involve any pr=
otocol work. It may be based
> on
> >> platform-specific methods, API, application profiling, etc.
> >
> > OK.
> >
> >> How the terminal selects the mobility protocol(s) to apply to a given =
flow, and how it coordinates
> >> execution of them are materials for an "informational" document that'd=
 also refer to the
> >> aforementioned discovery elements.
> >>
> >> Like Danny was suggesting, we can tackle this in the working team that=
 deals with the source
> address
> >> selection, as there's an interaction  between the two. Whether a flow =
needs a fixed or sustained or
> >> nomadic IP address is influenced by whether the application traffic wo=
uld need IP-layer mobility or
> >> not.
> >
> > It seems like some flows would need to go through the home network
> > using a stable home network address while others should go through
> > the visited network using an address specific to the access network.
> > And somehow, the mobile needs to keep the home and visited domains
> > separate.
> >
>=20
> Yes.
>=20
>=20
> > Don't some systems already do that? Or, am I missing the point?
> >
>=20
> The closest I can think of is:  3GPP systems using, say IMS APN and Inter=
net APN, where the Internet
> APN uses SIPTO at the local network.
> Do you have this, or something else in mind?

I don't have much to offer on this subject at the moment, but interested
to learn more.

Thanks - Fred
fred.l.templin@boeing.com

> Alper
>=20
>=20
>=20
>=20
> > Thanks - Fred
> > fred.l.templin@boeing.com
> >
> >> Alper
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> dmm mailing list
> >> dmm@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dmm


From nobody Mon Sep 29 08:50:18 2014
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 D90AC1A882D for ; Mon, 29 Sep 2014 08:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 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, J_CHICKENPOX_81=0.6, 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 ca9MtnwAaTLx for ; Mon, 29 Sep 2014 08:50:15 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0FE1A8832 for ; Mon, 29 Sep 2014 08:50:14 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id l4so18195201lbv.16 for ; Mon, 29 Sep 2014 08:50:13 -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=XOd44svCscqDL0Et3B+aeEUYs39ehA8CkmXMZ7Lqczk=; b=OH/cQqplCL8xRu8TMUercTGqQ8ypVilzYWtDlbYPXtXbH3Trha4dk+gv2MQO1+DoI6 j+5x4hkPzf3MuM/4ExKYN2xFaf2nKDz/bZbdx4t041PhlZNUMIyOcCh8JHKIUAoAnAjL BHsgvBj8ZcufSYpdptg+ly24a6LI0udiT/+mIxluSJ4gT5Mw5zxkFmWvdxMQTk3jQ29T X1UmERfBM4Eyq8u1SCx7yfnmfGt6Teiuuzu1M6TPbebnOHBShVCsI0ctVQs6Y7VmMyLj zYwVhzlv7YPLCmyUw7APwMOZjIuokvS50C/7Rp2x8njWJmq43G3MHbAGG5VpJJ3kxwiG F02A==
MIME-Version: 1.0
X-Received: by 10.152.121.8 with SMTP id lg8mr3890098lab.98.1412005813039; Mon, 29 Sep 2014 08:50:13 -0700 (PDT)
Received: by 10.114.77.37 with HTTP; Mon, 29 Sep 2014 08:50:12 -0700 (PDT)
In-Reply-To: <2134F8430051B64F815C691A62D9831832D28B47@XCH-BLV-504.nw.nos.boeing.com>
References: <5424FEFA.2050008@gmail.com>  <542592C2.7090008@innovationslab.net>  <2134F8430051B64F815C691A62D9831832D28B47@XCH-BLV-504.nw.nos.boeing.com>
Date: Mon, 29 Sep 2014 10:50:12 -0500
Message-ID: 
From: Behcet Sarikaya 
To: "Templin, Fred L" 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/dEGb2W9ZQOPPamgtxveyOy-flwY
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Going forward with the DMM work items
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: Mon, 29 Sep 2014 15:50:17 -0000

Hi Fred,


On Fri, Sep 26, 2014 at 2:34 PM, Templin, Fred L
 wrote:
> Hi Behcet,
>
>> -----Original Message-----
>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya
>> Sent: Friday, September 26, 2014 12:22 PM
>> To: Brian Haberman
>> Cc: dmm@ietf.org
>> Subject: Re: [DMM] Going forward with the DMM work items
>>
>> Hi Brian,
>>
>> You deleted maybe by mistake the first three paragraphs of my previous mail.
>>
>> Let me add to those one more point:
>>
>> Previously mobility groups in IETF produced single protocols like
>> Mobile IP or Proxy Mobile IP.
>> These protocols have seen some operator adoption, of course not much but some.
>> This time we will be asking the operators to adopt exposing mobility
>> state protocol, enhanced mobility anchoring protocol and forwarding
>> path and signaling protocol (maybe forwarding path protocol and
>> signaling protocol)l.
>> And maybe deployment models protocol which was in the charter but
>> somehow got dropped.
>> How is that going to happen?

Do you plan to divide your solution into

exposing mobility state protocol,
enhanced mobility anchoring protocol.
 forwarding path protocol
signaling protocol ?

That is the way things are going.
Otherwise you are off track.


>>
>> Anyway these are my concerns, I could not attend Interim call #2, I
>> believe many people could not including Jouni.
>
> Jouni was able to attend the call. I was on the call and asked the
> question as to whether non-MIPv6/PMIPv6 solutions could be considered
> and the answer I got (I think from Jouni) was "possibly".
>
>> People should speak up, otherwise it appears like it is only my issue.
>
> AERO is a solution alternative that I would like to see taken under
> wider consideration within this domain. I think that is starting to
> happen through some of the recent list discussions, so others on the
> list should now be coming aware of it. I also plan to attend IETF91
> where I would ask for another AERO presentation timeslot if it would
> please the wg and the chairs.
>
> So, it seems to me that I am already doing all I can. Do you think
> I should be doing more?

I think you are trying to push your own solution and you think that
you are effective in it.

I think DMM should see the big picture and everybody, including Ryuji,
Satoru and others should speak up.

Regards,

Behcet

>
> Thanks - Fred
> fred.l.templin@boeing.com
>
>> Regards,
>>
>> Behcet
>>
>> On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman
>>  wrote:
>> >
>> >
>> > On 9/26/14 11:14 AM, Behcet Sarikaya wrote:
>> >
>> >>
>> >> My question is we do that three four solution drafts and some of them
>> >> implemented.
>> >> What do we do with them?
>> >
>> > My expectation, as AD, is that the WG will assess the drafts presented
>> > by these teams for adoption.  People's opinion of those drafts should
>> > not be influenced by the fact they were written by a team.
>> >
>> >>
>> >> My advice to those colleagues wishing to lead the design teams is to
>> >> please come up with your own solution and get into the race with
>> >> others.
>> >
>> > Race?
>> >
>> >> How come they can get the hat of DT lead and produce something and get
>> >> priority over others who worked so hard?
>> >
>> > First of all, the chairs are well within their right to appoint DT
>> > leads.  They could have appointed all the other slots on the DT as well,
>> > but chose to ask for volunteers.
>> >
>> > I do not see anything in Jouni's note that indicates that a team's
>> > output gets any preferential treatment.  The rules of the IETF prevent that.
>> >
>> > To re-enforce Jouni's last sentence...
>> >
>> >>> These documents will be equivalent to any individual produced I-D, though.
>> >
>> > Regards,
>> > Brian
>> >
>> >
>> >
>> > _______________________________________________
>> > 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 Mon Sep 29 09:35:08 2014
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 663251A88B7 for ; Mon, 29 Sep 2014 09:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.787
X-Spam-Level: 
X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 bnygoPA4gHMK for ; Mon, 29 Sep 2014 09:35:01 -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 C84601A88B5 for ; Mon, 29 Sep 2014 09:35:01 -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 s8TGZ1nI020969; Mon, 29 Sep 2014 09:35:01 -0700
Received: from XCH-BLV-101.nw.nos.boeing.com (xch-blv-101.nw.nos.boeing.com [130.247.25.116]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s8TGYvw0020686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 29 Sep 2014 09:34:58 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-101.nw.nos.boeing.com ([169.254.1.220]) with mapi id 14.03.0181.006; Mon, 29 Sep 2014 09:34:57 -0700
From: "Templin, Fred L" 
To: "sarikaya@ieee.org" 
Thread-Topic: [DMM] Going forward with the DMM work items
Thread-Index: AQHP2b83XpUh8f5HfEmf5Z5P6OIeg5wTy7pggATwOwD//5JLAA==
Date: Mon, 29 Sep 2014 16:34:56 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832D2A3EF@XCH-BLV-504.nw.nos.boeing.com>
References: <5424FEFA.2050008@gmail.com>  <542592C2.7090008@innovationslab.net>  <2134F8430051B64F815C691A62D9831832D28B47@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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/uBR_MV_SNeRvt_MFpagVXJaN31s
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Going forward with the DMM work items
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, 29 Sep 2014 16:35:04 -0000

SGkgQmVoY2V0LA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlaGNl
dCBTYXJpa2F5YSBbbWFpbHRvOnNhcmlrYXlhMjAxMkBnbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRh
eSwgU2VwdGVtYmVyIDI5LCAyMDE0IDg6NTAgQU0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTA0KPiBD
YzogQnJpYW4gSGFiZXJtYW47IGRtbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0RNTV0gR29p
bmcgZm9yd2FyZCB3aXRoIHRoZSBETU0gd29yayBpdGVtcw0KPiANCj4gSGkgRnJlZCwNCj4gDQo+
IA0KPiBPbiBGcmksIFNlcCAyNiwgMjAxNCBhdCAyOjM0IFBNLCBUZW1wbGluLCBGcmVkIEwNCj4g
PEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+IEhpIEJlaGNldCwNCj4gPg0K
PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBkbW0gW21haWx0bzpk
bW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlaGNldCBTYXJpa2F5YQ0KPiA+PiBT
ZW50OiBGcmlkYXksIFNlcHRlbWJlciAyNiwgMjAxNCAxMjoyMiBQTQ0KPiA+PiBUbzogQnJpYW4g
SGFiZXJtYW4NCj4gPj4gQ2M6IGRtbUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW0RNTV0g
R29pbmcgZm9yd2FyZCB3aXRoIHRoZSBETU0gd29yayBpdGVtcw0KPiA+Pg0KPiA+PiBIaSBCcmlh
biwNCj4gPj4NCj4gPj4gWW91IGRlbGV0ZWQgbWF5YmUgYnkgbWlzdGFrZSB0aGUgZmlyc3QgdGhy
ZWUgcGFyYWdyYXBocyBvZiBteSBwcmV2aW91cyBtYWlsLg0KPiA+Pg0KPiA+PiBMZXQgbWUgYWRk
IHRvIHRob3NlIG9uZSBtb3JlIHBvaW50Og0KPiA+Pg0KPiA+PiBQcmV2aW91c2x5IG1vYmlsaXR5
IGdyb3VwcyBpbiBJRVRGIHByb2R1Y2VkIHNpbmdsZSBwcm90b2NvbHMgbGlrZQ0KPiA+PiBNb2Jp
bGUgSVAgb3IgUHJveHkgTW9iaWxlIElQLg0KPiA+PiBUaGVzZSBwcm90b2NvbHMgaGF2ZSBzZWVu
IHNvbWUgb3BlcmF0b3IgYWRvcHRpb24sIG9mIGNvdXJzZSBub3QgbXVjaCBidXQgc29tZS4NCj4g
Pj4gVGhpcyB0aW1lIHdlIHdpbGwgYmUgYXNraW5nIHRoZSBvcGVyYXRvcnMgdG8gYWRvcHQgZXhw
b3NpbmcgbW9iaWxpdHkNCj4gPj4gc3RhdGUgcHJvdG9jb2wsIGVuaGFuY2VkIG1vYmlsaXR5IGFu
Y2hvcmluZyBwcm90b2NvbCBhbmQgZm9yd2FyZGluZw0KPiA+PiBwYXRoIGFuZCBzaWduYWxpbmcg
cHJvdG9jb2wgKG1heWJlIGZvcndhcmRpbmcgcGF0aCBwcm90b2NvbCBhbmQNCj4gPj4gc2lnbmFs
aW5nIHByb3RvY29sKWwuDQo+ID4+IEFuZCBtYXliZSBkZXBsb3ltZW50IG1vZGVscyBwcm90b2Nv
bCB3aGljaCB3YXMgaW4gdGhlIGNoYXJ0ZXIgYnV0DQo+ID4+IHNvbWVob3cgZ290IGRyb3BwZWQu
DQo+ID4+IEhvdyBpcyB0aGF0IGdvaW5nIHRvIGhhcHBlbj8NCj4gDQo+IERvIHlvdSBwbGFuIHRv
IGRpdmlkZSB5b3VyIHNvbHV0aW9uIGludG8NCj4gDQo+IGV4cG9zaW5nIG1vYmlsaXR5IHN0YXRl
IHByb3RvY29sLA0KPiBlbmhhbmNlZCBtb2JpbGl0eSBhbmNob3JpbmcgcHJvdG9jb2wuDQo+ICBm
b3J3YXJkaW5nIHBhdGggcHJvdG9jb2wNCj4gc2lnbmFsaW5nIHByb3RvY29sID8NCj4gDQo+IFRo
YXQgaXMgdGhlIHdheSB0aGluZ3MgYXJlIGdvaW5nLg0KDQpBbGwgb2YgdGhlc2UgdGhpbmdzIEkg
dGhpbmsgaGF2ZSBhcmVhcyBvZiBvdmVybGFwIHdpdGggYXNwZWN0cw0Kb2YgdGhlIEFFUk8gcHJv
cG9zYWwuDQoNCj4gT3RoZXJ3aXNlIHlvdSBhcmUgb2ZmIHRyYWNrLg0KDQpJIHRoaW5rIHRoZSBi
ZXN0IEkgY2FuIGRvIGlzIHJlcHJlc2VudCB0aGUgQUVSTyBwcm9wb3NhbCBhbmQgc3BlYWsNCnRv
IHRoZSBhcmVhcyB3aGVyZSB0aGVyZSBpcyBvdmVybGFwLiBJIHRoaW5rIHdlIGhhdmUgYWxyZWFk
eQ0KZXN0YWJsaXNoZWQgdGhhdCBBRVJPIHNvbHZlcyB0aGUgdHVubmVsIE1UVSBwcm9ibGVtIGFu
ZCB0aGF0IGhhcw0KYXBwbGljYWJpbGl0eSBvdXRzaWRlIG9mIGp1c3QgQUVSTy4gSSBhbSBhbHNv
IGZlZWRpbmcgc29tZSBvZiBteQ0KY29ycmVzcG9uZGVudCBjYXBhYmlsaXR5IGRpc2NvdmVyeSBp
ZGVhcyB0byBBbHBlciBhbmQgdGhhdCBhZ2Fpbg0KaGFzIHdpZGVyIGFwcGxpY2FiaWxpdHkuIFRo
ZSBBRVJPIE5CTUEgbW9kZWwgaXMgYmVpbmcgZGlzY3Vzc2VkDQppbiByZWxhdGlvbiB0byB0aGUg
TUlQL1BNSVAgcG9pbnQtdG8tcG9pbnQgbW9kZWwuIFNpZ25hbGluZyBiYXNlZA0Kb24gcGxhaW4g
b2xkIERIQ1B2NiBhbmQgSVB2Nk5EIGluc3RlYWQgb2Ygc3BlY2lhbGl6ZWQgTW9iaWxpdHkNCkhl
YWRlcnMgaGFzIGFsc28gYmVlbiBkaXNjdXNzZWQuDQoNClNvLCBtYXliZSBJJ20gbm90IHNlZWlu
ZyB0aGUgZm9yZXN0IGZvciB0aGUgdHJlZXMgYnV0IGlmIHlvdQ0KdGhpbmsgSSBhbSBvZmYgdHJh
Y2sgd2hhdCBhbSBJIHN1cHBvc2VkIHRvIGRvIGFib3V0IGl0PyBDb21wbGFpbiwNCm9yIGNvbnRp
bnVlIHRvIGNvbmR1Y3QgYSBwcm9kdWN0aXZlIGludmVzdGlnYXRpb24gYXMgSSBhbSBhbHJlYWR5
DQpkb2luZz8NCg0KPiA+PiBBbnl3YXkgdGhlc2UgYXJlIG15IGNvbmNlcm5zLCBJIGNvdWxkIG5v
dCBhdHRlbmQgSW50ZXJpbSBjYWxsICMyLCBJDQo+ID4+IGJlbGlldmUgbWFueSBwZW9wbGUgY291
bGQgbm90IGluY2x1ZGluZyBKb3VuaS4NCj4gPg0KPiA+IEpvdW5pIHdhcyBhYmxlIHRvIGF0dGVu
ZCB0aGUgY2FsbC4gSSB3YXMgb24gdGhlIGNhbGwgYW5kIGFza2VkIHRoZQ0KPiA+IHF1ZXN0aW9u
IGFzIHRvIHdoZXRoZXIgbm9uLU1JUHY2L1BNSVB2NiBzb2x1dGlvbnMgY291bGQgYmUgY29uc2lk
ZXJlZA0KPiA+IGFuZCB0aGUgYW5zd2VyIEkgZ290IChJIHRoaW5rIGZyb20gSm91bmkpIHdhcyAi
cG9zc2libHkiLg0KPiA+DQo+ID4+IFBlb3BsZSBzaG91bGQgc3BlYWsgdXAsIG90aGVyd2lzZSBp
dCBhcHBlYXJzIGxpa2UgaXQgaXMgb25seSBteSBpc3N1ZS4NCj4gPg0KPiA+IEFFUk8gaXMgYSBz
b2x1dGlvbiBhbHRlcm5hdGl2ZSB0aGF0IEkgd291bGQgbGlrZSB0byBzZWUgdGFrZW4gdW5kZXIN
Cj4gPiB3aWRlciBjb25zaWRlcmF0aW9uIHdpdGhpbiB0aGlzIGRvbWFpbi4gSSB0aGluayB0aGF0
IGlzIHN0YXJ0aW5nIHRvDQo+ID4gaGFwcGVuIHRocm91Z2ggc29tZSBvZiB0aGUgcmVjZW50IGxp
c3QgZGlzY3Vzc2lvbnMsIHNvIG90aGVycyBvbiB0aGUNCj4gPiBsaXN0IHNob3VsZCBub3cgYmUg
Y29taW5nIGF3YXJlIG9mIGl0LiBJIGFsc28gcGxhbiB0byBhdHRlbmQgSUVURjkxDQo+ID4gd2hl
cmUgSSB3b3VsZCBhc2sgZm9yIGFub3RoZXIgQUVSTyBwcmVzZW50YXRpb24gdGltZXNsb3QgaWYg
aXQgd291bGQNCj4gPiBwbGVhc2UgdGhlIHdnIGFuZCB0aGUgY2hhaXJzLg0KPiA+DQo+ID4gU28s
IGl0IHNlZW1zIHRvIG1lIHRoYXQgSSBhbSBhbHJlYWR5IGRvaW5nIGFsbCBJIGNhbi4gRG8geW91
IHRoaW5rDQo+ID4gSSBzaG91bGQgYmUgZG9pbmcgbW9yZT8NCj4gDQo+IEkgdGhpbmsgeW91IGFy
ZSB0cnlpbmcgdG8gcHVzaCB5b3VyIG93biBzb2x1dGlvbg0KDQpJIGFtIGNvbmR1Y3RpbmcgYW4g
aW52ZXN0aWdhdGlvbi4gT3RoZXJzIGhhdmUgam9pbmVkIG1lIGluIGEgZnJpZW5kbHkNCmV4Y2hh
bmdlIG9mIGlkZWFzLiBJcyBpdCB0aGUgd3JvbmcgYXBwcm9hY2g/DQoNCj4gYW5kIHlvdSB0aGlu
ayB0aGF0IHlvdSBhcmUgZWZmZWN0aXZlIGluIGl0Lg0KDQpXaGljaCBtZWFucyB0aGF0IHlvdSB0
aGluayBJIGFtIG5vdCBlZmZlY3RpdmUgaW4gaXQ/DQoNCj4gSSB0aGluayBETU0gc2hvdWxkIHNl
ZSB0aGUgYmlnIHBpY3R1cmUgYW5kIGV2ZXJ5Ym9keSwgaW5jbHVkaW5nIFJ5dWppLA0KPiBTYXRv
cnUgYW5kIG90aGVycyBzaG91bGQgc3BlYWsgdXAuDQoNClN1cmUsIGl0IHdvdWxkIGJlIGdvb2Qg
dG8gaGVhciBmcm9tIHRoZW0uIEkgaGF2ZSBhbHJlYWR5IHNwZWNpZmllZA0KYSBCR1AtYmFzZWQg
ZGlzdHJpYnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBzY2hlbWUgaW4gYm90aCB0aGUgQUVSTw0K
c3BlYyBhbmQgZWFybGllciBpbiBSRkM2MTc5LiAoSSBoYXZlIHJlYWQgdGhlaXIgZHJhZnQ7IEkg
aGF2ZSBubyB3YXkNCm9mIGtub3dpbmcgd2hldGhlciB0aGV5IGhhdmUgcmVhZCBteSBkb2N1bWVu
dHMuKQ0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQogDQo+IFJl
Z2FyZHMsDQo+IA0KPiBCZWhjZXQNCj4gDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4gZnJl
ZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+ID4+IFJlZ2FyZHMsDQo+ID4+DQo+ID4+IEJl
aGNldA0KPiA+Pg0KPiA+PiBPbiBGcmksIFNlcCAyNiwgMjAxNCBhdCAxMToyMiBBTSwgQnJpYW4g
SGFiZXJtYW4NCj4gPj4gPGJyaWFuQGlubm92YXRpb25zbGFiLm5ldD4gd3JvdGU6DQo+ID4+ID4N
Cj4gPj4gPg0KPiA+PiA+IE9uIDkvMjYvMTQgMTE6MTQgQU0sIEJlaGNldCBTYXJpa2F5YSB3cm90
ZToNCj4gPj4gPg0KPiA+PiA+Pg0KPiA+PiA+PiBNeSBxdWVzdGlvbiBpcyB3ZSBkbyB0aGF0IHRo
cmVlIGZvdXIgc29sdXRpb24gZHJhZnRzIGFuZCBzb21lIG9mIHRoZW0NCj4gPj4gPj4gaW1wbGVt
ZW50ZWQuDQo+ID4+ID4+IFdoYXQgZG8gd2UgZG8gd2l0aCB0aGVtPw0KPiA+PiA+DQo+ID4+ID4g
TXkgZXhwZWN0YXRpb24sIGFzIEFELCBpcyB0aGF0IHRoZSBXRyB3aWxsIGFzc2VzcyB0aGUgZHJh
ZnRzIHByZXNlbnRlZA0KPiA+PiA+IGJ5IHRoZXNlIHRlYW1zIGZvciBhZG9wdGlvbi4gIFBlb3Bs
ZSdzIG9waW5pb24gb2YgdGhvc2UgZHJhZnRzIHNob3VsZA0KPiA+PiA+IG5vdCBiZSBpbmZsdWVu
Y2VkIGJ5IHRoZSBmYWN0IHRoZXkgd2VyZSB3cml0dGVuIGJ5IGEgdGVhbS4NCj4gPj4gPg0KPiA+
PiA+Pg0KPiA+PiA+PiBNeSBhZHZpY2UgdG8gdGhvc2UgY29sbGVhZ3VlcyB3aXNoaW5nIHRvIGxl
YWQgdGhlIGRlc2lnbiB0ZWFtcyBpcyB0bw0KPiA+PiA+PiBwbGVhc2UgY29tZSB1cCB3aXRoIHlv
dXIgb3duIHNvbHV0aW9uIGFuZCBnZXQgaW50byB0aGUgcmFjZSB3aXRoDQo+ID4+ID4+IG90aGVy
cy4NCj4gPj4gPg0KPiA+PiA+IFJhY2U/DQo+ID4+ID4NCj4gPj4gPj4gSG93IGNvbWUgdGhleSBj
YW4gZ2V0IHRoZSBoYXQgb2YgRFQgbGVhZCBhbmQgcHJvZHVjZSBzb21ldGhpbmcgYW5kIGdldA0K
PiA+PiA+PiBwcmlvcml0eSBvdmVyIG90aGVycyB3aG8gd29ya2VkIHNvIGhhcmQ/DQo+ID4+ID4N
Cj4gPj4gPiBGaXJzdCBvZiBhbGwsIHRoZSBjaGFpcnMgYXJlIHdlbGwgd2l0aGluIHRoZWlyIHJp
Z2h0IHRvIGFwcG9pbnQgRFQNCj4gPj4gPiBsZWFkcy4gIFRoZXkgY291bGQgaGF2ZSBhcHBvaW50
ZWQgYWxsIHRoZSBvdGhlciBzbG90cyBvbiB0aGUgRFQgYXMgd2VsbCwNCj4gPj4gPiBidXQgY2hv
c2UgdG8gYXNrIGZvciB2b2x1bnRlZXJzLg0KPiA+PiA+DQo+ID4+ID4gSSBkbyBub3Qgc2VlIGFu
eXRoaW5nIGluIEpvdW5pJ3Mgbm90ZSB0aGF0IGluZGljYXRlcyB0aGF0IGEgdGVhbSdzDQo+ID4+
ID4gb3V0cHV0IGdldHMgYW55IHByZWZlcmVudGlhbCB0cmVhdG1lbnQuICBUaGUgcnVsZXMgb2Yg
dGhlIElFVEYgcHJldmVudCB0aGF0Lg0KPiA+PiA+DQo+ID4+ID4gVG8gcmUtZW5mb3JjZSBKb3Vu
aSdzIGxhc3Qgc2VudGVuY2UuLi4NCj4gPj4gPg0KPiA+PiA+Pj4gVGhlc2UgZG9jdW1lbnRzIHdp
bGwgYmUgZXF1aXZhbGVudCB0byBhbnkgaW5kaXZpZHVhbCBwcm9kdWNlZCBJLUQsIHRob3VnaC4N
Cj4gPj4gPg0KPiA+PiA+IFJlZ2FyZHMsDQo+ID4+ID4gQnJpYW4NCj4gPj4gPg0KPiA+PiA+DQo+
ID4+ID4NCj4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiA+PiA+IGRtbSBtYWlsaW5nIGxpc3QNCj4gPj4gPiBkbW1AaWV0Zi5vcmcNCj4gPj4g
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPiA+PiA+DQo+ID4+
DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
ID4+IGRtbSBtYWlsaW5nIGxpc3QNCj4gPj4gZG1tQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo=


From nobody Tue Sep 30 07:19:16 2014
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 EBE461A1A16 for ; Tue, 30 Sep 2014 07:19:13 -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 f2AOzSJNtjQa for ; Tue, 30 Sep 2014 07:19:13 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA49B1A1A12 for ; Tue, 30 Sep 2014 07:19:12 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id w7so3283536lbi.22 for ; Tue, 30 Sep 2014 07:19:11 -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=1I+wWlBSPFLGJ50UGyhhXqeTjZkTE/1atmnsk5cDMFw=; b=F6b8ShXIt3nYR/KrQGd5saQD2F5wGJooUvRwXcivrScON1zEcDYwJcfmYueIokRWON yfbw/7+amxjwxr3OTToHL1k+1mt8L4x8khc9deaYzIycUYyXtjzXUtUw981igrBtl1Z7 lZVZ+MnO03XYu9KQtP5zFjwIImy8ZmiFDF4rWui4h8V7i9bfctozqbJDsClBgLWIUtwb ubq0yvTn+/DbLnUjIqjO0WGWvCt8gUkHOiR8hVOMXi/SuYPyjxEyaCMoYp5Sxyh30J4C +GSqsC3kctHmhl1SIVK99lJRAaQ1IPTTJvq2xxqtbAnu2B/pVsIjQLuDjxSLoat0L7ZJ YXag==
MIME-Version: 1.0
X-Received: by 10.112.198.131 with SMTP id jc3mr43305286lbc.42.1412086749292;  Tue, 30 Sep 2014 07:19:09 -0700 (PDT)
Received: by 10.114.77.37 with HTTP; Tue, 30 Sep 2014 07:19:09 -0700 (PDT)
In-Reply-To: <542947C6.8020600@gmail.com>
References: <542947C6.8020600@gmail.com>
Date: Tue, 30 Sep 2014 09:19:09 -0500
Message-ID: 
From: Behcet Sarikaya 
To: Jouni Korhonen 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/eQghFT350vtwJmMXxT4PCpSIP5s
Cc: H Anthony Chan , "dmm@ietf.org" 
Subject: Re: [DMM] Interim call #3 approaching
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: Tue, 30 Sep 2014 14:19:14 -0000

Hi Jouni,

On Mon, Sep 29, 2014 at 6:51 AM, Jouni Korhonen  wrote:
> Folks,
>
> The interim call #3 is approaching and it is time for the agenda building.
>

Please mention the date. When I saw this mail I thought the call was
on Sept. 30 :-)


> "Work Team" leads should prepare to give an update on their side. Other than
> that if you have something DMMish to share, let the chairs know.

Please give the right name. I think AD says it is DT.

Regards,

Behcet
>
> - Jouni & Dapeng
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From nobody Tue Sep 30 13:54:02 2014
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 443EB1A8A82 for ; Tue, 30 Sep 2014 13:54:00 -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 Y3SUI3g9xkzE for ; Tue, 30 Sep 2014 13:53:58 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6541A8A60 for ; Tue, 30 Sep 2014 13:53:58 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id u10so7555089lbd.28 for ; Tue, 30 Sep 2014 13:53:56 -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=DxGyUgc72RyLUrYfCNapN7Mr21CLGPm/mamtZQuRy1k=; b=TcY58DWrdA2Azu6PNNjkwYYZpq3FHQjWjvXFX2UsA6nOog1li+nVPQkIomY6WCik0m /aVPAPpMqBgzGXe1x/wW+w1jvVHTC6IWdOr5v2WEi4f+YEf8sfzAgD1ka5vckhKvtCiS uuf7RDchsJpUaIb5TEqsXX0tsMiiyWQsLuORBq5zzUZ6qVg13cwwDZJXAscJGnnfyPlc o2iCFsDr2WIFu65RugTxoBV7Y24nQSBb6pWrhudR9cKyQPbaR6FiBBCEyzqm4mFfrU32 MR05ht7371OdotVY5xJhrbDYIdk7SzW/yks5x6Ee4uaGloPRQbSzNwd9Fw+PB9J8sD+o yz9g==
X-Received: by 10.152.88.97 with SMTP id bf1mr50031305lab.58.1412110436853; Tue, 30 Sep 2014 13:53:56 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:19a0:4804:57a9:fbf1? ([2001:1bc8:101:f101:19a0:4804:57a9:fbf1]) by mx.google.com with ESMTPSA id qm12sm4183306lbc.27.2014.09.30.13.53.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 13:53:55 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jouni 
In-Reply-To: 
Date: Tue, 30 Sep 2014 23:53:52 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <542947C6.8020600@gmail.com> 
To: sarikaya@ieee.org
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/5lzgbmibY3Cokg40W9lRWZXsFKw
Cc: H Anthony Chan , "dmm@ietf.org" 
Subject: Re: [DMM] Interim call #3 approaching
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, 30 Sep 2014 20:54:00 -0000

On Sep 30, 2014, at 5:19 PM, Behcet Sarikaya wrote:

> Hi Jouni,
>=20
> On Mon, Sep 29, 2014 at 6:51 AM, Jouni Korhonen =
 wrote:
>> Folks,
>>=20
>> The interim call #3 is approaching and it is time for the agenda =
building.
>>=20
>=20
> Please mention the date. When I saw this mail I thought the call was
> on Sept. 30 :-)

http://www.ietf.org/mail-archive/web/dmm/current/msg01583.html

- jouni

>>=20
>> "Work Team" leads should prepare to give an update on their side. =
Other than
>> that if you have something DMMish to share, let the chairs know.
>=20
> Please give the right name. I think AD says it is DT.
>=20
> Regards,
>=20
> Behcet
>>=20
>> - Jouni & Dapeng
>>=20
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm