[DMM] Re: draft-liebsch-dmm-mts-03 review
Marco Liebsch <[email protected]> Fri, 26 Sep 2025 13:18:24 +0000
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <FR0P281MB15961EB093CFBCEB08ED562EE51EA__13122.1788747766$1758892783$gmane$org@FR0P281MB1596.DEUP281.PROD.OUTLOOK.COM> |
--===============8805176287172368955== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0023_01DC2EF8.CC73F1F0" ------=_NextPart_000_0023_01DC2EF8.CC73F1F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0024_01DC2EF8.CC73F1F0" ------=_NextPart_001_0024_01DC2EF8.CC73F1F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi John, many thanks for your constructive comments and suggestions. Please see for feedback inline [ml]. =20 =20 From: Kaippallimalil John <[email protected]>=20 Sent: Montag, 22. September 2025 15:11 To: Distributed Mobility Management Discussion List <[email protected]>; = Marco Liebsch <[email protected]> Subject: draft-liebsch-dmm-mts-03 review =20 Hi Marco, All, =20 The draft identifies a gap/problem in 5G systems and the need to = (re)select and steer flows. This draft can provide value and insight into a complex area. There are = gaps currently as 5G/3GPP does not fully cover the N6/IP segments of the = E2E path. However, the draft describes too much of existing/standards (using = different names and terms), and it is not easy for a reader to = distinguish the gaps from already specified standards. A couple of suggestions: 1. Since the architecture in section 4 is 5G, why not use the same = terminology/refer to TS 23.501. And add concepts that are new. This will make the text shorter and allow readers to see clearly what = the gaps are. For example, what part of the architecture in Figure 4 is = covered in 23.501, and what isn=E2=80=99t (same for many others). [ml] The draft proposes a solution that applies to a general mobile = communication system architecture that also 3GPP follows. Most relevant = for the draft is the mobile architecture=E2=80=99s entry points for user- and control-plane, which we depict in the reference = architecture of a mobile communication system. Intention from the very = beginning was to keep the draft independent of 3GPP but complementary and compatible with a general function architecture of = mobile communication systems. However, applicability and compatibility = with the 3GPP architecture is of course wanted. Keeping the draft independent of the current 3GPP specs was also = requested from various sides. We can discuss if and how it could be = addressed for information, if needed. =20 2. Regarding the gaps, there are architectural principles and options in = section 5 + but the draft does not outline the tradeoffs or say when one = option is preferrable over the other.=20 For example: if services/network require to only maximize bandwidth = utilization vs. guarantees on latency/bandwidth. And, resilience, = complexity (e.g., O(n^2) vs O (n), scalability, etc. =20 [ml] Good point, we will add more details about when a particular = deployment is preferrable and where the tradeoff is. Also for the = operational details we plan to add more details in the next revision. Another aspect is the relation between this draft and CATS. Where are = they complementary, or an alternative and the rationale for choosing = among these methods of steering. =20 [ml] We presented the MTS draft in CATS during IETF123 to make the group = aware and explained where is complements CATS and how their architecture = can use it. It=E2=80=99s between the CATS control plane and the mobile communication system in case CATS applies not only to = compute-aware traffic steering but if they need to inter-work with = mobile communication systems. We offered help in capturing this in their work and documents, e.g. in = terms of clear interfaces and synergies. =20 =20 Some detailed comments: a. Abstract & section 4.1 refer to =E2=80=9Ctwo architectural = principles=E2=80=9D but is not clarified what it is until much later.=20 The reader must read until section 5 to understand what it is about = steering. It should be stated much earlier and described later for = easier reading. [ml] Valid point, we=E2=80=99ll capture the aspects of later details and = differences coming with these options earlier in the draft. Thanks. A = result from adding more specifications and details in the back and not checking if these are properly introduced at = the beginning of the document =F0=9F=98=89 =20 b. Section 2 / Introduction: discusses =E2=80=9C how existing or new = IETF technology can serve as enabler to accomplish service continuity = for a mobile user in such agile and dynamic system by means of = controlled treatment of a mobile user's end-to-end traffic for steering, = with an option to extend for advanced treatment policies, such as = traffic engineering.=E2=80=9D Many concepts, and options make it hard to follow: (1) the scope has steering and =E2=80=9Cadvanced treatment = policies=E2=80=9D, and steering policies. What exactly are the = differences?=20 [ml] Thanks for the hint, we will be more thorough in the use of these = terms and include clarifying details once to let the reader know how we = use these terms in the context of the draft. (2) does advanced treatment policies refer to QoS aspects? [ml] Yes, steering is the primary objective but early when discussing = this work there were views that QoS should be covered. So, beyond = steering, advanced policies can address QoS, metering, etc. We will be = more clear in a revision. (3) steering and service continuity: does user mobility trigger = steering, or does measurement on path trigger steering, or both? [ml] it=E2=80=99s both and even beyond that. We see various triggers = that require steering and want to clarify this in the use cases section. = User mobility is typically handled by the mobile communication system, keeping a stable user plane anchor point. We do not touch this. Now and = in the future, more re-configurations are/will be supported by mobile = communication systems that may re-locate such anchor point or use multiple anchor points concurrently in the view of route = optimization between a mobile device and its multiple used service in = distributed data centers. Also a change in the transport network, e.g. failure or movement of a data plane node may require updated = steering policies. Please consider that the draft wants to complement a = mobile communication system by means of inter-working and not interfere with it. (4) The draft has many terms like =E2=80=9Cflexible deployment=E2=80=9D, = dynamic re-configurability, complexity which can be understood in = different ways. c. Section 4.2. MCS Proactive UPA relocation : = =E2=80=9Cproactive=E2=80=9D is a bit confusing and depends on = perspective.=20 (1) =E2=80=9CDue to mobility, the MCS may relocate the mobile user's UPA = from UPA1 to UPA2=E2=80=9D: that would seem more reactive?=20 [ml] From the viewpoint of the transport network and the MTS controller = it=E2=80=99s proactive by the mobile communication system, while the = transport network needs to react. Scenario per Sec. 4.3 is reactive, where the MTS controller or further instance on the path towards the = data network forces a change in traffic steering, and the mobile = communication system needs to react according to the MTS = controller=E2=80=99s advice. Let us again parse the description and we=E2=80=99ll try to be clearer = here in case it=E2=80=99s confusing. (2) =E2=80=9CIn case the user's IP address needs to continue only as = long as the data session with ASF1 takes ..=E2=80=9D How does UPA know = how long the session lasts?=20 [ml] You are right, we take an assumption on the transient use of a = user=E2=80=99s IP address before it=E2=80=99s deprecated and at some = point in time the UE starts using a newer address. Temporarily it may = keep both addresses until sessions, that use the older address, terminate. A case often = discussed in the past, while details about its implementation differ. = For this draft such control is considered out of scope. Let us parse this use case again and see how much details can be assumed = as they are not relevant for MTS between a user plane anchor and the = data network, and what else we need to consider in the draft. This is something we can investigate and address in the information/data = model that the draft defines, in case associated semantic is useful on = the addressed interface. =20 d. Section 4.2 =E2=80=9CIn order to keep routing paths short and latency = low, the ASF may be relocated from ASF1 to ASF2=E2=80=9D. How does ASF = /data network know how to do this? Does MCS proactively relocate the UPA (UPA1 -> UPA2) based on some = measurements of the path UPA1 =E2=80=93 ASF1 and expect to have better = performance after the move UPA2 -> ASF1? =20 [ml] Similar to the above, it may be negotiated and controlled within or = between data networks. 3GPP addressed such cases in the past by means of = single/multiple Application Function (AF) per Application Service (AS), and inter-actions between them to coordinate such relocation. Also, in = the past discussion about technical enabler for edge computing, = relocation of serving edges has been discussed. Same here, let us see and discuss what we need in the information/data = model for the MTS interface to support such case, and then we should add = it. Please consider we plan to have a clear scope of the interface that we = want to support and in particular an interface between the MTS = Controller and any data network services is out of scope. Maybe another = touchpoint with CATS, which has inter-working between compute sites and a CATS control plane, = according to my knowledge. =20 =20 e. Section 4.4: =E2=80=9CA MCS provide may deploy distributed UPAs in = order to shorten the route and resulting latency for the communication = between two mobile users=E2=80=9D Why is there a need to move UPA for shorter paths? Isn=E2=80=99t it = possible to have a routed network (with DPNs) that select the = shortest/lower latency path etc. The problem seems to be that the UPA is not distributed enough (that one = has to move from UPA1 -> UPA2 to get a shorter path to UPA3) [ml] The rationale behind this is when the mobile communication system = has far-edge kind of distributed user plane anchors, in an extreme case = anchor co-located with radio base station (similar to the ANUP draft in = DMM). Here the anchor should be relocated in alignment with a handover between = a user=E2=80=99s radio base station. DPN associated with an anchor needs = steering rules to forward data plane packets to the new, re-located user = plane anchor of its communication peer. But I understand and agree that more = clarifying description for this use case is needed, e.g. by means of = added incremental steps with description to the text. We=E2=80=99ll = implement this in the next revision. =20 f. Section 5:/ deployment options. Between the different options what is = the trade-off in terms of scale and complexity (of = provisioning/maintaining the paths) See overall comments also. [ml] Understood and confirmed as part of your comment (2) above. We will = introduce the rationale behind these options earlier in the draft and = details about advantages and constraints with each options in Sec. 5. Again, many comments and suggestions that help us improving the = document. Many thanks, John. Best regards, marco =20 =20 Best Regards, John ------=_NextPart_001_0024_01DC2EF8.CC73F1F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dutf-8"> <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta name=3DGenerator = content=3D"Microsoft Word 15 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Aptos;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:12.0pt; font-family:"Aptos",sans-serif; mso-ligatures:standardcontextual;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:36.0pt; font-size:12.0pt; font-family:"Aptos",sans-serif; mso-ligatures:standardcontextual;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:324826316; mso-list-template-ids:214334088;} @list l0:level1 {mso-level-start-at:5; mso-level-number-format:alpha-lower; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level3 {mso-level-number-format:alpha-lower; mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level4 {mso-level-number-format:alpha-lower; mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level6 {mso-level-number-format:alpha-lower; mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level7 {mso-level-number-format:alpha-lower; mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l0:level9 {mso-level-number-format:alpha-lower; mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l1 {mso-list-id:509108239; mso-list-type:hybrid; mso-list-template-ids:-474594134 67698703 67698713 67698715 67698703 = 67698713 67698715 67698703 67698713 67698715;} @list l1:level1 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} @list l1:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} @list l1:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l1:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} @list l2 {mso-list-id:1207983748; mso-list-template-ids:1579427090;} @list l3 {mso-list-id:1883058533; mso-list-type:hybrid; mso-list-template-ids:-1095222864 67698711 -1 -1 -1 -1 -1 -1 -1 -1;} @list l3:level1 {mso-level-number-format:alpha-lower; mso-level-text:"%1\)"; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt;} @list l3:level2 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt; font-family:"Courier New";} @list l3:level3 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt; font-family:Wingdings;} @list l3:level4 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt; font-family:Symbol;} @list l3:level5 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt; font-family:"Courier New";} @list l3:level6 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt; font-family:Wingdings;} @list l3:level7 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt; font-family:Symbol;} @list l3:level8 {mso-level-number-format:bullet; mso-level-text:o; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt; font-family:"Courier New";} @list l3:level9 {mso-level-number-format:bullet; mso-level-text:\F0A7; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-18.0pt; font-family:Wingdings;} @list l4 {mso-list-id:2057928343; mso-list-template-ids:1607395626;} @list l4:level1 {mso-level-number-format:alpha-lower; mso-level-tab-stop:36.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:72.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level3 {mso-level-number-format:alpha-lower; mso-level-tab-stop:108.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level4 {mso-level-number-format:alpha-lower; mso-level-tab-stop:144.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:180.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level6 {mso-level-number-format:alpha-lower; mso-level-tab-stop:216.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level7 {mso-level-number-format:alpha-lower; mso-level-tab-stop:252.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:288.0pt; mso-level-number-position:left; text-indent:-18.0pt;} @list l4:level9 {mso-level-number-format:alpha-lower; mso-level-tab-stop:324.0pt; mso-level-number-position:left; text-indent:-18.0pt;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DDE = link=3D"#467886" vlink=3D"#96607D" style=3D'word-wrap:break-word'><div = class=3DWordSection1><p class=3DMsoNormal><span lang=3DEN-GB = style=3D'mso-fareast-language:EN-US'>Hi John,<br><br>many thanks for = your constructive comments and suggestions.<o:p></o:p></span></p><p = class=3DMsoNormal><span lang=3DEN-GB = style=3D'mso-fareast-language:EN-US'>Please see for feedback inline = [ml].<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-GB = style=3D'mso-fareast-language:EN-US'><o:p> </o:p></span></p><p = class=3DMsoNormal><span lang=3DEN-GB = style=3D'mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><di= v style=3D'border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm'><p class=3DMsoNormal><b><span lang=3DEN-US = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;mso-ligatures:= none'>From:</span></b><span lang=3DEN-US = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;mso-ligatures:= none'> Kaippallimalil John <[email protected]> = <br><b>Sent:</b> Montag, 22. September 2025 15:11<br><b>To:</b> = Distributed Mobility Management Discussion List <[email protected]>; = Marco Liebsch <[email protected]><br><b>Subject:</b> = draft-liebsch-dmm-mts-03 review<o:p></o:p></span></p></div></div><p = class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><span = lang=3DEN-US>Hi Marco, All,<o:p></o:p></span></p><p = class=3DMsoNormal><span lang=3DEN-US><o:p> </o:p></span></p><p = class=3DMsoNormal><span lang=3DEN-US>The draft identifies a gap/problem = in 5G systems and the need to (re)select and steer = flows.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span lang=3DEN-US>This draft can provide = value and insight into a complex area. There are gaps currently as = 5G/3GPP does not fully cover the N6/IP segments of the E2E = path.<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>However, the draft describes too much of existing/standards = (using different names and terms), and it is not easy for a reader to = distinguish the gaps from already specified = standards.<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>A couple of suggestions:<o:p></o:p></span></p><ol = style=3D'margin-top:0cm' start=3D1 type=3D1><li class=3DMsoListParagraph = style=3D'margin-bottom:12.0pt;margin-left:0cm;mso-list:l1 level1 = lfo3'><span lang=3DEN-US>Since the architecture in section 4 is 5G, why = not use the same terminology/refer to TS 23.501. And add concepts that = are new.<br>This will make the text shorter and allow readers to see = clearly what the gaps are. For example, what part of the architecture in = Figure 4 is covered in 23.501, and what isn=E2=80=99t (same for many = others).<o:p></o:p></span></li></ol><p class=3DMsoNormal><span = lang=3DEN-US>[ml] The draft proposes a solution that applies to a = general mobile communication system architecture that also 3GPP follows. = Most relevant for the draft is the mobile architecture=E2=80=99s entry = points<br>for user- and control-plane, which we depict in the reference = architecture of a mobile communication system. Intention from the very = beginning was to keep the draft independent of 3GPP but<br>complementary = and compatible with a general function architecture of mobile = communication systems. However, applicability and compatibility with the = 3GPP architecture is of course wanted.<o:p></o:p></span></p><p = class=3DMsoNormal><span lang=3DEN-US>Keeping the draft independent of = the current 3GPP specs was also requested from various sides. We can = discuss if and how it could be addressed for information, if = needed.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span = lang=3DEN-US><o:p> </o:p></span></p><ol style=3D'margin-top:0cm' = start=3D2 type=3D1><li class=3DMsoListParagraph = style=3D'margin-left:0cm;mso-list:l1 level1 lfo3'><span = lang=3DEN-US>Regarding the gaps, there are architectural principles and = options in section 5 + but the draft does not outline the tradeoffs or = say when one option is preferrable over the other. <br>For example: if = services/network require to only maximize bandwidth utilization vs. = guarantees on latency/bandwidth. And, resilience, complexity = (e.g., O(n^2) vs O (n), scalability, = etc.<o:p></o:p></span></li></ol><p class=3DMsoNormal><span lang=3DEN-US = style=3D'background:lime;mso-highlight:lime'><o:p> </o:p></span></p>= <p class=3DMsoNormal><span lang=3DEN-US>[ml] Good point, we will add = more details about when a particular deployment is preferrable and where = the tradeoff is. Also for the operational details we plan to add more = details in the next revision.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-left:36.0pt'><span lang=3DEN-US><br>Another aspect is = the relation between this draft and CATS. Where are they complementary, = or an alternative and the rationale for choosing among these methods of = steering.<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>[ml] We presented the MTS draft in CATS during IETF123 to = make the group aware and explained where is complements CATS and how = their architecture can use it. It=E2=80=99s between the CATS control = plane<br>and the mobile communication system in case CATS applies not = only to compute-aware traffic steering but if they need to inter-work = with mobile communication systems.<br>We offered help in capturing this = in their work and documents, e.g. in terms of clear interfaces and = synergies.<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>Some detailed comments:<o:p></o:p></span></p><ol = style=3D'margin-top:0cm' start=3D1 type=3Da><li class=3DMsoListParagraph = style=3D'margin-bottom:12.0pt;margin-left:0cm;mso-list:l3 level1 = lfo6'><span lang=3DEN-US>Abstract & section 4.1 refer to = =E2=80=9C</span><span lang=3DEN-US style=3D'font-family:"Courier = New"'>two architectural principles</span><span lang=3DEN-US>=E2=80=9D = but is not clarified what it is until much later. <br>The reader must = read until section 5 to understand what it is about steering. It should = be stated much earlier and described later for easier = reading.<o:p></o:p></span></li></ol><p class=3DMsoNormal><span = lang=3DEN-US>[ml] Valid point, we=E2=80=99ll capture the aspects of = later details and differences coming with these options earlier in the = draft. Thanks. A result from adding more specifications and<br>details = in the back and not checking if these are properly introduced at the = beginning of the document </span><span lang=3DEN-US = style=3D'font-family:"Segoe UI = Emoji",sans-serif'>=F0=9F=98=89</span><span = lang=3DEN-US><o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span = lang=3DEN-US><o:p> </o:p></span></p><ol style=3D'margin-top:0cm' = start=3D2 type=3Da><li class=3DMsoListParagraph = style=3D'margin-bottom:12.0pt;margin-left:0cm;mso-list:l3 level1 = lfo6'><span lang=3DEN-US>Section 2 / Introduction: discusses =E2=80=9C = how existing or new IETF technology can serve as enabler to accomplish = service continuity for a mobile user in such agile and dynamic system by = means of controlled treatment of a mobile user's end-to-end traffic for = steering, with an option to extend for advanced treatment policies, such = as traffic engineering.=E2=80=9D<br>Many concepts, and options make it = hard to follow:<br>(1) the scope has steering and =E2=80=9Cadvanced = treatment policies=E2=80=9D, and steering policies. What exactly are the = differences? <o:p></o:p></span></li></ol><p class=3DMsoNormal><span = lang=3DEN-US>[ml] Thanks for the hint, we will be more thorough in the = use of these terms and include clarifying details once to let the reader = know how we use these terms in the context of the = draft.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;mar= gin-left:36.0pt'><span lang=3DEN-US><br>(2) does advanced treatment = policies refer to QoS aspects?<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span lang=3DEN-US>[ml] Yes, steering is = the primary objective but early when discussing this work there were = views that QoS should be covered. So, beyond steering, advanced policies = can address QoS, metering, etc. We will be more clear in a = revision.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;mar= gin-left:36.0pt'><span lang=3DEN-US><br>(3) steering and service = continuity: does user mobility trigger steering, or does measurement on = path trigger steering, or both?<o:p></o:p></span></p><p = class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span lang=3DEN-US>[ml] = it=E2=80=99s both and even beyond that. </span><span lang=3DEN-US>We see = various triggers that require steering and want to clarify this in the = use cases section. User mobility is typically handled by the mobile = communication system,<br>keeping a stable user plane anchor point. We do = not touch this. Now and in the future, more re-configurations are/will = be supported by mobile communication systems that may re-locate such = anchor<br>point or use multiple anchor points concurrently in the view = of route optimization between a mobile device and its multiple used = service in distributed data centers. Also a change in the transport = network,<br>e.g. failure or movement of a data plane node may require = updated steering policies. Please consider that the draft wants to = complement a mobile communication system by means of<br>inter-working = and not interfere with it.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;mar= gin-left:36.0pt'><span lang=3DEN-US><br>(4) The draft has many terms = like =E2=80=9Cflexible deployment=E2=80=9D, dynamic re-configurability, = complexity which can be understood in different = ways.<o:p></o:p></span></p><ol style=3D'margin-top:0cm' start=3D3 = type=3Da><li class=3DMsoListParagraph = style=3D'margin-bottom:12.0pt;margin-left:0cm;mso-list:l3 level1 = lfo6'><span lang=3DEN-US>Section 4.2. MCS Proactive UPA relocation : = =E2=80=9Cproactive=E2=80=9D is a bit confusing and depends on = perspective. <br>(1) =E2=80=9CDue to mobility, the MCS may relocate the = mobile user's UPA from UPA1 to UPA2=E2=80=9D: that would seem more = reactive? <o:p></o:p></span></li></ol><p class=3DMsoNormal><span = lang=3DEN-US>[ml] From the viewpoint of the transport network and the = MTS controller it=E2=80=99s proactive by the mobile communication = system, while the transport network needs to react. Scenario per Sec. = 4.3 is reactive,<br>where the MTS controller or further instance = on the path towards the data network forces a change in traffic = steering, and the mobile communication system needs to react according = to the MTS controller=E2=80=99s advice.<br>Let us again parse the = description and we=E2=80=99ll try to be clearer here in case = it=E2=80=99s confusing.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;mar= gin-left:36.0pt'><span lang=3DEN-US><br>(2) =E2=80=9CIn case the user's = IP address needs to continue only as long as the data session with ASF1 = takes ..=E2=80=9D How does UPA know how long the session lasts? = <o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span lang=3DEN-US>[ml] </span><span = lang=3DEN-US>You are right, we take an assumption on the transient use = of a user=E2=80=99s IP address before it=E2=80=99s deprecated and at = some point in time the UE starts using a newer address. Temporarily it = may keep both addresses<br>until sessions, that use the older address, = terminate. A case often discussed in the past, while details about its = implementation differ. For this draft such control is considered = out of scope.<br>Let us parse this use case again and see how much = details can be assumed as they are not relevant for MTS between a user = plane anchor and the data network, and what else we need to consider in = the draft.<br>This is something we can investigate and address in the = information/data model that the draft defines, in case associated = semantic is useful on the addressed interface.<o:p></o:p></span></p><p = class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span = lang=3DEN-US><o:p> </o:p></span></p><ol style=3D'margin-top:0cm' = start=3D4 type=3Da><li class=3DMsoListParagraph = style=3D'margin-left:0cm;mso-list:l3 level1 lfo6'><span = lang=3DEN-US>Section 4.2 =E2=80=9CIn order to keep routing paths short = and latency low, the ASF may be relocated from ASF1 to ASF2=E2=80=9D. = How does ASF /data network know how to do this?<br>Does MCS proactively = relocate the UPA (UPA1 -> UPA2) based on some measurements of the = path UPA1 =E2=80=93 ASF1 and expect to have better performance after the = move UPA2 -> ASF1?<o:p></o:p></span></li></ol><p = class=3DMsoNormal><span lang=3DEN-US = style=3D'background:lime;mso-highlight:lime'><o:p> </o:p></span></p>= <p class=3DMsoNormal><span lang=3DEN-US>[ml] </span><span = lang=3DEN-US>Similar to the above, it may be negotiated and controlled = within or between data networks. 3GPP addressed such cases in the past = by means of single/multiple Application Function (AF) per Application = Service (AS),<br>and inter-actions between them to coordinate such = relocation. Also, in the past discussion about technical enabler for = edge computing, relocation of serving edges has been discussed.<br>Same = here, let us see and discuss what we need in the information/data model = for the MTS interface to support such case, and then we should add = it.<br>Please consider we plan to have a clear scope of the interface = that we want to support and in particular an interface between the MTS = Controller and any data network services is out of scope. Maybe another = touchpoint with CATS,<br>which has inter-working between compute sites = and a CATS control plane, according to my = knowledge.<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p = class=3DMsoListParagraph><span = lang=3DEN-US><o:p> </o:p></span></p><ol style=3D'margin-top:0cm' = start=3D5 type=3Da><li class=3DMsoListParagraph = style=3D'margin-bottom:12.0pt;margin-left:0cm;mso-list:l3 level1 = lfo6'><span lang=3DEN-US>Section 4.4: =E2=80=9CA MCS provide may deploy = distributed UPAs in order to shorten the route and resulting latency for = the communication between two mobile users=E2=80=9D<br>Why is there a = need to move UPA for shorter paths? Isn=E2=80=99t it possible to have a = routed network (with DPNs) that select the shortest/lower latency path = etc.<br>The problem seems to be that the UPA is not distributed enough = (that one has to move from UPA1 -> UPA2 to get a shorter path to = UPA3)<o:p></o:p></span></li></ol><p class=3DMsoNormal><span = lang=3DEN-US>[ml] The rationale behind this is when the mobile = communication system has far-edge kind of distributed user plane = anchors, in an extreme case anchor co-located with radio base station = (similar to the ANUP draft in DMM).<br>Here the anchor should be = relocated in alignment with a handover between a user=E2=80=99s radio = base station. DPN associated with an anchor needs steering rules to = forward data plane packets to the new, re-located user plane<br>anchor = of its communication peer. But I understand and agree that more = clarifying description for this use case is needed, e.g. by means of = added incremental steps with description to the text. We=E2=80=99ll = implement this in<br>the next revision.<o:p></o:p></span></p><p = class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span = lang=3DEN-US><o:p> </o:p></span></p><ol style=3D'margin-top:0cm' = start=3D6 type=3Da><li class=3DMsoListParagraph = style=3D'margin-bottom:12.0pt;margin-left:0cm;mso-list:l3 level1 = lfo6'><span lang=3DEN-US>Section 5:/ deployment options. Between the = different options what is the trade-off in terms of scale and complexity = (of provisioning/maintaining the paths)<br>See overall comments = also.<o:p></o:p></span></li></ol><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span lang=3DEN-US>[ml] Understood and = confirmed as part of your comment (2) above. We will introduce the = rationale behind these options earlier in the draft and details about = advantages and constraints<br>with each options in Sec. = 5.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span lang=3DEN-US>Again, many comments = and suggestions that help us improving the document. Many thanks, = John.<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span lang=3DEN-US>Best = regards,<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span = lang=3DEN-US>marco<o:p></o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal = style=3D'margin-bottom:12.0pt'><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>Best Regards,<o:p></o:p></span></p><p = class=3DMsoNormal><span = lang=3DEN-US>John<o:p></o:p></span></p></div></body></html> ------=_NextPart_001_0024_01DC2EF8.CC73F1F0-- ------=_NextPart_000_0023_01DC2EF8.CC73F1F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISGjCCBaow ggOSoAMCAQICEFVS+B7bGyQsnruWGM0CKD4wDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCR1Ix NzA1BgNVBAoMLkhlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ0Ex JzAlBgNVBAMMHkhBUklDQSBDbGllbnQgUlNBIFJvb3QgQ0EgMjAyMTAeFw0yMTAyMTkxMDU4NDZa Fw00NTAyMTMxMDU4NDVaMG8xCzAJBgNVBAYTAkdSMTcwNQYDVQQKDC5IZWxsZW5pYyBBY2FkZW1p YyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENBMScwJQYDVQQDDB5IQVJJQ0EgQ2xpZW50IFJT QSBSb290IENBIDIwMjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCB21dCkCx0NfT4 uHQZTasJWndFgXNisDWf+NC3MwCHE7aWqw5UEjAHvJu3SNfRGYOujtip8akAhLCMXp7oDI9Uab/2 1AhPJnD+GEFjGrMyi0D4B6tXMfDGFnZnmrTdL/LRa8XQkoSRcW4PLmPpH1Ok3VITzAmDKYEMxVN1 RLEOZ1MY0MMfiEuflCS0Kby76E79b9IVHUncjXDyERogUVURuohvxPdQedaqMeKEPV4yyHcqUHHl Cy/pturvqwozOQ79j6VnQ4KOmGkJCRtAzThnR+rJ7JdxEt4k9XI80fdDTCb3kLKJ6UVLVT0xBXpB 4pW6Q8AXxbaFPRmNZHDzW6zNn9MpdYdLlWdqpvjR3byQholDKak3W/VdsCZaU0J2kCvPnlZsK1TP XJpl31uLSGA4fPvFC892BGMCMyp99YNn5/rGQ/0rD9QmL3ekMsEk6mSdv7M4cTFE8ke4omZBofub e7zHRmp1v1qijOhqRMG4lrXAMggte3Q1c7LKxv6vEXIY9ufIws+lKup71lnofKCyakAJaQ6lltvR ALnxiG428IiynfFS8sN8vzCJPApp+SKkZeGb4HTGsYWXliyulI9QpjkSH75H8oF403U2nn1aIJfi Uq6Zn8Z8m2bz/tjP7r2XBh0thdw+NlOWeyC66MjhrZZiPhF8swCEnqdMcatKNwIDAQABo0IwQDAP BgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSg1gc9XiT3e6BELiRSDRmqKwSRpzAOBgNVHQ8BAf8E BAMCAYYwDQYJKoZIhvcNAQELBQADggIBAA1H+QlmMVLsee7CqPJoPu2WRcs6pphjP+orTU4D0ByC 4cvT5darW2covJ3+DJkKgFWnzhsjYQ2wV/D+4Mq+5pDbgyy+g470ebb+0A1Cp1gfaeqB9QWl/kZo 62x4yeDq5+beMcXS1SyCYyidXagafojm5yvxLNXQBZ7cLb03ZtQEoqetvzrCqDut/42dM+C5moSh hx929IJ01w75MEg+W4g+qlxr1i8M6I5zwhiRgzm2ZlrQH2AnXU3j9joNZlCceHur8xMQrg8vq+hk sxggnUY1ZCVz6psQXFg1ibFGSKf0rNQdnlvMqaUaE08kUKrZG22xQPud3Vh0xMJvFHLs2zWfuFR1 RcOmyBooNTquZfKpmM6vW8k4jDE7f8zclv3iW9bQWfR2ugvLT4MQx0DQHWDpKuVIWHcMRWm+GXEE JOLjJB9KyME+mfWWmDhIJaEVsBvX4oQYW/ZxNZpoe0DMGFwMJJ3UlfWZqkbqrqy/9BQZJOiM7OP1 vAZoiioMBV8Kl3Wn3H7A/dd6GN8w0ThLH7CYcL/MfHPwbsQxpaSXHay/zmwhSr4nI2fzBlaBCpGO tuEDBTMs2jQITU5QI60fpcXUev7qCeynKGCLRny16pvdT/nnaxXGiM9D2+Un3ARWbm9GFfFWLehc DHPDI4E4IMvJDGnPLKs7hGAzGVL9aRQzMIIGIDCCBIigAwIBAgIQVXlYVZM2AWB+u0wnNrITfzAN BgkqhkiG9w0BAQsFADBjMQswCQYDVQQGEwJHUjE3MDUGA1UECgwuSGVsbGVuaWMgQWNhZGVtaWMg YW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDQTEbMBkGA1UEAwwSR0VBTlQgUy9NSU1FIFJTQSAx MB4XDTI1MDYwNDEwMDkwMVoXDTI3MDYwNDEwMDkwMVowKDEmMCQGCSqGSIb3DQEJARYXbWFyY28u bGllYnNjaEBuZWNsYWIuZXUwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC4m/p7lofL LMjA6RB2pIYlPVMvWQMwuE0LNejZeki8tfmDEf+NlKyaCdBAN7m5A9h2pzs4ptPYHJNizxXLIG/x 6fOAgbc7V4I6fwyJlnw5B4WrxGjqPScev69t+Ok3Jns60d5y7KrW90v679RTC92zRQCg3JJjwcAz ETkDXxXESV9R8KFgnOZo/iO+SOyB0uQNNftYQTQ34CjajtbWPin0i3msd6GEltwK/2T78n6aa9Hf kTujYFJw4gcaadflmPBvebBOa4MPOcMkYBRPFWJLjzjXZwwdriU4bBSqKvLh7Xu9yBnnsLMTpIQ1 up6fcseE+vrRPhCSbLrobTJMHvze9lAKjMgZubXpVu2BprYX+RoTCDwiBJhxMb3wWxbGFL4PUqMV JId3sWMMj07QLFtwm/6wrqDG6rjEI22G1NHDV1+r+nY9EcmBAO4vE6dUwplSMnvAimA9ltdlGptA A1yb8n+e6HOp+cv1SjbcmNop0BD0waEBqY7rS0HFiBnfy5pcZXqhcdLI17L2uARrmw7mvjZhpguY lCSiV/XK2IE3xe/ZZZp8UR+2QGUQBdGSEBXQ9HHbq+0kiXw56szGF6e1hzoeuRrhMjHaGBDyBTLG krZJZ1zpV2/FZEUqpH/EfV5ZyjKNoCA5HP+89kAfkDbkfe+5EIDA7wrF85932+LWqwIDAQABo4IB iTCCAYUwHwYDVR0jBBgwFoAU67IvO/2uAswqRAZdJc0dEiJosEcwSgYIKwYBBQUHAQEEPjA8MDoG CCsGAQUFBzAChi5odHRwOi8vY3J0LmhhcmljYS5nci9IQVJJQ0EtR0VBTlQtU01JTUUtUjEuY2Vy MCIGA1UdEQQbMBmBF21hcmNvLmxpZWJzY2hAbmVjbGFiLmV1MGMGA1UdIARcMFowCQYHZ4EMAQUB AjAIBgYEAI96AQMwQwYNKwYBBAGBzxEBAQIBAjAyMDAGCCsGAQUFBwIBFiRodHRwczovL3JlcG8u aGFyaWNhLmdyL2RvY3VtZW50cy9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMD8G A1UdHwQ4MDYwNKAyoDCGLmh0dHA6Ly9jcmwuaGFyaWNhLmdyL0hBUklDQS1HRUFOVC1TTUlNRS1S MS5jcmwwHQYDVR0OBBYEFActQvTCbFcwnlt1IGz9TEcjgUtgMA4GA1UdDwEB/wQEAwIFoDANBgkq hkiG9w0BAQsFAAOCAYEAQsMQSgnDXDSPoLlCmOUCVKcAYiX+3DTDcWtwZdhlK6J+U0lJvM5mBvsy fWJnffesctasuUt9x0oC+7tOAFwAU8I81Cf7v/jvtT/Jf0HNPK1L/LTdgpULYo1jHGV2LzXKPugd gT16N5JH9XaeGYjRTC2FqLIlVX8/Y+oyTFXHpRTBH7xZBawoNPhf1nkwpJuvNA+iItT57dXba5A4 kngBZuUt67zyrzveINh2RcuqEHgKAi2rEJGOMgjLvz1ARJJPLmpUVFepF4cdf12OxYURNyZHPeOK XaBIv3yP9ByVb5ltws17RxQtBUJDsYdlVUag3G+CA70m0RtfAHSjSeCdLqXAU4VoyAaIPVlps5qz pJY1gJWx26Sr1yrP9LQ2Fvn9XRG1yJ82jauCqtlAR/8UIdoCpi0V+P18jSwc4KGeCwgXdl6SuNFX L/A+gVybq+1Gekv/MUFq3/rg89im/q6/3/tCEYHmb/MfhyxyH0X7V2rxa7SBHOhryAc/9fEQSpDm MIIGRDCCBCygAwIBAgIQFfmubKqNLtTTb3h/Htx7ATANBgkqhkiG9w0BAQsFADBvMQswCQYDVQQG EwJHUjE3MDUGA1UECgwuSGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9u cyBDQTEnMCUGA1UEAwweSEFSSUNBIENsaWVudCBSU0EgUm9vdCBDQSAyMDIxMB4XDTI1MDEwMzEx MTMwOFoXDTM5MTIzMTExMTMwN1owYzELMAkGA1UEBhMCR1IxNzA1BgNVBAoMLkhlbGxlbmljIEFj YWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ0ExGzAZBgNVBAMMEkdFQU5UIFMvTUlN RSBSU0EgMTCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBAKu4bq/+byKjHo25Xz32YBmO +Wrkmc+UmfcdXSCI7yawwU9JSMEHAAKAASaJpLr9JAyt+tlB/rn/SaznSwY4ipBIffR0D5k/ndfi I553dWgI4i/tkOGlNej/7JyE2CS9kTlOOs6pg5HaDpwqjAhCkje+IByg5gKWH6lzvMJo5jQOtsGB 2q6e5cYKwa9LJOAcR8iquds9LFssbHSMuVdSuTjpAjcGLqWfW++C0YXpWD+UonjQ6lNEuiKUDmrF c+SEtLw56lYtp4uuxm4LW/HQSsx+oGwMBqaR6HhBQ3LydONjsbcbegRqJZFJoLsnwIHorEag44UI vjXzYJAx/NTiwVdHldO7cEvWscDbyQLR9koBoliq2HrgYFQs7NQxU+7MLNSh8i6znWVNISUEg36M //I8BZl4VqD70ELlhKKN7rx+i7BwKOd2gxdWgFJhkPyQu9o+82R9epXiRblo/rdkyv+2BFR7Vpbg PUzncdi8/0h4dP/qQFYnA+Df0FFj7gYczwIDAQABo4IBZjCCAWIwEgYDVR0TAQH/BAgwBgEB/wIB ADAfBgNVHSMEGDAWgBSg1gc9XiT3e6BELiRSDRmqKwSRpzBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9jcnQuaGFyaWNhLmdyL0hBUklDQS1DbGllbnQtUm9vdC0yMDIxLVJTQS5j ZXIwRAYDVR0gBD0wOzA5BgRVHSAAMDEwLwYIKwYBBQUHAgEWI2h0dHA6Ly9yZXBvLmhhcmljYS5n ci9kb2N1bWVudHMvQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBFBgNVHR8EPjA8 MDqgOKA2hjRodHRwOi8vY3JsLmhhcmljYS5nci9IQVJJQ0EtQ2xpZW50LVJvb3QtMjAyMS1SU0Eu Y3JsMB0GA1UdDgQWBBTrsi87/a4CzCpEBl0lzR0SImiwRzAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZI hvcNAQELBQADggIBADveuEX23DwrkygKtsF7DmcTGmi8SE20jmJLe0TMT8Nws1NqppE0ACym1agt Y1IjUFm5MWabG/IcvRTh8sB9cRZgDQMqZLNCLofqL4aj/dKBXH4bwH2MVdjNHBoGvZkyhRz/kBE+ x1vaWXclhWQMOX5nVvRMfiEJiYotMP7KM88IaVZ9DkGJJEVftsnUWuvCWUtjagD6XWlqLHjNl+Lu fiZ/h9lDvaWqG1/obfdStgofMc30RL+ES6gYKRwZpCA1coFzXV7Cnwx8toTl8bReqCNXexKzxlqA cRXPOmlKkJQuqRI297oNuMPnoNZCY+yLnxyd4kZuu0XcOTNTpVjM8bvg8ACqhSYanrNDi/zTiTk7 gwm9GyH1X45fFNGNEFgpIaApjT2UELukDOmP18ZwC4EQeHawPJIqffMEmUJm6qbRPKGnNmcyygh4 iZU3QbkRLLp3Z6QV3WoTEqyf5mL9qTGS6WJG65L8oaKw1Xh/bdGuVIDyBahpfP2c2pCd0UH6+x73 Rrq9GFlOijVr2OQSvKhzETNG917SvcURCBhMnIQFUXqHQyIY60eH1po6WtNOq/1K5kpOG6Sq1RVc 02LEit48uK4tRMVUKekSOjruGXW38DmAriPcMHjI6VQbqjc0Sq1VPz76ee4FM5uLviSUZHYqDDqM Wa8LFImK9iiKI8E3MYIEqTCCBKUCAQEwdzBjMQswCQYDVQQGEwJHUjE3MDUGA1UECgwuSGVsbGVu aWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDQTEbMBkGA1UEAwwSR0VBTlQg Uy9NSU1FIFJTQSAxAhBVeVhVkzYBYH67TCc2shN/MAkGBSsOAwIaBQCgggIHMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI1MDkyNjEzMTgyM1owIwYJKoZIhvcNAQkE MRYEFICZnrsV3hWG1zVwg3H4OmGmGTK5MIGGBgkrBgEEAYI3EAQxeTB3MGMxCzAJBgNVBAYTAkdS MTcwNQYDVQQKDC5IZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENB MRswGQYDVQQDDBJHRUFOVCBTL01JTUUgUlNBIDECEFV5WFWTNgFgfrtMJzayE38wgYgGCyqGSIb3 DQEJEAILMXmgdzBjMQswCQYDVQQGEwJHUjE3MDUGA1UECgwuSGVsbGVuaWMgQWNhZGVtaWMgYW5k IFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDQTEbMBkGA1UEAwwSR0VBTlQgUy9NSU1FIFJTQSAxAhBV eVhVkzYBYH67TCc2shN/MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIICAFupa71FH861T/PXGmFIcci+xbx/L0A4dkxMLFN5EX05+QwEl4FQCskecW4B 2boOqxGoCiaW6jrtDXSXPJgEHeAv09dC3Rf6OqIvRI0CzvF0jNyBIwDC6ioZJ1InxfpNukajit0t nDzDNfqwJALOOa1uZNNjf2VdXlb6gKTMWB3+eREVpp8zqHNa5h3XqQxQNA8VS7UpKX44C6JvrDzc E3XJOj+CrJN/FRdA4SUXLuqqKLFgT1GXmDX+mEzOBeIUnL/32mMIhDlfggW8SiY5kD8DaWxvOAy+ aClfE8TS+e7dKddvqWOERsu2za/w7RnNANSz4VxwiyFf1mPyvFpVaiOkjDkvB/IdGRkM++aJvQXf 01BHCRqqnmO2rDufCGeaGRjjCYNS4oFHRFk8dw/mbvqAeQBZbuDhD1KRMCkYV7U2FuwSXm4i+mNM 76zkLhwRQvoYXsiCOCDJIy4wb8cA7Y1I/9dF90+6nwOhJrZSGC/MpR/ecnwS9Kd9UGDGhvw4uSV6 dKpfVgRj0bVpl2LIFrZkyGmhtuJ520VlQwPlTHNh8Fto1VIpr9wVHxcp0AlTXEdGKWwX1BHBAqja 6s+bQUYmU87bllbFfNaTTdiXmyy2HYjKJoOphEElIj5AshSOE1ysTrD3/9OJEqUAq76KExb0nAjW lRrp92iQp+YMgLdsAAAAAAAA ------=_NextPart_000_0023_01DC2EF8.CC73F1F0-- --===============8805176287172368955== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZG1tIG1haWxp bmcgbGlzdCAtLSBkbW1AaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBk bW0tbGVhdmVAaWV0Zi5vcmcK --===============8805176287172368955==--