From nobody Mon Mar 2 01:15:47 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2073A107D; Mon, 2 Mar 2020 01:15:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , maxpassion@gmail.com, cpignata@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158314054287.21664.6708248776755104908@ietfa.amsl.com> Date: Mon, 02 Mar 2020 01:15:42 -0800 Archived-At: Subject: [DMM] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?dmm-distributed-mobility-anchoring-14=3A_=28with_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 09:15:43 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS. Please also address the review done by Carlos for the Internet Directorate (see: https://datatracker.ietf.org/doc/review-ietf-dmm-distributed-mobility-anchoring-14-intdir-telechat-pignataro-2020-02-28/ ) Thank you Carlos for this review. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 4 -- Can you better define what is a "dynamic IP address" ? In the last paragraph, is there any reason why draft-ietf-intarea-provisioning-domains is not mentioned as yet another means to select an IP address for new connections ? -- Section 4.1 -- Please expand AR at first use -- Section 4.3 -- To be honest, relocating the DP anchor is sending a bad feeling under my skin... Scalability will be a major concerned as mentioned in your document: "such a solution may present some scalability concerns" From nobody Mon Mar 2 02:11:19 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3243A03F4; Mon, 2 Mar 2020 02:11:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , max.ldp@alibaba-inc.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158314387762.21058.9241906725527874632@ietfa.amsl.com> Date: Mon, 02 Mar 2020 02:11:17 -0800 Archived-At: Subject: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-pmipv6-dlif-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 10:11:18 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dmm-pmipv6-dlif-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Sec 3.2: "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the retransmission timer." Use of this timeout from RFC6275 is fine. However, you should also indicate that the rest of the specified retransmission mechanism should be used as well. That means exponential backoff as well as a max number of retries. Further I think it would also be important to overall rate-limit the traffic e.g. as specified in RFC6275: "The mobile node MUST NOT send Mobility Header messages of a particular type to a particular correspondent node more than MAX_UPDATE_RATE times within a second." In addition the same mechanisms should probably be also required for any (new) message sent by the P/S-MAAR in other modes. Finally in the security consideration section I see this: "The CMD SHOULD use a pacing approach to limit this amplification risk." Which is good! But why is that a SHOULD and not a MUST? Update: This discuss is inline with the comments provided by the TSV-ART review (thanks Jörg!) which lead to an update that don't seem fully addressed. So please review that feedback as well and continue discussion with the TSV-ART reviewer if needed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial comments/nits: 1)Sec 1: "Following this idea, in our proposal, the central anchor is..." Maybe remove "in our proposal" as this is not a proposal only anymore when published. 2) Sec 2: "The following terms used in this document are defined in the DMM Deployment Models and Architectural Considerations document [I-D.ietf-dmm-deployment-models]:" As there doesn't seem to be any plan to actually publish draft-ietf-dmm-deployment-models anymore, maybe move the respective definitions into this document. 3) Sec 3: "Note that a MN MAY move across different MAARs" This should be lower case "may". 4) As section 3.6 talks mainly about implementation details, I suggest to move this section into the appendix. 5) In the appendix you always talk about "our solution". This is rather uncommon for an RFC. I recommend to chance to e.g. "the solution specified in this document". 6) Are both appendices A and B are still needed? 7) One overall editorial comment which might be too late to address: I would have found it more easy to read if you would have first introduced the new messages and then used the concrete message names in the description in section 3. From nobody Mon Mar 2 12:55:04 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F93A0804; Mon, 2 Mar 2020 12:54:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , max.ldp@alibaba-inc.com, Carlos Pignataro (cpignata) X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158318249840.27483.9051628354202166127@ietfa.amsl.com> Date: Mon, 02 Mar 2020 12:54:58 -0800 Archived-At: Subject: [DMM] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-dmm-p?= =?utf-8?q?mipv6-dlif-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 20:54:59 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-dmm-pmipv6-dlif-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. And congratulations for the many advanced ASCII art ! Except for section 3.6, the text is really easy to read. I have a block DISCUSS below but it should be trivial to fix. Please also address the points raised by Carlos during the INT directorate review. Thank you again Carlos ! https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28/ I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 4.3 & 4.4 & 4.5 -- Probably trivial to fix but is "Prefix Length" expressed in bits (/64) or in bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? The definition of the "Prefix length" field should be specific about the unit (bits/bytes) and be aligned with the definition of "Anchored prefix" (as this one seems to assert that the prefix length must be a multiple of 8). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == COMMENTS == A generic question, can a MN be attached to multiple MAAR at the same time? I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR at any time. -- Section 3.1 -- Should the length of the prefix assigned to the MN be specified? Adding a /64 would make things clearer without using too much of text. For my own curiosity, the text is about "IPv6 global prefix", but, would ULA also work ? -- Section 3.6 -- This section is so different than the previous ones in section 3, that I would have created a section on its own. This section also uses EUI-64 for the link-local address; and, this is no more advised for privacy reason. Not really important in the DMM context though. Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ ;-) The text of this section is really difficult to parse. After 2 readings I am not even sure that I got it... I was about to open a DISCUSS for the point 2) but I am unsure whether I am reading the text correctly. 1) If the MAC and LLA for the 'virtual router' mn1mar2 are different than the one for mn1mar2, why is there a need for different interface? Multiple routers can exist on the same link. 2) For packets sourced by MN1 with prefix1 how can we ensure that they are sent to mn1mar1 and not to mn1mar? PvD could help there and should be mentionned draft-ietf-intarea-provisioning-domains. -- Section 4.2 -- Bit 31 is not described, it is probably reserved but you should really described it. With this PBA packet format, all flags / bits are used and assigned for an experimental document. Isn't it a waste of bits? I will really appreciate an answer on this question. == NITS == -- Section 3 (and possibly others) -- The CMD and MAAR acronyms are expanded multiple times. This makes the reading easier for newcomers of course. From nobody Mon Mar 2 13:32:06 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AC53A122D for ; Mon, 2 Mar 2020 13:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJcma7zoPIia for ; Mon, 2 Mar 2020 13:31:46 -0800 (PST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C743A1212 for ; Mon, 2 Mar 2020 13:31:45 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id n18so1565138edw.9 for ; Mon, 02 Mar 2020 13:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T79m5MF+4jRIY/FIttpXaAsg6NVfRKmLIHA7N+F2Gv4=; b=dRZiPbp8mXspDkS+1IUZbpq3kgAd98wIIbDFI1uuVlxFtLeuLJdTZEf+BIay6f4RLM Ro9FyLJAteU/dKgLkfyEcexn9GHHF94QEMAVFZ3L4Wr6oigjJ73mUGqQhmiBfNu5dUDc EN5h2tsHCUyIBTLKZG8SH3+qr5NWw+CP+8Kp7cL6Mq9q5dYHSApe3UmtkBYRlgBYpwz6 ZHTjg5bo+QdOoic9TAoGurf6uuRvscjSHpSzyUnpx5Agg5/QIHfhDBjfUUEeB74jfUza Wv/MbmIzjVoPfM04JhR6O4MvdsFn6OAFX5gGffeV46G/fkLmUd9ZapAMh59b9DrIjVOG bdrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T79m5MF+4jRIY/FIttpXaAsg6NVfRKmLIHA7N+F2Gv4=; b=qeHgbpB0IspTB1VfXIr9ypOe2nyNmdprUZo28TYD/w26jQHfXmx5PEVoY9eaIGRT2L +Cwmdm2UK5VQkTAm79cN7Le8It/gradlIuzQRAS08VCH9nTbN3boIT1foegaDTkyEZkT rEtKoeoCjKbvXlGV+ZxFmc7DbwIkRmIgsJaKp0fgV75bDuHYsuD2iWC3mAGb8TJOXwy2 tGEz8ZHTF5EneU0tqqdZj/73OIoJRROO9kOxpME0vyApj/qVt0HAmypn1lbDXaRDIuQa 8O+NcJQvHPwk8apByDyrIuxK1rnUyz8aS33CnLazF3H816q7heZFGe7xPhFp8gI4IZJ5 2s/w== X-Gm-Message-State: ANhLgQ0Ix32J1oC3sFzm90dgetbmwWgIqMD8U+SX+FFAE+tFN0qAu7ly 8PDqWI/8ZqRXWO6ooBfCXBjPWtjaE+AH/CA/3rZX1Q== X-Google-Smtp-Source: ADFU+vvHDrYtd/hj+G9pC5ilzT6bNjn04Av8w3ci7NezlqI9btjjAS8hJ5tibJg0ywkfl2afwN1ecssEgZtKGhgtiMs= X-Received: by 2002:aa7:da03:: with SMTP id r3mr1224591eds.163.1583184703781; Mon, 02 Mar 2020 13:31:43 -0800 (PST) MIME-Version: 1.0 References: <158294551595.19795.13194872695997233791@ietfa.amsl.com> In-Reply-To: <158294551595.19795.13194872695997233791@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Mon, 2 Mar 2020 22:31:27 +0100 Message-ID: To: Carlos Pignataro Cc: "" , last-call@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, dmm Content-Type: multipart/alternative; boundary="000000000000e21a70059fe5e92d" Archived-At: Subject: Re: [DMM] Intdir telechat review of draft-ietf-dmm-distributed-mobility-anchoring-14 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 21:32:00 -0000 --000000000000e21a70059fe5e92d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Carlos, Thanks a lot for your review. Please see inline below. On Sat, Feb 29, 2020 at 4:05 AM Carlos Pignataro via Datatracker < noreply@ietf.org> wrote: > Reviewer: Carlos Pignataro > Review result: Ready with Nits > > I am an assigned INT directorate reviewer for this Internet-Draft. These > comments were written primarily for the benefit of the Internet Area > Directors. > Document editors and shepherd(s) should treat these comments just like th= ey > would treat comments from any other IETF contributors and resolve them > along > with any other Last Call comments that have been received. For more > details on > the INT Directorate, see http://www.ietf.org/iesg/directorate.html. > > I hope these comments are clear and useful. > > As requested, from the Internet area Directorate review, these two DMM > documents are being reviewed together: > * draft-ietf-dmm-distributed-mobility-anchoring-14 > * draft-ietf-dmm-pmipv6-dlif-05 > > This document defines distributed mobility anchoring, in terms of the > different configurations and functions to provide IP mobility support, > including network-based or host-based mobility support. > > The intended status is Informational. It is a very well written and > comprehensive document. It is technically sound. > > No major or minor issues. > > Nits: > > A set of small nits for your consideration. > > 1. Introduction > > As a Mobile Node (MN) attaches to an access router and establishes a > link between them, a /64 IPv6 prefix anchored to the router may be > assigned to the link for exclusive use by the MN [RFC6459]. The MN > may then configure a global IPv6 address from this prefix and use it > as the source IP address in a flow to communicate with its > correspondent node (CN). > > Capitalize: > s/correspondent node/Correspondent Node/ > [CB] OK, fixed in -15 (to be submitted). > > 2. Conventions and Terminology > > These include terms such as mobile node (MN), correspondent node > (CN), home agent (HA), home address (HoA), care-of-address (CoA), > local mobility anchor (LMA), and mobile access gateway (MAG). > > Capitalize =E2=80=9CMobile Node=E2=80=9D (as per =C2=A7 1), =E2=80=9CCore= spondent Node=E2=80=9D, etc. > [CB] OK, fixed in -15 (to be submitted). > Similar within this same =C2=A7 2, =E2=80=9Cmobile router=E2=80=9D, etc. > Same throughout the document (e.g., =E2=80=9Crouter advertisement (RA)=E2= =80=9D) > [CB] OK, fixed in -15 (to be submitted). > > 4.3. Mobility case, anchor relocation > > The IP prefix/address anchoring may move without changing the IP > prefix/address of the flow. Here the LM and FM functions in Figure 1 > in Section 3.1 are implemented as shown in Figure 7. > > =E2=80=9CFigure 1 in Section 3.1.1 are implemented=E2=80=9D > [CB] OK, fixed in -15 (to be submitted). > > Figure 7: Anchor mobility > > Should this figure=E2=80=99s label be =E2=80=9CAnchor Relocation=E2=80=9D= instead of =E2=80=98Anchor > mobility=E2=80=9D? > [CB] OK, makes sense. Fixed in -15 (to be submitted). > 5. Security Considerations > > As stated in [RFC7333], "a DMM solution MUST supportany security > > s/supportany/support any/ > [CB] OK, fixed in -15 (to be submitted). > > 8.2. Informative References > > The relationship of this document and draft-ietf-dmm-deployment-models is > mostly clear, thank you for that. > [CB] Related to this, we got a comment from Mirja. Since draft-ietf-dmm-deployment-models is not going to progress any further, we'll try to remove the reference and incorporate the needed content to make our document self contained without the reference. > > I hope you fid these comments useful. > [CB] Very much indeed. Thanks a lot! Carlos > > Carlos Pignataro. > > > > --000000000000e21a70059fe5e92d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Carlos,

Thanks a = lot for your review. Please see inline below.

On Sat, F= eb 29, 2020 at 4:05 AM Carlos Pignataro via Datatracker <noreply@ietf.org> wrote:
Reviewer: Carlos Pignataro
Review result: Ready with Nits

I am an assigned INT directorate reviewer for this Internet-Draft.=C2=A0 Th= ese
comments were written primarily for the benefit of the Internet Area Direct= ors.
Document editors and shepherd(s) should treat these comments just like they=
would treat comments from any other IETF contributors and resolve them alon= g
with any other Last Call comments that have been received. For more details= on
the INT Directorate, see http://www.ietf.org/iesg/directora= te.html.

I hope these comments are clear and useful.

As requested, from the Internet area Directorate review, these two DMM
documents are being reviewed together:
* draft-ietf-dmm-distributed-mobility-anchoring-14
* draft-ietf-dmm-pmipv6-dlif-05

This document defines distributed mobility anchoring, in terms of the
different configurations and functions to provide IP mobility support,
including network-based or host-based mobility support.

The intended status is Informational. It is a very well written and
comprehensive document. It is technically sound.

No major or minor issues.

Nits:

A set of small nits for your consideration.

1.=C2=A0 Introduction

=C2=A0 =C2=A0As a Mobile Node (MN) attaches to an access router and establi= shes a
=C2=A0 =C2=A0link between them, a /64 IPv6 prefix anchored to the router ma= y be
=C2=A0 =C2=A0assigned to the link for exclusive use by the MN [RFC6459].=C2= =A0 The MN
=C2=A0 =C2=A0may then configure a global IPv6 address from this prefix and = use it
=C2=A0 =C2=A0as the source IP address in a flow to communicate with its
=C2=A0 =C2=A0correspondent node (CN).

Capitalize:
s/correspondent node/Correspondent Node/

[CB] OK, fixed in -15 (to be submitted).=C2=A0
=C2=A0

2.=C2=A0 Conventions and Terminology

=C2=A0 =C2=A0These include terms such as mobile node (MN), correspondent no= de
=C2=A0 =C2=A0(CN), home agent (HA), home address (HoA), care-of-address (Co= A),
=C2=A0 =C2=A0local mobility anchor (LMA), and mobile access gateway (MAG).<= br>
Capitalize =E2=80=9CMobile Node=E2=80=9D (as per =C2=A7 1), =E2=80=9CCoresp= ondent Node=E2=80=9D, etc.

[CB] OK, fix= ed in -15 (to be submitted).


Similar within this same =C2=A7 2, =E2=80=9Cmobile router=E2=80=9D, etc. Same throughout the document (e.g., =E2=80=9Crouter advertisement (RA)=E2= =80=9D)

[CB] OK, fixed in -15 (to be su= bmitted).=C2=A0
=C2=A0

4.3.=C2=A0 Mobility case, anchor relocation

=C2=A0 =C2=A0The IP prefix/address anchoring may move without changing the = IP
=C2=A0 =C2=A0prefix/address of the flow.=C2=A0 Here the LM and FM functions= in Figure 1
=C2=A0 =C2=A0in Section 3.1 are implemented as shown in Figure 7.

=E2=80=9CFigure 1 in Section 3.1.1 are implemented=E2=80=9D

[CB] OK, fixed in -15 (to be submitted).=C2=A0
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Figure 7: Anchor mobility

Should this figure=E2=80=99s label be =E2=80=9CAnchor Relocation=E2=80=9D i= nstead of =E2=80=98Anchor mobility=E2=80=9D?

[CB] OK, makes sense. Fixed in -15 (to be submitted).=C2=A0=C2=A0


5.=C2=A0 Security Considerations

=C2=A0 =C2=A0As stated in [RFC7333], "a DMM solution MUST supportany s= ecurity

s/supportany/support any/

[CB] OK, fixe= d in -15 (to be submitted).=C2=A0
=C2=A0

8.2. Informative References

The relationship of this document and draft-ietf-dmm-deployment-models is mostly clear, thank you for that.

[CB] = Related to this, we got a comment from Mirja. Since draft-ietf-dmm-deployme= nt-models is not going to progress any further, we'll try to remove the= reference and incorporate the needed content to make our document self con= tained without the reference.
=C2=A0

I hope you fid these comments useful.

[= CB] Very much indeed. Thanks a lot!

Carlos
=C2=A0

Carlos Pignataro.



--000000000000e21a70059fe5e92d-- From nobody Mon Mar 2 14:26:24 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762453A12ED for ; Mon, 2 Mar 2020 14:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdbMO9nriWAY for ; Mon, 2 Mar 2020 14:26:18 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679AC3A12F5 for ; Mon, 2 Mar 2020 14:26:18 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id n18so1728980edw.9 for ; Mon, 02 Mar 2020 14:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dPT1XTchAgwd2oKrPk6oGHHmt/uNbY9z2HTFLDlKUrA=; b=KzAGMsf0jbdsZQ+RaEYTKAhHVXqB3oVLPPyzN4mdHxH7hNNp5lefjUXXjxOOvUmrUj E2IrP/acaWWlXp+VU/SUdxzlEHpj/tIIw23gONUgClkHYBo/7ZkzcuJElsxTSuFS6gij gPNtZa+ZuscJYYQREJk5NDJJk7kkx2PoHbHy8lQH34EdAoIRCRgkRS4PFWXaB3oK3ZV3 PTSAy1YHvPktn8EmIyb6jhCiaBD96tTOu7+rQ98ZQagG07E5i2f5KXZd7VXSp4zjDoMu fNBLancfCleNd3ObPRavNchtin5U2qYFLNV+FBdcJBdmDIbtcuIs9wS/sv249g/I3k2q HeHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dPT1XTchAgwd2oKrPk6oGHHmt/uNbY9z2HTFLDlKUrA=; b=GlxYgq8M0jmUx5U3swMFejVV9jRGK0NdFO3qltZDr3MiIFTID9Bw839ZBtApJ6nnV1 lLEMQmahszfLXxfBMdUL+jr2oeQQ5V3JMuPEkhtFfWrDxzf+UskaMjvnMG61REu1sLaZ Jt2v3n+YfJU4lX6Qf1L7cbjwAZ1HGRJSiKsshOIfY54SDIAA9TU79mcKJnkwetc5WX4F iFOTN7quxER8nH8qZtl2uZiBJS1Hy21fM5Yl0f/MUZwHC0ltRpkJsEznyrPX+34wfXQI EJjBCWMJsEUz9BLQbqY967ezZwSuRwiXNIcYbg4j6euKQG3fsOaaosgov4TCACleksbY brtQ== X-Gm-Message-State: ANhLgQ2grqD1F2pyCSsQ/oleUL/ovdGcKMo4zv28dg2VGb+VVgy3KVVO t0P5WzW+zxyzQUYHOa+pDagko/OrEX5+u+n063lckZoxowf+wA== X-Google-Smtp-Source: ADFU+vs1TYHsFdl6zv3rnwUlM/+/lQTdF7/fLii4AtNvpVWfiGzf7YLC4ROgIHUqnsysrorBNy5E4u9YLqiCDGdp044= X-Received: by 2002:a05:6402:3047:: with SMTP id bu7mr1398305edb.44.1583187976711; Mon, 02 Mar 2020 14:26:16 -0800 (PST) MIME-Version: 1.0 References: <158314054287.21664.6708248776755104908@ietfa.amsl.com> In-Reply-To: <158314054287.21664.6708248776755104908@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Mon, 2 Mar 2020 23:26:00 +0100 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs , dmm , Dapeng Liu , "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary="000000000000f7201b059fe6ac4f" Archived-At: Subject: Re: [DMM] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?dmm-distributed-mobility-anchoring-14=3A_=28with_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 22:26:22 -0000 --000000000000f7201b059fe6ac4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =C3=89ric, Thanks for your review. Please see inline below. On Mon, Mar 2, 2020 at 10:15 AM =C3=89ric Vyncke via Datatracker < noreply@ietf.org> wrote: > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anch= oring/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. > > Nevertheless, please find below some non-blocking COMMENTs (and I would > appreciate a response from the authors) and NITS. > > Please also address the review done by Carlos for the Internet Directorat= e > (see: > > https://datatracker.ietf.org/doc/review-ietf-dmm-distributed-mobility-anc= horing-14-intdir-telechat-pignataro-2020-02-28/ > ) Thank you Carlos for this review. > [CB] I've just replied to Carlos. Version -15 (to be submitted) addresses his comments. > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > =3D=3D COMMENTS =3D=3D > > -- Section 4 -- > Can you better define what is a "dynamic IP address" ? > [CB] I've added in -15 (to be submitted) the following explanatory text: "[...] dynamic IP address (meaning that this address is only used while the MN is attached to this access router, and therefore the IP address configured by the MN dynamically changes when attaching to a different access network)." > In the last paragraph, is there any reason why > draft-ietf-intarea-provisioning-domains is not mentioned as yet another > means > to select an IP address for new connections ? > [CB] The reason is that we mention mechanisms that consider the mobility properties of the addresses, while draft-ietf-intarea-provisioning-domains is a generic mechanism. Do you think we should add the reference? > > -- Section 4.1 -- > Please expand AR at first use > [CB] Done in -15 (to be submitted). > -- Section 4.3 -- > To be honest, relocating the DP anchor is sending a bad feeling under my > skin... Scalability will be a major concerned as mentioned in your > document: > "such a solution may present some scalability concerns" > [CB] I personally agree with that for a generic scenario, and I'm not a fan of it. However, I must admit that this mechanism might be a viable option under certain (limited scope) scenarios. I tried to be neutral here, and report this as an option (as it is an option, even if it is not the one I'd personally go for ;)). Thanks! Carlos --000000000000f7201b059fe6ac4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi =C3=89ric,

Thanks f= or your review. Please see inline below.


On Mon, Mar 2,= 2020 at 10:15 AM =C3=89ric Vyncke via Datatracker <noreply@ietf.org> wrote:
=C3=89ric Vyncke has entered the following= ballot position for
draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.i= etf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Nevertheless, please find below some non-blocking COMMENTs (and I would
appreciate a response from the authors) and NITS.

Please also address the review done by Carlos for the Internet Directorate<= br> (see:
https://datatracker.ietf.org/doc/review-ietf-dmm-distri= buted-mobility-anchoring-14-intdir-telechat-pignataro-2020-02-28/
) Thank you Carlos for this review.

[CB= ] I've just replied to Carlos. Version -15 (to be submitted) addresses = his comments.
=C2=A0

I hope that this helps to improve the document,

Regards,

-=C3=A9ric

=3D=3D COMMENTS =3D=3D

-- Section 4 --
Can you better define what is a "dynamic IP address" ?

[CB] I've added in -15 (to be submitted) the = following explanatory text:

"[...] dynamic IP= address (meaning that this address is only used while the MN is attached t= o this access router, and therefore the IP address configured by the MN dyn= amically changes when attaching to a different access network)."
=


In the last paragraph, is there any reason why
draft-ietf-intarea-provisioning-domains is not mentioned as yet another mea= ns
to select an IP address for new connections ?

[CB] The reason is that we mention mechanisms that consider the mobi= lity properties of the addresses, while draft-ietf-intarea-provisioning-dom= ains is a generic mechanism. Do you think we should add the reference?
=C2=A0

-- Section 4.1 --
Please expand AR at first use

[CB] Done= in -15 (to be submitted).


-- Section 4.3 --
To be honest, relocating the DP anchor is sending a bad feeling under my skin... Scalability will be a major concerned as mentioned in your document= :
"such a solution may present some scalability concerns"

[CB] I personally agree with that for a generic = scenario, and I'm not a fan of it. However, I must admit that this mech= anism might be a viable option under certain (limited scope) scenarios. I t= ried to be neutral here, and report this as an option (as it is an option, = even if it is not the one I'd personally go for ;)).

Thanks!

Carlos
=C2=A0
=
--000000000000f7201b059fe6ac4f-- From nobody Mon Mar 2 14:26:42 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8694C3A1332; Mon, 2 Mar 2020 14:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=bwubTd05; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lW6rj9WD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgisk_pooBJT; Mon, 2 Mar 2020 14:26:36 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2912F3A131F; Mon, 2 Mar 2020 14:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17037; q=dns/txt; s=iport; t=1583187996; x=1584397596; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mz55iZjWyB8RpnoCRTM9tPXOLEc9mmFPbTKrjfTWIyE=; b=bwubTd05wq0/pa1wD5sDcJktMgssZqzmx+I8J9lnqhRiIGA/xpwDpEf1 Wxaftu533NuQ2aJSxDvdlsZeNI12t8IiC4SBBNNa3hDWpMLQQabMJw1gM 3zIz1AXCSqUm0gz2bkbAP0z3jnLB/e2zMFvav3xFfynVsaC539X+SeRR+ 4=; IronPort-PHdr: =?us-ascii?q?9a23=3ANerpAR9pq0sBCf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcWdCEL9JeLjRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKBQAwh11e/5tdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBVCknBWxYIAQLKgqECoNGA4pmgjqMe4ZdhGKBQoEQA1QJAQE?= =?us-ascii?q?BDAEBIwoCBAEBhEACF4F0JDgTAgMNAQEFAQEBAgEFBG2FVgyFZAIBAxIRHQE?= =?us-ascii?q?BMAcBDwIBBgI/AwICAjAUEQIEDgUJEgeDBAGBfU0DLgEOkFWQZwKBOYhidYE?= =?us-ascii?q?ygn8BAQWFEhiCDAmBOIwlGoFBP4ERJwwUgk0+glkLAgGBKjmDEjKCLIdWhgi?= =?us-ascii?q?CTDuFcIoLjk9wCoI8kjSEMhyCSYgfkEmVaJEigzICBAIEBQIOAQEFgWkigVh?= =?us-ascii?q?wFWUBgkEJNRIYDY4dDBeBBAEIgkOFFIVBdAKBJ446AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.70,508,1574121600"; d="scan'208,217";a="448839437" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Mar 2020 22:26:35 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 022MQZZd005814 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Mar 2020 22:26:35 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Mar 2020 16:26:35 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 2 Mar 2020 16:26:34 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 2 Mar 2020 16:26:34 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jRz31e6ct4Clq8A4BmKjRNJuFI6HfsGn9y1fA3G9b8V3INVuFw2PO3WTyNRPshgWYr0/iaPhReyugBXYy476s2fUQ7AKuZ1tHQi94szm4rw7gc8b/TJ/VLJ3k+lCxcpQLWQul4nmy483oA+Vl1u3zSmqg6ay8kuP9iiyH1di9KSd0+Giz235ENNzcJQsEe2ZXWWcjjUTs89VM74cJORid1x9JoOM9lCon3PJxJzQq66IXeAgT18eMUSu3Dhkxqy43Ygs2UqHviyTPxU6QwXCblawDd/mriWgKgXtoIHMCkWsgc5iuTjb+wgqbDDVmLzPZxFOhSZaRm9F+nppU+0cwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mz55iZjWyB8RpnoCRTM9tPXOLEc9mmFPbTKrjfTWIyE=; b=JjreCRJoLQ/L72/u5anJP+1mf86USAbVged3oRxoCj0PacShAZuJJMe7aT4sC5MMgcYtjcduEp+HRXGl/s/sE+RAw+tparYmgGgXTbXz9pVCSSkwbI2nQypGJLjDXmtDaZek3K4o3xv9JrQzSbczplXFTsFLZy6oufOJksYmPMQO9Ithfh5+l7zOYgS2NSKjzxjDEojQ0FU9+0Dmk1/RJ3nzWxgDzbsf58pKHxyrQvK5jc2eHtTibnc2cVaBBTMAwwp3tBm3ck7bG2ihhbAdZh6jzvoyzGHcx150FVpgKr7fy/yBGkRC+ItNncfIHqQWiWz4V+Hm3v0fY5euiItQdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mz55iZjWyB8RpnoCRTM9tPXOLEc9mmFPbTKrjfTWIyE=; b=lW6rj9WDFNypRu8BeZGeMPfTM8ThRNBTpCcl0oq/OgbhJ0W68C5u6iCj+/Cv/YPZV3xm3ZAhZCU8HtgkkbLmDgd7V4qcvL1NnonJ10hvUG6rHiGCOujQ7GAzIXB1Qyw+qDyVRaZOi6/dD3ygK5Xhi6rwHwftLjL1UCwx4hFp5M8= Received: from MN2PR11MB4415.namprd11.prod.outlook.com (2603:10b6:208:192::31) by MN2PR11MB4430.namprd11.prod.outlook.com (2603:10b6:208:192::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.19; Mon, 2 Mar 2020 22:26:33 +0000 Received: from MN2PR11MB4415.namprd11.prod.outlook.com ([fe80::393e:c7fe:1d69:fa4e]) by MN2PR11MB4415.namprd11.prod.outlook.com ([fe80::393e:c7fe:1d69:fa4e%4]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 22:26:33 +0000 From: "Carlos Pignataro (cpignata)" To: CARLOS JESUS BERNARDOS CANO CC: "" , "last-call@ietf.org" , "draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org" , dmm Thread-Topic: Intdir telechat review of draft-ietf-dmm-distributed-mobility-anchoring-14 Thread-Index: AQHV8Nn9JuxzTggRjkGztoIFRaqelKg14YwA Date: Mon, 2 Mar 2020 22:26:33 +0000 Message-ID: References: <158294551595.19795.13194872695997233791@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.60.0.2.5) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [173.38.117.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fd58d9ad-728b-49c1-6894-08d7bef8c35c x-ms-traffictypediagnostic: MN2PR11MB4430: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(39860400002)(376002)(346002)(199004)(189003)(21615005)(2616005)(36756003)(76116006)(66574012)(6486002)(8676002)(4326008)(66556008)(64756008)(66446008)(66476007)(81166006)(81156014)(66946007)(53546011)(6506007)(19273905006)(478600001)(33656002)(8936002)(6916009)(86362001)(6512007)(5660300002)(71200400001)(316002)(186003)(26005)(966005)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4430; H:MN2PR11MB4415.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: odj46zDQhnNSYNPvMh0Jg6qQ9AY/QAx0JQVSRxgS1FogIu3ecSGBA+iSCxYuTwwTeuzJjGZrR4YGidMhmMGxt1CV1s80xi6V5p73OD7mSM7ALFXSP+y0zH6Tw2PVJ0sK5dqJap/+BXlDL7uVskrKZdunIxRNed012VQbH2BfvGtqTHw959sI+ZFzwobeglbCv1NOf2CzIn8KQfY9XkwKweL5SFoy12UtFKGdN3WQs3YtWUhC/FpZROQ6kVdILl2Vxkov4MHPZqEwnmOGDN/ZjbrIrzW3lW6acnftG08TFWHC7jK1LqJfGS4likOzYp1lMqVGoM+Usd3iXt6TOJXQWwUcmIM6FlFPbErG2Z7TU/CcuCA7Fw2QUjCg+0H+m14hLhKHdOfIK7UneUwDCTyxH9poXLuHCwnJikDKPXHvOaprlf5BVeOkkBKSkb3g7bcLzFXLphdMjpk5elbmIyZtJTK9XlL4C9ZQXPq7Vjt8sf1JUQ92NwqCVO7m54UhUEkV4z6FDHf4tv5RohvGY3GEkw== x-ms-exchange-antispam-messagedata: U+L6MGyV5/vimuM473JuGOHav9C3MDNc9WE4eUn3LkI1XbHasAyqRUyoAdajH0OJVJSlx0thPkwbUkRasZMjZpAAdDmX3/zYS0ppUNQyXhDbeLFFtj/QeIWlSZuVd3mosN3sMcWTxPm0WhCJ+fe+yA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F767356C1ED44957B32A92B32587772Aciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fd58d9ad-728b-49c1-6894-08d7bef8c35c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 22:26:33.3515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9WlW3jzckD4tSUsn1qF/HwpCTwvxz2DMXpa+UHFdLPAo4z0+MlUsRDAlQYf0FWl4Ts3TpsPV8KS+m0J1F/O1sQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4430 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [DMM] Intdir telechat review of draft-ietf-dmm-distributed-mobility-anchoring-14 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 22:26:40 -0000 --_000_F767356C1ED44957B32A92B32587772Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDYXJsb3MsDQoNClRoYW5rIHlvdSBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlIGFuZCB0aGUg ZXhwbGljaXQgQWNrIG9uIGFsbCB0aGUgaXNzdWVzISBIYXBweSB0aGUgcmV2aWV3IHdhcyB1c2Vm dWwuDQoNCkJlc3QsDQoNCihBbm90aGVyKSBDYXJsb3MuDQoNCg0KMjAyMC8wMy8wMiDljYjlvow0 OjMx44CBQ0FSTE9TIEpFU1VTIEJFUk5BUkRPUyBDQU5PIDxjamJjQGl0LnVjM20uZXM8bWFpbHRv OmNqYmNAaXQudWMzbS5lcz4+44Gu44Oh44O844OrOg0KDQpEZWFyIENhcmxvcywNCg0KVGhhbmtz IGEgbG90IGZvciB5b3VyIHJldmlldy4gUGxlYXNlIHNlZSBpbmxpbmUgYmVsb3cuDQoNCg0KT24g U2F0LCBGZWIgMjksIDIwMjAgYXQgNDowNSBBTSBDYXJsb3MgUGlnbmF0YXJvIHZpYSBEYXRhdHJh Y2tlciA8bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+IHdyb3RlOg0K UmV2aWV3ZXI6IENhcmxvcyBQaWduYXRhcm8NClJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggTml0 cw0KDQpJIGFtIGFuIGFzc2lnbmVkIElOVCBkaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBJ bnRlcm5ldC1EcmFmdC4gIFRoZXNlDQpjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZv ciB0aGUgYmVuZWZpdCBvZiB0aGUgSW50ZXJuZXQgQXJlYSBEaXJlY3RvcnMuDQpEb2N1bWVudCBl ZGl0b3JzIGFuZCBzaGVwaGVyZChzKSBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBs aWtlIHRoZXkNCndvdWxkIHRyZWF0IGNvbW1lbnRzIGZyb20gYW55IG90aGVyIElFVEYgY29udHJp YnV0b3JzIGFuZCByZXNvbHZlIHRoZW0gYWxvbmcNCndpdGggYW55IG90aGVyIExhc3QgQ2FsbCBj b21tZW50cyB0aGF0IGhhdmUgYmVlbiByZWNlaXZlZC4gRm9yIG1vcmUgZGV0YWlscyBvbg0KdGhl IElOVCBEaXJlY3RvcmF0ZSwgc2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0 ZS5odG1sLg0KDQpJIGhvcGUgdGhlc2UgY29tbWVudHMgYXJlIGNsZWFyIGFuZCB1c2VmdWwuDQoN CkFzIHJlcXVlc3RlZCwgZnJvbSB0aGUgSW50ZXJuZXQgYXJlYSBEaXJlY3RvcmF0ZSByZXZpZXcs IHRoZXNlIHR3byBETU0NCmRvY3VtZW50cyBhcmUgYmVpbmcgcmV2aWV3ZWQgdG9nZXRoZXI6DQoq IGRyYWZ0LWlldGYtZG1tLWRpc3RyaWJ1dGVkLW1vYmlsaXR5LWFuY2hvcmluZy0xNA0KKiBkcmFm dC1pZXRmLWRtbS1wbWlwdjYtZGxpZi0wNQ0KDQpUaGlzIGRvY3VtZW50IGRlZmluZXMgZGlzdHJp YnV0ZWQgbW9iaWxpdHkgYW5jaG9yaW5nLCBpbiB0ZXJtcyBvZiB0aGUNCmRpZmZlcmVudCBjb25m aWd1cmF0aW9ucyBhbmQgZnVuY3Rpb25zIHRvIHByb3ZpZGUgSVAgbW9iaWxpdHkgc3VwcG9ydCwN CmluY2x1ZGluZyBuZXR3b3JrLWJhc2VkIG9yIGhvc3QtYmFzZWQgbW9iaWxpdHkgc3VwcG9ydC4N Cg0KVGhlIGludGVuZGVkIHN0YXR1cyBpcyBJbmZvcm1hdGlvbmFsLiBJdCBpcyBhIHZlcnkgd2Vs bCB3cml0dGVuIGFuZA0KY29tcHJlaGVuc2l2ZSBkb2N1bWVudC4gSXQgaXMgdGVjaG5pY2FsbHkg c291bmQuDQoNCk5vIG1ham9yIG9yIG1pbm9yIGlzc3Vlcy4NCg0KTml0czoNCg0KQSBzZXQgb2Yg c21hbGwgbml0cyBmb3IgeW91ciBjb25zaWRlcmF0aW9uLg0KDQoxLiAgSW50cm9kdWN0aW9uDQoN CiAgIEFzIGEgTW9iaWxlIE5vZGUgKE1OKSBhdHRhY2hlcyB0byBhbiBhY2Nlc3Mgcm91dGVyIGFu ZCBlc3RhYmxpc2hlcyBhDQogICBsaW5rIGJldHdlZW4gdGhlbSwgYSAvNjQgSVB2NiBwcmVmaXgg YW5jaG9yZWQgdG8gdGhlIHJvdXRlciBtYXkgYmUNCiAgIGFzc2lnbmVkIHRvIHRoZSBsaW5rIGZv ciBleGNsdXNpdmUgdXNlIGJ5IHRoZSBNTiBbUkZDNjQ1OV0uICBUaGUgTU4NCiAgIG1heSB0aGVu IGNvbmZpZ3VyZSBhIGdsb2JhbCBJUHY2IGFkZHJlc3MgZnJvbSB0aGlzIHByZWZpeCBhbmQgdXNl IGl0DQogICBhcyB0aGUgc291cmNlIElQIGFkZHJlc3MgaW4gYSBmbG93IHRvIGNvbW11bmljYXRl IHdpdGggaXRzDQogICBjb3JyZXNwb25kZW50IG5vZGUgKENOKS4NCg0KQ2FwaXRhbGl6ZToNCnMv Y29ycmVzcG9uZGVudCBub2RlL0NvcnJlc3BvbmRlbnQgTm9kZS8NCg0KW0NCXSBPSywgZml4ZWQg aW4gLTE1ICh0byBiZSBzdWJtaXR0ZWQpLg0KDQoNCjIuICBDb252ZW50aW9ucyBhbmQgVGVybWlu b2xvZ3kNCg0KICAgVGhlc2UgaW5jbHVkZSB0ZXJtcyBzdWNoIGFzIG1vYmlsZSBub2RlIChNTiks IGNvcnJlc3BvbmRlbnQgbm9kZQ0KICAgKENOKSwgaG9tZSBhZ2VudCAoSEEpLCBob21lIGFkZHJl c3MgKEhvQSksIGNhcmUtb2YtYWRkcmVzcyAoQ29BKSwNCiAgIGxvY2FsIG1vYmlsaXR5IGFuY2hv ciAoTE1BKSwgYW5kIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSAoTUFHKS4NCg0KQ2FwaXRhbGl6ZSDi gJxNb2JpbGUgTm9kZeKAnSAoYXMgcGVyIMKnIDEpLCDigJxDb3Jlc3BvbmRlbnQgTm9kZeKAnSwg ZXRjLg0KDQpbQ0JdIE9LLCBmaXhlZCBpbiAtMTUgKHRvIGJlIHN1Ym1pdHRlZCkuDQoNCg0KU2lt aWxhciB3aXRoaW4gdGhpcyBzYW1lIMKnIDIsIOKAnG1vYmlsZSByb3V0ZXLigJ0sIGV0Yy4NClNh bWUgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgKGUuZy4sIOKAnHJvdXRlciBhZHZlcnRpc2VtZW50 IChSQSnigJ0pDQoNCltDQl0gT0ssIGZpeGVkIGluIC0xNSAodG8gYmUgc3VibWl0dGVkKS4NCg0K DQo0LjMuICBNb2JpbGl0eSBjYXNlLCBhbmNob3IgcmVsb2NhdGlvbg0KDQogICBUaGUgSVAgcHJl Zml4L2FkZHJlc3MgYW5jaG9yaW5nIG1heSBtb3ZlIHdpdGhvdXQgY2hhbmdpbmcgdGhlIElQDQog ICBwcmVmaXgvYWRkcmVzcyBvZiB0aGUgZmxvdy4gIEhlcmUgdGhlIExNIGFuZCBGTSBmdW5jdGlv bnMgaW4gRmlndXJlIDENCiAgIGluIFNlY3Rpb24gMy4xIGFyZSBpbXBsZW1lbnRlZCBhcyBzaG93 biBpbiBGaWd1cmUgNy4NCg0K4oCcRmlndXJlIDEgaW4gU2VjdGlvbiAzLjEuMSBhcmUgaW1wbGVt ZW50ZWTigJ0NCg0KW0NCXSBPSywgZml4ZWQgaW4gLTE1ICh0byBiZSBzdWJtaXR0ZWQpLg0KDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNzogQW5jaG9yIG1vYmlsaXR5DQoNClNo b3VsZCB0aGlzIGZpZ3VyZeKAmXMgbGFiZWwgYmUg4oCcQW5jaG9yIFJlbG9jYXRpb27igJ0gaW5z dGVhZCBvZiDigJhBbmNob3IgbW9iaWxpdHnigJ0/DQoNCltDQl0gT0ssIG1ha2VzIHNlbnNlLiBG aXhlZCBpbiAtMTUgKHRvIGJlIHN1Ym1pdHRlZCkuDQoNCg0KNS4gIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zDQoNCiAgIEFzIHN0YXRlZCBpbiBbUkZDNzMzM10sICJhIERNTSBzb2x1dGlvbiBNVVNU IHN1cHBvcnRhbnkgc2VjdXJpdHkNCg0Kcy9zdXBwb3J0YW55L3N1cHBvcnQgYW55Lw0KDQpbQ0Jd IE9LLCBmaXhlZCBpbiAtMTUgKHRvIGJlIHN1Ym1pdHRlZCkuDQoNCg0KOC4yLiBJbmZvcm1hdGl2 ZSBSZWZlcmVuY2VzDQoNClRoZSByZWxhdGlvbnNoaXAgb2YgdGhpcyBkb2N1bWVudCBhbmQgZHJh ZnQtaWV0Zi1kbW0tZGVwbG95bWVudC1tb2RlbHMgaXMNCm1vc3RseSBjbGVhciwgdGhhbmsgeW91 IGZvciB0aGF0Lg0KDQpbQ0JdIFJlbGF0ZWQgdG8gdGhpcywgd2UgZ290IGEgY29tbWVudCBmcm9t IE1pcmphLiBTaW5jZSBkcmFmdC1pZXRmLWRtbS1kZXBsb3ltZW50LW1vZGVscyBpcyBub3QgZ29p bmcgdG8gcHJvZ3Jlc3MgYW55IGZ1cnRoZXIsIHdlJ2xsIHRyeSB0byByZW1vdmUgdGhlIHJlZmVy ZW5jZSBhbmQgaW5jb3Jwb3JhdGUgdGhlIG5lZWRlZCBjb250ZW50IHRvIG1ha2Ugb3VyIGRvY3Vt ZW50IHNlbGYgY29udGFpbmVkIHdpdGhvdXQgdGhlIHJlZmVyZW5jZS4NCg0KDQpJIGhvcGUgeW91 IGZpZCB0aGVzZSBjb21tZW50cyB1c2VmdWwuDQoNCltDQl0gVmVyeSBtdWNoIGluZGVlZC4gVGhh bmtzIGEgbG90IQ0KDQpDYXJsb3MNCg0KDQpDYXJsb3MgUGlnbmF0YXJvLg0KDQoNCg0KDQo= --_000_F767356C1ED44957B32A92B32587772Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <568C6849BF00174AB737560B1FC7B97F@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkRlYXIgQ2FybG9zLA0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmsgeW91IGZvciB0aGUgcXVp Y2sgcmVzcG9uc2UgYW5kIHRoZSBleHBsaWNpdCBBY2sgb24gYWxsIHRoZSBpc3N1ZXMhIEhhcHB5 IHRoZSByZXZpZXcgd2FzIHVzZWZ1bC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4oQW5vdGhlcikgQ2FybG9zLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4yMDIwLzAzLzAyIOWNiOW+ jDQ6MzHjgIFDQVJMT1MgSkVTVVMgQkVSTkFSRE9TIENBTk8gJmx0OzxhIGhyZWY9Im1haWx0bzpj amJjQGl0LnVjM20uZXMiIGNsYXNzPSIiPmNqYmNAaXQudWMzbS5lczwvYT4mZ3Q744Gu44Oh44O8 44OrOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSIiPkRlYXIgQ2FybG9zLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldy4gUGxlYXNlIHNlZSBpbmxp bmUgYmVsb3cuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0i bHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gU2F0LCBGZWIgMjksIDIwMjAgYXQgNDowNSBBTSBD YXJsb3MgUGlnbmF0YXJvIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVw bHlAaWV0Zi5vcmciIGNsYXNzPSIiPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwy MDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NClJldmlld2VyOiBDYXJsb3MgUGlnbmF0YXJvPGJy IGNsYXNzPSIiPg0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KSSBhbSBhbiBhc3NpZ25lZCBJTlQgZGlyZWN0b3JhdGUgcmV2aWV3ZXIg Zm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQuJm5ic3A7IFRoZXNlPGJyIGNsYXNzPSIiPg0KY29tbWVu dHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0 IEFyZWEgRGlyZWN0b3JzLjxiciBjbGFzcz0iIj4NCkRvY3VtZW50IGVkaXRvcnMgYW5kIHNoZXBo ZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgdGhleTxiciBjbGFz cz0iIj4NCndvdWxkIHRyZWF0IGNvbW1lbnRzIGZyb20gYW55IG90aGVyIElFVEYgY29udHJpYnV0 b3JzIGFuZCByZXNvbHZlIHRoZW0gYWxvbmc8YnIgY2xhc3M9IiI+DQp3aXRoIGFueSBvdGhlciBM YXN0IENhbGwgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQuIEZvciBtb3JlIGRldGFp bHMgb248YnIgY2xhc3M9IiI+DQp0aGUgSU5UIERpcmVjdG9yYXRlLCBzZWUgPGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlLmh0bWwiIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVj dG9yYXRlLmh0bWw8L2E+LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgaG9wZSB0aGVz ZSBjb21tZW50cyBhcmUgY2xlYXIgYW5kIHVzZWZ1bC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpBcyByZXF1ZXN0ZWQsIGZyb20gdGhlIEludGVybmV0IGFyZWEgRGlyZWN0b3JhdGUgcmV2 aWV3LCB0aGVzZSB0d28gRE1NPGJyIGNsYXNzPSIiPg0KZG9jdW1lbnRzIGFyZSBiZWluZyByZXZp ZXdlZCB0b2dldGhlcjo8YnIgY2xhc3M9IiI+DQoqIGRyYWZ0LWlldGYtZG1tLWRpc3RyaWJ1dGVk LW1vYmlsaXR5LWFuY2hvcmluZy0xNDxiciBjbGFzcz0iIj4NCiogZHJhZnQtaWV0Zi1kbW0tcG1p cHY2LWRsaWYtMDU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGRvY3VtZW50IGRl ZmluZXMgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgYW5jaG9yaW5nLCBpbiB0ZXJtcyBvZiB0aGU8YnIg Y2xhc3M9IiI+DQpkaWZmZXJlbnQgY29uZmlndXJhdGlvbnMgYW5kIGZ1bmN0aW9ucyB0byBwcm92 aWRlIElQIG1vYmlsaXR5IHN1cHBvcnQsPGJyIGNsYXNzPSIiPg0KaW5jbHVkaW5nIG5ldHdvcmst YmFzZWQgb3IgaG9zdC1iYXNlZCBtb2JpbGl0eSBzdXBwb3J0LjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NClRoZSBpbnRlbmRlZCBzdGF0dXMgaXMgSW5mb3JtYXRpb25hbC4gSXQgaXMgYSB2 ZXJ5IHdlbGwgd3JpdHRlbiBhbmQ8YnIgY2xhc3M9IiI+DQpjb21wcmVoZW5zaXZlIGRvY3VtZW50 LiBJdCBpcyB0ZWNobmljYWxseSBzb3VuZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpO byBtYWpvciBvciBtaW5vciBpc3N1ZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTml0 czo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBIHNldCBvZiBzbWFsbCBuaXRzIGZvciB5 b3VyIGNvbnNpZGVyYXRpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KMS4mbmJzcDsg SW50cm9kdWN0aW9uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO0Fz IGEgTW9iaWxlIE5vZGUgKE1OKSBhdHRhY2hlcyB0byBhbiBhY2Nlc3Mgcm91dGVyIGFuZCBlc3Rh Ymxpc2hlcyBhPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2xpbmsgYmV0d2VlbiB0aGVtLCBh IC82NCBJUHY2IHByZWZpeCBhbmNob3JlZCB0byB0aGUgcm91dGVyIG1heSBiZTxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDthc3NpZ25lZCB0byB0aGUgbGluayBmb3IgZXhjbHVzaXZlIHVzZSBi eSB0aGUgTU4gW1JGQzY0NTldLiZuYnNwOyBUaGUgTU48YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7bWF5IHRoZW4gY29uZmlndXJlIGEgZ2xvYmFsIElQdjYgYWRkcmVzcyBmcm9tIHRoaXMgcHJl Zml4IGFuZCB1c2UgaXQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7YXMgdGhlIHNvdXJjZSBJ UCBhZGRyZXNzIGluIGEgZmxvdyB0byBjb21tdW5pY2F0ZSB3aXRoIGl0czxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDtjb3JyZXNwb25kZW50IG5vZGUgKENOKS48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpDYXBpdGFsaXplOjxiciBjbGFzcz0iIj4NCnMvY29ycmVzcG9uZGVudCBub2Rl L0NvcnJlc3BvbmRlbnQgTm9kZS88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5bQ0JdIE9LLCBmaXhl ZCBpbiAtMTUgKHRvIGJlIHN1Ym1pdHRlZCkuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQp O3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyIGNsYXNzPSIiPg0KMi4mbmJzcDsgQ29udmVudGlvbnMg YW5kIFRlcm1pbm9sb2d5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNw O1RoZXNlIGluY2x1ZGUgdGVybXMgc3VjaCBhcyBtb2JpbGUgbm9kZSAoTU4pLCBjb3JyZXNwb25k ZW50IG5vZGU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7KENOKSwgaG9tZSBhZ2VudCAoSEEp LCBob21lIGFkZHJlc3MgKEhvQSksIGNhcmUtb2YtYWRkcmVzcyAoQ29BKSw8YnIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7bG9jYWwgbW9iaWxpdHkgYW5jaG9yIChMTUEpLCBhbmQgbW9iaWxlIGFj Y2VzcyBnYXRld2F5IChNQUcpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNhcGl0YWxp emUg4oCcTW9iaWxlIE5vZGXigJ0gKGFzIHBlciDCpyAxKSwg4oCcQ29yZXNwb25kZW50IE5vZGXi gJ0sIGV0Yy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5bQ0JdIE9LLCBmaXhlZCBpbiAtMTUgKHRv IGJlIHN1Ym1pdHRlZCkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPg0KPGJyIGNsYXNzPSIiPg0KU2ltaWxhciB3aXRoaW4gdGhpcyBzYW1lIMKnIDIs IOKAnG1vYmlsZSByb3V0ZXLigJ0sIGV0Yy48YnIgY2xhc3M9IiI+DQpTYW1lIHRocm91Z2hvdXQg dGhlIGRvY3VtZW50IChlLmcuLCDigJxyb3V0ZXIgYWR2ZXJ0aXNlbWVudCAoUkEp4oCdKTxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPltDQl0gT0ssIGZpeGVkIGluIC0xNSAodG8gYmUgc3VibWl0dGVk KS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVy LWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnIg Y2xhc3M9IiI+DQo0LjMuJm5ic3A7IE1vYmlsaXR5IGNhc2UsIGFuY2hvciByZWxvY2F0aW9uPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1RoZSBJUCBwcmVmaXgvYWRk cmVzcyBhbmNob3JpbmcgbWF5IG1vdmUgd2l0aG91dCBjaGFuZ2luZyB0aGUgSVA8YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7cHJlZml4L2FkZHJlc3Mgb2YgdGhlIGZsb3cuJm5ic3A7IEhlcmUg dGhlIExNIGFuZCBGTSBmdW5jdGlvbnMgaW4gRmlndXJlIDE8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7aW4gU2VjdGlvbiAzLjEgYXJlIGltcGxlbWVudGVkIGFzIHNob3duIGluIEZpZ3VyZSA3 LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCuKAnEZpZ3VyZSAxIGluIFNlY3Rpb24gMy4x LjEgYXJlIGltcGxlbWVudGVk4oCdPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+W0NCXSBPSywgZml4 ZWQgaW4gLTE1ICh0byBiZSBzdWJtaXR0ZWQpLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4m bmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0 KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO0ZpZ3VyZSA3OiBBbmNob3IgbW9iaWxpdHk8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpTaG91bGQgdGhpcyBmaWd1cmXigJlzIGxhYmVsIGJlIOKAnEFuY2hvciBSZWxv Y2F0aW9u4oCdIGluc3RlYWQgb2Yg4oCYQW5jaG9yIG1vYmlsaXR54oCdPzxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPltDQl0gT0ssIG1ha2VzIHNlbnNlLiBGaXhlZCBpbiAtMTUgKHRvIGJlIHN1Ym1p dHRlZCkuJm5ic3A7Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAw cHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRp bmctbGVmdDoxZXgiPg0KPGJyIGNsYXNzPSIiPg0KNS4mbmJzcDsgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7QXMgc3RhdGVk IGluIFtSRkM3MzMzXSwgJnF1b3Q7YSBETU0gc29sdXRpb24gTVVTVCBzdXBwb3J0YW55IHNlY3Vy aXR5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0Kcy9zdXBwb3J0YW55L3N1cHBvcnQgYW55 LzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPltDQl0gT0ssIGZpeGVkIGluIC0xNSAodG8gYmUgc3Vi bWl0dGVkKS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+ DQo8YnIgY2xhc3M9IiI+DQo4LjIuIEluZm9ybWF0aXZlIFJlZmVyZW5jZXM8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGUgcmVsYXRpb25zaGlwIG9mIHRoaXMgZG9jdW1lbnQgYW5kIGRy YWZ0LWlldGYtZG1tLWRlcGxveW1lbnQtbW9kZWxzIGlzPGJyIGNsYXNzPSIiPg0KbW9zdGx5IGNs ZWFyLCB0aGFuayB5b3UgZm9yIHRoYXQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+W0NCXSBSZWxh dGVkIHRvIHRoaXMsIHdlIGdvdCBhIGNvbW1lbnQgZnJvbSBNaXJqYS4gU2luY2UgZHJhZnQtaWV0 Zi1kbW0tZGVwbG95bWVudC1tb2RlbHMgaXMgbm90IGdvaW5nIHRvIHByb2dyZXNzIGFueSBmdXJ0 aGVyLCB3ZSdsbCB0cnkgdG8gcmVtb3ZlIHRoZSByZWZlcmVuY2UgYW5kIGluY29ycG9yYXRlIHRo ZSBuZWVkZWQgY29udGVudCB0byBtYWtlIG91ciBkb2N1bWVudCBzZWxmIGNvbnRhaW5lZCB3aXRo b3V0IHRoZQ0KIHJlZmVyZW5jZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgg MC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0 OjFleCI+DQo8YnIgY2xhc3M9IiI+DQpJIGhvcGUgeW91IGZpZCB0aGVzZSBjb21tZW50cyB1c2Vm dWwuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+W0NCXSBWZXJ5IG11Y2ggaW5kZWVkLiBUaGFua3Mg YSBsb3QhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5DYXJsb3M8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+ DQo8YnIgY2xhc3M9IiI+DQpDYXJsb3MgUGlnbmF0YXJvLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F767356C1ED44957B32A92B32587772Aciscocom_-- From nobody Tue Mar 3 10:57:31 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 893E13A25AF; Tue, 3 Mar 2020 10:57:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , maxpassion@gmail.com, bill.wu@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <158326185053.7640.4273113400366955585@ietfa.amsl.com> Date: Tue, 03 Mar 2020 10:57:30 -0800 Archived-At: Subject: [DMM] Warren Kumari's No Objection on draft-ietf-dmm-distributed-mobility-anchoring-14: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 18:57:31 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am balloting NoObj, but I had a hard time deciding between this and DISCUSS (I went with NoObj because I'm submitting this late) - Qin Wu submitted an OpsDir review with a number of open questions, as well as some very easy to address comments / suggestions. It looks like this were either ignored, or missed (or, perhaps I missed the discussion) I strongly encourage the authors and AD to review and address these comments. From nobody Tue Mar 3 13:20:59 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ED43A09D1 for ; Tue, 3 Mar 2020 13:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sY2a7ZhHQk8 for ; Tue, 3 Mar 2020 13:20:55 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2033A09CC for ; Tue, 3 Mar 2020 13:20:55 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id m13so6259713edb.6 for ; Tue, 03 Mar 2020 13:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6NegvsqVphW1WvchcdZt47VN/0hw9icdcQXwx9zkRn0=; b=oyuOPkF13gjS/zs7GORK7qdE8rM7u864Sj5/VAc6NFb6tT4V6YRKOx688kK7kXp7/C 8hT6nINObY004XFCx9Q1aZ+WU2wSZek6zQQR6o0AVas/ucrw4OZoKMP1sAUxYVZgzOj+ IRyKJnM6n6BFP+BkmoSK9CKvNa6ZaLmorl5g4LoY7k9g4H+UKAKdjlMYkqGB76/MpkY7 ulFlT8NYODu1srU9fcuUtbu0waEC/VwIki9FbCf8cGMDkLyQhHYdW3b97zaL92lSBdYe poV+Q4kIhRgya+KcriWtRJU5T3/ovmlsE45mFP4KxuHTlGZGek6VFfGDOtKhITeIvGA/ KpyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6NegvsqVphW1WvchcdZt47VN/0hw9icdcQXwx9zkRn0=; b=RpTxb8Xgb7eqmjP2ftw5fYXHhJrpjqA4JN3LDY2t8anfxwPEg6j22GrdSEcZPdCPPX fIa+XUXDsNH7qc8Rr++IMzrpAL/PQNFMkuxd/iX/F5Nkd+jxxGmJ+M/OLUHx6I5Q5748 CzjKl92X7A4FJIlSvRu8RqOFA/Mw2VoR+74Al9qW2Bde89CfJSmz/P5QUq7gIoasV7Gk thxaVDuPr9pCrWIekfzm9o9micVT41ISSQLxUfdNdVm+j9LmbxYD2ek//q/O/fWLp34R juDiL0MCX1LZaXF9WJ8faCdN2oXkEMOqcKsxuB+5UfYSXWi0O2vRQAxeUsZOZqqYYMfz pbtA== X-Gm-Message-State: ANhLgQ0LaFH/vq7mGVK3OfRZhtNDigrQvQJ+NsuG/EFbAA1Uwz+1MiUW Jg6FAD3T89Mxqzk70/eNlwVpmuTftSUR89N/KgmzbA== X-Google-Smtp-Source: ADFU+vtkVZ3hRxAJgx2MFScVxuvRqU91VTAxfxI+zfc0Tu03M6UPUQM8hou+NPWfLm9t7QXJWkeuTBdDtUIfJKHisjA= X-Received: by 2002:a17:906:4b06:: with SMTP id y6mr5604621eju.287.1583270453828; Tue, 03 Mar 2020 13:20:53 -0800 (PST) MIME-Version: 1.0 References: <158326185053.7640.4273113400366955585@ietfa.amsl.com> In-Reply-To: <158326185053.7640.4273113400366955585@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Tue, 3 Mar 2020 22:20:37 +0100 Message-ID: To: Warren Kumari Cc: The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs , dmm , Dapeng Liu , bill.wu@huawei.com Content-Type: multipart/alternative; boundary="000000000000fbfea0059ff9e067" Archived-At: Subject: Re: [DMM] Warren Kumari's No Objection on draft-ietf-dmm-distributed-mobility-anchoring-14: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 21:20:58 -0000 --000000000000fbfea0059ff9e067 Content-Type: text/plain; charset="UTF-8" Hi Warren, Thanks for your comments. I've checked my e-mail twice and I haven't been able to see the review from Qin Wu. Can you please forward it to me. According to my records I've replied to all the comments and reviews to this draft (I'm working on another one that is also at the IESG evaluation now -- draft-ietf-dmm-pmipv6-dlif -- but this a different document). Apologies in advance if I've missed the review from Qin Wu. Thanks, Carlos On Tue, Mar 3, 2020 at 7:57 PM Warren Kumari via Datatracker < noreply@ietf.org> wrote: > Warren Kumari has entered the following ballot position for > draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am balloting NoObj, but I had a hard time deciding between this and > DISCUSS > (I went with NoObj because I'm submitting this late) - Qin Wu submitted an > OpsDir review with a number of open questions, as well as some very easy to > address comments / suggestions. It looks like this were either ignored, or > missed (or, perhaps I missed the discussion) > > I strongly encourage the authors and AD to review and address these > comments. > > > > --000000000000fbfea0059ff9e067 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Warren,

Thanks for your comments. I&= #39;ve checked my e-mail twice and I haven't been able to see the revie= w from Qin Wu. Can you please forward it to me. According to my records I&#= 39;ve replied to all the comments and reviews to this draft (I'm workin= g on another one that is also at the IESG evaluation now --=C2=A0draft-ietf= -dmm-pmipv6-dlif -- but this a different document).

Apologies in advance if I've missed the review from Qin Wu.

Thanks,

Carlos

On Tue, Mar 3,= 2020 at 7:57 PM Warren Kumari via Datatracker <noreply@ietf.org> wrote:
Warren Kumari has entered the following ballot = position for
draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.i= etf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am balloting NoObj, but I had a hard time deciding between this and DISCU= SS
(I went with NoObj because I'm submitting this late) - Qin Wu submitted= an
OpsDir review with a number of open questions, as well as some very easy to=
address comments / suggestions. It looks like this were either ignored, or<= br> missed (or, perhaps I missed the discussion)

I strongly encourage the authors and AD to review and address these comment= s.



--000000000000fbfea0059ff9e067-- From nobody Tue Mar 3 16:38:06 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB143A0964 for ; Tue, 3 Mar 2020 16:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBKGx6GWoFJX for ; Tue, 3 Mar 2020 16:37:50 -0800 (PST) Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8313A0966 for ; Tue, 3 Mar 2020 16:37:49 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id c19so50201qvv.4 for ; Tue, 03 Mar 2020 16:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MZH/bR/qgAxT4gJUzr9VJZuznJLZhr2KTTWiuUIJqdo=; b=WlPfgX+SbfRJlNN1B8LsOzcsMPPMkgI/wkcblRZmjPIM0s1FYyulB0p6sUkNFynibZ wghb5098WBy8Ou4MphWqFnnyXRpcCmzHRDYTCQMPeSbiZ8LTrknw/Y98MXXkng1NmPk1 tyGk51leFIjlTtk0OKgXBp+RbGDrRRwUOeGl7IA/tu1/lGH31JCjoHq/56u1AtlV2UGW QEa12Go7r++Z7VIGNelDE/SrJ/ia6RaXHasRzTJbomKB3SXwEDUZsl+6gGWHyLraMv6f VisUnzW2CQmgrPOktCR7cdA1aGe+8pe5J46tgG7LQZt9tEX24x1YbLnvXGV8LYGxxj6K RrtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MZH/bR/qgAxT4gJUzr9VJZuznJLZhr2KTTWiuUIJqdo=; b=X2nm0oKfjrS5Ls5Bc5vm3h4RA1ZKvtSuJhKrCO84K482i2Ki2qeP7QlC+2xloEJi4Y qqcJJG3gB3DV3arc8tLhhR1G4HHy3bYlEqqcOZbeIkKfE389oyCh/cSsaocTaZQ71+ky VFw7vpglv4PO2Q4ZomZmx2J3knNduw/q4QzLkpX240KJ58ApE01f1RCFcTECsnSaSTgI /X5m7BvgK8biWQG7b2gNFmlJfpGWsaXfOf5BE310NNh+OtcU0mL2buEQAefafx4zc/hC Nv8VMrXq+5tmwLf9g7xVT7dc1iw6ibeFBpSF/+0dy6YTvEiwjD7kb0QJiaLNMfhT0r5v i5Yw== X-Gm-Message-State: ANhLgQ2qIRTrVqtquk9bhfyAhaxjMQi4Er6atl8J+s/dSjSSIljdNHBV jqWJjkgT9puaiPBaypn31Nw+WyOc529fyzptYhy0ww== X-Google-Smtp-Source: ADFU+vtXJlAK+LrGkbVYNzUQEBoh2/sKLARe674Xp/X3U5IC1xOUVWLN3o+DE2EfjuKs1/jf8mK4op2Tl07DyXD7e8M= X-Received: by 2002:ad4:59d1:: with SMTP id el17mr143499qvb.29.1583282268296; Tue, 03 Mar 2020 16:37:48 -0800 (PST) MIME-Version: 1.0 References: <158326185053.7640.4273113400366955585@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Tue, 3 Mar 2020 19:37:11 -0500 Message-ID: To: CARLOS JESUS BERNARDOS CANO Cc: The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs , dmm , Dapeng Liu , Qin Wu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DMM] Warren Kumari's No Objection on draft-ietf-dmm-distributed-mobility-anchoring-14: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 00:37:56 -0000 On Tue, Mar 3, 2020 at 4:20 PM CARLOS JESUS BERNARDOS CANO wrote: > > Hi Warren, > > Thanks for your comments. I've checked my e-mail twice and I haven't been= able to see the review from Qin Wu. Can you please forward it to me. Accor= ding to my records I've replied to all the comments and reviews to this dra= ft (I'm working on another one that is also at the IESG evaluation now -- d= raft-ietf-dmm-pmipv6-dlif -- but this a different document). > All directorate reviews should be linked from the Datatracker page: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchor= ing/ The direct link to Qin's is: https://datatracker.ietf.org/doc/review-ietf-dmm-distributed-mobility-ancho= ring-13-opsdir-lc-wu-2019-10-02/ > Apologies in advance if I've missed the review from Qin Wu. > Ah, fair enough, it is easy to miss emails, sometimes they go into spam, et= c. W > Thanks, > > Carlos > > On Tue, Mar 3, 2020 at 7:57 PM Warren Kumari via Datatracker wrote: >> >> Warren Kumari has entered the following ballot position for >> draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anc= horing/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I am balloting NoObj, but I had a hard time deciding between this and DI= SCUSS >> (I went with NoObj because I'm submitting this late) - Qin Wu submitted = an >> OpsDir review with a number of open questions, as well as some very easy= to >> address comments / suggestions. It looks like this were either ignored, = or >> missed (or, perhaps I missed the discussion) >> >> I strongly encourage the authors and AD to review and address these comm= ents. >> >> >> --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Mar 3 17:46:38 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8F3A0AAB; Tue, 3 Mar 2020 17:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=IOgRNwpv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lhn6cFV3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PDBkqX3V4EG; Tue, 3 Mar 2020 17:46:33 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D2533A0AAC; Tue, 3 Mar 2020 17:46:30 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 5F74871A; Tue, 3 Mar 2020 20:46:29 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 03 Mar 2020 20:46:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=Znjn5vBf44YqjykdMdEf4+T Ves+BY1Zq22WKzzSXQvI=; b=IOgRNwpv/isrGSl0blSG4TzxUFvbPq8I76eIQNg l0vYHhaSYwa9RMR34Y6tG7FzfuWScd8ZrghPGLEWxzJpkLXH4eCc6zB5Dp3VKQPf qVUThvQ5x5p/PPkt3UmS7jydzYQ7q5LIH8DS0DKglbY1lho+X4IZpruujaoO22hQ t2488Ku86QBDngtEZ0jh82itMoxBBAgMOZuT9SUJ3qT7k1ydHsteR4FqxIs8StC3 IFUoEEHEYNafN4WK+abT+WP1FU5wBcKrYNfM1ICWv8pNAXtsHgjlm0nFHMhxrYnv 9JD1GXsFd1eS/GgLYSiHeef2Nvlakh6jj9yGeuyfDjdPHTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Znjn5v Bf44YqjykdMdEf4+TVes+BY1Zq22WKzzSXQvI=; b=lhn6cFV3xM6Qo8ieGqnXfL j4DJYkQI15t9s0Y8xpumD9Eaerc9KNBscFPeBKeAxJujHlKaDQ5r0hbbjVeX5GBm iQBDaaCbX4rjd4AlyiF9GJNWfygG4jT23WplHJxVzH2aov8BZFTaqWYn2jYE/WBJ xTqCdiCCZTT9T7Y2Ur2eUVMwob5XYt2dDRsNzARt6wRXoBl3//lr86n0nJlPuE8D HljTAGV5TAG+j84bJEgcTvcuWktqjXuyFE6M8R9stheSZBxTgc1+i9YBhSUmfILb I/e2CK4eRHevfloQd/hboAOu+tbbZiCWPcpiLzVK302YC6TGAYmM9xmshXHr1PLg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtjedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghdpmhguphhirdgtohhmnecukfhppedujeefrdefkedruddujedr jedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.71]) by mail.messagingengine.com (Postfix) with ESMTPA id 177893060F09; Tue, 3 Mar 2020 20:46:28 -0500 (EST) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8F51D918-1410-43CC-B6D1-447CB7AB6739" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 3 Mar 2020 20:46:27 -0500 In-Reply-To: Cc: draft-ietf-dmm-pmipv6-dlif.all@ietf.org, General Area Review Team , dmm To: CARLOS JESUS BERNARDOS CANO , Ines Robles References: <157108446243.24779.12043209679040887677@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [DMM] [Gen-art] Genart last call review of draft-ietf-dmm-pmipv6-dlif-04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 01:46:35 -0000 --Apple-Mail=_8F51D918-1410-43CC-B6D1-447CB7AB6739 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ines, thanks for your review. Carlos, thanks for your response. I = entered a No Objection ballot. Alissa > On Nov 2, 2019, at 7:44 AM, CARLOS JESUS BERNARDOS CANO = wrote: >=20 > Hi Ines, >=20 > We've just posted a new revision addressing your comments. >=20 > Thanks, >=20 > Carlos >=20 > On Fri, Oct 18, 2019 at 1:21 PM CARLOS JESUS BERNARDOS CANO = > wrote: > Hi Ines, >=20 > Thanks for the review. We'll check with IANA folks about how to add = more details (whether they do it or we do). >=20 > Thanks, >=20 > Carlos >=20 > On Mon, Oct 14, 2019 at 10:21 PM Ines Robles via Datatracker = > wrote: > Reviewer: Ines Robles > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > >. >=20 > Document: draft-ietf-dmm-pmipv6-dlif-04 > Reviewer: Ines Robles > Review Date: 2019-10-14 > IETF LC End Date: 2019-10-14 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > I believe the draft is technically good. This document is well = written. >=20 > The document proposes Distributed Mobility Management for Proxy Mobile = IPv6 in > which mobility sessions are anchored at the last IP hop router called = MAAR > (mobility anchor and access router). The document focuses on the = required > extensions to effectively support simultaneously anchoring several = flows at > different distributed gateways. >=20 > I have a minor concern detailed in Nits section. >=20 > Major issues:Not Issues found >=20 > Minor issues: Not Issues found >=20 > Nits/editorial comments: >=20 > It would be nice to specify IANA Section with more details, such as = indicating > the registry which the option type belong, etc. [rfc8126] >=20 > Thank you for this document, >=20 > Ines. >=20 >=20 >=20 >=20 > --=20 > Special Issue "Beyond 5G Evolution": = https://www.mdpi.com/journal/electronics/special_issues/beyond_5g = >=20 >=20 >=20 > --=20 > Special Issue "Beyond 5G Evolution": = https://www.mdpi.com/journal/electronics/special_issues/beyond_5g = >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art = --Apple-Mail=_8F51D918-1410-43CC-B6D1-447CB7AB6739 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ines,= thanks for your review. Carlos, thanks for your response. I entered a = No Objection ballot.

Alissa


On Nov = 2, 2019, at 7:44 AM, CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> = wrote:

Hi Ines,

We've just posted a new revision addressing your = comments.

Thanks,

Carlos

On Fri, Oct 18, 2019 at 1:21 PM CARLOS JESUS = BERNARDOS CANO <cjbc@it.uc3m.es> wrote:
Hi = Ines,

Thanks for the = review. We'll check with IANA folks about how to add more details = (whether they do it or we do).

Thanks,

Carlos

On Mon, Oct = 14, 2019 at 10:21 PM Ines Robles via Datatracker <noreply@ietf.org> wrote:
Reviewer: Ines Robles
Review result: Ready with Nits

I = am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being = processed
by the IESG for the IETF Chair.  Please = treat these comments just
like any other last call = comments.

For more information, please see = the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dmm-pmipv6-dlif-04
Reviewer: Ines Robles
Review Date: = 2019-10-14
IETF LC End Date: 2019-10-14
IESG = Telechat date: Not scheduled for a telechat

Summary:

I believe the draft is = technically good. This document is well written.

The document proposes Distributed Mobility Management for = Proxy Mobile IPv6 in
which mobility sessions are anchored = at the last IP hop router called MAAR
(mobility anchor and = access router). The document focuses on the required
extensions to effectively support simultaneously anchoring = several flows at
different distributed gateways.

I have a minor concern detailed in Nits = section.

Major issues:Not Issues found

Minor issues: Not Issues found
Nits/editorial comments:

It = would be nice to specify IANA Section with more details, such as = indicating
the registry which the option type belong, etc. = [rfc8126]

Thank you for this document,

Ines.




-- 
Special= Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_= 5g



-- 
Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_= 5g

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_8F51D918-1410-43CC-B6D1-447CB7AB6739-- From nobody Wed Mar 4 18:00:29 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 978773A085E; Wed, 4 Mar 2020 18:00:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , maxpassion@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158337360559.29429.15629947241139453126@ietfa.amsl.com> Date: Wed, 04 Mar 2020 18:00:05 -0800 Archived-At: Subject: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-distributed-mobility-anchoring-14: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 02:00:06 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dmm-distributed-mobility-anchoring-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for discussing the need to secure the various control-plane interactions as part of the Security Considerations. In addition to the integrity and source-authentication properties already mentioned, we need to say that the control-plane functionality will apply authorization checks to any commands or updates that are made by the control-plane protocol. Similarly, I didn't see any discussion of authorization for applying or making changes to the "rules" that are mentioned as needing to be applied by a data-plane node (as mentioned in the COMMENT where I ask for clarification on the nature of such rules). Also, we should reference RFCs 8221 and 8247 for the current guidance on IPsec and IKEv2 usage. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While I see the value in having this document to crystallize thinking about the various mobility anchoring techniques that are possible, it's not clear to me how much archival value this document would add to the RFC series in the absence of specific protocol mechanisms to implement the functionality described therein. As such, I expect to change my ballot position to Abstain after my Discuss points are resolved. Section 1 When the MN wants to continue using its assigned prefix to complete ongoing data sessions after it has moved to a new network, the network needs to provide support for the MN's IP address -- and The new network, right? Section 2 Anchoring (of an IP prefix/address): An IP prefix, i.e., Home Network Prefix (HNP), or address, i.e., HoA, assigned for use by an MN is topologically anchored to an anchor node when the anchor node is able to advertise a connected route into the routing Is "connected route" a term of art I should be looking up? and manages the network location information of an MN. The location information may be a binding of the advertised IP address/prefix, e.g., HoA or HNP, to the IP routing address of the MN or of a node that can forward packets destined to the MN. I assume this ("may be [...] or") is not intended to be an exhaustive list? In a client-server protocol model, location query and update messages may be exchanged between a Location Management client (LMc) and a Location Management server (LMs), where the location information can be updated to or queried from the LMc. nit: s/updated to/updated from/? Do we want to discuss the authentication/authorization for such location management functions here? (Including both MN/LMc and LMc/LMs interactions.) Section 4 There may be multiple IP prefixes/addresses that an MN can select when initiating a flow. They may be from the same access network or different access networks. The network may advertise these prefixes with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node may choose the one with the least cost. In addition, these IP This draft has not been updated since 2016. Is it still expected to progress, such that a reference to it remains valuable? prefixes/addresses may be of different types regarding whether mobility support is needed [RFC8653]. A MN will need to choose which IP prefix/address to use for each flow according to whether it needs IP mobility support or not, using for example the mechanisms described in [RFC8653]. I'm confused. "these prefixes/addresses" seems to refer to the ones advertised by the network, but the question of whether mobility support is needed seems like a matter local to the MN and not a need of the network. (Perhaps the network might *provide* different mobility services for different prefixes/addresses, but that's not what this text currently says.) Section 4.1 I suggest to expand access router or list it in the terminology section. When IP session continuity is needed, even if a flow is ongoing as the MN moves, it may still be desirable for the flow to change to using the new IP prefix configured in the new network. The flow may then close and then restart using a new IP address configured in the new network. Such a change in the IP address of the flow may be It's perhaps a little confusing, in a rhetorical sense, to talk about "the flow changing to use the new prefix" but doing that by having the flow "close and then restart" -- is it really the same flow after it has closed? Note that in this scenarios, if there is no mobility support provided by L4 or above, an application might be able to stop before changing point of attachement, and therefore the traffic would stop. I'm not sure what "might be able to stop" is intended to mean. Regardless, it's quite clear that the traffic will stop upon the mobility event in this scenario, since the network does not provide continuity services! Section 4.2 prefix. The latter enables optimized routes but requires some data plane node that enforces rules for traffic indirection. Next, we I'm not sure I understand the role this rule-enforcment is meant to play. What sort of rules would it be enforcing? to AR1 per default routing). The LM and FM functions are implemented as shown in Figure 6. Where is FM indicated in Figure 6? I cannot find it. Also, should there be any control-plane anchoring indicated in Figure 6? Section 4.3 We focus next on the case where the mobility anchor (data plane function) is changed but binds the MN's transferred IP address/ prefix. This enables optimized routes but requires some data plane node that enforces rules for traffic indirection. [same question as above about the rules] IP mobility is invoked to enable IP session continuity for an ongoing flow as the MN moves to a new network. Here the anchoring of the IP address of the flow is in the home network of the flow (i.e., different from the current network of attachment). A centralized nit(?): this usage of "here" is surprising, in that it seems to discuss the same case as the previous section, and not the new mechanism that we're describing in this section. The IP prefix/address anchoring may move without changing the IP prefix/address of the flow. Here the LM and FM functions in Figure 1 in Section 3.1 are implemented as shown in Figure 7. Where is the FM function indicated in Figure 7? I cannot find it. [I-D.ietf-rtgwg-atn-bgp]. When a mobile associates with an anchor the anchor injects the mobile's prefix into the global routing system. If the mobile moves to a new anchor, the old anchor nit: "mobile node" or just "MN" (twice)? withdraws the /64 and the new anchor injects it instead. What kind of synchronization and/or serialization is needed between the withdrawl and injection of the /64 in question? Section 5 As stated in [RFC7333], "a DMM solution MUST supportany security nit: s/supportany/support any/ From nobody Wed Mar 4 21:13:50 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB5F3A0C4C; Wed, 4 Mar 2020 21:13:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , maxpassion@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158338522449.29441.3534240903752483882@ietfa.amsl.com> Date: Wed, 04 Mar 2020 21:13:44 -0800 Archived-At: Subject: [DMM] Barry Leiba's No Objection on draft-ietf-dmm-distributed-mobility-anchoring-14: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 05:13:45 -0000 Barry Leiba has entered the following ballot position for draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- You include the BCP 14 boilerplate and references, but there are no BCP 14 key words in the document (except in a quotation from another document). I suggest removing the boilerplate and the references. From nobody Wed Mar 4 21:20:03 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6889C3A0C6A; Wed, 4 Mar 2020 21:20:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , max.ldp@alibaba-inc.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <158338560241.29408.3648898527474669779@ietfa.amsl.com> Date: Wed, 04 Mar 2020 21:20:02 -0800 Archived-At: Subject: [DMM] Adam Roach's No Objection on draft-ietf-dmm-pmipv6-dlif-05: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 05:20:03 -0000 Adam Roach has entered the following ballot position for draft-ietf-dmm-pmipv6-dlif-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work on this document. I have only one editorial suggestion. Section 3.6: > to-point link) with MN1, exposing itself as a (logical) router with a > specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., Please use a MAC address from the range reserved for documentation purposes by section 2.1.1 of RFC 7042. From nobody Wed Mar 4 21:22:24 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9476E3A0C71; Wed, 4 Mar 2020 21:22:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , max.ldp@alibaba-inc.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158338573858.29475.12173301575622176655@ietfa.amsl.com> Date: Wed, 04 Mar 2020 21:22:18 -0800 Archived-At: Subject: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 05:22:19 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dmm-pmipv6-dlif-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a very boring Discuss point and a somewhat boring point, and expect to change my ballot to Yes once they're resolved. In Section 3.2 we say that pacing mechanisms "MAY" be used to avoid bursts when the CMD is fanning out PBUs, but in Section 6 we say that pacing "SHOULD" be used; please resolve the inconsistency (preferrably with "MUST" as Mirja requests). Please also include some discussion of privacy considerations (I give some suggestions in the COMMENT). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this well-written document! It is clearly written, and when multiple approaches exist, does well at laying out the different options and their pros/cons, as befits an Experimental document. Also, several times I have started to write a comment only to realize that it is answered by the following text :) Section 1 The Distributed Mobility Management (DMM) paradigm aims at minimizing the impact of currently standardized mobility management solutions which are centralized (at least to a considerable extent). I'd consider saying a little more about which aspects of their operation are centralized. Perhaps the following paragraph suffices, though. Following this idea, in our proposal, the central anchor is moved to the edge of the network, being deployed in the default gateway of the mobile node. That is, the first elements that provide IP (side note: Using the singular "central anchor" poses an interesting rhetorical question: is the (formerly) single central anchor being duplicated and spread amongst all access routers, or does there remain a single central anchor (per MN), just one that moves around along with the MN.) anchors to retrieve the MN's previous location(s). Also, a key- aspect of network-based DMM, is that a prefix pool belongs exclusively to each MAAR, in the sense that those prefixes are assigned by the MAAR to the MNs attached to it, and they are routable at that MAAR. It might be worth some statement relating this "ownership" of prefixes to actual mobility events -- e.g., they are assigned to MNs attached to it at that time, but remain with those MNs as mobility occurs, but always remain routable at that MAAR as well as towards the MN itself. We consider partially distributed schemes, where the data plane only is distributed among access routers similar to MAGs, whereas the nit: I suggest s/the data plane only/only the data plane/ control plane is kept centralized towards a cardinal node used as information store, but relieved from any route management and MN's data forwarding task. What's the scope of "single" here -- per deployment, per prefix, per MAAR, ...? P-MAAR (Previous MAAR). When a MN moves to a new point of attachment a new MAAR might be allocated as its anchor point for future IPv6 prefixes. The MAAR that served the MN prior to new attachment becomes the P-MAAR. It is still the anchor point for the IPv6 prefixes it had allocated to the MN in the past and serves as the (side note? Do we expect those previous allocations to eventually "time out" as sessions using them terminate? Or are the allocations more permanent, with intent to reuse if/when the MN returns to that MAAR?) Section 3 interest and eventually take the appropriate action. The procedure adopted for the query and the messages exchange sequence might vary to optimize the update latency and/or the signaling overhead. Here nit: wrong pluralization in "messages exchange sequence" Section 3.1 3. Since this is an initial registration, the CMD stores a permanent BCE containing as primary fields the MN-ID, Pref1 and MAAR1's address as a Proxy-CoA. [how permanent is "permanent"?] Section 3.2 1. When the MN moves from its current point of attachment and attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6 prefix (Pref2), it stores a temporary BCE, and it sends a plain PBU to the CMD for registration. It's not clear to me at this point how MAAR2 has enough information to determine that this will be a "plain" PBU vs. the the PBU used for initial registration. (That said, it's also not clear to me that the send PBU actually differs on the wire, so maybe this is just a rhetorical question. Er, a question of rhetoric, that is.) 4. The CMD, after receiving the PBA, updates the BCE populating an instance of the P-MAAR list. The P-MAAR list is an additional field on the BCE that contains an element for each P-MAAR involved in the MN's mobility session. The list element contains the P-MAAR's global address and the prefix it has delegated (see Appendix B for further details). Also, the CMD sends a PBA to the new S-MAAR, containing the previous Proxy-CoA and the prefix anchored to it embedded into a new mobility option called Previous MAAR Option (defined in Section 4.5), so that, upon PBA arrival, a bi-directional tunnel can be established between the two MAARs and new routes are set appropriately to recover the IP flow(s) carrying Pref1. To check my understanding: there will only be one Previous MAAR Option present and it will describe only a single MAAR, which implies that if there are multiple P-MAARs, traffic directed to an arbitrary prefix based at one of them is expected to traverse multiple tunnels from P-MAAR to P-MAAR before making its way to the S-MAAR and the MN? [Hmm, looks like my understanding is wrong. I'd consider making "previous Proxy-CoA" and "the prefix anchored to it" plural to give the reader a hint as to what's coming, though I can understand if there is desire to keep the initial mobility example simple and only gradually introduce the complexity in question.] For MN's next movements the process is repeated except the number of P-MAARs involved increases (accordingly to the number of prefixes that the MN wishes to maintain). Indeed, once the CMD receives the first PBU from the new S-MAAR, it forwards copies of the PBU to all the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR prior to handover) and in the P-MAARs list. They reply with a PBA to the CMD, which aggregates them into a single one to notify the S-MAAR, that finally can establish the tunnels with the P-MAARs. I'm not sure I understand the cardinality of P-CoA -- is it one, the single S-MAAR prior to handover, or many, all P-MAARs in the list? When there are multiple previous MAARs, e.g., k MAARs, a single PBU received by the CMD triggers k outgoing packets from a single incoming packet. This may lead to packet bursts originated from the CMD, albeit to different targets. Pacing mechanisms MAY be introduced to avoid bursts on the outgoing link. I'll defer to my TSV colleagues, but a "SHOULD" feels more comfortable than "MAY" to me, here. Section 3.3 The handover latency experienced in the approach shown before can be reduced if the P-MAARs are allowed to signal directly their information to the new S-MAAR. This procedure reflects what was described in Section 3.2 up to the moment the P-MAAR receives the PBU with the P-MAAR option. At that point a P-MAAR is aware of the new nit(?): I think this is the S-MAAR option, not the P-MAAR option? S-MAAR including the prefix it is anchoring. This latter PBA does not need to include new options, as the prefix is embedded in the HNP option and the P-MAAR's address is taken from the message's source address. The CMD is relieved from forwarding the PBA to the S-MAAR, (side note: this assumes there's no NAT or tunneling or similar between MAARs, which seems like a plausible assumption, at least for now.) Section 3.4 side. When P-MAARs complete the update, they send a PBA to the CMD to indicate that the operation is concluded and the information is updated in all network nodes. This procedure is obtained from the Is there anything useful to say about behavior on timeout at the CMD (failing to reive a PBA from one or more P-MAARs)? Section 3.5 The de-registration mechanism devised for PMIPv6 cannot be used as is in this solution. The reason for this is that each MAAR handles an nit: s/as is/as-is/ Indeed, when a previous MAAR initiates a de-registration procedure, because the MN is no longer present on the MAAR's access link, it removes the routing state for that (those) prefix(es), that would be deleted by the CMD as well, hence defeating any prefix continuity attempt. The simplest approach to overcome this limitation is to nit(?): s/when/if/. At least, this makes more sense to me if I do that ... maybe I'm just confused. serving MAAR to de-register the whole MN session. This can be achieved by first removing any layer-2 detachment event, so that de- registration is triggered only when the session lifetime expires, I see that RFC 5213 has some mechanisms for lifetime management, but didn't get to look closely enough to understand how clear the necessary lifetime management will be in the DMM case when there are multiple prefixes registered to a given MN at different MAARs. (Also, 5213 doesn't seem to use the "session lifetime" phrase verbatim.) Section 3.6 requiring special support from the mobile node's IP stack. This document defines the Distributed Logical Interface (DLIF), which is a software construct that allows to easily hide the change of associated anchors from the mobile node. A software construct in the MAAR, right? How common is "HMAC" as an abbreviation for "hardware MAC address"? It's also an abbreviation for Hash-based Message Authentication Code, which confuses my poor security-focused brain, though I acknowledge that this does not necessarily extend to most of the target audience for this document... and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)? role of anchoring MAAR for the attached (served) MNs. Each MAAR has one single physical wireless interface. Have we defined "anchoring MAAR" yet? Also, I assume that the "single physical interface" is just "as depicted in this example" and not a protocol requirement :) As introduced before, each MN always "sees" multiple logical routers -- one per P-MAAR -- independently of its currently serving MAAR. [same P-MAAR vs. S-MAAR split as above] by the serving MAAR (MAAR2) configuring an additional distributed logical interface: mn1mar1, which behaves exactly as the logical interface configured by MAAR1 when MN1 was attached to it. This nit(?): "exactly" is asking for pedants to try and poke holes in the claimed perfection. deprecated). The goal is to deprecate the prefixes delegated by these MAARs (which will be no longer serving the MN). Note that on- nit(?): s/which will be no longer/so that they will no longer be/, IIUC Section 4.1 The intdir reviewer's comments regarding the flag bits seem apropos (I presume they were allocated by other extensions to 5213, but we should say something about it). A new flag (D) is included in the Proxy Binding Update to indicate that the Proxy Binding Update is coming from a Mobility Anchor and "D" is for "DMM", I trust? It could be worth mentioning. Is the D bit set for the PBUs sent from CMD to P-MAAR as well? (I see that the PBA description uses a slightly different formulation to cover the 'D' bit; is there a reason to diverge?) Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC6275]. The MAAR MUST ignore and skip any options that it does not understand. MAARs that *receive* PBUs must be P-MAARs, right? Section 4.2 MAAR (D) The D is set to indicate that the sender of the message supports operating as a Mobility Anchor and Access Router. When a MAG that does not support the extensions described in this document receives a message with the D-Flag set, it MUST ignore the message and an error MUST be returned. Is the CMD considered a MAAR for this purpose? contains zero or more TLV-encoded mobility options. The encoding and format of defined options are described in Section 6.2 of [RFC6275]. The MAAR MUST ignore and skip any options that it does not understand. What about the CMD? Section 4.3, 4.4 Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. Anchored Prefix A sixteen-byte field containing the mobile node's IPv6 Anchored Prefix. Only the first Prefix Length bytes are valid for the Anchored Prefix. The rest of the bytes MUST be ignored. Is the prefix length bits or bytes? Section 4.4 Is this also used to convey "local" prefixes in the PBA from CMD to S-MAAR? (If not, how does the S-MAAR know to advertise them from its DLIF?) Section 4.5 What's the alignment requirement? (There's no need to put in a Reserved octet to keep things word aligned?) Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option. [...] Home Network Prefix A sixteen-byte field containing the mobile node's IPv6 Home Network Prefix. Only the first Prefix Length bytes are valid for the mobile node's IPv6 Home Network Prefix. The rest of the bytes MUST be ignored. [is the prefix length bits or bytes?] Section 4.6 Is there an alignment requirement for this option? This new option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgement messages exchanged between the CMD and When is this option used in a PBA? Section 4.7 A new DLIF Link-local Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between MAARs. This option is used for exchanging the MAARs but not CMDs? When is this used in the PBU? Section 4.8 A new DLIF Link-layer Address option is defined for use with the Proxy Binding Update and Proxy Binding Acknowledgment messages exchanged between MAARs. This option is used for exchanging the MAARs but not CMDs? When is this used in the PBU? Section 6 Unfortunately it seems that RFC 5213 does not include any privacy considerations discussion. While the privacy properties of this protocol bear similarities to those of RFC 5213, it seems that there are also some significant differences, so I do think it is important to produce some documentation of privacy considerations for this document. The main factor would, of cousre, be tracking which entities obtain updates/information about the location of the MN, what those entities are expected to do with that data, and how trusted they are to be proper custodians of it. Other factors may exist as well, including the potential for side-channel information leakage, e.g., due to traffic analysis. There might also be a reverse situation where exposing the link-layer address(es) of a P-MAAR have privacy considerations, though I don't have anything particular in mind at the moment. security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended that the signaling messages, Proxy Binding Update and Proxy Binding Acknowledgment, exchanged between the MAARs are protected using IPsec using the established security association between them. This This is essentially unchanged from 5213, just with different names for the endpoints, right, and so the existing guidance/experiences apply? I think we should also say something about all MAARs and the CMD being trusted parties. We should also say something about the authorization model (I assume it's just "all trusted parties are trusted to perform all operations relevant to their role", but that's still useful to say). When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a single PBU to multiple previous MAARs. In situations of many fast handovers (e.g., with vehicular networks), there may exist multiple previous (e.g., k) MAARs exist. In this situation, the CMD creates k nit: remove the redundant "exist" When the CMD acts as MAAR locator, mobility signaling (PBAs) is exchanged between P-MAARs and current S-MAAR. This requires security associations to exist between the involved MAARs (in addition to the ones needed with the CMD). Is this relevant because of scaling/resource-consumption concerns or keying/trust ones? Appendix A.5 not implement existing mobility protocols. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when the needed mobility management Hmm, separate administrative domains makes the risk of NAT relatively higher (per previous comment about NAT). intervention. The partially distributed DMM solution can be deployed across different domains with trust agreements if the CMDs of the operators are enabled to transfer context from one node to another. It would probably be worth expounding a bit more about this scenario and the necessary trust/authorization relationships, in the security considerations. From nobody Wed Mar 4 21:29:59 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0252D3A0CA0; Wed, 4 Mar 2020 21:29:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , maxpassion@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158338619598.29359.1563714463313257220@ietfa.amsl.com> Date: Wed, 04 Mar 2020 21:29:56 -0800 Archived-At: Subject: [DMM] Roman Danyliw's No Objection on draft-ietf-dmm-distributed-mobility-anchoring-14: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 05:29:57 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Ben Kaduk’s DISCUSS point. Section 5. To provide symmetry with the IPSec recommendation, s/IKEv2 should/IKEv2 SHOULD/ From nobody Wed Mar 4 21:51:29 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FEC3A0D44; Wed, 4 Mar 2020 21:51:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , max.ldp@alibaba-inc.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158338747964.29279.13608150336261590355@ietfa.amsl.com> Date: Wed, 04 Mar 2020 21:51:19 -0800 Archived-At: Subject: [DMM] Roman Danyliw's No Objection on draft-ietf-dmm-pmipv6-dlif-05: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 05:51:20 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-dmm-pmipv6-dlif-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Mirja Kühlewind's and Ben Kaduk's DISCUSS position. ** Section 6. Per “The CMD SHOULD use a pacing approach to limit this amplification risk”, could you address Vincent Roca’s SECDIR Review (thank you!) question “should that pacing be on the In the incoming queue (i.e., by delaying some PBU/PBA messages) or in the outgoing queue (i.e., to limit output traffic), or both?” ** Section 6. To provide normative language: s/This requires security associations to exist between the involved MAARs/ Hence, security associations are REQUIRED to exist between the involved MAARs/ Editorial Nit: ** Section 6. s/there may exist multiple previous (e.g., k) MAARs exist/ there may exist multiple previous (e.g., k) MAARs/ From nobody Wed Mar 4 22:23:48 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE79E3A0DE8; Wed, 4 Mar 2020 22:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id digiHXWMvBvs; Wed, 4 Mar 2020 22:23:43 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 93C6F3A0DE4; Wed, 4 Mar 2020 22:23:43 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 5656D5548A0862F9B1CC; Thu, 5 Mar 2020 06:23:41 +0000 (GMT) Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 5 Mar 2020 06:23:40 +0000 Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by nkgeml701-chm.china.huawei.com (10.98.57.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5; Thu, 5 Mar 2020 14:23:38 +0800 Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.1713.004; Thu, 5 Mar 2020 14:23:37 +0800 From: "Gengxuesong (Geng Xuesong)" To: Satoru Matsushima , dmm CC: "Dongjie (Jimmy)" , "draft-geng-teas-network-slice-mapping@ietf.org" Thread-Topic: [DMM] IETF107 DMM Call for Agenda Items Thread-Index: AQHV6wuCAC/SKbeRHke7gnFAzAEjlag5lmZQ Date: Thu, 5 Mar 2020 06:23:37 +0000 Message-ID: <6159877a501046a69f00073b70199463@huawei.com> References: <7A0C0A85-E661-4564-AEB7-C81E645404F6@gmail.com> In-Reply-To: <7A0C0A85-E661-4564-AEB7-C81E645404F6@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.200] Content-Type: multipart/alternative; boundary="_000_6159877a501046a69f00073b70199463huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [DMM] IETF107 DMM Call for Agenda Items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 06:23:46 -0000 --_000_6159877a501046a69f00073b70199463huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Satoru, I would like to apply a time slot for our new draft: draft-geng-teas-networ= k-slice-mapping-00 . Title: 5G End-to-end Network Slice Mapping from the view of Transport Netwo= rk Presenter: Xuesong Geng (present remotely maybe) Time slot: 10 minutes You could find the draft : https://tools.ietf.org/html/draft-geng-teas-netw= ork-slice-mapping-00 The draft intends to give an overview of how to map network slice from RAN/= Core defined in 3GPP to transport network slice defined in IETF, which is a= very important issue when SP deploys 5G Network slice in real network. This is the first version of the draft, and we are still looking for a prop= er home for further promotion. Considering that the draft is very relevant = to the topic that has been discussed in dmm, It will be great that the draf= t could be discussed and get more feedback in dmm; Best Regards Xuesong -----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Satoru Matsushima Sent: Monday, February 24, 2020 8:11 PM To: dmm Subject: [DMM] IETF107 DMM Call for Agenda Items Folks, The DMM working group chairs are planning the dmm meeting in Vancouver at I= ETF107. If you have a draft, or any topics you would like to discuss, please send y= our request for agenda time to the dmm chairs with: Presentation title: Presenter name: Time you need: Draft reference: Please send your proposed agenda items to the chairs by 2020-03-09 (March 9= th). Reminder: The draft cut-for date: 2020-03-09 UTC23:59. Cheers, --satoru _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_6159877a501046a69f00073b70199463huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Satoru,<= /span>

 =

I would like = to apply a time slot for our new draft: draft-geng-teas-network-slice-mappi= ng-00 .

Title: 5G En= d-to-end Network Slice Mapping from the view of Transport Network

Presenter:= X= uesong Geng (present remotely maybe)=

Time slot:= 1= 0 minutes

You could fin= d the draft : https://tools.ietf.org/= html/draft-geng-teas-network-slice-mapping-00

The draft int= ends to give an overview of how to map network slice from RAN/Core defined = in 3GPP to transport network slice defined in IETF, which is a very importa= nt issue when SP deploys 5G Network slice in real network.

This is the f= irst version of the draft, and we are still looking for a proper home for f= urther promotion. Considering that the draft is very relevant to the topic = that has been discussed in dmm, It will be great that the draft could be discussed and get more feedback in dmm;

 =

Best Regards<= /span>

Xuesong

 

-----Original Message----- From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Satoru Matsushima
Sent: Monday, February 24, 2020 8:11 PM
To: dmm <dmm@ietf.org>
Subject: [DMM] IETF107 DMM Call for Agenda Items

 

Folks,

 

The DMM working group chairs= are planning the dmm meeting in Vancouver at IETF107.

 

If you have a draft, or any = topics you would like to discuss, please send your request for agenda time = to the dmm chairs with:

 

Presentation title:

Presenter name:

Time you need:

Draft reference:<= /span>

 

Please send your proposed ag= enda items to the chairs by 2020-03-09 (March 9th).

 

Reminder:<= /p>

The draft cut-for date: 2020= -03-09 UTC23:59.

 

Cheers,

--satoru

____________________________= ___________________

dmm mailing list<= /span>

dmm@ietf.org

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

--_000_6159877a501046a69f00073b70199463huaweicom_-- From nobody Fri Mar 6 09:55:10 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E113A0C4D for ; Fri, 6 Mar 2020 09:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TZC6YsXr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZpvGzlnc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4NY-Du20XbP for ; Fri, 6 Mar 2020 09:55:00 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7793A0C49 for ; Fri, 6 Mar 2020 09:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4631; q=dns/txt; s=iport; t=1583517300; x=1584726900; h=from:to:subject:date:message-id:mime-version; bh=Rnz4c4VP/JYyXvGXOuCZwQvxbcHJOZSDMSYGIcKz6ms=; b=TZC6YsXry6zh4QUuuR7+FnKQbj+uwVnBuB69G1PlL758u04iB+OC8u2R FlYHTQ5VG0BOdjiA8MIlt3fFMgfjfjILWytWurThI81G+V277oe6cMObq lWVul9U+nqTQtuSoVvBJH0FPHNC04iRaa87gaOU0eQgA93kKN6Jye1Dqg I=; IronPort-PHdr: =?us-ascii?q?9a23=3A3y82Rx0uZpQIncrLsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEkLmKvLjcSESF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQIABfjWJe/4YNJK1lgkOBIy9QBWx?= =?us-ascii?q?YIAQLKgqEC4NGA4prTpVEhGKBQoEQA1QJAQEBDAEBLQIEAQGEXIF3JDkFDQI?= =?us-ascii?q?DAQELAQEFAQEBAgEFBG2FVgELhXwRHQEBOBEBDD4CBDAnBDWDBAGBfU0DLgG?= =?us-ascii?q?eCgKBOYhidYEygn8BAQWCRIJDGIIMCYE4jCgagUE/gTgghA+DDYNLMoIskGi?= =?us-ascii?q?FcplLCoI8j0mHHRUHmzWER4ovm1ECBAIEBQIOAQEFgWohgVhwFWUBgkFQGA2?= =?us-ascii?q?ONYNbilV0gSmNCwSBLwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,523,1574121600"; d="scan'208,217";a="729670359" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Mar 2020 17:54:59 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 026HswFd008056 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Mar 2020 17:54:59 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Mar 2020 11:54:59 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 6 Mar 2020 11:54:58 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 6 Mar 2020 11:54:58 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LTSUuhrfkstt/gy2+xTUCN7EWQfG8w9Vl0r7g1w9gwoUTxkj+UQJHmbRg6AI3h+5WgA2vz+SOTOmcYWAPuyX4ZswLxNVTVkYrnFyNj/0qiS8laUecCKPCWhTK/Q7x8fugtPfYu4LoRwNP799fj1nCeoZ8mBPQJrjLnnOVdB8eqCIQ90C5ztKa1fsGVVxnAldMN1rDm36Kb/ei7qOZnbG3TL2g2OAFNmVXFJ7YP+XOAP+mI9qYclq7lXataelJ0Xeo3f+Dk/JYgECdxio2uksgMsSuB7Fqc3E2OBPGOtbqVfDngTuqymqCNWqZ8JTMOPSFOG87oEzy5aOybEmQXrJNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rnz4c4VP/JYyXvGXOuCZwQvxbcHJOZSDMSYGIcKz6ms=; b=RFv47x6mRBDMMy9eR2M5K3MU7Ff0DLiEvuU5we6cF3fSoXG9cgfxT1BJzyEBMXQpA1mSIu21dMBedNnVcg5SPFJxPL45OAsPBnb6WjwiufjIuvaz3xIDLziNhexdFNa/OZISm69PqmFJ93cxCxB6teYneqXd4PStnUhn97L29uHFT3yB1AsQ48Doqh3BfKgji9CitdeZjCq80F+N3hr1wQ2P5xlfy+1c0YHX5i3uIXlcJ9KlmDCqUQjv3Gf5HzZXsQMIk/KicwU1KpJ8uejWkF2eX+E38OtzADmOvMliSRgvkjdqplKer8Q23bcQTzbFXszCKXbYFhqdmNc3Hs+4Jg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rnz4c4VP/JYyXvGXOuCZwQvxbcHJOZSDMSYGIcKz6ms=; b=ZpvGzlnc6hn/F/jHXAvhfowQULsdF7eAsiigRZKcEbgGbJOfgTNn9PhxqOa83tIStMUd27P5FVw2u5h9N5bOOMVQSGTS1kknqWPTPtGcuW9WLbIcCildTCkL0Q2/zzT1QeOaqeW0w/DoHJwWJ2587jkVu2T1XhPtsdMJOOhlfho= Received: from BYAPR11MB3558.namprd11.prod.outlook.com (2603:10b6:a03:b3::11) by BYAPR11MB3349.namprd11.prod.outlook.com (2603:10b6:a03:1c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 6 Mar 2020 17:54:56 +0000 Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::1d2b:8e10:820d:c90b]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::1d2b:8e10:820d:c90b%5]) with mapi id 15.20.2772.019; Fri, 6 Mar 2020 17:54:56 +0000 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: IETF 107 - DMM Working Group Session Cancellation Thread-Index: AQHV8+BYeHf3ME/B9E+RPuYix6418A== Date: Fri, 6 Mar 2020 17:54:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgundave@cisco.com; x-originating-ip: [128.107.241.183] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 041d1ebf-ea09-4d0f-4a8c-08d7c1f77b54 x-ms-traffictypediagnostic: BYAPR11MB3349: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0334223192 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(346002)(366004)(396003)(199004)(189003)(6506007)(64756008)(26005)(186003)(66946007)(4744005)(76116006)(66476007)(66556008)(5660300002)(66446008)(2616005)(316002)(33656002)(2906002)(8936002)(86362001)(6486002)(8676002)(71200400001)(36756003)(478600001)(6512007)(81156014)(81166006)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3349; H:BYAPR11MB3558.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: z7NDFl8hwiu823n60wU+tyTeSNQgE+aOAKEnPQ3ZRb0FPO4vbZL5DwUcCdqR7Sa2w6zp6h1g/QEVPLPypNPEnTqcNG8j77qtut0iMGRdE9VVdqbB5zslF4kz/SiYMzhfqKG2hO1i1rln7mj4JkZ/hkQMnP2Ccm2I57MCv2W9Kb/MnaWahgI1nHnNxg3DRXcfXhshZzyEPdzvN6J3efLlAN+Ob8YcVo+OxKnv+DOdfLrKtlCqZOvmOMakmf016fnm3I8voVB+WhF2w4YkvRBIS2aENPEtsZSyLPSLkZGHxOLvGGTmQm10e9HczATYRFPUSSbMUJfqQkuGJse61yOJxjVgxVM88z8qF/i/mFpneng95izB9kh8rNe/lb83VXaJEpfckhB2FWeVYG/+bZGIiLbTmjG286TRJGCvkdKrnrEnGbEhk7xYL5nixGQwZV8h x-ms-exchange-antispam-messagedata: matTN4hJO/GDolEU/urAA1I4UIZbnVjFgSWJV/gHG2vDCoiJye7MZi2kozq4Ud7J95HrQRxdNGQlKCMx2WKWWpqf4G6jBVpViCcCb9eJuTYaYTvXLMO+fb8a6ZvCabvWxCVZLairj05QL/qAurzfPw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_E4F0929CF5F44B319D87D1A00CB0A79Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 041d1ebf-ea09-4d0f-4a8c-08d7c1f77b54 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2020 17:54:56.5199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UiXKqugQc/EdxRwfPOvHdkIlt35Rb5fmp/OUsOxLyEbKzHUAAWTcqo0BKahI0xiqJ5mDoFmtTd9qcDvKHzzUNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3349 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: [DMM] IETF 107 - DMM Working Group Session Cancellation X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2020 17:55:09 -0000 --_000_E4F0929CF5F44B319D87D1A00CB0A79Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQoNCkR1ZSB0byBzb21lIHRyYXZlbCByZXN0cmljdGlvbnMgdGhhdCBpbiBhcmUg cGxhY2UgZnJvbSBteSBlbXBsb3llciwgYW5kIGFzIHdlbGwgZnJvbSBTYXRvcnXigJlzIGVtcGxv eWVyLCB3ZSBoYWQgdG8gY2FuY2VsIG91ciB0cmF2ZWwgdG8gVmFuY291dmVyLiBJbiBkaXNjdXNz aW9ucyB3aXRoIG91ciBBRCwgd2UgaGF2ZSBqb2ludGx5IGRlY2lkZWQgdG8gY2FuY2VsIHRoZSBE TU0gV29ya2luZyBHcm91cCBtZWV0aW5nIGZvciBJRVRGMTA3LiBBcG9sb2dpZXMgZm9yIHRoZSBs YXRlIG5vdGlmaWNhdGlvbnMsIGJ1dCB0aGVzZSBhcmUgZHVlIHRvIHNpdHVhdGlvbnMgYmV5b25k IG91ciBjb250cm9sLiBBbHNvLCB0aGUgV0cgbWFpbGVycyBoYXZlIGJlZW4gdmVyeSBxdWlldCwg aXQgd2lsbCBiZSBnb29kIHRvIGZpbmQgc29tZSByZWxldmFudCB0b3BpY3MgYW5kIGJyaW5nIHNv bWUgZW5lcmd5IGludG8gdGhlIGRpc2N1c3Npb25zLg0KDQpXZSBsb29rIGZvcndhcmQgdG8gc2Vl aW5nIGluIHlvdSBhbGwgaW4gSUVURjEwOC4NCg0KDQpTYXRvcnUgJiBTcmkNCihETU0gV29ya2lu ZyBHcm91cCBDaGFpcnMpDQoNCg== --_000_E4F0929CF5F44B319D87D1A00CB0A79Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgQWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RHVlIHRvIHNvbWUgdHJhdmVsIHJlc3RyaWN0aW9ucyB0 aGF0IGluIGFyZSBwbGFjZSBmcm9tIG15IGVtcGxveWVyLCBhbmQgYXMgd2VsbCBmcm9tIFNhdG9y deKAmXMgZW1wbG95ZXIsIHdlIGhhZCB0byBjYW5jZWwgb3VyIHRyYXZlbCB0byBWYW5jb3V2ZXIu IEluIGRpc2N1c3Npb25zIHdpdGggb3VyIEFELCB3ZSBoYXZlIGpvaW50bHkgZGVjaWRlZCB0byBj YW5jZWwNCiB0aGUgRE1NIFdvcmtpbmcgR3JvdXAgbWVldGluZyBmb3IgSUVURjEwNy4gQXBvbG9n aWVzIGZvciB0aGUgbGF0ZSBub3RpZmljYXRpb25zLCBidXQgdGhlc2UgYXJlIGR1ZSB0byBzaXR1 YXRpb25zIGJleW9uZCBvdXIgY29udHJvbC4gQWxzbywgdGhlIFdHIG1haWxlcnMgaGF2ZSBiZWVu IHZlcnkgcXVpZXQsIGl0IHdpbGwgYmUgZ29vZCB0byBmaW5kIHNvbWUgcmVsZXZhbnQgdG9waWNz IGFuZCBicmluZyBzb21lIGVuZXJneSBpbnRvIHRoZSBkaXNjdXNzaW9ucy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIGxvb2sgZm9yd2FyZCB0byBzZWVpbmcg aW4geW91IGFsbCBpbiBJRVRGMTA4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNhdG9ydSAmYW1wOyBTcmk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+KERNTSBXb3JraW5nIEdyb3VwIENoYWlycyk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E4F0929CF5F44B319D87D1A00CB0A79Dciscocom_-- From nobody Sat Mar 7 09:11:17 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 895DF3A1668; Sat, 7 Mar 2020 09:11:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <158360107548.18202.17771527603015123251@ietfa.amsl.com> Date: Sat, 07 Mar 2020 09:11:15 -0800 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-distributed-mobility-anchoring-15.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 17:11:16 -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 WG of the IETF. Title : Distributed Mobility Anchoring Authors : H. Anthony Chan Xinpeng Wei Jong-Hyouk Lee Seil Jeon Carlos J. Bernardos Filename : draft-ietf-dmm-distributed-mobility-anchoring-15.txt Pages : 21 Date : 2020-03-07 Abstract: This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support according to the needs of mobility support. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or re-started using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-15 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-distributed-mobility-anchoring-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-distributed-mobility-anchoring-15 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 Sat Mar 7 13:18:19 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DCE3A1A8A for ; Sat, 7 Mar 2020 13:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk7LdbZmFV8O for ; Sat, 7 Mar 2020 13:18:06 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B2A3A1A8C for ; Sat, 7 Mar 2020 13:18:06 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id m25so7143564edq.8 for ; Sat, 07 Mar 2020 13:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DZC+kiBBvYx7VzJqCU1KqTOr+HJB5Q1/F58/ECiu6q8=; b=WvXsrSIybAMIFMmI4gAYCT7DvuGBEqvttOcitL7NQcEYGt0P5q7MwF6Sgph3jqwbUP KWhX0E0fRGpduPQ5i7qjFzoZgluwCaRzDIlJzaZ8koiXgWsIu8Rt6v6hMDNK8na/rcUG 8TV/3pknRj5jQ9uom+TFgTxIgcowydlIwTMK8DgQzfq1DAbVLgvCF7cy7JbV/OcGDJXE XwelvKXYQv1VbcywCC9NEvkzCnNHFdTbTUmvFXvlH2U9NMGg2YlEnzkYZqVux2lmLH30 wXjPfZKOAk8+cm21Gs/zgIirnLdPBu4J3Ze3ehCt0ndbyZw3CZb+laW+RTCg30RMs53w WXmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DZC+kiBBvYx7VzJqCU1KqTOr+HJB5Q1/F58/ECiu6q8=; b=qrYkv8ovO7zCVg8nO/EQWx3y6oBwmxh9BN9tzQveTHDOysWGQbXlA3KoJnPHu8lCG4 nc02gr5ukR4LpXpAOTKOBx+ge6xig71hmjDvJhZKrOYKE8Bs9lJOH/HWhvYUE0/szUAG 1zr1lCJGykhXcCA3/l5qUg95EZyU6aOyE5fcBKBBDkJaAKd+fNrSYWEN6AUUBaEQnuLH 1mmSxJuFEpfUBvQyCCQi4Hx9lItMaCRVAT3t3qpOpE6S25yy0emKY1iRODk/A/tOAiGy pV7V+JkrVNlz216gQA0CMN8RatortFeh7F8qv/2+jYYV+BQoxmi0Ok/Ex2/fQKIhb9CO Rtzw== X-Gm-Message-State: ANhLgQ1deqo1pWDzFBzZ44gSdWH8nhFEMqoYWZOqJhsiuraR5roY4+sg EY3MojruX3dOLtlTWfAJ1mZqSng4kmPsxaUqyugxID966zs= X-Google-Smtp-Source: ADFU+vuactAe/0/87UREG74SboUPFHSrTfGh0oc2abVk8cTI5o2kph40S2/yg0ialzaKdka/gq7WpopZBfst20BBq2Q= X-Received: by 2002:a05:6402:128c:: with SMTP id w12mr10035578edv.368.1583615884404; Sat, 07 Mar 2020 13:18:04 -0800 (PST) MIME-Version: 1.0 References: <158281546210.2262.1845082722013562869@ietfa.amsl.com> In-Reply-To: <158281546210.2262.1845082722013562869@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sat, 7 Mar 2020 22:17:46 +0100 Message-ID: To: Vincent Roca Cc: secdir , dmm , last-call@ietf.org, draft-ietf-dmm-pmipv6-dlif.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000040472305a04a4e3b" Archived-At: Subject: Re: [DMM] Secdir telechat review of draft-ietf-dmm-pmipv6-dlif-05 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 21:18:08 -0000 --00000000000040472305a04a4e3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vincent, Thanks a lot for your review. Please see inline below for my comments. On Thu, Feb 27, 2020 at 3:57 PM Vincent Roca via Datatracker < noreply@ietf.org> wrote: > Reviewer: Vincent Roca > Review result: Has Nits > > Hello, > > I have reviewed this document as part of the security directorate=E2=80= =99s ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. > > Summary: Has Nits > > Thank you for the clarification of the Security Considerations section. > I just have a minor comment and a typo. > > - It is said (section 6): > "The CMD SHOULD use a pacing approach to limit > this amplification risk." > I agree, but where do you intend to apply pacing? In the incoming queue > (i.e., > by delaying some PBU/PBA messages) or in the outgoing queue (i.e., to lim= it > output traffic), or both? It's a bit unclear. > [CB] I meant limiting the output traffic. I've clarified this in version -06 (to be submitted soon). > > - Typo: remove one "exist" in sentence: "there may exist multiple previou= s > (e.g., k) MAARs exist." > > [CB] Fixed, thanks. Thanks again for your comments. Carlos > Regards, Vincent > > > --00000000000040472305a04a4e3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vincent,

Thanks a l= ot for your review. Please see inline below for my comments.
On Thu, F= eb 27, 2020 at 3:57 PM Vincent Roca via Datatracker <noreply@ietf.org> wrote:
Reviewer: Vincent Roca
Review result: Has Nits

Hello,

I have reviewed this document as part of the security directorate=E2=80=99s= ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.=C2=A0 Document editors and WG chairs should treat these comments= just
like any other last call comments.

Summary: Has Nits

Thank you for the clarification of the Security Considerations section.
I just have a minor comment and a typo.

- It is said (section 6):
=C2=A0 "The CMD SHOULD use a pacing approach to limit
=C2=A0 =C2=A0this amplification risk."
I agree, but where do you intend to apply pacing? In the incoming queue (i.= e.,
by delaying some PBU/PBA messages) or in the outgoing queue (i.e., to limit=
output traffic), or both? It's a bit unclear.

=
[CB] I meant limiting the output traffic. I've clarified thi= s in version -06 (to be submitted soon).
=C2=A0

- Typo: remove one "exist" in sentence: "there may exist mul= tiple previous
(e.g., k) MAARs exist."

[CB] Fixed, thanks.

Thanks a= gain for your comments.

Carlos
=C2=A0
Regards,=C2=A0 =C2=A0 Vincent


--00000000000040472305a04a4e3b-- From nobody Sat Mar 7 16:06:25 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93CB3A1655 for ; Sat, 7 Mar 2020 09:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVqlsYsmGy8Y for ; Sat, 7 Mar 2020 09:06:22 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B4D3A1652 for ; Sat, 7 Mar 2020 09:06:21 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id m25so6562687edq.8 for ; Sat, 07 Mar 2020 09:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rOvKWIVn3NZoC2+BpS/eUC+WLR1Vm605g2A56NTdRP8=; b=Lt6U++WuMwKSJ17WLJw5bJOftZ/J8pMaQ8zVXC0cxB0Xb3S7S1ZUsdqyLhGYa0n+/Z hC/VkpCw/5uYpCYC0wdr/PhOn9GrH5Fm2BNUyD9HR0DqDFC19jtzZf8SSDogve31XqpB LhDukX8VlZ0v5j58AkDUpOktLtUydg+SouRxooGnlUSYYgN+hSJCq3M8BvwM39tcw51d xC/Qa7fP1sBJJKdrm+jjGSPFP9jQcqdQihlf8r4iy6Ertgb6WZqMrPWqUl5f0J58VivK agwT/ioUK2WZVcGlnCbBRFxKCt/fX7vGjf2dQwRqKrmkBios+ejyOKsvyihGqmthrc0X r0Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rOvKWIVn3NZoC2+BpS/eUC+WLR1Vm605g2A56NTdRP8=; b=KBzYQ4sogs/kwTCwUq7Vy7xnufVCF6L9SEUKdTS1AduaRMCFl5ixDuJ6IJUwyWSc/S XcTP6wDHV604aqGqakAY+0d5xE3ivqHz/9K3Bgbq2SaRxBH/sMaFrWrhOmEEe5UTF+jy 6VTFrfrvMAy/FBZwFZxtiTs+TWLONdku4PRoAp1JE5cqYmirvisB83j3H7rdd8Sfm8Ow C5fAeK2tVCnbW83599cg3KcJ/zLzuIETXMjVSe9IFwzPAfti9YtF4/MFV+hH/NkJQKwV 9zxMtvLFlSSGBUSS8sRkkPsu01E/N2ay+fbN1yzJVE+7g9R9LSUsaCptmYNB4udFDwGe xz2g== X-Gm-Message-State: ANhLgQ02bLYlNvGNLx5uXaYuU6DutawchwFvRID9Uh8eR+bZ7MdNBECX +1PIoceyXcuAgKOzRgmbQ2OCkPc5i44HLbu7XJ1pMmdTjzs= X-Google-Smtp-Source: ADFU+vvC4t8JcUxp0927L8Ry9hj+SYLaVYWRd68Vb7O2QO8909Ui0zz4zmjyLrtn/Fi6pyePcRixooebqlXW2dDfPoQ= X-Received: by 2002:aa7:d04a:: with SMTP id n10mr9440552edo.123.1583600779660; Sat, 07 Mar 2020 09:06:19 -0800 (PST) MIME-Version: 1.0 References: <158338522449.29441.3534240903752483882@ietfa.amsl.com> In-Reply-To: <158338522449.29441.3534240903752483882@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sat, 7 Mar 2020 18:06:02 +0100 Message-ID: To: Barry Leiba Cc: The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs , dmm , Dapeng Liu Content-Type: multipart/alternative; boundary="000000000000f03a8c05a046c91b" Archived-At: Subject: Re: [DMM] Barry Leiba's No Objection on draft-ietf-dmm-distributed-mobility-anchoring-14: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 17:06:25 -0000 X-List-Received-Date: Sat, 07 Mar 2020 17:06:25 -0000 --000000000000f03a8c05a046c91b Content-Type: text/plain; charset="UTF-8" Hi Barry, Thanks for your comments. Please see inline below. On Thu, Mar 5, 2020 at 6:13 AM Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > You include the BCP 14 boilerplate and references, but there are no BCP 14 > key > words in the document (except in a quotation from another document). I > suggest > removing the boilerplate and the references. > > [CB] As part of the modifications performed to address other comments we have added some BCP 14 keywords, so I think in version -15 we need to keep the boilerplate. Thanks! Carlos --000000000000f03a8c05a046c91b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Barry,

Thanks for y= our comments. Please see inline below.

On Thu, Mar 5, 2020 at 6:13 AM = Barry Leiba via Datatracker <noreply= @ietf.org> wrote:
Barry Leiba has entered the following ballot position for
draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.i= etf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

You include the BCP 14 boilerplate and references, but there are no BCP 14 = key
words in the document (except in a quotation from another document).=C2=A0 = I suggest
removing the boilerplate and the references.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0
[CB] As part of the modifications=C2=A0performed to address other comment= s we have added some BCP 14 keywords, so I think in version -15 we need to = keep the boilerplate.

Thanks!

=
Carlos=C2=A0
--000000000000f03a8c05a046c91b-- From nobody Sat Mar 7 16:16:54 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431383A0F78 for ; Sat, 7 Mar 2020 02:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHoC_XGaR714 for ; Sat, 7 Mar 2020 02:15:06 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F123A0F67 for ; Sat, 7 Mar 2020 02:15:05 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id h62so5579455edd.12 for ; Sat, 07 Mar 2020 02:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZYcbWmlzHAsLrzy5jKQYdAacs6rxwUVfibHRbV4pSkA=; b=EnjSQMjsWP6e6L2xQzwi3sw3eK9LLaOADUfb0q8H4gYJmrc6uZqy8p7SUxVk+JlT3M 0iSngHE+SSG9HChoWVsNN9B0RqgwATLzrHDusALEQIiGS7lIZXeaL9pxncOPOqBtnD3Z QHwPg+JvaDKCp8VRz/TdUNsr3H/1dCKG9bonvMHxtFDR7a6I6sJX01GmYRCuxRJ0P6Ca Bzu47Ww2HibxJ6/9RUpcYNPdDxe/VkcY1JW7ON2f0gD97n8Aen+yYdzoLRxiapQpYRpU e5Iqj6OGhyHCorTl7K4pv8k0iVK2OygmqWLt2fq/qPC62Wx2uBpmicmTYU5vnb7PNsp9 QisA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZYcbWmlzHAsLrzy5jKQYdAacs6rxwUVfibHRbV4pSkA=; b=qWBVte1GBliYm2sIJ0yWy/8XgFb1Dfh19fRYsqB/DmvjUjFy64v+OZay/qIsDZ/xp9 Rkp3wESupwXkITCXjIeloHlEa9q7AoW2Xq10/LuP/6mdTDxmskOd+9xbq+2M8aaGrk7z l4Sds3Lsg6xnHJAHj8eHipYT7NguAv7wvlw7XrJS3ycl0pIgDwYEX6tm4b5BC+WvYLH3 Ve1iucb1rCfknFZ1YLgnksAnTAt/Jx6Cjkqxj8qbR01S3ztyHsD3ClXgt8X+u7kIVQ3b 3UFMN6neFw/99QMBPoeZMuXKXRYU5NJ0uG9JT5RxbqYnT+UytWPuqVqovAcqd5yAp6/A j+Dg== X-Gm-Message-State: ANhLgQ2MQlTbQHHvaxVCYXFhX91GWBybyrHfuf3OSGkeThnIpdNMNdET I+5R+7GZsQYEB/pMaGJDK1FE5FDjWu0FbUGrNkB5Bw== X-Google-Smtp-Source: ADFU+vvdMkyYaC4+Wce5U6HA0yfOB3erFWrQI7s9B0nENkV9+sG3UYwUIs+NcBDcu4LczcEQOZsH5P3FuHCBIlLqnu4= X-Received: by 2002:a17:906:76c6:: with SMTP id q6mr6583718ejn.176.1583576102768; Sat, 07 Mar 2020 02:15:02 -0800 (PST) MIME-Version: 1.0 References: <157003081719.8945.440750359268316955@ietfa.amsl.com> In-Reply-To: <157003081719.8945.440750359268316955@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sat, 7 Mar 2020 11:14:43 +0100 Message-ID: To: Qin Wu Cc: ops-dir@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, ietf@ietf.org, dmm Content-Type: multipart/alternative; boundary="00000000000014bef205a0410b35" Archived-At: Subject: Re: [DMM] Opsdir last call review of draft-ietf-dmm-distributed-mobility-anchoring-13 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 10:15:14 -0000 X-List-Received-Date: Sat, 07 Mar 2020 10:15:14 -0000 --00000000000014bef205a0410b35 Content-Type: text/plain; charset="UTF-8" Hi Qin, Apologies for not reply. I got my mail filters messed up and I missed your e-mail. Thanks to Warren I was aware of this. Thanks a lot for your review. Please see inline below for my comments. On Wed, Oct 2, 2019 at 5:40 PM Qin Wu via Datatracker wrote: > Reviewer: Qin Wu > Review result: Has Issues > > I have reviewed this document as part of the Operational directorate's > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects > of > the IETF drafts. Comments that are not addressed in last call may be > included > in AD reviews during the IESG review. Document editors and WG chairs > should > treat these comments just like any other last call comments. > > This draft discusses how distributed mobility anchoring functions work in > both > network based mobility solution and host based mobility solution. I think > this > draft lacks clarity on terminoloy definition and IP mobility support in > different use cases. > > [CB] We did some updates in -14 trying to improve clarity. And we have performed additional ones in -15 (to be submitted), based on your review and others providing similar comments. More next. Major issue: > Not found > > Minor issue: > 1. Good to see anchor definition in the terminology section, however when > we > say anchor of IP prefix, how it is related to control plane anchor and data > plane anchor? It will be nice to define CPA and DPA in the terminology > section > as well and clarify their relationship. [CB] We have included all the terms originally defined in the DMM deployment model into the terminology, to make all this clear and also to remove the reference to that draft (which was decided not to be progressed any further). These changes are made in version -15 (to be submitted). 2. LM and FM functions are two terms > defined in terminology section, however it is not clear to me how LM and FM > functions related to 3GPP mobility components? How they are related to > anchor > defined in this document? Clarify this in ther terminology section will be > helpful. Add 3GGP reference will be good. [CB] LM and FM functions are not 3GPP terms, but specific sub-functions involved in mobility management. We use them in the document to better explain how (data plane) anchors can be distributed, and the potential impact/relation to where LM and FM functions are placed. We have made this clearer in version -15 (to be submitted). 3.Section 4.1 > Not sure IP session continuity is needed in this nomadic case. If IP > session > continuity is supported, how is it different from two mobility cases? I > think > normadic case only supports application layer session continuity rather > than > IP session continuity. Would it be great to clarify the difference > between IP > session continuity, higher layer session continuity and IP mobility > support > in the terminology section > [CB] You are completely right. The nomadic case implies no IP session continuity, but it is documented as one potential model for distributing anchors (in which higher layer session continuity would be required if needed by the application). We have clarified the difference between higher layer session continuity and IP mobility support in the terminology section in version -15 (to be submitted), by adding the terms. > 4. Section 4.1. I see in most cases IP mobiity support is equivalent to IP > session continuity support, but in this draft, I see some difference > between IP > mobility and IP session continuity, e.g., IP mobility may not support IP > session continuity, if the answer is yes, please clarify in the terminology > section and redefine IP mobility. > [CB] Yes, the difference between IP mobility and IP session mobility is that IP mobility encompasses session mobility plus address reachability. We have clarified this in version -15 (to be submitted). > > 5. Section 4.1, Figuer 4. In figuer 4, it is not clear to me how does CN > know > new address of MN, i.e.,IP2? Do we need any communication between CPA and > DPA > or CPA in the home network and CPA in new visited network? Control plane > channel or data plane channel or Do we rely on LM and FM function to make > CN > know new IP address of MN when MN moves to new network? Please clarify. [CB] How the CN knows the new IP address of the MN is not in the scope of the draft, as this case represents when the MN does not require any type of mobility support from the IP layer. If session continuity is required, then higher layers have to take care of it. There is a piece of text that explains this: "Note that in this scenarios, if there is no mobility support provided by L4 or above, an application might be able to stop before changing point of attachment, and therefore the traffic would stop." 6. Section 4.2, Not sure the case (ii) always enable optimized routes, it > seems > not consistent with what was said in section 4.3 since section 4.3 > supports two > cases, one is keeping anchoring to IP address of flow in the home networ, > the > other is switch the IP prefix/address anchoring to the new network. [CB] Section 4.2 focused on the case (i) the mobility anchor remains playing that role and forwards traffic to a new locator in the new network, which does not imply optimized routes. Section 4.3 focuses on the case (ii) the mobility anchor (data plane function) is changed but binds the MN's transferred IP address/prefix. The latter enables optimized routes but requires some data plane node that enforces rules for traffic indirection. I'm not sure if I got your comment properly. Current text mentions that Section 4.2 deals with case (i) and Section 4.3 with (ii). > 7. Section 4.3 Also it is not clear to me why traffic redirection mobility > case described > in section 4.2 and anchor relocation mobility case described in section 4.3 > should be breifly discussed in section 4.2. [CB] We just did this to introduce the two possible "mobility cases" before then going in detail to each of them. > 8. How work flow in traffic redirection mobility case in section 4.2 is > different from anchor relocation > mobility case described in section 4.3? Why some piece of work flow for > anchor > relocation should be described in figure 5. > > [CB] Traffic redirection implies that the IP addresses remain anchored at their original anchors and traffic needs to be redirected to the currently allocated IP addresses of the MNs (it's just like (Proxy) Mobile IPv6 using multiple anchors at the same time, while anchor relocation involves the actual movement of the anchor. There is no work flow for anchor relocation described in Figure 5. Not sure I got this comment right. Thanks a lot again for all the good feedback. Carlos --00000000000014bef205a0410b35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Qin,

Apologies for = not reply. I got my mail filters messed up and I missed your e-mail. Thanks= to Warren I was aware of this.

Thanks a lot for y= our review. Please see inline below for my comments.

On Wed, Oct 2, 20= 19 at 5:40 PM Qin Wu via Datatracker <noreply@ietf.org> wrote:
Reviewer: Qin Wu
Review result: Has Issues

I have reviewed this document as part of the Operational directorate's = ongoing
effort to review all IETF documents being processed by the IESG.=C2=A0 Thes= e
comments were written with the intent of improving the operational aspects = of
the IETF drafts. Comments that are not addressed in last call may be includ= ed
in AD reviews during the IESG review.=C2=A0 Document editors and WG chairs = should
treat these comments just like any other last call comments.

This draft discusses how distributed mobility anchoring functions work in b= oth
network based mobility solution and host based mobility solution. I think t= his
draft lacks clarity on terminoloy definition and IP mobility support in
different use cases.


=C2=A0[CB] We did some updates in -14 = trying to improve clarity. And we have performed additional ones in -15 (to= be submitted), based on your review and others providing similar comments.= More next.

Major issue:
Not found

Minor issue:
1. Good to see anchor definition in the terminology section, however when w= e
say anchor of IP prefix, how it is related to control plane anchor and data=
plane anchor? It will be nice to define CPA and DPA in the terminology sect= ion
as well and clarify their relationship.

[CB= ] We have included all the terms originally defined in the DMM deployment m= odel into the terminology, to make all this clear and also to remove the re= ference to that draft (which was decided not to be progressed any further).= These changes are made in version -15 (to be submitted).
2. LM and FM funct= ions are two terms
defined in terminology section, however it is not clear to me how LM and FM=
functions related to 3GPP mobility components? How they are related to anch= or
defined in this document? Clarify this in ther terminology section will be<= br> helpful. Add 3GGP reference will be good.

[= CB] LM and FM functions are not 3GPP terms, but specific sub-functions invo= lved in mobility management. We use them in the document to better explain = how (data plane) anchors can be distributed, and the potential impact/relat= ion to where LM and FM functions are placed. We have made this clearer in v= ersion -15 (to be submitted).

3.Section 4.1
=C2=A0Not sure IP session continuity is needed in this nomadic case. If IP = session
=C2=A0continuity is supported, how is it different from two mobility cases?= I think
=C2=A0normadic case only supports application layer session continuity rath= er than
=C2=A0IP session continuity. Would it be great to clarify the difference be= tween IP
=C2=A0session continuity, higher layer session continuity and=C2=A0 IP mobi= lity support
=C2=A0in the terminology section

[CB] You are completely right. The nomadic= case implies no IP session continuity, but it is documented as one potenti= al model for distributing anchors (in which higher layer session continuity= would be required if needed by the application). We have clarified the dif= ference between higher layer session continuity and IP mobility support in = the terminology section in version -15 (to be submitted), by adding the ter= ms.
=C2=A0
4. Section 4.1. I see in most cases IP mobiity support is equivalent t= o IP
session continuity support, but in this draft, I see some difference betwee= n IP
mobility and IP session continuity, e.g., IP mobility may not support IP session continuity, if the answer is yes, please clarify in the terminology=
section and redefine IP mobility.

[CB] Yes, = the difference between IP mobility and IP session mobility is that IP mobil= ity encompasses session mobility plus address reachability. We have clarifi= ed this in version -15 (to be submitted).
=C2=A0

5. Section 4.1, Figuer 4. In figuer 4, it is not clear to me how does CN kn= ow
new address of MN, i.e.,IP2? Do we need any communication between CPA and D= PA
or CPA in the home network and CPA in new visited network? Control plane channel or data plane channel or Do we rely on LM and FM function to make C= N
know new IP address of MN when MN moves to new network? Please clarify.

[CB] How the CN knows the new IP address of th= e MN is not in the scope of the draft, as this case represents when the MN = does not require any type of mobility support from the IP layer. If session= continuity is required, then higher layers have to take care of it. There = is a piece of text that explains this:

"Note = that in this scenarios, if there is no mobility support provided by L4 orabove, an application might be able to stop before changing point of
a= ttachment, and therefore the traffic would stop."

6. Section 4.2, Not s= ure the case (ii) always enable optimized routes, it seems
not consistent with what was said in section 4.3 since section 4.3 supports= two
cases, one is keeping anchoring to IP address of flow in the home networ, t= he
other is switch the IP prefix/address anchoring to the new network.

[CB] Section 4.2 focused on the case (i) the mobil= ity anchor remains playing that role and forwards traffic to a new locator = in the new network, which does not imply optimized routes. Section 4.3 focu= ses on the case (ii) the mobility anchor (data plane function) is changed b= ut binds the MN's transferred IP address/prefix. The latter enables opt= imized routes but requires some data plane node that enforces rules for tra= ffic indirection.

I'm not sure if I got your comment properly. Current = text mentions that Section 4.2 deals with case (i) and Section 4.3 with (ii= ).
=C2=A0
7. Section 4.3 Also it is not clear to me why tr= affic redirection mobility case described
in section 4.2 and anchor relocation mobility case described in section 4.3=
should be breifly discussed in section 4.2.

[CB] We just did this to introduce the two possible "mobility cases&q= uot; before then going in detail to each of them.
=C2=A0
8. How work flow in traf= fic redirection mobility case in section 4.2 is different from anchor reloc= ation
mobility case described in section 4.3? Why some piece of work flow for anc= hor
relocation should be described in figure 5.


[CB] Traffic redirection implies that = the IP addresses remain anchored at their original anchors and traffic need= s to be redirected to the currently allocated IP addresses of the MNs (it&#= 39;s just like (Proxy) Mobile IPv6 using multiple anchors at the same time,= while anchor relocation involves the actual movement of the anchor.
<= div>
There is no work flow for anchor relocation described in= Figure 5. Not sure I got this comment right.=C2=A0

Thanks a lot again for all the good feedback.

Ca= rlos

--00000000000014bef205a0410b35-- From nobody Sat Mar 7 16:17:07 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D723A0F7F for ; Sat, 7 Mar 2020 02:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA8aduwHUEI8 for ; Sat, 7 Mar 2020 02:17:43 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E2C3A0F8E for ; Sat, 7 Mar 2020 02:17:37 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id n18so5594863edw.9 for ; Sat, 07 Mar 2020 02:17:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WVhM/ak6wyLMYjOY4MtECIvB0q9F9jGYaI4/R2dlS7E=; b=WgF/WqPLjm0Py/gm1vVjObRybulM6ssVY3sKtxb3Gx6eknGs35pxyNion11x21yaJg sTmTiwpC6P2JIYAmhOcA6PFvNknqam8V+KSsotLi5rSD1yxaaBE+DacCP2bllcc/h1Eg zeozwtL+WOChwdJ+Yl8cF9GJorV8uiyaIpJozNce0DjSr2oSydw1HxXtKWoiUVwJsogq M77rW8wXkOdSHH1smyhKD8nuxWEcfLLVB1rLTuYxtzmXlfJi5ujGjyBpIhnTNpW85Kx/ YpoWAKYxUQq7INdeWJTYrhCy9bEt3473q68Wpck6sfZHBwJI3qMaVhH0M+xlOWCR+hn6 zSdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WVhM/ak6wyLMYjOY4MtECIvB0q9F9jGYaI4/R2dlS7E=; b=Qxp6lbr7QWfe0frNNqQSS4vDRhNN02QQFRIUdHwfgsgsu7zdCO9VWSdgE0y1OHWw78 pH+xCYwzZ4ISFBhbRFC9672/KMVQekDoINFWc2BlkBDDTOJWx6IdMhiwApYZLtru2j9B lGvtoTC/hMEzu2G2EccJ4m7nTTB5gsTAacUC7g3ozhrj7vxDMe4rk4pO0VKnDW/7exfH fyDmrsD4BSgtXOovSgd9A+AvzM9lfteutEnH4QLnNV5kcnP5x1FgNeRtWyftBKkJmov1 KIHIQcqjwG8bWuriNdqJFWCnGdBG4Q9GwxCrXmtiH3HSq+T8BFJC5jCZBFPsnqzx+soH THXQ== X-Gm-Message-State: ANhLgQ0/5I4/Cp9y2iG3K02o+eFkbnpLxvGQx/0pOyojOZqUgLB2V/n7 4alSFwT8rFHi8T8QocH0XyzDpBUVbU6RXsQ2cRtvUyLAfvs= X-Google-Smtp-Source: ADFU+vs2Nu1JiBWQAMA+2RDXBuStwWlWwfj/gZgqpZHIjV0jASVFItsVRH6J62IR37XJnEZT4X62MLvxbFw0d2Ap+U8= X-Received: by 2002:a05:6402:549:: with SMTP id i9mr7491678edx.323.1583576255979; Sat, 07 Mar 2020 02:17:35 -0800 (PST) MIME-Version: 1.0 References: <158326185053.7640.4273113400366955585@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Sat, 7 Mar 2020 11:17:16 +0100 Message-ID: To: Warren Kumari Cc: The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs , dmm , Dapeng Liu , Qin Wu Content-Type: multipart/alternative; boundary="00000000000036828405a041145e" Archived-At: Subject: Re: [DMM] Warren Kumari's No Objection on draft-ietf-dmm-distributed-mobility-anchoring-14: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 10:17:48 -0000 X-List-Received-Date: Sat, 07 Mar 2020 10:17:48 -0000 --00000000000036828405a041145e Content-Type: text/plain; charset="UTF-8" Thanks Warren. I've just replied to Qin's comments. The original e-mail went to the wrong place due to some misconfigured filters :( Version -15 (to be submitted soon) should address all the comments received. Thanks, Carlos On Wed, Mar 4, 2020 at 1:37 AM Warren Kumari wrote: > On Tue, Mar 3, 2020 at 4:20 PM CARLOS JESUS BERNARDOS CANO > wrote: > > > > Hi Warren, > > > > Thanks for your comments. I've checked my e-mail twice and I haven't > been able to see the review from Qin Wu. Can you please forward it to me. > According to my records I've replied to all the comments and reviews to > this draft (I'm working on another one that is also at the IESG evaluation > now -- draft-ietf-dmm-pmipv6-dlif -- but this a different document). > > > > All directorate reviews should be linked from the Datatracker page: > > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ > The direct link to Qin's is: > > https://datatracker.ietf.org/doc/review-ietf-dmm-distributed-mobility-anchoring-13-opsdir-lc-wu-2019-10-02/ > > > > Apologies in advance if I've missed the review from Qin Wu. > > > > Ah, fair enough, it is easy to miss emails, sometimes they go into spam, > etc. > > W > > > > Thanks, > > > > Carlos > > > > On Tue, Mar 3, 2020 at 7:57 PM Warren Kumari via Datatracker < > noreply@ietf.org> wrote: > >> > >> Warren Kumari has entered the following ballot position for > >> draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> I am balloting NoObj, but I had a hard time deciding between this and > DISCUSS > >> (I went with NoObj because I'm submitting this late) - Qin Wu submitted > an > >> OpsDir review with a number of open questions, as well as some very > easy to > >> address comments / suggestions. It looks like this were either ignored, > or > >> missed (or, perhaps I missed the discussion) > >> > >> I strongly encourage the authors and AD to review and address these > comments. > >> > >> > >> > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > --00000000000036828405a041145e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Warren. I've just replied to Qin's comments= . The original e-mail=C2=A0went to the wrong place due to some misconfigure= d=C2=A0filters :(

Version -15 (to be submitted soon) sho= uld address all the comments received.

Thanks,

Carlos

On Wed, Mar 4, 2020 at 1:37 AM Warren Kum= ari <warren@kumari.net> wrot= e:
On Tue, Mar 3= , 2020 at 4:20 PM CARLOS JESUS BERNARDOS CANO
<cjbc@it.uc3m.es> wrote:
>
> Hi Warren,
>
> Thanks for your comments. I've checked my e-mail twice and I haven= 't been able to see the review from Qin Wu. Can you please forward it t= o me. According to my records I've replied to all the comments and revi= ews to this draft (I'm working on another one that is also at the IESG = evaluation now -- draft-ietf-dmm-pmipv6-dlif -- but this a different docume= nt).
>

All directorate reviews should be linked from the Datatracker page:
https://datatracker.i= etf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/
The direct link to Qin's is:
https://datatracker.ietf.org/doc/review-ietf-dmm-distributed-mobilit= y-anchoring-13-opsdir-lc-wu-2019-10-02/


> Apologies in advance if I've missed the review from Qin Wu.
>

Ah, fair enough, it is easy to miss emails, sometimes they go into spam, et= c.

W


> Thanks,
>
> Carlos
>
> On Tue, Mar 3, 2020 at 7:57 PM Warren Kumari via Datatracker <noreply@ietf.org> w= rote:
>>
>> Warren Kumari has entered the following ballot position for
>> draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut= this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>> https://data= tracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/
>>
>>
>>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>> I am balloting NoObj, but I had a hard time deciding between this = and DISCUSS
>> (I went with NoObj because I'm submitting this late) - Qin Wu = submitted an
>> OpsDir review with a number of open questions, as well as some ver= y easy to
>> address comments / suggestions. It looks like this were either ign= ored, or
>> missed (or, perhaps I missed the discussion)
>>
>> I strongly encourage the authors and AD to review and address thes= e comments.
>>
>>
>>


--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf
--00000000000036828405a041145e-- From nobody Sat Mar 7 16:21:43 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF98E3A1625 for ; Sat, 7 Mar 2020 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCdIF8js1pIN for ; Sat, 7 Mar 2020 08:56:19 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7951C3A161F for ; Sat, 7 Mar 2020 08:56:18 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id a13so6532640edu.7 for ; Sat, 07 Mar 2020 08:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5f2HqVXki9UnzhAsIYhn0hM5zVBOzEMndN813NY9IV4=; b=FYUiFWsAEn2sEqKq388bITBZX1pbHTCCkBo3nB13BhYFrfRhqyRzIeon6nE1mU6ICt FvyT4uqKSF8Hc14oUvdqD148Q52KSSMOUekVXz6wa0fLJFuyd9s8iqgwUWnCL4UpX8kl RDd0DrgZGyC1xmI1R0AbxK6TjRc6lz9qNnzKpD/hOwk9hLrJlEAY/Ot9qZVp3EMnzCzz iFgWPEF2tKrje12+z3j5dt2hd59kPAx/gagsmN5EL2yMuhJPz8w0Eig5Ry1CLGCPXDG+ DdU4aRhpYDegugaKXnD2wNAREIB0MaeDvztJQFTE7KavnFiE/UMgIQ8dkgB12FlQDONe LT5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5f2HqVXki9UnzhAsIYhn0hM5zVBOzEMndN813NY9IV4=; b=lh8IazwOda7cL3imEBq6jjZSG5B9Sm3/45JoJjwocG4gXEGcbM81arJrUOqnIWu0LV Ua9tBebdEAz432r/yOG3aO0EfycTBOsdgtTzFh99PwIJdYAPRewB08Z4WP6DbmIi2kKi da+1MU3KmR8dsjw0rL34JmhePorx4aKPH1WppekZLiQfMwtpnTjDB/nED1kWrcqJY4Yg EubwMsS6s688bnsiIAyEMN2evOqiaAUlrGDbRgxHoi+MszVEjxNQgRb4lWZRNej6mIRr yspVqxbYK4xSH5AgdRghMaUGbIraXxFYeuM1iL37UPN81ezWnqCsfRzZ8FY4JMgXYYx+ 8CgA== X-Gm-Message-State: ANhLgQ1xjJyOYI2dIUFyxivd+mNXI5hhwKD77rbpdg4A7ADWC/C2Yh8O 1ZxIs4Z7+NEUQXFuYm9WUVcNmNHbjKsmCS8f/c2phQ== X-Google-Smtp-Source: ADFU+vs8RauE/2gpBcW+W/58h8fEanTF2492kuek+M65LoqevXtsSiX8Q418mYF/0aLcCTmTLG9fwy92YvTMQUaEZhc= X-Received: by 2002:a17:906:ca53:: with SMTP id jx19mr8045004ejb.192.1583600176373; Sat, 07 Mar 2020 08:56:16 -0800 (PST) MIME-Version: 1.0 References: <158337360559.29429.15629947241139453126@ietfa.amsl.com> In-Reply-To: <158337360559.29429.15629947241139453126@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sat, 7 Mar 2020 17:55:59 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs , dmm , Dapeng Liu Content-Type: multipart/alternative; boundary="000000000000facc9e05a046a51e" Archived-At: Subject: Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-distributed-mobility-anchoring-14: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 16:56:22 -0000 X-List-Received-Date: Sat, 07 Mar 2020 16:56:22 -0000 --000000000000facc9e05a046a51e Content-Type: text/plain; charset="UTF-8" Hi Benjamin, Thanks a lot for your comments. Please find below my answers. On Thu, Mar 5, 2020 at 3:00 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dmm-distributed-mobility-anchoring-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for discussing the need to secure the various control-plane > interactions as part of the Security Considerations. In addition to the > integrity and source-authentication properties already mentioned, we > need to say that the control-plane functionality will apply > authorization checks to any commands or updates that are made by the > control-plane protocol. > [CB] Thanks. I've added that to version -15 (to be submitted soon). > > Similarly, I didn't see any discussion of authorization for applying or > making changes to the "rules" that are mentioned as needing to be > applied by a data-plane node (as mentioned in the COMMENT where I ask > for clarification on the nature of such rules). > [CB] Thanks. Even though we have changed a bit the writing to avoid the term "rule", we have added some text regarding the use of authentication and authorization mechanisms when doing traffic indirection in version -15. > > Also, we should reference RFCs 8221 and 8247 for the current guidance on > IPsec and IKEv2 usage. > [CB] Thanks. Added. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > While I see the value in having this document to crystallize thinking > about the various mobility anchoring techniques that are possible, it's > not clear to me how much archival value this document would add to the > RFC series in the absence of specific protocol mechanisms to implement > the functionality described therein. As such, I expect to change my > ballot position to Abstain after my Discuss points are resolved. > > Section 1 > > When the MN wants to continue using its assigned prefix to complete > ongoing data sessions after it has moved to a new network, the > network needs to provide support for the MN's IP address -- and > > The new network, right? > > [CB] The new network and the old one, understanding "old" by the one anchoring the prefix used by the MN. That's why we just use the generic term "network" without prepending "new". Section 2 > > Anchoring (of an IP prefix/address): An IP prefix, i.e., Home > Network Prefix (HNP), or address, i.e., HoA, assigned for use by > an MN is topologically anchored to an anchor node when the anchor > node is able to advertise a connected route into the routing > > Is "connected route" a term of art I should be looking up? > > [CB] I agree it's probably better to just use "route". We have changed this in version -15 (to be submitted soon). > and manages the network location information of an MN. The > location information may be a binding of the advertised IP > address/prefix, e.g., HoA or HNP, to the IP routing address of the > MN or of a node that can forward packets destined to the MN. > > I assume this ("may be [...] or") is not intended to be an exhaustive > list? > [CB] Right. Though the cases listed are the ones I can think of now as making sense. But we don't want to close the door for other options that might also work there. > > In a client-server protocol model, location query and update > messages may be exchanged between a Location Management client > (LMc) and a Location Management server (LMs), where the location > information can be updated to or queried from the LMc. > > nit: s/updated to/updated from/? > [CB] Right, thanks. > > Do we want to discuss the authentication/authorization for such location > management functions here? (Including both MN/LMc and LMc/LMs > interactions.) > [CB] I've added "secure (i.e., authenticated and authorized)" before "location query and update messages may be exchanged between [...]" to make it clear that of course these signalling needs to be properly secured. I think going into more details there will deviate the focus from the main point of this document. Anyway, the security considerations section should cover all these parts as well. > > Section 4 > > There may be multiple IP prefixes/addresses that an MN can select > when initiating a flow. They may be from the same access network or > different access networks. The network may advertise these prefixes > with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node > may choose the one with the least cost. In addition, these IP > > This draft has not been updated since 2016. Is it still expected to > progress, such that a reference to it remains valuable? > [CB] We use this reference as an example of approach. There are other examples that we could reference, but I wanted to give the credit to the guys that I think first proposed this. That's why I kept the reference, but I can very easily replace it with another one if you think it would be best. > prefixes/addresses may be of different types regarding whether > mobility support is needed [RFC8653]. A MN will need to choose which > IP prefix/address to use for each flow according to whether it needs > IP mobility support or not, using for example the mechanisms > described in [RFC8653]. > > I'm confused. "these prefixes/addresses" seems to refer to the ones > advertised by the network, but the question of whether mobility support > is needed seems like a matter local to the MN and not a need of the > network. (Perhaps the network might *provide* different mobility > services for different prefixes/addresses, but that's not what this text > currently says.) > [CB] The prefixes/addresses refer to the one provided by the network. The question of whether the MN needs mobility or not is local to the MN, but if the MN actually need it, support from the network might be needed (depending on the type of mobility support of the MN and network). I've reworded it to: "In addition, the IP prefixes/addresses provided by the network may be of different types regarding whether mobility support is supported [RFC 8653] ." I hope now the text is clearer. > Section 4.1 > > I suggest to expand access router or list it in the terminology section. > [CB] Done (expanded first time it appears in the text). > > When IP session continuity is needed, even if a flow is ongoing as > the MN moves, it may still be desirable for the flow to change to > using the new IP prefix configured in the new network. The flow may > then close and then restart using a new IP address configured in the > new network. Such a change in the IP address of the flow may be > > It's perhaps a little confusing, in a rhetorical sense, to talk about > "the flow changing to use the new prefix" but doing that by having the > flow "close and then restart" -- is it really the same flow after it has > closed? > [CB] You are right. If we are picky with the terminology, the flow is indeed different. I've reworded to use "application flow" instead of "flow". Hope this is a bit better. Current text (some other small changes performed) read as follows: "When IP session continuity is needed, even if an application flow is ongoing as the MN moves, it may still be desirable for the application flow to change to using the new IP prefix configured in the new network. The application flow may then be closed at IP level and then be restarted using a new IP address configured in the new network. Such a change in the IP address used by the application flow may be enabled using a higher layer mobility support which is not in the scope of this document." > > Note that in this scenarios, if there is no mobility support provided > by L4 or above, an application might be able to stop before changing > point of attachement, and therefore the traffic would stop. > > I'm not sure what "might be able to stop" is intended to mean. > Regardless, it's quite clear that the traffic will stop upon the > mobility event in this scenario, since the network does not provide > continuity services! > [CB] That sentence was definitely not good. I've just simplified it to: "Note that in these scenarios, if there is no mobility support provided by L4 or above, application traffic would stop." which is kind of clear, but I think it doesn't harm keeping it. > Section 4.2 > > prefix. The latter enables optimized routes but requires some data > plane node that enforces rules for traffic indirection. Next, we > > I'm not sure I understand the role this rule-enforcment is meant to > play. What sort of rules would it be enforcing? > [CB] We mean routing updates that enable the anchor mobility. I probably used the term "rules" because one example of approach to use in a local domain is OpenFlow. I've reworded it to the following: "The latter enables optimized routes but requires some data plane node that enforces traffic indirection." > > to AR1 per default routing). The LM and FM functions are implemented > as shown in Figure 6. > > Where is FM indicated in Figure 6? I cannot find it. > [CB] Ooops. Thanks. Fixed! > > Also, should there be any control-plane anchoring indicated in Figure 6? > [CB] There is the LM part indicated in AR2. > > Section 4.3 > > We focus next on the case where the mobility anchor (data plane > function) is changed but binds the MN's transferred IP address/ > prefix. This enables optimized routes but requires some data plane > node that enforces rules for traffic indirection. > > [same question as above about the rules] > [CB] Same resolution as before. > > IP mobility is invoked to enable IP session continuity for an ongoing > flow as the MN moves to a new network. Here the anchoring of the IP > address of the flow is in the home network of the flow (i.e., > different from the current network of attachment). A centralized > > nit(?): this usage of "here" is surprising, in that it seems to discuss > the same case as the previous section, and not the new mechanism that > we're describing in this section. > [CB] OK, I've removed "here". > > The IP prefix/address anchoring may move without changing the IP > prefix/address of the flow. Here the LM and FM functions in Figure 1 > in Section 3.1 are implemented as shown in Figure 7. > > Where is the FM function indicated in Figure 7? I cannot find it. > [CB] FM is not involved here. I've fixed the text. When we wrote the text I was thinking on a generic way of referring to LM and FM functions, not implying that they need to be implemented in all the cases. But I agree it is not very clear. > > [I-D.ietf-rtgwg-atn-bgp]. When a mobile associates with an anchor > the anchor injects the mobile's prefix into the global routing > system. If the mobile moves to a new anchor, the old anchor > > nit: "mobile node" or just "MN" (twice)? > [CB] Probably better to use MN. I've fixed it. > > withdraws the /64 and the new anchor injects it instead. > > What kind of synchronization and/or serialization is needed between the > withdrawl and injection of the /64 in question? > [CB] That'd be part of the control plane signalling, which would depend on the actual solution being used. Since this document does not go into the specifics of an actual solution, we don't go further. > > Section 5 > > As stated in [RFC7333], "a DMM solution MUST supportany security > > nit: s/supportany/support any/ > [CB] Fixed, thanks. Thanks again for all the good comments. Carlos --000000000000facc9e05a046a51e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,

Thanks a = lot for your comments. Please find below my answers.

On Thu, Mar 5, 20= 20 at 3:00 AM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered the = following ballot position for
draft-ietf-dmm-distributed-mobility-anchoring-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.i= etf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for discussing the need to secure the various control-plane
interactions as part of the Security Considerations.=C2=A0 In addition to t= he
integrity and source-authentication properties already mentioned, we
need to say that the control-plane functionality will apply
authorization checks to any commands or updates that are made by the
control-plane protocol.

[CB] Thanks. I&= #39;ve added that to version -15 (to be submitted soon).
=C2=A0

Similarly, I didn't see any discussion of authorization for applying or=
making changes to the "rules" that are mentioned as needing to be=
applied by a data-plane node (as mentioned in the COMMENT where I ask
for clarification on the nature of such rules).

[CB] Thanks. Even though we have changed a bit the writing to avoi= d the term=C2=A0"rule", we have added some text regarding the use= of authentication and authorization mechanisms when doing traffic indirect= ion=C2=A0 in version -15.
=C2=A0

Also, we should reference RFCs 8221 and 8247 for the current guidance on IPsec and IKEv2 usage.

[CB] Thanks. Add= ed.
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

While I see the value in having this document to crystallize thinking
about the various mobility anchoring techniques that are possible, it's=
not clear to me how much archival value this document would add to the
RFC series in the absence of specific protocol mechanisms to implement
the functionality described therein.=C2=A0 As such, I expect to change my ballot position to Abstain after my Discuss points are resolved.

Section 1

=C2=A0 =C2=A0When the MN wants to continue using its assigned prefix to com= plete
=C2=A0 =C2=A0ongoing data sessions after it has moved to a new network, the=
=C2=A0 =C2=A0network needs to provide support for the MN's IP address -= - and

The new network, right?


[CB] The new network and the old one, = understanding "old" by the one anchoring the prefix used by the M= N. That's why we just use the generic term "network" without = prepending "new".

Section 2

=C2=A0 =C2=A0Anchoring (of an IP prefix/address):=C2=A0 An IP prefix, i.e.,= Home
=C2=A0 =C2=A0 =C2=A0 Network Prefix (HNP), or address, i.e., HoA, assigned = for use by
=C2=A0 =C2=A0 =C2=A0 an MN is topologically anchored to an anchor node when= the anchor
=C2=A0 =C2=A0 =C2=A0 node is able to advertise a connected route into the r= outing

Is "connected route" a term of art I should be looking up?


[CB] I agree it's probably better = to just use "route". We have changed this in version -15 (to be s= ubmitted soon).
=C2=A0
=C2=A0 =C2=A0 =C2=A0 and manages the network location information of an MN.= =C2=A0 The
=C2=A0 =C2=A0 =C2=A0 location information may be a binding of the advertise= d IP
=C2=A0 =C2=A0 =C2=A0 address/prefix, e.g., HoA or HNP, to the IP routing ad= dress of the
=C2=A0 =C2=A0 =C2=A0 MN or of a node that can forward packets destined to t= he MN.

I assume this ("may be [...] or") is not intended to be an exhaus= tive
list?

[CB] Right. Though the cases list= ed are the ones I can think of now as making sense. But we don't want t= o close the door for other options that might also work there.
= =C2=A0

=C2=A0 =C2=A0 =C2=A0 In a client-server protocol model, location query and = update
=C2=A0 =C2=A0 =C2=A0 messages may be exchanged between a Location Managemen= t client
=C2=A0 =C2=A0 =C2=A0 (LMc) and a Location Management server (LMs), where th= e location
=C2=A0 =C2=A0 =C2=A0 information can be updated to or queried from the LMc.=

nit: s/updated to/updated from/?

[CB] R= ight, thanks.
=C2=A0

Do we want to discuss the authentication/authorization for such location management functions here?=C2=A0 (Including both MN/LMc and LMc/LMs
interactions.)

[CB] I've added &quo= t;secure (i.e., authenticated and authorized)" before "location q= uery and update messages may be
exchanged between [...]" to make = it clear that of course these signalling needs to be properly secured. I th= ink going into more details there will deviate the focus from the main poin= t of this document. Anyway, the security considerations section should cove= r all these parts as well.
=C2=A0

Section 4

=C2=A0 =C2=A0There may be multiple IP prefixes/addresses that an MN can sel= ect
=C2=A0 =C2=A0when initiating a flow.=C2=A0 They may be from the same access= network or
=C2=A0 =C2=A0different access networks.=C2=A0 The network may advertise the= se prefixes
=C2=A0 =C2=A0with cost options [I-D.mccann-dmm-prefixcost] so that the mobi= le node
=C2=A0 =C2=A0may choose the one with the least cost.=C2=A0 In addition, the= se IP

This draft has not been updated since 2016.=C2=A0 Is it still expected to progress, such that a reference to it remains valuable?

[CB] We use this reference as an example of approach. Ther= e are other examples that we could reference, but I wanted to give the cred= it to the guys that I think first proposed this. That's why I kept the = reference, but I can very easily replace it with another one if you think i= t would be best.=C2=A0


=C2=A0 =C2=A0prefixes/addresses may be of different types regarding whether=
=C2=A0 =C2=A0mobility support is needed [RFC8653].=C2=A0 A MN will need to = choose which
=C2=A0 =C2=A0IP prefix/address to use for each flow according to whether it= needs
=C2=A0 =C2=A0IP mobility support or not, using for example the mechanisms =C2=A0 =C2=A0described in [RFC8653].

I'm confused.=C2=A0 "these prefixes/addresses" seems to refer= to the ones
advertised by the network, but the question of whether mobility support
is needed seems like a matter local to the MN and not a need of the
network.=C2=A0 (Perhaps the network might *provide* different mobility
services for different prefixes/addresses, but that's not what this tex= t
currently says.)

[CB] The prefixes/addr= esses refer to the one provided by the network. The question of whether the= MN needs mobility or not is local to the MN, but if the MN actually need i= t, support from the network might be needed (depending on the type of mobil= ity support of the MN and network). I've reworded it to:

=
"In addition, the IP prefixes/addresses provided by the net= work may be of
different types regarding whether mobility support is s= upported [RFC 8653] ."
=C2=A0
I hope now the text is cle= arer.


Section 4.1

I suggest to expand access router or list it in the terminology section.

[CB] Done (expanded first time it appears= in the text).
=C2=A0

=C2=A0 =C2=A0When IP session continuity is needed, even if a flow is ongoin= g as
=C2=A0 =C2=A0the MN moves, it may still be desirable for the flow to change= to
=C2=A0 =C2=A0using the new IP prefix configured in the new network.=C2=A0 T= he flow may
=C2=A0 =C2=A0then close and then restart using a new IP address configured = in the
=C2=A0 =C2=A0new network.=C2=A0 Such a change in the IP address of the flow= may be

It's perhaps a little confusing, in a rhetorical sense, to talk about "the flow changing to use the new prefix" but doing that by havin= g the
flow "close and then restart" -- is it really the same flow after= it has
closed?

[CB] You are right. If we are p= icky with the terminology, the flow is indeed different. I've reworded = to use "application flow" instead of "flow". Hope this = is a bit better. Current text (some other small changes performed) read as = follows:

"When IP session continuity is neede= d, even if an application flow is ongoing as
the MN moves, it may stil= l be desirable for the application flow to change to
using the new IP pr= efix configured in the new network. The application flow may
then be clo= sed at IP level and then be restarted using a new IP address
configured = in the new network. Such a change in the IP address used by the
applicat= ion flow may be enabled using a higher layer mobility support which is
n= ot in the scope of this document."
=C2=A0=C2=A0

=C2=A0 =C2=A0Note that in this scenarios, if there is no mobility support p= rovided
=C2=A0 =C2=A0by L4 or above, an application might be able to stop before ch= anging
=C2=A0 =C2=A0point of attachement, and therefore the traffic would stop.
I'm not sure what "might be able to stop" is intended to mean= .
Regardless, it's quite clear that the traffic will stop upon the
mobility event in this scenario, since the network does not provide
continuity services!

[CB] That sentence= was definitely not good. I've just simplified it to:

"Note that in these scenarios, if there is no mobility support= provided by L4 or
above, application traffic would stop."
<= div class=3D"gmail_quote">
which is kin= d of clear, but I think it doesn't harm keeping it.


Section 4.2

=C2=A0 =C2=A0prefix.=C2=A0 The latter enables optimized routes but requires= some data
=C2=A0 =C2=A0plane node that enforces rules for traffic indirection.=C2=A0 = Next, we

I'm not sure I understand the role this rule-enforcment is meant to
play.=C2=A0 What sort of rules would it be enforcing?
=
[CB] We mean routing updates that enable the anchor mobility= . I probably used the term "rules" because one example of approac= h to use in a local domain is OpenFlow. I've reworded it to the followi= ng:

"The latter enables optimized routes but = requires some data plane node that enforces
traffic indirection."=
=C2=A0

=C2=A0 =C2=A0to AR1 per default routing).=C2=A0 The LM and FM functions are= implemented
=C2=A0 =C2=A0as shown in Figure 6.

Where is FM indicated in Figure 6?=C2=A0 I cannot find it.
=

[CB] Ooops. Thanks. Fixed!
=C2=A0

Also, should there be any control-plane anchoring indicated in Figure 6?

[CB] There is the LM part indicated in AR= 2.
=C2=A0

Section 4.3

=C2=A0 =C2=A0We focus next on the case where the mobility anchor (data plan= e
=C2=A0 =C2=A0function) is changed but binds the MN's transferred IP add= ress/
=C2=A0 =C2=A0prefix.=C2=A0 This enables optimized routes but requires some = data plane
=C2=A0 =C2=A0node that enforces rules for traffic indirection.

[same question as above about the rules]

[CB] Same resolution as before.
=C2=A0

=C2=A0 =C2=A0IP mobility is invoked to enable IP session continuity for an = ongoing
=C2=A0 =C2=A0flow as the MN moves to a new network.=C2=A0 Here the anchorin= g of the IP
=C2=A0 =C2=A0address of the flow is in the home network of the flow (i.e.,<= br> =C2=A0 =C2=A0different from the current network of attachment).=C2=A0 A cen= tralized

nit(?): this usage of "here" is surprising, in that it seems to d= iscuss
the same case as the previous section, and not the new mechanism that
we're describing in this section.

[= CB] OK, I've removed "here".=C2=A0

=C2=A0 =C2=A0The IP prefix/address anchoring may move without changing the = IP
=C2=A0 =C2=A0prefix/address of the flow.=C2=A0 Here the LM and FM functions= in Figure 1
=C2=A0 =C2=A0in Section 3.1 are implemented as shown in Figure 7.

Where is the FM function indicated in Figure 7?=C2=A0 I cannot find it.
=

[CB] FM is not involved here. I've fix= ed the text. When we wrote the text I was thinking on a generic way of refe= rring to LM and FM functions, not implying that they need to be implemented= in all the cases. But I agree it is not very clear.
=C2=A0=C2=A0=

=C2=A0 =C2=A0[I-D.ietf-rtgwg-atn-bgp].=C2=A0 When a mobile associates with = an anchor
=C2=A0 =C2=A0the anchor injects the mobile's prefix into the global rou= ting
=C2=A0 =C2=A0system.=C2=A0 If the mobile moves to a new anchor, the old anc= hor

nit: "mobile node" or just "MN" (twice)?

[CB] Probably better to use MN. I've fixed it.
=C2=A0

=C2=A0 =C2=A0withdraws the /64 and the new anchor injects it instead.

What kind of synchronization and/or serialization is needed between the
withdrawl and injection of the /64 in question?

[CB] That'd be part of the control plane signalling, which wou= ld depend on the actual solution being used. Since this document does not g= o into the specifics of an actual solution, we don't go further.
<= div>=C2=A0

Section 5

=C2=A0 =C2=A0As stated in [RFC7333], "a DMM solution MUST supportany s= ecurity

nit: s/supportany/support any/

[CB] Fix= ed, thanks.

Thanks again for all the good comments= .

Carlos
=C2=A0
--000000000000facc9e05a046a51e-- From nobody Sat Mar 7 16:21:47 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473B33A1648 for ; Sat, 7 Mar 2020 09:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS4vH8_qzHxt for ; Sat, 7 Mar 2020 09:03:58 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDA33A1649 for ; Sat, 7 Mar 2020 09:03:58 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id a20so618193edj.2 for ; Sat, 07 Mar 2020 09:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/43tNNxkD2udX13tspDGHRGUPwIKWlMsYAGH/ItMkT8=; b=H5YGdcZtYyIgDYD3Gh86RzYeR9gwc2a5qTTdAC2pBwHCGWH07gXOGzAdBEFnhxtbO3 qcjx7fMRayels8UMHmZLZ514DewX++fLiI8Tppi2+l7d5btn2Axt/GVM/Ru51giu7Vi3 1z28jDsC0gvcqN3WeNmczOWlNQUaaowm04ZnP85tJNk8EWTnXW+g/LwYb2oXJdxCswPc Vf72kstwIcmlTbe+ihTxohSdr5mglzOVnRdVAaEMdqkBds0jKXglm0LsHsLFPSiZ1cty Dexlvc+jE+aSHve8sp8ae9SfTcdh1I28cEfb7Lrr2Yo59P6IsNBQsSLAZICat8k8hPmk ajUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/43tNNxkD2udX13tspDGHRGUPwIKWlMsYAGH/ItMkT8=; b=pU5tQ2L3t71QXspjQK5QxW6l1wSCaJSiIIAiZ5yprPZAyQaVNit3TspnXXE+0AjKdq 294As9LEPHJO+mSB6sMK7M9Y1TfIpVq7gI3RO2g/Bi3P7G9BRm4wOZ6dUlSEzHz5wVYa FyNSdB78aOdUMHXMvvq2wqDLn9S1mfqrAQsYLwv+apIwaaYCO/qM+jzmBadGHWohpiUi K9njJVVyJrYKYUeJp8hT064Gj1sCLxW2h3P4d1hUoIZ8pqEF77Av4s3K2U929kh8zhz3 6TN9XjTR4qtKWhJIbvqABgy5gx2PXi0O8JrbUK/aB+0x30x4goO2zZrcckKBJV3NcwIQ d86g== X-Gm-Message-State: ANhLgQ1zvSvZjmQP3JpYfFZhQQySkNQARG2ZIuundqNXt+LU2npwZZwV gwbOOOo8+7vytyphK02u4JbQ7IZb/TZKy7Hk4rhzSw== X-Google-Smtp-Source: ADFU+vv+KCtmiN1xzu0m4dVd6Ez0Vu2Cto3/8jiO9UkCI3YcvKZu98Rts4/Gb9nqB4fd2sK0522mMdraYONFNMZIB7c= X-Received: by 2002:aa7:dd1a:: with SMTP id i26mr9036665edv.321.1583600636517; Sat, 07 Mar 2020 09:03:56 -0800 (PST) MIME-Version: 1.0 References: <158338619598.29359.1563714463313257220@ietfa.amsl.com> In-Reply-To: <158338619598.29359.1563714463313257220@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sat, 7 Mar 2020 18:03:39 +0100 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs , dmm , Dapeng Liu Content-Type: multipart/alternative; boundary="000000000000682e8f05a046c166" Archived-At: Subject: Re: [DMM] Roman Danyliw's No Objection on draft-ietf-dmm-distributed-mobility-anchoring-14: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 17:04:00 -0000 X-List-Received-Date: Sat, 07 Mar 2020 17:04:00 -0000 --000000000000682e8f05a046c166 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Thanks for your review. Please see inline below. On Thu, Mar 5, 2020 at 6:29 AM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anch= oring/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Ben Kaduk=E2=80=99s DISCUSS point. > [CB] I've just replied to Benjamin's review, addressing all his comments. > > Section 5. To provide symmetry with the IPSec recommendation, s/IKEv2 > should/IKEv2 SHOULD/ > > > [CB] OK, fixed in version -15 to be submitted. Thanks. Carlos --000000000000682e8f05a046c166 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

Thanks for y= our review. Please see inline below.

On Thu, Mar 5, 2020 = at 6:29 AM Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
Roman Danyliw has entered the following ballot positi= on for
draft-ietf-dmm-distributed-mobility-anchoring-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.i= etf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Ben Kaduk=E2=80=99s DISCUSS point.

[CB]=C2=A0I've just replied to Benjamin's review, addressing = all his comments.
=C2=A0

Section 5.=C2=A0 To provide symmetry with the IPSec recommendation, s/IKEv2= should/IKEv2 SHOULD/


[CB] OK, fixed in version -15 to be submitted. Thanks= .

Carlos
=C2=A0
--000000000000682e8f05a046c166-- From nobody Sun Mar 8 03:31:27 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D195F3A092F for ; Sun, 8 Mar 2020 03:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXysmjCCL071 for ; Sun, 8 Mar 2020 03:31:09 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E6D3A0926 for ; Sun, 8 Mar 2020 03:31:09 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id m13so8413655edb.6 for ; Sun, 08 Mar 2020 03:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=owhJNtNFF8T1ihwkjZu/C9ORkTJ5XjocLqKJs5Tr83U=; b=kW4ZBnIaXDZ9k2Wn9AUBlNeIMC+lZL7aSQ1RGCnOFLDadiC36Ld4cgal0Jx/hz3jz0 JS1Rm9aJUtL93XapLZMlodZklapB7hXvYqwUJoGJ+v+C/TS8t6qYqAVWPwziWz3dcDvR ET/AAz+PQkggRQjQ3ep4Bf/kauPumHDb+2jICYm5W4+LoijDB+GXFGT+1fRATP9lBDxA iv0EG5YC0h+Yl02NjG6H2ljHO/MsyD8MDo4YQzfQNfMgJr3N075Ieb15mNZ3jXBKrWC+ 85RLwsoyqQN++k8++asMeOrTV3gANToze7PzZjBX/ebAElMzE+SpURnHQHRsDlUlEhvj 7GmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=owhJNtNFF8T1ihwkjZu/C9ORkTJ5XjocLqKJs5Tr83U=; b=F7E7SRZsQDSIeePsppOZCWOqkZRyaOlK77dRP0x927X6ywsXbm4+pI4mjW/0rfresC ZhKAYy/+DIayy2ypdmug1v8lbYAFX4q2XSYtnqqrL8Hn+GyFekZygSR4d9w3Oaahm7iZ 2Y5AsmjqQ+7WfrcdJy3Mmjpcki27JexXp2qcePJAn4HLI5IGB5csrsGExgGCiGmjRuIP kJRioVgJEphf/oE8jbaiwGmCo4zMvF1Y80jxGAotOYxZdpWNHXPDnZ8ZaIlt6cV7VLDv s3CI7y9oxZL9LEK+nef2mojZyS9RQsy9CdsMYhB9Bv1bH0xIPQJ1j2HoyXH2m0p/24au AzEA== X-Gm-Message-State: ANhLgQ3blCjmrWZsYckUNcf6HRREsfmObNW1sLopKSrliis2dOC6h1DF e8hiJFgrhjCTtFopJlQULnSn9GRcwsCeFj9NIsnOFUPmOi/LfQ== X-Google-Smtp-Source: ADFU+vv/TpToVizf2bAgMx/wyBo3GCrKQ2FOn7eHDoBC7FIx1aKhA46aU7hn8iArN13Lq2J7QOGn6PMbKfW2hJfxEQ8= X-Received: by 2002:a17:906:76c6:: with SMTP id q6mr10432689ejn.176.1583663467718; Sun, 08 Mar 2020 03:31:07 -0700 (PDT) MIME-Version: 1.0 References: <158290959879.22292.8550769571577161380@ietfa.amsl.com> In-Reply-To: <158290959879.22292.8550769571577161380@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sun, 8 Mar 2020 11:30:50 +0100 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs , dmm , Dapeng Liu Content-Type: multipart/alternative; boundary="000000000000700da005a05562e0" Archived-At: Subject: Re: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?mm-pmipv6-dlif-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 10:31:26 -0000 --000000000000700da005a05562e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, Thanks a lot for your review. Please see below my comments. On Fri, Feb 28, 2020 at 6:06 PM Mirja K=C3=BChlewind via Datatracker < noreply@ietf.org> wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-dmm-pmipv6-dlif-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Sec 3.2: > "The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD > be used for configuring the retransmission timer." > Use of this timeout from RFC6275 is fine. However, you should also indica= te > that the rest of the specified retransmission mechanism should be used as > well. > That means exponential backoff as well as a max number of retries. Furthe= r > I > think it would also be important to overall rate-limit the traffic e.g. a= s > specified in RFC6275: "The mobile node MUST NOT send Mobility Header > messages > of a particular type to a particular correspondent node more than > MAX_UPDATE_RATE times within a second." > > [CB] This is a good point. I've added some text along the lines you proposed in a new section "3.6. Retransmissions and Rate Limiting" > In addition the same mechanisms should probably be also required for any > (new) > message sent by the P/S-MAAR in other modes. > [CB] The new section 3.6 referred to in my previous comment applies to all the nodes (CMD or MAAR) sending a message. > > Finally in the security consideration section I see this: > "The CMD SHOULD use a pacing approach to limit > this amplification risk." > Which is good! But why is that a SHOULD and not a MUST? > [CB] I was not sure whether to go for a SHOULD or a MUST. I agree with you it's better to use a MUST there. I've replaced it. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Editorial comments/nits: > > 1)Sec 1: "Following this idea, in our proposal, the central anchor is..." > Maybe remove "in our proposal" as this is not a proposal only anymore whe= n > published. > [CB] Fixed. > > 2) Sec 2: > "The following terms used in this document are defined in the DMM > Deployment Models and Architectural Considerations document > [I-D.ietf-dmm-deployment-models]:" > As there doesn't seem to be any plan to actually publish > draft-ietf-dmm-deployment-models anymore, maybe move the respective > definitions > into this document. > [CB] Done. > > 3) Sec 3: "Note that a MN MAY move across different MAARs" > This should be lower case "may". > [CB] Done. > > 4) As section 3.6 talks mainly about implementation details, I suggest to > move > this section into the appendix. > [CB] While it's true that it's mainly about implementation details, I prefer to keep it in the main body, as it explains a mechanism that enables hiding the change of anchors from the mobile node. > > 5) In the appendix you always talk about "our solution". This is rather > uncommon for an RFC. I recommend to chance to e.g. "the solution specifie= d > in > this document". > > [CB] Right, fixed. > 6) Are both appendices A and B are still needed? > [CB] Here I'm neutral. I think they offered value when the document was discussed at the WG. But I agree now they can be perfectly removed. I'm removing them in version -06 (to be submitted soon), but if the IESG believes it is better to put them back, I can easily do it. > > 7) One overall editorial comment which might be too late to address: I > would > have found it more easy to read if you would have first introduced the ne= w > messages and then used the concrete message names in the description in > section > 3. > [CB] I prefer to keep the document as is. I think it is a matter of personal preferences, and now it would involve lots of changes. Thanks again for all your good cooments. Carlos --000000000000700da005a05562e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

Thanks a lot= for your review. Please see below my comments.

On Fri, Feb 28, 2020= at 6:06 PM Mirja K=C3=BChlewind via Datatracker <noreply@ietf.org> wrote:
Mirja K=C3=BChlewind has en= tered the following ballot position for
draft-ietf-dmm-pmipv6-dlif-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-dmm-pmipv6-dlif/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Sec 3.2:
"The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD
=C2=A0 =C2=A0be used for configuring the retransmission timer."
Use of this timeout from RFC6275 is fine. However, you should also indicate=
that the rest of the specified retransmission mechanism should be used as w= ell.
That means exponential backoff as well as a max number of retries. Further = I
think it would also be important to overall rate-limit the traffic e.g. as<= br> specified in RFC6275: "The mobile node MUST NOT send Mobility Header m= essages
=C2=A0 =C2=A0of a particular type to a particular correspondent node more t= han
=C2=A0 =C2=A0MAX_UPDATE_RATE times within a second."

[CB] This is a good point. I've added some text a= long the lines you proposed in a new section "3.6.=C2=A0 Retransmissio= ns and Rate Limiting"
=C2=A0
In addition the same mechanisms should probably be also required for any (n= ew)
message sent by the P/S-MAAR in other modes.

[CB] The new section 3.6 referred to in my previous comment applies t= o all the nodes (CMD or MAAR) sending a message.
=C2=A0

Finally in the security consideration section I see this:
"The CMD SHOULD use a pacing approach to limit
=C2=A0 =C2=A0this amplification risk."
Which is good! But why is that a SHOULD and not a MUST?

[CB] I was not sure whether to go for a SHOULD or a MUST. = I agree with you it's better to use a MUST there. I've replaced it.=
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial comments/nits:

1)Sec 1: "Following this idea, in our proposal, the central anchor is.= .."
Maybe remove "in our proposal" as this is not a proposal only any= more when
published.

[CB] Fixed.
=C2=A0=

2) Sec 2:
"The following terms used in this document are defined in the DMM
=C2=A0 =C2=A0Deployment Models and Architectural Considerations document =C2=A0 =C2=A0[I-D.ietf-dmm-deployment-models]:"
As there doesn't seem to be any plan to actually publish
draft-ietf-dmm-deployment-models anymore, maybe move the respective definit= ions
into this document.

[CB] Done.
=C2=A0

3) Sec 3: "Note that a MN MAY move across different MAARs"
This should be lower case "may".

<= div>[CB] Done.
=C2=A0

4) As section 3.6 talks mainly about implementation details, I suggest to m= ove
this section into the appendix.

[CB] Wh= ile it's true that it's mainly about implementation details, I pref= er to keep it in the main body, as it explains a mechanism that enables hid= ing the change of
=C2=A0anchors from the mobile node.

5) In the appendix you always talk about "our solution". This is = rather
uncommon for an RFC. I recommend to chance to e.g. "the solution speci= fied in
this document".

[CB] Right, fixed.
=C2=A0
6) Are both appendices A and B are still needed?

<= /div>
[CB] Here I'm neutral. I think they offered value when the do= cument was discussed at the WG. But I agree now they can be perfectly remov= ed. I'm removing them in version -06 (to be submitted soon), but if the= IESG believes it is better to put them back, I can easily do it.
=C2=A0

7) One overall editorial comment which might be too late to address: I woul= d
have found it more easy to read if you would have first introduced the new<= br> messages and then used the concrete message names in the description in sec= tion
3.

[CB] I prefer to keep the document a= s is.=C2=A0I think it is a matter of personal preferences, and now it would= involve lots of changes.

Thanks again for all you= r good cooments.

Carlos
--000000000000700da005a05562e0-- From nobody Sun Mar 8 05:09:43 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875913A041E for ; Sun, 8 Mar 2020 05:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7xOPiS963ZO for ; Sun, 8 Mar 2020 05:09:35 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40DA3A044F for ; Sun, 8 Mar 2020 05:09:34 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id b23so555742edx.4 for ; Sun, 08 Mar 2020 05:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m3AHJXOsd4q2p/q2bdzgGHEKM16dqWxYE6Vlq2qcm9Y=; b=Da3WhOSwTuTX8etpfozCkm/T+HR5XZ3wuQmYOaMTIQ6iLl0IcLU9cCy6HC9aT81n3p L3uMDjkvyKbc10QBJtsRwX8In4tPWWaHFEP5iBtifIOAJoL/NQs5T3XRY0QCF+hA8qWy kQEwOsLN8Cmo1Kz77o4jS1Qv1U4FcdkpjleYO8wqOwDxwVuEJqNi8dnhBGwuePWHSx7G Pfn7bRuLdpYSsI+20mJEAm7TzF+xX9hxwLUfMu3vQIzxvFfYuqypbA+ffqhlJ7A6PIPl a7befyI0fvRBbIZg5F65XF3CMV5Pjs/pV/oSM7SCuGWXBStYF1S3axOZAYxMmIMjs+28 rqXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m3AHJXOsd4q2p/q2bdzgGHEKM16dqWxYE6Vlq2qcm9Y=; b=FW2N5vUkDj+H5ng1aAUVnDeCrxNGuSKDiGDX82l25y4AetvoylJmCv3zB35+CNEsnR TdSjg6m9MUUsataemyzckHyRfsagBIo6+3LPm74PS56TPCX8QoFEX1XKGXqtnrmAXO7y l3Zz09s75YOOCKsdjujWIzyVsUEyeXlv8IJ5ZrtBsV2iRl9tjhLlxLFv9zL0fmqDnybx Q2y6RbS1LtwJdEyWqieo0/USwNREHiSjEfW99Iw8LRULdeQBHZ0mRvH0xby6zYfVr/NZ E3hcPaWLNvC9s9jsd7kUFP1SuMcBZ62WTcr0Cxk1GZ75199D56mu+6Vvyk7MBPT4Ur8R 9FRg== X-Gm-Message-State: ANhLgQ23kjI0CvUX1E2Kvmx+MByUXunuMQpqoUwOs5zX25BzjXUg0s9z 8A7P7yMsF1PcdJjBRwXjkfwiZ+KKQ9YK7LhYMH4qhA== X-Google-Smtp-Source: ADFU+vtKUKu2BOVZyCNvCTLdAsDwMRJIj7kAKAQ3ixYZcq/I2meD+KdYaqs2s5WuHvxofpQpUx6LKN0EIfXMlbD0Drw= X-Received: by 2002:aa7:dd1a:: with SMTP id i26mr12314205edv.321.1583669372810; Sun, 08 Mar 2020 05:09:32 -0700 (PDT) MIME-Version: 1.0 References: <158318249840.27483.9051628354202166127@ietfa.amsl.com> In-Reply-To: <158318249840.27483.9051628354202166127@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sun, 8 Mar 2020 13:09:16 +0100 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs , dmm , Dapeng Liu , Carlos Pignataro Content-Type: multipart/alternative; boundary="00000000000068a1e505a056c212" Archived-At: Subject: Re: [DMM] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-dmm-p?= =?utf-8?q?mipv6-dlif-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 12:09:40 -0000 --00000000000068a1e505a056c212 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi =C3=89ric, Thanks a lot for your review. Please see inline below my comments. On Mon, Mar 2, 2020 at 9:55 PM =C3=89ric Vyncke via Datatracker wrote: > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-dmm-pmipv6-dlif-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. And congratulations for th= e > many > advanced ASCII art ! Except for section 3.6, the text is really easy to > read. > > I have a block DISCUSS below but it should be trivial to fix. > > Please also address the points raised by Carlos during the INT directorat= e > review. Thank you again Carlos ! > > https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-te= lechat-pignataro-2020-02-28/ > > I hope that this helps to improve the document, > [CB] Thanks. I've addressed the comments from Carlos in version -06 (to be submitted soon). > > Regards, > > -=C3=A9ric > > =3D=3D DISCUSS =3D=3D > > -- Section 4.3 & 4.4 & 4.5 -- > Probably trivial to fix but is "Prefix Length" expressed in bits (/64) or > in > bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? Th= e > definition of the "Prefix length" field should be specific about the unit > (bits/bytes) and be aligned with the definition of "Anchored prefix" (as > this > one seems to assert that the prefix length must be a multiple of 8). > > [CB] The prefix length is expressed in bits. I've clarified this in the text. I've also fixed this in the "Anchored prefix" definition. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > =3D=3D COMMENTS =3D=3D > > A generic question, can a MN be attached to multiple MAAR at the same tim= e? > I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR > at > any time. > [CB] The document assumes only S-MAAR at a time. Adding support for multiple S-MAARs at the same time could be feasible, but it'd add complexity. IMHO it's better to see the potential adoption of this solution and gain from implementation experience before going into adding support for multiple S-MAARs. > > -- Section 3.1 -- > Should the length of the prefix assigned to the MN be specified? Adding a > /64 > would make things clearer without using too much of text. > [CB] I agree it could be added and be helpful, but since the message options defined could support other prefix lengths (though I agree /64 would be one most of the times), using /64 in Section 3.1 could lead to assume that only that prefix length is valid. But if you think it's better to add it, I can do it (I don't have a strong opinion against). > For my own curiosity, the text is about "IPv6 global prefix", but, would > ULA > also work ? > [CB] I think it would as well. I always tend to think that mobility solutions only make sense in global scenarios, but there is nothing preventing it to use the mechanisms with ULA. I also tried to follow as much as possible RFC 5213 terminology and there "global" is used. I've kept the "global" for the time being, but it can be removed. > -- Section 3.6 -- > This section is so different than the previous ones in section 3, that I > would > have created a section on its own. > [CB] I agree section 3.6 (which is section 3.7 in version -06) is different from the other 3.x, but it is about PMIPv6 DMM extensions, and that's why I believe it belongs to Section 3. Creating a section on its own would probably give it too much focus. > This section also uses EUI-64 for the link-local address; and, this is no > more > advised for privacy reason. Not really important in the DMM context thoug= h. > [CB] Yes, I agree. Since the exemplary addresses are not that important, I've removed them by rewriting the text as follows: OLD: [...] router with a specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using [...] NEW: [...] router with a specific MAC and IPv6 addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using [...] > Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ > ;-) > [CB] Right! Fixed in my new proposed text above (fe80::MAAR1/64). > > The text of this section is really difficult to parse. After 2 readings I > am > not even sure that I got it... I was about to open a DISCUSS for the poin= t > 2) > but I am unsure whether I am reading the text correctly. > > 1) If the MAC and LLA for the 'virtual router' mn1mar2 are different than > the > one for mn1mar2, why is there a need for different interface? Multiple > routers > can exist on the same link. > [CB] Since mn1mar1 and mn1mar2 have different MAC addresses, we need to have a different "logical" interface over the same physical interface (as one interface can only have one MAC address). They actually co-exist on the same link, as the distributed logical interface is just a mechanism to hide the change of anchors from the mobile node. The mobile node actually "sees" multiple routers on the same link, even though the anchors (MAARs) are not actually on that same link. > 2) For packets sourced by MN1 with prefix1 how can we ensure that they ar= e > sent > to mn1mar1 and not to mn1mar? PvD could help there and should be mentionn= ed > draft-ietf-intarea-provisioning-domains. > [CB] The MN, for each CN it is communicates, uses the source address that was selected when the communication was initiated with that CN. At each given time, only one (global) IPv6 address is not deprecated, and therefore when the MN is attached to MAARX, only the address allocated from the prefix anchored at MAARX (e.g. PrefX::MN) is non-deprecated. If the MN visited before other MAARs (e.g., MAARY) and has an active communication with a CN that was established while MN was attached to MAARY (e.g., PrefY::MN), then that communication will continue using the deprecated address (PrefY::MN). Deprecated addresses can be used while there are ongoing communications using them, but for new communications a non-deprecated address is preferred (according to RFC 6724). Then, according to RFC 2461, next-hop determination is not performed on every packet that is sent, but the results of next-hop determination computations are saved in the Destination Cache (which will contain the right mn1marX for the used source address in a given communication). > -- Section 4.2 -- > Bit 31 is not described, it is probably reserved but you should really > described it. > [CB] Yes, it is reserved and that's why we didn't describe it. Since there is a bit 'R' defined in RFC 3963, and there is only one bit left reserved I was not sure how to refer to it in the message format. Other mobility RFCs defining new flags just describe the new ones and refer to RFC 6275, but I agree that when there are multiple reserved bits and the message format figure shows "Reser" or something like that it is much easier to understand that these are not yet assigned and you don't need text to explain it. Any advice on how to do this in this case in which only one bit is left reserved? > > With this PBA packet format, all flags / bits are used and assigned for a= n > experimental document. Isn't it a waste of bits? I will really appreciate > an > answer on this question. > [CB] Well, this is a good question. I'm not aware of any policy about how to assign flags to protocols. I can only say that there are other experimental protocols using flags of the Binding Update / Binding Acknowledgement messages registered by the IANA. I think the use of the 'D' flag is well justified, but I'm of course biased here :) > > =3D=3D NITS =3D=3D > > -- Section 3 (and possibly others) -- > The CMD and MAAR acronyms are expanded multiple times. This makes the > reading > easier for newcomers of course. > [CB] I've removed some of the duplicated expansions. I still kept two because I think it makes the reading easier. It is probably not very relevant, but I think one of the reasons we expand the terms several times is because we got a request in some of the reviews at the WG to do so, but I'm 100% sure about that. Thanks a lot for your comments! Carlos --00000000000068a1e505a056c212 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi =C3=89ric,

Thanks a= lot for your review. Please see inline below my comments.

<= div class=3D"gmail_quote">
On Mon, Mar= 2, 2020 at 9:55 PM =C3=89ric Vyncke via Datatracker <noreply@ietf.org> wrote:
=C3=89ric Vyncke has entered the followin= g ballot position for
draft-ietf-dmm-pmipv6-dlif-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-dmm-pmipv6-dlif/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. And congratulations for the = many
advanced ASCII art ! Except for section 3.6, the text is really easy to rea= d.

I have a block DISCUSS below but it should be trivial to fix.

Please also address the points raised by Carlos during the INT directorate<= br> review. Thank you again Carlos !
https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-tel= echat-pignataro-2020-02-28/

I hope that this helps to improve the document,

[CB] Thanks. I've addressed the comments from Carlos in versio= n -06 (to be submitted soon).
=C2=A0

Regards,

-=C3=A9ric

=3D=3D DISCUSS =3D=3D

-- Section 4.3 & 4.4 & 4.5 --
Probably trivial to fix but is "Prefix Length" expressed in bits = (/64) or in
bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? The<= br> definition of the "Prefix length" field should be specific about = the unit
(bits/bytes) and be aligned with the definition of "Anchored prefix&qu= ot; (as this
one seems to assert that the prefix length must be a multiple of 8).

[CB] The prefix length is expressed in bits. I've= clarified this in the text. I've also fixed this in the "Anchored= prefix" definition.
=C2=A0

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

=3D=3D COMMENTS =3D=3D

A generic question, can a MN be attached to multiple MAAR at the same time?=
I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR a= t
any time.

[CB] The document assumes onl= y S-MAAR at a time. Adding support for multiple S-MAARs at the same time co= uld be feasible, but it'd add complexity. IMHO it's better to see t= he potential adoption of this solution and gain from implementation experie= nce before going into adding support for multiple S-MAARs.
=C2=A0=

-- Section 3.1 --
Should the length of the prefix assigned to the MN be specified? Adding a /= 64
would make things clearer without using too much of text.
<= div>
[CB] I agree it could be added and be helpful, but since= the message options defined could support other prefix lengths (though I a= gree /64 would be one most of the times), using /64 in Section 3.1 could le= ad to assume that only that prefix length is valid. But if you think it'= ;s better to add it, I can do it (I don't have a strong opinion against= ).


For my own curiosity, the text is about "IPv6 global prefix", but= , would ULA
also work ?

[CB] I think it would as we= ll. I always tend to think that mobility solutions only make sense in globa= l scenarios, but there is nothing preventing it to use the mechanisms with = ULA. I also tried to follow as much as possible RFC 5213 terminology and th= ere "global" is used. I've kept the "global" for th= e time being, but it can be removed.=C2=A0


-- Section 3.6 --
This section is so different than the previous ones in section 3, that I wo= uld
have created a section on its own.

[CB]= I agree section 3.6 (which is section 3.7 in version -06) is different fro= m the other 3.x, but it is about PMIPv6 DMM extensions, and that's why = I believe it belongs to Section 3. Creating a section on its own would prob= ably give it too much focus.


This section also uses EUI-64 for the link-local address; and, this is no m= ore
advised for privacy reason. Not really important in the DMM context though.=

[CB] Yes, I agree. Since the exemplary= addresses are not that important, I've removed them by rewriting the t= ext as follows:

OLD:
[...] router with a= specific MAC (e.g., 00:11:22:33:01:01) and IPv6
addresses (e.g.,= prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using [...]
<= br>
NEW:
[...] router with a specific MAC and IPv6<= br>
addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using [...]

Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ ;= -)

[CB] Right! Fixed in my new proposed= text above (fe80::MAAR1/64).
=C2=A0

The text of this section is really difficult to parse. After 2 readings I a= m
not even sure that I got it... I was about to open a DISCUSS for the point = 2)
but I am unsure whether I am reading the text correctly.

1) If the MAC and LLA for the 'virtual router' mn1mar2 are differen= t than the
one for mn1mar2, why is there a need for different interface? Multiple rout= ers
can exist on the same link.

[CB] Since = mn1mar1 and mn1mar2 have different MAC addresses, we need to have a differe= nt "logical" interface over the same physical interface (as one i= nterface can only have one MAC address). They actually co-exist on the same= link, as the distributed logical interface is just a mechanism to hide the= change of anchors from the mobile node. The mobile node actually "see= s" multiple routers on the same link, even though the anchors (MAARs) = are not actually on that same link.


2) For packets sourced by MN1 with prefix1 how can we ensure that they are = sent
to mn1mar1 and not to mn1mar? PvD could help there and should be mentionned=
draft-ietf-intarea-provisioning-domains.

[CB] The MN, for each CN it is communicates, uses the source address that= was selected when the communication was initiated with that CN. At each gi= ven time, only one (global) IPv6 address is not deprecated, and therefore w= hen the MN is attached to MAARX, only the address allocated from the prefix= anchored at MAARX (e.g. PrefX::MN) is non-deprecated. If the MN visited be= fore other MAARs (e.g., MAARY) and has an active communication with a CN th= at was established while MN was attached to MAARY=C2=A0(e.g., PrefY::MN), t= hen that communication will continue using the deprecated address (PrefY::M= N). Deprecated addresses can be used while there are ongoing communications= using them, but for new communications a non-deprecated address is preferr= ed (according to RFC 6724). Then, according to RFC 2461, next-hop determina= tion is not performed on every packet that is sent, but the results of next= -hopdetermination computations are saved in the Destination Cache (wh= ich will contain the right mn1marX for the used source address in a given c= ommunication).


-- Section 4.2 --
Bit 31 is not described, it is probably reserved but you should really
described it.

[CB] Yes, it is reserved = and that's why we didn't describe it. Since there is a bit 'R&#= 39; defined in RFC 3963, and there is only one bit left reserved I was not = sure how to refer to it in the message format. Other mobility RFCs defining= new flags just describe the new ones and refer to RFC 6275, but I agree th= at when there are multiple reserved bits and the message format figure show= s "Reser" or something like that it is much easier to understand = that these are not yet assigned and you don't need text to explain it. = Any advice on how to do this in this case in which only one bit is left res= erved?
=C2=A0

With this PBA packet format, all flags / bits are used and assigned for an<= br> experimental document. Isn't it a waste of bits? I will really apprecia= te an
answer on this question.

[CB] Well, thi= s is a good question. I'm not aware of any policy about how to assign f= lags to protocols. I can only say that there are other experimental protoco= ls using flags of the Binding Update / Binding Acknowledgement messages reg= istered by the IANA. I think the use of the 'D' flag is well justif= ied, but I'm of course biased here :)
=C2=A0

=3D=3D NITS =3D=3D

-- Section 3 (and possibly others) --
The CMD and MAAR acronyms are expanded multiple times. This makes the readi= ng
easier for newcomers of course.

[CB] I&= #39;ve removed some of the duplicated expansions. I still kept two because = I think it makes the reading easier. It is probably not very relevant, but = I think one of the reasons we expand the terms several times is because we = got a request in some of the reviews at the WG to do so, but I'm 100% s= ure about that.

Thanks a lot for your comments!

Carlos
--00000000000068a1e505a056c212-- From nobody Sun Mar 8 05:12:00 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6893A0593 for ; Sun, 8 Mar 2020 05:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgZLcyvivmAk for ; Sun, 8 Mar 2020 05:11:56 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDFB3A05A7 for ; Sun, 8 Mar 2020 05:11:56 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id y3so8550362edj.13 for ; Sun, 08 Mar 2020 05:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k1o40GfQfsaIF9ps8V0mysTXZbYLfELvv3v/FLtmZds=; b=jjhDuywPJvSmt54PkmdyJH0ED6nWJJYP7lWydYNiL4v/3fVIsA8VzMf15Y8WEKnOMf pU9jrtH9aV0WsUGZ6pZGUI7L/cbat+9shtJ3u49V9ab1paGmhw3CMGDGIi5h5fAl9tDe iDOhXxJhXfxUl8hpAcN3NdxUSLx7LboeDIFX7KU3jKsZNWMJGE7u3ZMYkLTPRrQ0Z/se SBoqdhmYJsXlM9ZEjSPFKDNQ+AZXqv9L/iNZiWyIYzjRzs4/kE+58FHMARkGQ220PbzB R0ADzWoXT5KRckCyEuCgcmBpT5E4Jh+qwD3eybYmhvVHVrDiCOmfbrdkhnH+pkBINyFQ Cc5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k1o40GfQfsaIF9ps8V0mysTXZbYLfELvv3v/FLtmZds=; b=pX7jcEUdl20MW0MFw4aez7BoAEG9lU72U26yUrk0+Q3j+akcjpMmtJWCFFAnKZuK1g PWDKDh0/4tgHf7dQEVsyWCOXQCTdExwpJb2jTZnNhLtTm7u13Faj97Uq+2uHEqkrV6RR vSsm1zyHgf793MKDtRxI21wrD0+EoJjVlEkLj/yQhJMdoqQNqEfCXumKIcraMIHuBJnl UP0HmQ13QAPK5G6WI6CdTaIQX0BeFdmZ3SkGsEKzyXnGhpl0LCe2z80iSqa0rQfbsDPY jx0SyJEroyt/4v/13eszA6qiPGKc+iMMYeZXRzZZ4AMUW4pEKhdwUGoeg+ggpH3C39nh DmVw== X-Gm-Message-State: ANhLgQ2ra1IvIYnC0A0SVReROdpbSIipEs01w79fSvR6kPFfKMDR7+eT JUZLfC8e1YJaTR3oYATGImylBRgo4TnXUycxLrTqXA== X-Google-Smtp-Source: ADFU+vv5/TsJEJ9jgtZl/1GM0PRyId7BkcigxkXqwkF3vZx7WR/nl/e5M+VaYjT0rgEnbdlBNbSBvWOcoqxKJBRoJGw= X-Received: by 2002:a17:906:ca53:: with SMTP id jx19mr11188076ejb.192.1583669514807; Sun, 08 Mar 2020 05:11:54 -0700 (PDT) MIME-Version: 1.0 References: <158338560241.29408.3648898527474669779@ietfa.amsl.com> In-Reply-To: <158338560241.29408.3648898527474669779@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sun, 8 Mar 2020 13:11:37 +0100 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs , dmm , Dapeng Liu Content-Type: multipart/alternative; boundary="000000000000df534105a056ca3d" Archived-At: Subject: Re: [DMM] Adam Roach's No Objection on draft-ietf-dmm-pmipv6-dlif-05: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 12:11:59 -0000 --000000000000df534105a056ca3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adam, Thanks a lot for your review. Please see inline below for my comments. On Thu, Mar 5, 2020 at 6:20 AM Adam Roach via Datatracker wrote: > Adam Roach has entered the following ballot position for > draft-ietf-dmm-pmipv6-dlif-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the work on this document. I have only one editorial suggestio= n. > > Section 3.6: > > > to-point link) with MN1, exposing itself as a (logical) router with a > > specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., > > Please use a MAC address from the range reserved for documentation > purposes by > section 2.1.1 of RFC 7042. > [CB] Thanks. Addressing a comment from =C3=89ric I've ended up removing the= MAC address in the text, so this is not necessary, though I'll keep it in mind in case we need to mention a MAC address. Thanks, Carlos --000000000000df534105a056ca3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adam,

Thanks a lot = for your review. Please see inline below for my comments.

On Thu, Mar = 5, 2020 at 6:20 AM Adam Roach via Datatracker <noreply@ietf.org> wrote:
Adam Roach has entered the following ballot posi= tion for
draft-ietf-dmm-pmipv6-dlif-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-dmm-pmipv6-dlif/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this document. I have only one editorial suggestion.=

Section 3.6:

>=C2=A0 =C2=A0to-point link) with MN1, exposing itself as a (logical) ro= uter with a
>=C2=A0 =C2=A0specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses = (e.g.,

Please use a MAC address from the range reserved for documentation purposes= by
section 2.1.1 of RFC 7042.

[CB] Thanks.= Addressing a comment from =C3=89ric I've ended up removing the MAC add= ress in the text, so this is not necessary, though I'll keep it in mind= in case we need to mention a MAC address.

Thanks,=

Carlos
--000000000000df534105a056ca3d-- From nobody Sun Mar 8 07:35:12 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F52F3A0AAE for ; Sun, 8 Mar 2020 07:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCuUnlhrueph for ; Sun, 8 Mar 2020 07:35:09 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCDB3A0AAB for ; Sun, 8 Mar 2020 07:35:09 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id i10so5499359lfg.11 for ; Sun, 08 Mar 2020 07:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9WKXzWhJPfEfgCQJ7lojKNyfjXqcrIT7qFxosnf60DM=; b=kOimf+GuMG6fOQSm7XNzfGbU2e3OoX47vpyiyVXrRc3IwcREKkbPxjAfrh63pWu28M JeEaFXzwBpVu5DnKgOfS3qwtR8x9OCfGwMW9DXXDU8vUGnmK2gx6t9nQVWWTkhB5Mq/G G76BmfpZevocsh28ODlWe3TB9tE/8q+STZb5Srk6CnS5NiFr+2BaKwAoShGODJKYUgeq yFtp+4hyv6iDyOMZZRxSzmpAuJpSyaAvKNCzMNmjvap06INJwN9CJfNQ7gdgCjW2z7a8 HW7VCmN9ogLs4M1twopEbOAcbjeipv6j2id8TzAsjWGiKdB5I+35VUMqK+vtR44EVGLF N8+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9WKXzWhJPfEfgCQJ7lojKNyfjXqcrIT7qFxosnf60DM=; b=Lw9waDIuxplUFvkdxSx4jt80XXSgFoLVkBHe10AxlKIaVBjVnZKJiWRrNiINOe+pyh Ayqt9UbnS/t/906DABckceaZgtpqlYxRP5H3H0rsEHzoM5/7kDmQNj/8y3AZCVPR4MMz q1FEaFlzMNcMF6/GCGiRs+j2KcFzFmcw4OYNkfYnIRn6xPAVvk/W8l+r2/jrcprDUjP/ Ls63Mn5FG5/eiML5hBLwqjvaqS3fLUY20b6C7GOzA6DCuM1aaRoXHxf/vaz01ea7n6R8 PcL+8Ens5E3LfB73ySQXSL+rgQkQmSOSFSy6gndehf4tvWF9kgFNcYdvKGno8QyzF5eT K6Eg== X-Gm-Message-State: ANhLgQ05bofdwsgjPlNUiOzAZ9diS4JK3uNpMOEtQNBYaaW4so2Of760 c7joUHFHyuiDEhFxAxNTsXGOGkKVqGgSSu+CBXc= X-Google-Smtp-Source: ADFU+vsio+dhRFKgw4dhQTGM1heD/C62qZV1GecSBEW4gn+wtROevkOhTvrtgI/AFjUW6fZpBlmm0CdvXruia/9N3VU= X-Received: by 2002:ac2:4d16:: with SMTP id r22mr6336161lfi.174.1583678107548; Sun, 08 Mar 2020 07:35:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Miya Kohno Date: Sun, 8 Mar 2020 23:34:56 +0900 Message-ID: To: "Sri Gundavelli (sgundave)" Cc: "dmm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000a001705a058cb14" Archived-At: Subject: Re: [DMM] IETF 107 - DMM Working Group Session Cancellation X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 14:35:11 -0000 --0000000000000a001705a058cb14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sri, Satoru, all, It was unfortunate, but understandable. We have updated the draft. SRv6 mobile user plane enables to create overlay with underlay optimization and it would have a lot of advantages. But we'd encourage to revisit the current architectural convention to fully utilize the benefits. We would appreciate feedbacks. https://www.ietf.org/id/draft-kohno-dmm-srv6mob-arch-01.txt Thanks! Miya On Sat, Mar 7, 2020 at 2:55 AM Sri Gundavelli (sgundave) wrote: > Dear All, > > > > Due to some travel restrictions that in are place from my employer, and a= s > well from Satoru=E2=80=99s employer, we had to cancel our travel to Vanco= uver. In > discussions with our AD, we have jointly decided to cancel the DMM Workin= g > Group meeting for IETF107. Apologies for the late notifications, but thes= e > are due to situations beyond our control. Also, the WG mailers have been > very quiet, it will be good to find some relevant topics and bring some > energy into the discussions. > > > > We look forward to seeing in you all in IETF108. > > > > > > Satoru & Sri > > (DMM Working Group Chairs) > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --0000000000000a001705a058cb14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sri, Satoru, all,

It was unfortunate= , but understandable.=C2=A0

We have updated the dr= aft. SRv6 mobile user plane enables to create overlay with underlay optimiz= ation and it would have a lot of advantages. But we'd encourage to revi= sit the current architectural convention to fully utilize the benefits. We = would appreciate feedbacks.


Thanks= !
Miya

On Sat, Mar 7, 2020 at 2:55 AM Sri Gundavelli (sgunda= ve) <sgundave=3D40cisco.co= m@dmarc.ietf.org> wrote:

Dear All,

=C2=A0<= /span>

Due to some travel re= strictions that in are place from my employer, and as well from Satoru=E2= =80=99s employer, we had to cancel our travel to Vancouver. In discussions = with our AD, we have jointly decided to cancel the DMM Working Group meeting for IETF107. Apologies for the late notifica= tions, but these are due to situations beyond our control. Also, the WG mai= lers have been very quiet, it will be good to find some relevant topics and= bring some energy into the discussions.

=C2=A0<= /span>

We look forward to se= eing in you all in IETF108.

=C2=A0<= /span>

=C2=A0<= /span>

Satoru & Sri

(DMM Working Group Ch= airs)

=C2=A0<= /span>

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
--0000000000000a001705a058cb14-- From nobody Sun Mar 8 10:58:45 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869A23A0E3F for ; Sun, 8 Mar 2020 10:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1iDLYAb3ZXx for ; Sun, 8 Mar 2020 10:58:33 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019ED3A0E3D for ; Sun, 8 Mar 2020 10:58:32 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id dc19so9228356edb.10 for ; Sun, 08 Mar 2020 10:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tVJitEHtibU7Bab1vL9avG8BI8OWJ9dEyYBm6RFvIbU=; b=o39dbZeqTHTFU5f2fLVCu6s5GAYSROZPe/c11yIeeTctGRJ0Kkxe0CHbNs6RvEn30D j596VtdXcmdXdFy3TYtbmJuS5cV9sF0DMPsvL2n8JlM4L28ADm4DQK2CCQ9OzLtTBkK4 E2cPrbZxeZLWF4Y8wrprGrnYuHYi9m9vp5DIPnFlRn+aagBCJn9B/ew1d1uQEknYuUy0 hUFB97gkOZVSKv9OCGY6emEXNJ+ob7VkOMR+vScGWr04DDq8p6GTffZ3wufHYY8RW5yO Bw0NJghfe5kRiXxFOQ0pZF7LL8Zsn2ahSo2+kEvDBmfPlNmxaGs+00Hz4ArT8UNnAGpT 7adw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tVJitEHtibU7Bab1vL9avG8BI8OWJ9dEyYBm6RFvIbU=; b=irYJFTaidaf1gGiGvopsBmKj5ByeWU0JlGmrTG1O8VYzDiciubDYGfAgQaQvwLhlJF 4NJZX+grm4V5wu/DD6NsJfRnhQNzomTdj1/nK7VW7sM4eDXKFPG9C9iCisDa3juC4hqN /+XNSkRYuZifx0r2ZaEFddrBLos6UNgwUUn/T/JXLVZl0U0H4f+Np4q81/UwPBniw3qf tvlN3V3Sw6UN01t0M2kOqqGv9c2G+OWabANG49HfRWOFLp6fpCVaVciih6j+Wxgn/dWf JWPivnsiSaQ9uBSuveI/2aGP+tl1lkAtLvJMFJQOEmZkPCr5Jsz73y0wAuwIqaf71Aew pL/Q== X-Gm-Message-State: ANhLgQ1jdflOqstPUyWIqvTxxQkks0s996tAUxIau4Qdg8ZG0r/eUxSv YgmNgXJzTMZYedXYjf6addrP2uX9b7f30iTnK30L7w== X-Google-Smtp-Source: ADFU+vv+AZQk+64QmEoZb3T9U9kuAcnRTGhsrPMXGCepoUh3+uDh9ancQAWla7SarCaApmIBAnD2f/tmNWi8xT6sJck= X-Received: by 2002:a17:906:ca53:: with SMTP id jx19mr12282909ejb.192.1583690310657; Sun, 08 Mar 2020 10:58:30 -0700 (PDT) MIME-Version: 1.0 References: <158338573858.29475.12173301575622176655@ietfa.amsl.com> In-Reply-To: <158338573858.29475.12173301575622176655@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sun, 8 Mar 2020 18:58:14 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs , dmm , Dapeng Liu Content-Type: multipart/alternative; boundary="00000000000066c5d805a05ba2f6" Archived-At: Subject: Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 17:58:39 -0000 --00000000000066c5d805a05ba2f6 Content-Type: text/plain; charset="UTF-8" Hi Benjamin, Thanks a lot for another very good review. Please find my comments inline below. On Thu, Mar 5, 2020 at 6:22 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dmm-pmipv6-dlif-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have a very boring Discuss point and a somewhat boring point, and > expect to change my ballot to Yes once they're resolved. > > In Section 3.2 we say that pacing mechanisms "MAY" be used to avoid > bursts when the CMD is fanning out PBUs, but in Section 6 we say that > pacing "SHOULD" be used; please resolve the inconsistency (preferrably > with "MUST" as Mirja requests). > [CB] Done in version -06 (to be submitted soon). > > Please also include some discussion of privacy considerations (I give > some suggestions in the COMMENT). > [CB] OK, I'll do. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this well-written document! It is clearly written, and when > multiple approaches exist, does well at laying out the different options > and their pros/cons, as befits an Experimental document. Also, several > times I have started to write a comment only to realize that it is > answered by the following text :) > [CB] Thanks, very much appreciated. > > Section 1 > > The Distributed Mobility Management (DMM) paradigm aims at minimizing > the impact of currently standardized mobility management solutions > which are centralized (at least to a considerable extent). > > I'd consider saying a little more about which aspects of their operation > are centralized. Perhaps the following paragraph suffices, though. > [CB] I've added another reference to RFC 7333, where this is explained in detail. As you mention below, we go a bit into these aspects of centralized operation in the following paragraph, and I personally believe it is better not to add too much text on this aspect (which is covered by RFC 7333). Please, let me know if you are not happy with this resolution. > > Following this idea, in our proposal, the central anchor is moved to > the edge of the network, being deployed in the default gateway of the > mobile node. That is, the first elements that provide IP > > (side note: Using the singular "central anchor" poses an interesting > rhetorical question: is the (formerly) single central anchor being > duplicated and spread amongst all access routers, or does there remain a > single central anchor (per MN), just one that moves around along with > the MN.) > [CB] The whole idea of the DMM approach specified in this document is that we move from a "single central anchor" to a "multiple distributed anchors". Note that the specified approach allows for a central anchor to be still present (and used by an MN for communications where it is more appropriate), but this is more an operational decision (probably more in scope of RFC 8653). > > anchors to retrieve the MN's previous location(s). Also, a key- > aspect of network-based DMM, is that a prefix pool belongs > exclusively to each MAAR, in the sense that those prefixes are > assigned by the MAAR to the MNs attached to it, and they are routable > at that MAAR. > > It might be worth some statement relating this "ownership" of prefixes > to actual mobility events -- e.g., they are assigned to MNs attached to > it at that time, but remain with those MNs as mobility occurs, but > always remain routable at that MAAR as well as towards the MN itself. > > [CB] OK, I've added a sentence adopting part of your text. Thanks. > We consider partially distributed schemes, where the data plane only > is distributed among access routers similar to MAGs, whereas the > > nit: I suggest s/the data plane only/only the data plane/ > [CB] OK, thanks. > > control plane is kept centralized towards a cardinal node used as > information store, but relieved from any route management and MN's > data forwarding task. > > What's the scope of "single" here -- per deployment, per prefix, per > MAAR, ...? > [CB] Sorry, I don't get this comment. I don't see "single" mentioned in the quoted textl > > P-MAAR (Previous MAAR). When a MN moves to a new point of attachment > a new MAAR might be allocated as its anchor point for future IPv6 > prefixes. The MAAR that served the MN prior to new attachment > becomes the P-MAAR. It is still the anchor point for the IPv6 > prefixes it had allocated to the MN in the past and serves as the > > (side note? Do we expect those previous allocations to eventually "time > out" as sessions using them terminate? Or are the allocations more > permanent, with intent to reuse if/when the MN returns to that MAAR?) > [CB] The expectation is that previous allocations will eventually time-out as sessions using them terminate. > > Section 3 > > interest and eventually take the appropriate action. The procedure > adopted for the query and the messages exchange sequence might vary > to optimize the update latency and/or the signaling overhead. Here > > nit: wrong pluralization in "messages exchange sequence" > [CB] OK, fixed. > > Section 3.1 > > 3. Since this is an initial registration, the CMD stores a permanent > BCE containing as primary fields the MN-ID, Pref1 and MAAR1's > address as a Proxy-CoA. > > [how permanent is "permanent"?] > [CB] I've removed "permanent" as it is not really needed. The BCE stays at the CMD until the session is de-registered (it is "more permanent" that the BCEs at the P-MAARs). > > Section 3.2 > > 1. When the MN moves from its current point of attachment and > attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6 > prefix (Pref2), it stores a temporary BCE, and it sends a plain > PBU to the CMD for registration. > > It's not clear to me at this point how MAAR2 has enough information to > determine that this will be a "plain" PBU vs. the the PBU used for > initial registration. (That said, it's also not clear to me that the > send PBU actually differs on the wire, so maybe this is just a > rhetorical question. Er, a question of rhetoric, that is.) > [CB] They are actually the same PBUs, as MAAR2 does not know at that point if the MN had been already registered. Both PBUs would be "plain". I've removed "plain" and "another" to make it clearer. > > 4. The CMD, after receiving the PBA, updates the BCE populating an > instance of the P-MAAR list. The P-MAAR list is an additional > field on the BCE that contains an element for each P-MAAR > involved in the MN's mobility session. The list element contains > the P-MAAR's global address and the prefix it has delegated (see > Appendix B for further details). Also, the CMD sends a PBA to > the new S-MAAR, containing the previous Proxy-CoA and the prefix > anchored to it embedded into a new mobility option called > Previous MAAR Option (defined in Section 4.5), so that, upon PBA > arrival, a bi-directional tunnel can be established between the > two MAARs and new routes are set appropriately to recover the IP > flow(s) carrying Pref1. > > To check my understanding: there will only be one Previous MAAR Option > present and it will describe only a single MAAR, which implies that if > there are multiple P-MAARs, traffic directed to an arbitrary prefix > based at one of them is expected to traverse multiple tunnels from > P-MAAR to P-MAAR before making its way to the S-MAAR and the MN? > [Hmm, looks like my understanding is wrong. I'd consider making > "previous Proxy-CoA" and "the prefix anchored to it" plural to give the > reader a hint as to what's coming, though I can understand if there is > desire to keep the initial mobility example simple and only gradually > introduce the complexity in question.] > [CB] I've been looking at it and changing it back and forth several times. I prefer to keep the initial mobility example. Just to answer your question, in general there might be multiple options. This is what the text you point below should indicate (among other things). > For MN's next movements the process is repeated except the number of > P-MAARs involved increases (accordingly to the number of prefixes > that the MN wishes to maintain). Indeed, once the CMD receives the > first PBU from the new S-MAAR, it forwards copies of the PBU to all > the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR > prior to handover) and in the P-MAARs list. They reply with a PBA to > the CMD, which aggregates them into a single one to notify the > S-MAAR, that finally can establish the tunnels with the P-MAARs. > > I'm not sure I understand the cardinality of P-CoA -- is it one, > the single S-MAAR prior to handover, or many, all P-MAARs in the list? > [CB] There are multiple P-CoAs, but current writing might lead to think there is only one. One P-CoA is the one listed in the BCE (the one of the previously visited MAAR) plus the P-CoAs listed in the P-MAAR list. I've rewritten a bit the text trying to make this clearer: "Indeed, once the CMD receives the first PBU from the new S-MAAR, it forwards copies of the PBU to all the P-MAARs indicated in the BCE, namely the one registered as current P-CoA (i.e., the MAAR prior to handover) plus the ones in the P-MAARs list." > When there are multiple previous MAARs, e.g., k MAARs, a single PBU > received by the CMD triggers k outgoing packets from a single > incoming packet. This may lead to packet bursts originated from the > CMD, albeit to different targets. Pacing mechanisms MAY be > introduced to avoid bursts on the outgoing link. > > I'll defer to my TSV colleagues, but a "SHOULD" feels more comfortable > than "MAY" to me, here. > [CB] Actually, based on other comments we have decided to go for "MUST". > Section 3.3 > > The handover latency experienced in the approach shown before can be > reduced if the P-MAARs are allowed to signal directly their > information to the new S-MAAR. This procedure reflects what was > described in Section 3.2 up to the moment the P-MAAR receives the PBU > with the P-MAAR option. At that point a P-MAAR is aware of the new > > nit(?): I think this is the S-MAAR option, not the P-MAAR option? > [CB] Right! Thanks. > > S-MAAR including the prefix it is anchoring. This latter PBA does > not need to include new options, as the prefix is embedded in the HNP > option and the P-MAAR's address is taken from the message's source > address. The CMD is relieved from forwarding the PBA to the S-MAAR, > > (side note: this assumes there's no NAT or tunneling or similar between > MAARs, which seems like a plausible assumption, at least for now.) > [CB] Yes, that's right. > > Section 3.4 > > side. When P-MAARs complete the update, they send a PBA to the CMD > to indicate that the operation is concluded and the information is > updated in all network nodes. This procedure is obtained from the > > Is there anything useful to say about behavior on timeout at the CMD > (failing to reive a PBA from one or more P-MAARs)? > > [CB] A new Section 3.6 "Retransmissions and Rate Limiting" has been added (to address also other received comments). I hope this addresses this comment. > Section 3.5 > > The de-registration mechanism devised for PMIPv6 cannot be used as is > in this solution. The reason for this is that each MAAR handles an > > nit: s/as is/as-is/ > [CB] Fixed, thanks. > > Indeed, when a previous MAAR initiates a de-registration procedure, > because the MN is no longer present on the MAAR's access link, it > removes the routing state for that (those) prefix(es), that would be > deleted by the CMD as well, hence defeating any prefix continuity > attempt. The simplest approach to overcome this limitation is to > > nit(?): s/when/if/. At least, this makes more sense to me if I do that > ... maybe I'm just confused. > [CB] OK, fixed. > > serving MAAR to de-register the whole MN session. This can be > achieved by first removing any layer-2 detachment event, so that de- > registration is triggered only when the session lifetime expires, > > I see that RFC 5213 has some mechanisms for lifetime management, but > didn't get to look closely enough to understand how clear the necessary > lifetime management will be in the DMM case when there are multiple > prefixes registered to a given MN at different MAARs. (Also, 5213 > doesn't seem to use the "session lifetime" phrase verbatim.) > [CB] I've replaced "session lifetime" with "binding lifetime" to make it more consistent with the terminology used in RFC 5213. Note that "mobility session" is used in RFC 5213. > > Section 3.6 > > requiring special support from the mobile node's IP stack. This > document defines the Distributed Logical Interface (DLIF), which is a > software construct that allows to easily hide the change of > associated anchors from the mobile node. > > A software construct in the MAAR, right? > [CB] Yes, I've added "in the MAAR" to the text. > > > How common is "HMAC" as an abbreviation for "hardware MAC address"? > It's also an abbreviation for Hash-based Message Authentication Code, > which confuses my poor security-focused brain, though I acknowledge that > this does not necessarily extend to most of the target audience for this > document... > [CB] It is not common. To avoid potential confusions I've removed HMAC and just used MAC, which I think it is sufficient in the scope of this document (as we use LMAC for the logical one). > and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two > P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the > > Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)? > [CB] You are right. Here there was a mistake, as P-MAAR was being mixed with anchoring MAAR. I've removed that sentence to keep it clearer. > role of anchoring MAAR for the attached (served) MNs. Each MAAR has > one single physical wireless interface. > > Have we defined "anchoring MAAR" yet? > [CB] We have added a definition to the terminology section. > Also, I assume that the "single physical interface" is just "as depicted > in this example" and not a protocol requirement :) > [CB] Yes, right. > > As introduced before, each MN always "sees" multiple logical routers > -- one per P-MAAR -- independently of its currently serving MAAR. > > [same P-MAAR vs. S-MAAR split as above] > [CB] Right, fixed by replacing P-MAAR with anchoring MAAR. > > by the serving MAAR (MAAR2) configuring an additional distributed > logical interface: mn1mar1, which behaves exactly as the logical > interface configured by MAAR1 when MN1 was attached to it. This > > nit(?): "exactly" is asking for pedants to try and poke holes in the > claimed perfection. > [CB] Right, I removed "exactly". > > deprecated). The goal is to deprecate the prefixes delegated by > these MAARs (which will be no longer serving the MN). Note that on- > > nit(?): s/which will be no longer/so that they will no longer be/, IIUC > [CB] Fixed. > > Section 4.1 > > The intdir reviewer's comments regarding the flag bits seem apropos (I > presume they were allocated by other extensions to 5213, but we should > say something about it). > [CB] OK, I'll address this in my response to the intdir review. > > > A new flag (D) is included in the Proxy Binding Update to indicate > that the Proxy Binding Update is coming from a Mobility Anchor and > > "D" is for "DMM", I trust? It could be worth mentioning. [CB] Yes, done. > > Is the D bit set for the PBUs sent from CMD to P-MAAR as well? > [CB] Yes, I've fixed that. > (I see that the PBA description uses a slightly different formulation to > cover the 'D' bit; is there a reason to diverge?) > [CB] No reason. I've updated the text to use the same formulation. > > Mobility Options > > Variable-length field of such length that the complete Mobility > Header is an integer multiple of 8 octets long. This field > contains zero or more TLV-encoded mobility options. The encoding > and format of defined options are described in Section 6.2 of > [RFC6275]. The MAAR MUST ignore and skip any options that it does > not understand. > > MAARs that *receive* PBUs must be P-MAARs, right? > [CB] Yes, but also a CMD. Therefore I've replaced "MAAR" with "receiving node". > Section 4.2 > > MAAR (D) > > The D is set to indicate that the sender of the message supports > operating as a Mobility Anchor and Access Router. When a MAG that > does not support the extensions described in this document > receives a message with the D-Flag set, it MUST ignore the message > and an error MUST be returned. > > Is the CMD considered a MAAR for this purpose? > [CB] I've replaced "operating as a Mobility Anchor and Access Router" with "operating as a MAAR or a CMD". > contains zero or more TLV-encoded mobility options. The encoding > and format of defined options are described in Section 6.2 of > [RFC6275]. The MAAR MUST ignore and skip any options that it does > not understand. > > What about the CMD? > [CB] Same.. Therefore I've replaced "MAAR" with "receiving node". > > Section 4.3, 4.4 > > Prefix Length > > 8-bit unsigned integer indicating the prefix length of the IPv6 > prefix contained in the option. > > Anchored Prefix > > A sixteen-byte field containing the mobile node's IPv6 Anchored > Prefix. Only the first Prefix Length bytes are valid for the > Anchored Prefix. The rest of the bytes MUST be ignored. > > Is the prefix length bits or bytes? > [CB] Bits. Fixed (also mentioned by another review). > > Section 4.4 > > Is this also used to convey "local" prefixes in the PBA from CMD to > S-MAAR? (If not, how does the S-MAAR know to advertise them from its > DLIF?) > [CB] Yes, this is right. I've rewritten the text to reflect it. > > Section 4.5 > > What's the alignment requirement? > (There's no need to put in a Reserved octet to keep things word > aligned?) > [CB] You are right. And this is embarrassing, as the internal code we use is actually using the format with the extra reserved byte that was not reflected in the document. > Prefix Length > > 8-bit unsigned integer indicating the prefix length of the IPv6 > prefix contained in the option. > [...] > Home Network Prefix > > A sixteen-byte field containing the mobile node's IPv6 Home > Network Prefix. Only the first Prefix Length bytes are valid for > the mobile node's IPv6 Home Network Prefix. The rest of the bytes > MUST be ignored. > > [is the prefix length bits or bytes?] > [CB] Bits. Fixed. > > Section 4.6 > > Is there an alignment requirement for this option? > [CB] Yes, added. > > This new option is defined for use with the Proxy Binding Update and > Proxy Binding Acknowledgement messages exchanged between the CMD and > > When is this option used in a PBA? > [CB] Right, it is only used in a PBU. Fixed. > > Section 4.7 > > A new DLIF Link-local Address option is defined for use with the > Proxy Binding Update and Proxy Binding Acknowledgment messages > exchanged between MAARs. This option is used for exchanging the > > MAARs but not CMDs? > When is this used in the PBU? > [CB] Also CMDs. And only in PBA. Fixed. > > Section 4.8 > > A new DLIF Link-layer Address option is defined for use with the > Proxy Binding Update and Proxy Binding Acknowledgment messages > exchanged between MAARs. This option is used for exchanging the > > MAARs but not CMDs? > When is this used in the PBU? > [CB] Same as before. > > Section 6 > > Unfortunately it seems that RFC 5213 does not include any privacy > considerations discussion. While the privacy properties of this > protocol bear similarities to those of RFC 5213, it seems that there are > also some significant differences, so I do think it is important to > produce some documentation of privacy considerations for this document. > The main factor would, of cousre, be tracking which entities obtain > updates/information about the location of the MN, what those entities > are expected to do with that data, and how trusted they are to be proper > custodians of it. Other factors may exist as well, including the > potential for side-channel information leakage, e.g., due to traffic > analysis. There might also be a reverse situation where exposing the > link-layer address(es) of a P-MAAR have privacy considerations, though I > don't have anything particular in mind at the moment. > [CB] OK, I see your point. I've tried to add something in version -06. Let me know if you think it is sufficient (I tried to keep it short and simple, while still addressing your point). > > security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended > that the signaling messages, Proxy Binding Update and Proxy Binding > Acknowledgment, exchanged between the MAARs are protected using IPsec > using the established security association between them. This > > This is essentially unchanged from 5213, just with different names for > the endpoints, right, and so the existing guidance/experiences apply? > [CB] Yes, it should apply. We haven't identified anything different. > > I think we should also say something about all MAARs and the CMD being > trusted parties. We should also say something about the authorization > model (I assume it's just "all trusted parties are trusted to perform > all operations relevant to their role", but that's still useful to say). > [CB] OK, I've added a sentence on that. > > When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a > single PBU to multiple previous MAARs. In situations of many fast > handovers (e.g., with vehicular networks), there may exist multiple > previous (e.g., k) MAARs exist. In this situation, the CMD creates k > > nit: remove the redundant "exist" > [CB] Done. > > When the CMD acts as MAAR locator, mobility signaling (PBAs) is > exchanged between P-MAARs and current S-MAAR. This requires security > associations to exist between the involved MAARs (in addition to the > ones needed with the CMD). > > Is this relevant because of scaling/resource-consumption concerns or > keying/trust ones? > [CB] This is relevant because RFC 5213 uses a model in which signalling is exchanged only between LMA (the anchor) and MAGs (the access routers), while in this document there are some operation modes that also involve signalling between MAARs (the access routers). This was just to highlight this point (it is related to the point you made before about the trust model). > > Appendix A.5 > > not implement existing mobility protocols. Furthermore, a DMM > solution SHOULD work across different networks, possibly operated as > separate administrative domains, when the needed mobility management > > Hmm, separate administrative domains makes the risk of NAT relatively > higher (per previous comment about NAT). > > intervention. The partially distributed DMM solution can be deployed > across different domains with trust agreements if the CMDs of the > operators are enabled to transfer context from one node to another. > > It would probably be worth expounding a bit more about this scenario and > the necessary trust/authorization relationships, in the security > considerations. > > [CB] As per other comment from IESG evaluation I've removed the two appendixes. Huge thanks for your very good points! Carlos --00000000000066c5d805a05ba2f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin,

Thanks a = lot for another very good review. Please find my comments inline below.

On Thu, Mar 5, 2020 at 6:22 AM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered the= following ballot position for
draft-ietf-dmm-pmipv6-dlif-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-dmm-pmipv6-dlif/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a very boring Discuss point and a somewhat boring point, and
expect to change my ballot to Yes once they're resolved.

In Section 3.2 we say that pacing mechanisms "MAY" be used to avo= id
bursts when the CMD is fanning out PBUs, but in Section 6 we say that
pacing "SHOULD" be used; please resolve the inconsistency (prefer= rably
with "MUST" as Mirja requests).

[CB] Done in version -06 (to be submitted soon).
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Please also include some discussion of privacy considerations (I give
some suggestions in the COMMENT).

[CB] = OK, I'll do.
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this well-written document!=C2=A0 It is clearly written, and whe= n
multiple approaches exist, does well at laying out the different options and their pros/cons, as befits an Experimental document.=C2=A0 Also, severa= l
times I have started to write a comment only to realize that it is
answered by the following text :)

[CB] = Thanks, very much appreciated.
=C2=A0

Section 1

=C2=A0 =C2=A0The Distributed Mobility Management (DMM) paradigm aims at min= imizing
=C2=A0 =C2=A0the impact of currently standardized mobility management solut= ions
=C2=A0 =C2=A0which are centralized (at least to a considerable extent).

I'd consider saying a little more about which aspects of their operatio= n
are centralized.=C2=A0 Perhaps the following paragraph suffices, though.

[CB] I've added another reference to = RFC 7333, where this is explained in detail. As you mention below, we go a = bit into these aspects of centralized operation in the following paragraph,= and I personally believe it is better not to add too much text on this asp= ect (which is covered by RFC 7333). Please, let me know if you are not happ= y with this resolution.
=C2=A0

=C2=A0 =C2=A0Following this idea, in our proposal, the central anchor is mo= ved to
=C2=A0 =C2=A0the edge of the network, being deployed in the default gateway= of the
=C2=A0 =C2=A0mobile node.=C2=A0 That is, the first elements that provide IP=

(side note: Using the singular "central anchor" poses an interest= ing
rhetorical question: is the (formerly) single central anchor being
duplicated and spread amongst all access routers, or does there remain a single central anchor (per MN), just one that moves around along with
the MN.)

[CB] The whole idea of the DMM= approach specified in this document is that we move from a "single ce= ntral anchor" to a "multiple distributed anchors". Note that= the specified approach allows for a central anchor to be still present (an= d used by an MN for communications where it is more appropriate), but this = is more an operational decision (probably more in scope of RFC 8653).
=
=C2=A0

=C2=A0 =C2=A0anchors to retrieve the MN's previous location(s).=C2=A0 A= lso, a key-
=C2=A0 =C2=A0aspect of network-based DMM, is that a prefix pool belongs
=C2=A0 =C2=A0exclusively to each MAAR, in the sense that those prefixes are=
=C2=A0 =C2=A0assigned by the MAAR to the MNs attached to it, and they are r= outable
=C2=A0 =C2=A0at that MAAR.

It might be worth some statement relating this "ownership" of pre= fixes
to actual mobility events -- e.g., they are assigned to MNs attached to
it at that time, but remain with those MNs as mobility occurs, but
always remain routable at that MAAR as well as towards the MN itself.

[CB] OK, I've added a sentence adopting part of y= our text. Thanks.
=C2=A0
=C2=A0 =C2=A0We consider partially distributed schemes, where the data plan= e only
=C2=A0 =C2=A0is distributed among access routers similar to MAGs, whereas t= he

nit: I suggest s/the data plane only/only the data plane/
<= div>
[CB] OK, thanks.
=C2=A0

=C2=A0 =C2=A0control plane is kept centralized towards a cardinal node used= as
=C2=A0 =C2=A0information store, but relieved from any route management and = MN's
=C2=A0 =C2=A0data forwarding task.

What's the scope of "single" here -- per deployment, per pref= ix, per
MAAR, ...?

[CB] Sorry, I don't get = this comment. I don't see "single" mentioned in the quoted te= xtl
=C2=A0

=C2=A0 =C2=A0P-MAAR (Previous MAAR).=C2=A0 When a MN moves to a new point o= f attachment
=C2=A0 =C2=A0 =C2=A0 a new MAAR might be allocated as its anchor point for = future IPv6
=C2=A0 =C2=A0 =C2=A0 prefixes.=C2=A0 The MAAR that served the MN prior to n= ew attachment
=C2=A0 =C2=A0 =C2=A0 becomes the P-MAAR.=C2=A0 It is still the anchor point= for the IPv6
=C2=A0 =C2=A0 =C2=A0 prefixes it had allocated to the MN in the past and se= rves as the

(side note? Do we expect those previous allocations to eventually "tim= e
out" as sessions using them terminate?=C2=A0 Or are the allocations mo= re
permanent, with intent to reuse if/when the MN returns to that MAAR?)

[CB] The expectation is that previous alloca= tions will eventually time-out as sessions using them terminate.
= =C2=A0

Section 3

=C2=A0 =C2=A0interest and eventually take the appropriate action.=C2=A0 The= procedure
=C2=A0 =C2=A0adopted for the query and the messages exchange sequence might= vary
=C2=A0 =C2=A0to optimize the update latency and/or the signaling overhead.= =C2=A0 Here

nit: wrong pluralization in "messages exchange sequence"

[CB] OK, fixed.
=C2=A0

Section 3.1

=C2=A0 =C2=A03.=C2=A0 Since this is an initial registration, the CMD stores= a permanent
=C2=A0 =C2=A0 =C2=A0 =C2=A0BCE containing as primary fields the MN-ID, Pref= 1 and MAAR1's
=C2=A0 =C2=A0 =C2=A0 =C2=A0address as a Proxy-CoA.

[how permanent is "permanent"?]

[CB] I've removed "permanent" as it is not really needed. = The BCE stays at the CMD until the session is de-registered (it is "mo= re permanent" that the BCEs at the P-MAARs).
=C2=A0

Section 3.2

=C2=A0 =C2=A01.=C2=A0 When the MN moves from its current point of attachmen= t and
=C2=A0 =C2=A0 =C2=A0 =C2=A0attaches to MAAR2 (now the S-MAAR), MAAR2 reserv= es another IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix (Pref2), it stores a temporary BCE, and i= t sends a plain
=C2=A0 =C2=A0 =C2=A0 =C2=A0PBU to the CMD for registration.

It's not clear to me at this point how MAAR2 has enough information to<= br> determine that this will be a "plain" PBU vs. the the PBU used fo= r
initial registration.=C2=A0 (That said, it's also not clear to me that = the
send PBU actually differs on the wire, so maybe this is just a
rhetorical question.=C2=A0 Er, a question of rhetoric, that is.)

[CB] They are actually the same PBUs, as MAAR2 do= es not know at that point if the MN had been already registered. Both PBUs = would be "plain". I've removed "plain" and "an= other" to make it clearer.
=C2=A0

=C2=A0 =C2=A04.=C2=A0 The CMD, after receiving the PBA, updates the BCE pop= ulating an
=C2=A0 =C2=A0 =C2=A0 =C2=A0instance of the P-MAAR list.=C2=A0 The P-MAAR li= st is an additional
=C2=A0 =C2=A0 =C2=A0 =C2=A0field on the BCE that contains an element for ea= ch P-MAAR
=C2=A0 =C2=A0 =C2=A0 =C2=A0involved in the MN's mobility session.=C2=A0= The list element contains
=C2=A0 =C2=A0 =C2=A0 =C2=A0the P-MAAR's global address and the prefix i= t has delegated (see
=C2=A0 =C2=A0 =C2=A0 =C2=A0Appendix B for further details).=C2=A0 Also, the= CMD sends a PBA to
=C2=A0 =C2=A0 =C2=A0 =C2=A0the new S-MAAR, containing the previous Proxy-Co= A and the prefix
=C2=A0 =C2=A0 =C2=A0 =C2=A0anchored to it embedded into a new mobility opti= on called
=C2=A0 =C2=A0 =C2=A0 =C2=A0Previous MAAR Option (defined in Section 4.5), s= o that, upon PBA
=C2=A0 =C2=A0 =C2=A0 =C2=A0arrival, a bi-directional tunnel can be establis= hed between the
=C2=A0 =C2=A0 =C2=A0 =C2=A0two MAARs and new routes are set appropriately t= o recover the IP
=C2=A0 =C2=A0 =C2=A0 =C2=A0flow(s) carrying Pref1.

To check my understanding: there will only be one Previous MAAR Option
present and it will describe only a single MAAR, which implies that if
there are multiple P-MAARs, traffic directed to an arbitrary prefix
based at one of them is expected to traverse multiple tunnels from
P-MAAR to P-MAAR before making its way to the S-MAAR and the MN?
[Hmm, looks like my understanding is wrong.=C2=A0 I'd consider making "previous Proxy-CoA" and "the prefix anchored to it" pl= ural to give the
reader a hint as to what's coming, though I can understand if there is<= br> desire to keep the initial mobility example simple and only gradually
introduce the complexity in question.]

= [CB] I've been looking at it and changing it back and forth several tim= es. I prefer to keep the initial mobility example. Just to answer your ques= tion, in general there might be multiple options. This is what the text you= point below should indicate (among other things).


=C2=A0 =C2=A0For MN's next movements the process is repeated except the= number of
=C2=A0 =C2=A0P-MAARs involved increases (accordingly to the number of prefi= xes
=C2=A0 =C2=A0that the MN wishes to maintain).=C2=A0 Indeed, once the CMD re= ceives the
=C2=A0 =C2=A0first PBU from the new S-MAAR, it forwards copies of the PBU t= o all
=C2=A0 =C2=A0the P-MAARs indicated in the BCE as current P-CoA (i.e., the M= AAR
=C2=A0 =C2=A0prior to handover) and in the P-MAARs list.=C2=A0 They reply w= ith a PBA to
=C2=A0 =C2=A0the CMD, which aggregates them into a single one to notify the=
=C2=A0 =C2=A0S-MAAR, that finally can establish the tunnels with the P-MAAR= s.

I'm not sure I understand the cardinality of P-CoA -- is it one,
the single S-MAAR prior to handover, or many, all P-MAARs in the list?
<= /blockquote>

[CB] There are multiple P-CoAs, but current= writing might lead to think there is only one. One P-CoA is the one listed= in the BCE (the one of the previously visited MAAR) plus the P-CoAs listed= in the P-MAAR list. I've rewritten a bit the text trying to make this = clearer: "Indeed, once the CMD receives the first PBU from the new S-M= AAR, it forwards copies of the PBU to all the P-MAARs indicated in the BCE,= namely the one registered as current P-CoA (i.e., the MAAR prior to handov= er) plus the ones in the P-MAARs list."


=C2=A0 =C2=A0When there are multiple previous MAARs, e.g., k MAARs, a singl= e PBU
=C2=A0 =C2=A0received by the CMD triggers k outgoing packets from a single<= br> =C2=A0 =C2=A0incoming packet.=C2=A0 This may lead to packet bursts originat= ed from the
=C2=A0 =C2=A0CMD, albeit to different targets.=C2=A0 Pacing mechanisms MAY = be
=C2=A0 =C2=A0introduced to avoid bursts on the outgoing link.

I'll defer to my TSV colleagues, but a "SHOULD" feels more co= mfortable
than "MAY" to me, here.

[CB] = Actually, based on other comments we have decided to go for "MUST"= ;.


Section 3.3

=C2=A0 =C2=A0The handover latency experienced in the approach shown before = can be
=C2=A0 =C2=A0reduced if the P-MAARs are allowed to signal directly their =C2=A0 =C2=A0information to the new S-MAAR.=C2=A0 This procedure reflects w= hat was
=C2=A0 =C2=A0described in Section 3.2 up to the moment the P-MAAR receives = the PBU
=C2=A0 =C2=A0with the P-MAAR option.=C2=A0 At that point a P-MAAR is aware = of the new

nit(?): I think this is the S-MAAR option, not the P-MAAR option?

[CB] Right! Thanks.
=C2=A0

=C2=A0 =C2=A0S-MAAR including the prefix it is anchoring.=C2=A0 This latter= PBA does
=C2=A0 =C2=A0not need to include new options, as the prefix is embedded in = the HNP
=C2=A0 =C2=A0option and the P-MAAR's address is taken from the message&= #39;s source
=C2=A0 =C2=A0address.=C2=A0 The CMD is relieved from forwarding the PBA to = the S-MAAR,

(side note: this assumes there's no NAT or tunneling or similar between=
MAARs, which seems like a plausible assumption, at least for now.)

[CB] Yes, that's right.
=C2=A0

Section 3.4

=C2=A0 =C2=A0side.=C2=A0 When P-MAARs complete the update, they send a PBA = to the CMD
=C2=A0 =C2=A0to indicate that the operation is concluded and the informatio= n is
=C2=A0 =C2=A0updated in all network nodes.=C2=A0 This procedure is obtained= from the

Is there anything useful to say about behavior on timeout at the CMD
(failing to reive a PBA from one or more P-MAARs)?

[CB] A new Section 3.6 "Retransmissions and Rate= Limiting" has been added (to address also other received comments). I= hope this addresses this comment.
=C2=A0
Section 3.5

=C2=A0 =C2=A0The de-registration mechanism devised for PMIPv6 cannot be use= d as is
=C2=A0 =C2=A0in this solution.=C2=A0 The reason for this is that each MAAR = handles an

nit: s/as is/as-is/

[CB] Fixed, thanks.=
=C2=A0

=C2=A0 =C2=A0Indeed, when a previous MAAR initiates a de-registration proce= dure,
=C2=A0 =C2=A0because the MN is no longer present on the MAAR's access l= ink, it
=C2=A0 =C2=A0removes the routing state for that (those) prefix(es), that wo= uld be
=C2=A0 =C2=A0deleted by the CMD as well, hence defeating any prefix continu= ity
=C2=A0 =C2=A0attempt.=C2=A0 The simplest approach to overcome this limitati= on is to

nit(?): s/when/if/.=C2=A0 At least, this makes more sense to me if I do tha= t
... maybe I'm just confused.

[CB] O= K, fixed.
=C2=A0

=C2=A0 =C2=A0serving MAAR to de-register the whole MN session.=C2=A0 This c= an be
=C2=A0 =C2=A0achieved by first removing any layer-2 detachment event, so th= at de-
=C2=A0 =C2=A0registration is triggered only when the session lifetime expir= es,

I see that RFC 5213 has some mechanisms for lifetime management, but
didn't get to look closely enough to understand how clear the necessary=
lifetime management will be in the DMM case when there are multiple
prefixes registered to a given MN at different MAARs.=C2=A0 (Also, 5213
doesn't seem to use the "session lifetime" phrase verbatim.)<= br>

[CB] I've replaced "session li= fetime" with "binding lifetime" to make it more consistent w= ith the terminology used in RFC 5213. Note that "mobility session"= ; is used in RFC 5213.
=C2=A0

Section 3.6

=C2=A0 =C2=A0requiring special support from the mobile node's IP stack.= =C2=A0 This
=C2=A0 =C2=A0document defines the Distributed Logical Interface (DLIF), whi= ch is a
=C2=A0 =C2=A0software construct that allows to easily hide the change of =C2=A0 =C2=A0associated anchors from the mobile node.

A software construct in the MAAR, right?

[CB] Yes, I've added "in the MAAR" to the text.
= =C2=A0


How common is "HMAC" as an abbreviation for "hardware MAC ad= dress"?
It's also an abbreviation for Hash-based Message Authentication Code, which confuses my poor security-focused brain, though I acknowledge that this does not necessarily extend to most of the target audience for this document...

[CB] It is not common. To a= void potential confusions I've removed HMAC and just used MAC, which I = think it is sufficient in the scope of this document (as we use LMAC for th= e logical one).=C2=A0


=C2=A0 =C2=A0and MN3, while MAAR2 is serving MN1.=C2=A0 MN1, MN2 and MN3 ha= ve two
=C2=A0 =C2=A0P-MAARs: MAAR1 and MAAR2.=C2=A0 Note that a serving MAAR alway= s plays the

Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)?

[CB] You are right. Here there was a mistake, as P-= MAAR was being mixed with anchoring MAAR. I've removed that sentence to= keep it clearer.


=C2=A0 =C2=A0role of anchoring MAAR for the attached (served) MNs.=C2=A0 Ea= ch MAAR has
=C2=A0 =C2=A0one single physical wireless interface.

Have we defined "anchoring MAAR" yet?

[CB] We have added a definition to the terminology section.
<= div>=C2=A0
Also, I assume that the "single physical interface" is just "= ;as depicted
in this example" and not a protocol requirement :)

[CB] Yes, right.
=C2=A0

=C2=A0 =C2=A0As introduced before, each MN always "sees" multiple= logical routers
=C2=A0 =C2=A0-- one per P-MAAR -- independently of its currently serving MA= AR.

[same P-MAAR vs. S-MAAR split as above]

[CB] Right, fixed by replacing P-MAAR with anchoring MAAR.

<= /div>
=C2=A0

=C2=A0 =C2=A0by the serving MAAR (MAAR2) configuring an additional distribu= ted
=C2=A0 =C2=A0logical interface: mn1mar1, which behaves exactly as the logic= al
=C2=A0 =C2=A0interface configured by MAAR1 when MN1 was attached to it.=C2= =A0 This

nit(?): "exactly" is asking for pedants to try and poke holes in = the
claimed perfection.

[CB] Right, I remov= ed "exactly".
=C2=A0

=C2=A0 =C2=A0deprecated).=C2=A0 The goal is to deprecate the prefixes deleg= ated by
=C2=A0 =C2=A0these MAARs (which will be no longer serving the MN).=C2=A0 No= te that on-

nit(?): s/which will be no longer/so that they will no longer be/, IIUC
=

[CB] Fixed.
=C2=A0

Section 4.1

The intdir reviewer's comments regarding the flag bits seem apropos (I<= br> presume they were allocated by other extensions to 5213, but we should
say something about it).

[CB] OK, I'= ;ll address this in my response to the intdir review.
=C2=A0


=C2=A0 =C2=A0A new flag (D) is included in the Proxy Binding Update to indi= cate
=C2=A0 =C2=A0that the Proxy Binding Update is coming from a Mobility Anchor= and

"D" is for "DMM", I trust?=C2=A0 It could be worth ment= ioning.

[CB] Yes, done.
=C2=A0
=C2=A0

Is the D bit set for the PBUs sent from CMD to P-MAAR as well?

[CB] Yes, I've fixed that.
=C2=A0
(I see that the PBA description uses a slightly different formulation to cover the 'D' bit; is there a reason to diverge?)
<= div>
[CB] No reason. I've updated the text to use the sam= e formulation.
=C2=A0

=C2=A0 =C2=A0Mobility Options

=C2=A0 =C2=A0 =C2=A0 Variable-length field of such length that the complete= Mobility
=C2=A0 =C2=A0 =C2=A0 Header is an integer multiple of 8 octets long.=C2=A0 = This field
=C2=A0 =C2=A0 =C2=A0 contains zero or more TLV-encoded mobility options.=C2= =A0 The encoding
=C2=A0 =C2=A0 =C2=A0 and format of defined options are described in Section= 6.2 of
=C2=A0 =C2=A0 =C2=A0 [RFC6275].=C2=A0 The MAAR MUST ignore and skip any opt= ions that it does
=C2=A0 =C2=A0 =C2=A0 not understand.

MAARs that *receive* PBUs must be P-MAARs, right?

=
[CB] Yes, but also a CMD. Therefore I've replaced "MAAR= " with "receiving node".


Section 4.2

=C2=A0 =C2=A0MAAR (D)

=C2=A0 =C2=A0 =C2=A0 The D is set to indicate that the sender of the messag= e supports
=C2=A0 =C2=A0 =C2=A0 operating as a Mobility Anchor and Access Router.=C2= =A0 When a MAG that
=C2=A0 =C2=A0 =C2=A0 does not support the extensions described in this docu= ment
=C2=A0 =C2=A0 =C2=A0 receives a message with the D-Flag set, it MUST ignore= the message
=C2=A0 =C2=A0 =C2=A0 and an error MUST be returned.

Is the CMD considered a MAAR for this purpose?

[CB] I've replaced "operating as a Mobility Anchor and Acc= ess Router" with "operating as a MAAR or a CMD".
<= br>

=C2=A0 =C2=A0 =C2=A0 contains zero or more TLV-encoded mobility options.=C2= =A0 The encoding
=C2=A0 =C2=A0 =C2=A0 and format of defined options are described in Section= 6.2 of
=C2=A0 =C2=A0 =C2=A0 [RFC6275].=C2=A0 The MAAR MUST ignore and skip any opt= ions that it does
=C2=A0 =C2=A0 =C2=A0 not understand.

What about the CMD?

[CB] Same.. Therefo= re I've replaced "MAAR" with "receiving node".
<= /div>
=C2=A0

Section 4.3, 4.4

=C2=A0 =C2=A0Prefix Length

=C2=A0 =C2=A0 =C2=A0 8-bit unsigned integer indicating the prefix length of= the IPv6
=C2=A0 =C2=A0 =C2=A0 prefix contained in the option.

=C2=A0 =C2=A0Anchored Prefix

=C2=A0 =C2=A0 =C2=A0 A sixteen-byte field containing the mobile node's = IPv6 Anchored
=C2=A0 =C2=A0 =C2=A0 Prefix.=C2=A0 Only the first Prefix Length bytes are v= alid for the
=C2=A0 =C2=A0 =C2=A0 Anchored Prefix.=C2=A0 The rest of the bytes MUST be i= gnored.

Is the prefix length bits or bytes?

[CB= ] Bits. Fixed (also mentioned by another review).
=C2=A0

Section 4.4

Is this also used to convey "local" prefixes in the PBA from CMD = to
S-MAAR?=C2=A0 (If not, how does the S-MAAR know to advertise them from its<= br> DLIF?)

[CB] Yes, this is right. I'v= e rewritten the text to reflect it.

Section 4.5

What's the alignment requirement?
(There's no need to put in a Reserved octet to keep things word
aligned?)

[CB] You are right. And this = is embarrassing, as the internal code we use is actually using the format w= ith the extra reserved byte that was not reflected in the document.


=C2=A0 =C2=A0Prefix Length

=C2=A0 =C2=A0 =C2=A0 8-bit unsigned integer indicating the prefix length of= the IPv6
=C2=A0 =C2=A0 =C2=A0 prefix contained in the option.
=C2=A0 =C2=A0[...]
=C2=A0 =C2=A0Home Network Prefix

=C2=A0 =C2=A0 =C2=A0 A sixteen-byte field containing the mobile node's = IPv6 Home
=C2=A0 =C2=A0 =C2=A0 Network Prefix.=C2=A0 Only the first Prefix Length byt= es are valid for
=C2=A0 =C2=A0 =C2=A0 the mobile node's IPv6 Home Network Prefix.=C2=A0 = The rest of the bytes
=C2=A0 =C2=A0 =C2=A0 MUST be ignored.

[is the prefix length bits or bytes?]

[= CB] Bits. Fixed.
=C2=A0

Section 4.6

Is there an alignment requirement for this option?
[CB] Yes, added.
=C2=A0

=C2=A0 =C2=A0This new option is defined for use with the Proxy Binding Upda= te and
=C2=A0 =C2=A0Proxy Binding Acknowledgement messages exchanged between the C= MD and

When is this option used in a PBA?

[CB]= Right, it is only used in a PBU. Fixed.
=C2=A0

Section 4.7

=C2=A0 =C2=A0A new DLIF Link-local Address option is defined for use with t= he
=C2=A0 =C2=A0Proxy Binding Update and Proxy Binding Acknowledgment messages=
=C2=A0 =C2=A0exchanged between MAARs.=C2=A0 This option is used for exchang= ing the

MAARs but not CMDs?
When is this used in the PBU?

[CB] Also= CMDs. And only in PBA. Fixed.
=C2=A0

Section 4.8

=C2=A0 =C2=A0A new DLIF Link-layer Address option is defined for use with t= he
=C2=A0 =C2=A0Proxy Binding Update and Proxy Binding Acknowledgment messages=
=C2=A0 =C2=A0exchanged between MAARs.=C2=A0 This option is used for exchang= ing the

MAARs but not CMDs?
When is this used in the PBU?

[CB] Same= as before.
=C2=A0

Section 6

Unfortunately it seems that RFC 5213 does not include any privacy
considerations discussion.=C2=A0 While the privacy properties of this
protocol bear similarities to those of RFC 5213, it seems that there are also some significant differences, so I do think it is important to
produce some documentation of privacy considerations for this document.
The main factor would, of cousre, be tracking which entities obtain
updates/information about the location of the MN, what those entities
are expected to do with that data, and how trusted they are to be proper custodians of it.=C2=A0 Other factors may exist as well, including the
potential for side-channel information leakage, e.g., due to traffic
analysis.=C2=A0 There might also be a reverse situation where exposing the<= br> link-layer address(es) of a P-MAAR have privacy considerations, though I don't have anything particular in mind at the moment.
<= div>
[CB] OK, I see your point. I've tried to add somethi= ng in version -06. Let me know if you think it is sufficient (I tried to ke= ep it short and simple, while still addressing your point).
=C2= =A0

=C2=A0 =C2=A0security concerns of Proxy Mobile IPv6 [RFC5213].=C2=A0 It is = recommended
=C2=A0 =C2=A0that the signaling messages, Proxy Binding Update and Proxy Bi= nding
=C2=A0 =C2=A0Acknowledgment, exchanged between the MAARs are protected usin= g IPsec
=C2=A0 =C2=A0using the established security association between them.=C2=A0= This

This is essentially unchanged from 5213, just with different names for
the endpoints, right, and so the existing guidance/experiences apply?

[CB] Yes, it should apply. We haven't id= entified anything different.
=C2=A0

I think we should also say something about all MAARs and the CMD being
trusted parties.=C2=A0 We should also say something about the authorization=
model (I assume it's just "all trusted parties are trusted to perf= orm
all operations relevant to their role", but that's still useful to= say).

[CB] OK, I've added a senten= ce on that.
=C2=A0

=C2=A0 =C2=A0When the CMD acts as a PBU/PBA relay, the CMD may act as a rel= ay of a
=C2=A0 =C2=A0single PBU to multiple previous MAARs.=C2=A0 In situations of = many fast
=C2=A0 =C2=A0handovers (e.g., with vehicular networks), there may exist mul= tiple
=C2=A0 =C2=A0previous (e.g., k) MAARs exist.=C2=A0 In this situation, the C= MD creates k

nit: remove the redundant "exist"

=
[CB] Done.
=C2=A0

=C2=A0 =C2=A0When the CMD acts as MAAR locator, mobility signaling (PBAs) i= s
=C2=A0 =C2=A0exchanged between P-MAARs and current S-MAAR.=C2=A0 This requi= res security
=C2=A0 =C2=A0associations to exist between the involved MAARs (in addition = to the
=C2=A0 =C2=A0ones needed with the CMD).

Is this relevant because of scaling/resource-consumption concerns or
keying/trust ones?

[CB] This is relevan= t because RFC 5213 uses a model in which signalling is exchanged only betwe= en LMA (the anchor) and MAGs (the access routers), while in this document t= here are some operation modes that also involve signalling between MAARs (t= he access routers). This was just to highlight this point (it is related to= the point you made before about the trust model).
=C2=A0

Appendix A.5

=C2=A0 =C2=A0not implement existing mobility protocols.=C2=A0 Furthermore, = a DMM
=C2=A0 =C2=A0solution SHOULD work across different networks, possibly opera= ted as
=C2=A0 =C2=A0separate administrative domains, when the needed mobility mana= gement

Hmm, separate administrative domains makes the risk of NAT relatively
higher (per previous comment about NAT).

=C2=A0 =C2=A0intervention.=C2=A0 The partially distributed DMM solution can= be deployed
=C2=A0 =C2=A0across different domains with trust agreements if the CMDs of = the
=C2=A0 =C2=A0operators are enabled to transfer context from one node to ano= ther.

It would probably be worth expounding a bit more about this scenario and the necessary trust/authorization relationships, in the security
considerations.

[CB] As per other comment from IESG evaluation I'= ve removed the two appendixes.

Huge thanks for you= r very good points!

Carlos=C2=A0

--00000000000066c5d805a05ba2f6-- From nobody Sun Mar 8 11:06:08 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC49B3A0E5F for ; Sun, 8 Mar 2020 11:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xN2kv4SCCQY for ; Sun, 8 Mar 2020 11:06:04 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FF43A0E61 for ; Sun, 8 Mar 2020 11:06:04 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id c21so9284323edt.1 for ; Sun, 08 Mar 2020 11:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bGwO4fUaaqgNq6PUMmkkAXJ2r2iGswYnDgaSIdP0UJk=; b=VN/nr1r9Zxtx9/ffRa7HVgYF7bjw5RtCg9T/036iw4l7eCSNXjNFS0U8eCY1N8+dgf BPA7rORso8nWjPYdOA/8OOZekSCDfO76nZIGWgxf3wY9g7a0JsLCmSOBaBTj6KfQobxU aofbUCPkFpieljH7Rm5AxK40Ocsr6ndhY76kYH3dQ/iS8XlS9bJaZNcNRDUuN7RlDBCB bJOLcOebgDNt5+9zLhgAHYMEXoAvTssB/D6nDY6sIk+cY53AyRzK4FjVMdFpEkxK4B0k m1amnoiQNS7SlUvTQwXyM4K1RUN1FKfmLfISZY7JBjpaDkK+ZU6k9Y5cTD3T0PR4DsB7 uviA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bGwO4fUaaqgNq6PUMmkkAXJ2r2iGswYnDgaSIdP0UJk=; b=ST7RQYP0X70OldjHu73fjJgepWEWWVti5iqodwioAG8TXUDw/T38NTh0OQO5Qw5Eja Keh/QujdBREh38Qxma/RStDqyrWdZOcaZhEs5FJ0wBIPlzynWnvEv7yrhuOSrWGYpIPE T1ogMRjDND7G0Ch0fIntmkrUUIXZ4zGG8MBzaNI19aEMriFkpePVpPNsNE+c5oIiuM4H RzpCrz75NRZ7MHC94FGOEsWd9VIcI+TlUgUEAPgHs4MZAHorKRPvip/kP9xmiif80SHA TfuVnaX9U3Ph+c65QSCsiLqheNHav2t8XKnYu/v2kO1VKOh+EraVibZaJI9t+9EWKcQ+ AezQ== X-Gm-Message-State: ANhLgQ3vIO2eMquh9wif2m4dsjMlj1bPHsO9+TNGYEvR2n5Sd+vPTMV0 AUQ3bNp4SpL0mkqIrhq3Q1tFO6iJJZbv3b8wU+dc4A== X-Google-Smtp-Source: ADFU+vuLEsRkApYjEb6ECf3UnhvA/yixW71/FoqK2RMHmyVGkv5sKGhBlYjsPguGvrqcS7x38nfBSgs+ifsOfPSdunQ= X-Received: by 2002:aa7:dd1a:: with SMTP id i26mr13549224edv.321.1583690762652; Sun, 08 Mar 2020 11:06:02 -0700 (PDT) MIME-Version: 1.0 References: <158338747964.29279.13608150336261590355@ietfa.amsl.com> In-Reply-To: <158338747964.29279.13608150336261590355@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Sun, 8 Mar 2020 19:05:46 +0100 Message-ID: To: Roman Danyliw Cc: The IESG , draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs , dmm , Dapeng Liu Content-Type: multipart/alternative; boundary="00000000000057b0d205a05bbd66" Archived-At: Subject: Re: [DMM] Roman Danyliw's No Objection on draft-ietf-dmm-pmipv6-dlif-05: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 18:06:08 -0000 --00000000000057b0d205a05bbd66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Roman, Thanks a lot for your review. Please see inline below my comments. On Thu, Mar 5, 2020 at 6:51 AM Roman Danyliw via Datatracker < noreply@ietf.org> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-dmm-pmipv6-dlif-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support Mirja K=C3=BChlewind's and Ben Kaduk's DISCUSS position. > [CB] I've addressed all their points, hopefully in a way satisfactory to them. > ** Section 6. Per =E2=80=9CThe CMD SHOULD use a pacing approach to limit = this > amplification risk=E2=80=9D, could you address Vincent Roca=E2=80=99s SEC= DIR Review (thank > you!) question =E2=80=9Cshould that pacing be on the In the incoming queu= e (i.e., > by > delaying some PBU/PBA messages) or in the outgoing queue (i.e., to limit > output > traffic), or both?=E2=80=9D > [CB] Done. > > ** Section 6. To provide normative language: > s/This requires security associations to exist between the involved MAARs= / > Hence, security associations are REQUIRED to exist between the involved > MAARs/ > [CB] Fixed, thanks. > > Editorial Nit: > ** Section 6. s/there may exist multiple previous (e.g., k) MAARs exist/ > there > may exist multiple previous (e.g., k) MAARs/ > > [CB] Fixed, thanks. Thanks a lot for your review! Carlos --00000000000057b0d205a05bbd66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman,

Thanks a lot= for your review. Please see inline below my comments.

On Thu, Mar 5, = 2020 at 6:51 AM Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
Roman Danyliw has entered the following ballot p= osition for
draft-ietf-dmm-pmipv6-dlif-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-i= etf-dmm-pmipv6-dlif/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Mirja K=C3=BChlewind's and Ben Kaduk's DISCUSS position.<= br>

[CB] I've addressed all their point= s, hopefully in a way satisfactory to them.


** Section 6. Per =E2=80=9CThe CMD SHOULD use a pacing approach to limit th= is
amplification risk=E2=80=9D, could you address Vincent Roca=E2=80=99s SECDI= R Review (thank
you!) question =E2=80=9Cshould that pacing be on the In the incoming queue = (i.e., by
delaying some PBU/PBA messages) or in the outgoing queue (i.e., to limit ou= tput
traffic), or both?=E2=80=9D

[CB] Done.<= /div>
=C2=A0

** Section 6.=C2=A0 To provide normative language:
s/This requires security associations to exist between the involved MAARs/<= br> Hence, security associations are REQUIRED to exist between the involved MAA= Rs/

[CB] Fixed, thanks.
=C2= =A0

Editorial Nit:
** Section 6. s/there may exist multiple previous (e.g., k) MAARs exist/ th= ere
may exist multiple previous (e.g., k) MAARs/

[CB] Fixed, thanks.

Thanks a= lot for your review!

Carlos
--00000000000057b0d205a05bbd66-- From nobody Sun Mar 8 11:43:23 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8E23A0041 for ; Sun, 8 Mar 2020 11:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8wll5iH-2wX for ; Sun, 8 Mar 2020 11:43:19 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB473A003A for ; Sun, 8 Mar 2020 11:43:18 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id m13so9342612edb.6 for ; Sun, 08 Mar 2020 11:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4SJ/C/+6jzJhjfLMP1uogDn4PJ5WP3gnKde2W7y1FUY=; b=FrXoD7M0J7nxLeQhGbA1VvwM5S0o41rsZaIEX3sMlMswF9cwbF8Ar51dvDXIWrs68U dTBA1k7cvDrzZZy9IWl5el3nfIc+6AHZFnjskFH0HKA9p5ivJJznpERHTtigshOewkny qRFXwZqyWrAYTiJJN5Eeyhsd8SvJTJDGj0oedby14KdErmsFl6jSKNkaPtoeIpDNgub0 qoJ/uqkTpkLHS032bcmsgy3it5bfM4lA2Q2rPYDnXwZluVcXowb+8eGaxLlWUIQ+LE/F N1U27XOeBoQUZiLESjhQwynVvXn21DEWNVSe9/qkw5Vtgh0o7I3Obkqt4p4l+BUu/EWq 5BNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4SJ/C/+6jzJhjfLMP1uogDn4PJ5WP3gnKde2W7y1FUY=; b=HOivxvy2OrW7W+gQFYTTxnowWJcPRSLDoGiTiTx4RokUx6nGqQcXqNhiLtw+lws2do SV4vLQjY9siwTe6Ao9frrhp/+Bp3fqfsfCZuT72gIqUbZo8DQb1qt1Sc72slBG8L3xB5 fYN3zBAwFyS/mEwCwCo/878NQ22NZitx76+f1hq4HgZh35pi86xQCmyzW/hugroHuT5f RZB2sfBnnx1McGVJNYMMj6WzrH6raG8fViZ4QkMTf0+KB274H92z7YrDwaLzXFlYAsJ7 MHinRoTRa9FUS3q8o2DGsnHLLTxm4B8mdkwZqnFLGml4Q6U6e8F7lfHpnkn7e8yBzbKQ g9mQ== X-Gm-Message-State: ANhLgQ1mAsqjOhkD5Pibeh70v7e5+6fVCUKK5nPjJ6qi2XR5q04Ep4br d3oAPs5ZP4EB/c+oyZL9koStmxAOmKelVc8wK76/XA== X-Google-Smtp-Source: ADFU+vty0y15ApWgJFAmlTfI2GxKpBkdHe+HvPnVAwo5kr3tW8r45kWc9/d5El7nLXJj2YCVyfNZltssZaB9Cvjghoc= X-Received: by 2002:aa7:dd1a:: with SMTP id i26mr13656748edv.321.1583692996958; Sun, 08 Mar 2020 11:43:16 -0700 (PDT) MIME-Version: 1.0 References: <5480B86B-3D6B-490B-9CAC-609EE7A41278@cisco.com> In-Reply-To: <5480B86B-3D6B-490B-9CAC-609EE7A41278@cisco.com> From: CARLOS JESUS BERNARDOS CANO Date: Sun, 8 Mar 2020 19:43:00 +0100 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: "int-dir@ietf.org" , "last-call@ietf.org" , "draft-ietf-dmm-pmipv6-dlif.all@ietf.org" , "dmm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008472f305a05c429d" Archived-At: Subject: Re: [DMM] [Last-Call] Intdir telechat review of draft-ietf-dmm-pmipv6-dlif -05 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 18:43:22 -0000 --0000000000008472f305a05c429d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, Thanks for your review. Please find inline below my comments. On Sat, Feb 29, 2020 at 4:15 AM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Reviewer: Carlos Pignataro > Review result: Ready with Nits > > I am an assigned INT directorate reviewer for this Internet-Draft. These > comments were written primarily for the benefit of the Internet Area > Directors. > Document editors and shepherd(s) should treat these comments just like th= ey > would treat comments from any other IETF contributors and resolve them > along > with any other Last Call comments that have been received. For more > details on > the INT Directorate, see http://www.ietf.org/iesg/directorate.html. > > I hope these comments are clear and useful. > > As requested, from the Internet area Directorate review, these two DMM > documents are being reviewed together: > * draft-ietf-dmm-distributed-mobility-anchoring-14 > * draft-ietf-dmm-pmipv6-dlif-05 > > This document defines distributed mobility anchoring, in terms of the > different configurations and functions to provide IP mobility support, > including network-based or host-based mobility support. > > The intended status is Informational. It is a very well written and > comprehensive > document. It is technically sound. > > No major or minor issues. > > Nits: > > A set of small nits for your consideration. > > 1. Introduction > > As a Mobile Node (MN) attaches to an access router and establishes a > link between them, a /64 IPv6 prefix anchored to the router may be > assigned to the link for exclusive use by the MN [RFC6459]. The MN > may then configure a global IPv6 address from this prefix and use it > as the source IP address in a flow to communicate with its > correspondent node (CN). > > Capitalize: > s/correspondent node/Correspondent Node/ > > 2. Conventions and Terminology > > These include terms such as mobile node (MN), correspondent node > (CN), home agent (HA), home address (HoA), care-of-address (CoA), > local mobility anchor (LMA), and mobile access gateway (MAG). > > Capitalize =E2=80=9CMobile Node=E2=80=9D (as per =C2=A7 1), =E2=80=9CCore= spondent Node=E2=80=9D, etc. > > Similar within this same =C2=A7 2, =E2=80=9Cmobile router=E2=80=9D, etc. > Same throughout the document (e.g., =E2=80=9Crouter advertisement (RA)=E2= =80=9D) > > 4.3. Mobility case, anchor relocation > > The IP prefix/address anchoring may move without changing the IP > prefix/address of the flow. Here the LM and FM functions in Figure 1 > in Section 3.1 are implemented as shown in Figure 7. > > =E2=80=9CFigure 1 in Section 3.1.1 are implemented=E2=80=9D > > Figure 7: Anchor mobility > > Should this figure=E2=80=99s label be =E2=80=9CAnchor Relocation=E2=80=9D= instead of =E2=80=98Anchor > mobility=E2=80=9D? > > 5. Security Considerations > > As stated in [RFC7333], "a DMM solution MUST supportany security > > s/supportany/support any/ > > 8.2. Informative References > > The relationship of this document and draft-ietf-dmm-deployment-models is > mostly clear, thank you for that. > > I hope you fid these comments useful. > > Carlos Pignataro. > > > https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif-05 > > I am an assigned INT directorate reviewer for this Internet-Draft. These > comments were written primarily for the benefit of the Internet Area > Directors. > Document editors and shepherd(s) should treat these comments just like th= ey > would treat comments from any other IETF contributors and resolve them > along > with any other Last Call comments that have been received. For more > details on > the INT Directorate, see http://www.ietf.org/iesg/directorate.html. > > I hope these comments are clear and useful. > > As requested, from the Internet area Directorate review, these two DMM > documents are being reviewed together: > * draft-ietf-dmm-distributed-mobility-anchoring-14 > * draft-ietf-dmm-pmipv6-dlif-05 > > This document provides an approach to distributed mobility management > by extending network-based mobility protocols (like Proxy Mobile IPv6). I= n > this solution, mobility sessions are anchored at the last IP hop router. > > This document=E2=80=99s intended status is Experimental. It is well writt= en for > such a complex comprehensive document, and technically complete and > sensible. > > No major or minor issues. > > Nits: > > Please find some small comments for your consideration: > > > 4.1. Proxy Binding Update > > A new flag (D) is included in the Proxy Binding Update to indicate > that the Proxy Binding Update is coming from a Mobility Anchor and > Access Router and not from a mobile access gateway. The rest of the > Proxy Binding Update format remains the same as defined in [RFC5213]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|L|K|M|R|P|F|T|B|S|D| Reser | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > However, for RFC 5213 S 8.1: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|L|K|M|R|P| Reserved | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So, therefore, seems like: > 1. The definition of Flags F, T, B, and S is missing. > 2. =E2=80=9CReser=E2=80=9D is not really clear and =E2=80=9CRsrvd=E2=80= =9D seems to fit and be more > unambiguous. > [CB] I've replaced "Reser" with "Rsrvd". The other flags are defined in other RFCs, published after RFC 5213. Do I need to explain what each of these flags do in this document? In any case, there might be additional flags defined in the future, so I think it is not needed. > > 4.2. Proxy Binding Acknowledgment > > =E2=80=A6 > The rest of the Proxy Binding Acknowledgment format > remains the same as defined in [RFC5213]. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status |K|R|P|T|B|S|D| | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > However, from RFC 5213: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status |K|R|P|Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > And thus, Flags T, B, S are not defined. > [CB] Same as before. Additional flags were defined and added to IANA registry after RFC 5213 was published. I refer to RFC 5213 as it is where the actual PBU/PBA format was specified (although they are basically BU/BA with P flag set to 1). > 4.3. Anchored Prefix Option > > Anchored Prefix > > A sixteen-byte field containing the mobile node's IPv6 Anchored > Prefix. Only the first Prefix Length bytes are valid for the > Anchored Prefix. The rest of the bytes MUST be ignored. > > Not being pedantic, but: > s/byte/octet/g // throughout. > Or=E2=80=A6 "128-bit=E2=80=9D instead of =E2=80=9Csixteen-octet=E2=80=9D. > [CB] OK, I see that RFC 6275 uses only "octet", while RFC 5213 uses both "octet" and "byte". But I agree that using only one is the right thing to do. I've chosen "octet" as you suggested. > > 5. IANA Considerations > > This document defines six new mobility options that need to be > registered in the Mobility Options registry on the Mobile IPv6 > parameters registry. The required IANA actions are marked as IANA-1 > to IANA-6. > > It would be useful to breakout the specific IANA requests in a table, > sections, or other structure detailing how it should look in the IANA > registries. > [CB] I've added some additional text, but following the approach of RFC 5213, which keeps it simple. I hope this is sufficient. > 6. Security Considerations > > Is there underlying protection against spoofing that can be called out? > This should be addressed in the Security Dir review, so I will not mentio= n > it here =F0=9F=99=82 > [CB] We assume that using the mechanisms described for RFC 5213 is enough. We have added some additional considerations for the risks/procedures that are specific to the distributed solution. > 8.2. Informative References > > [I-D.ietf-dmm-deployment-models] > Gundavelli, S. and S. Jeon, "DMM Deployment Models and > Architectural Considerations", draft-ietf-dmm-deployment- > models-04 (work in progress), May 2018. > > Since there are key definitions from this document, should this be > Normative? > [CB] Since this document is not going to be progressed any further, we have included the relevant terms in the terminology section and remove the reference. > > [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. > Korhonen, "Requirements for Distributed Mobility > Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, > . > > Similarly, should this reference be Normative instead of Informative? > [CB] I don't have a strong opinion here. I've moved it to Normative, but I think it could stay as Informative as well. > Appendix B. Implementation experience > > Should this really be an Implementation Status section [RFC7942], as it > describes a point in time rather than learnings? > > Should the Appendices clarify they make no normative specs? > [CB] Based also on other comments we have remove both appendixes. > I hope these comments are useful. > [CB] Yes, they are indeed. Thanks! Carlos > > Thank you very much, > > Carlos Pignataro. --0000000000008472f305a05c429d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Thanks for = your review. Please find inline below my comments.

On Sat, Feb 29, 202= 0 at 4:15 AM Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Reviewer: Carlos Pignataro
Review result: Ready with Nits

I am an assigned INT directorate reviewer for this Internet-Draft.=C2=A0 Th= ese
comments were written primarily for the benefit of the Internet Area Direct= ors.
Document editors and shepherd(s) should treat these comments just like they=
would treat comments from any other IETF contributors and resolve them alon= g
with any other Last Call comments that have been received. For more details= on
the INT Directorate, see http://www.ietf.org/iesg/directora= te.html.

I hope these comments are clear and useful.

As requested, from the Internet area Directorate review, these two DMM
documents are being reviewed together:
* draft-ietf-dmm-distributed-mobility-anchoring-14
* draft-ietf-dmm-pmipv6-dlif-05

This document defines distributed mobility anchoring, in terms of the
different configurations and functions to provide IP mobility support,
including network-based or host-based mobility support.

The intended status is Informational. It is a very well written and compreh= ensive
document. It is technically sound.

No major or minor issues.

Nits:

A set of small nits for your consideration.

1.=C2=A0 Introduction

=C2=A0 =C2=A0As a Mobile Node (MN) attaches to an access router and establi= shes a
=C2=A0 =C2=A0link between them, a /64 IPv6 prefix anchored to the router ma= y be
=C2=A0 =C2=A0assigned to the link for exclusive use by the MN [RFC6459].=C2= =A0 The MN
=C2=A0 =C2=A0may then configure a global IPv6 address from this prefix and = use it
=C2=A0 =C2=A0as the source IP address in a flow to communicate with its
=C2=A0 =C2=A0correspondent node (CN).

Capitalize:
s/correspondent node/Correspondent Node/

2.=C2=A0 Conventions and Terminology

=C2=A0 =C2=A0These include terms such as mobile node (MN), correspondent no= de
=C2=A0 =C2=A0(CN), home agent (HA), home address (HoA), care-of-address (Co= A),
=C2=A0 =C2=A0local mobility anchor (LMA), and mobile access gateway (MAG).<= br>
Capitalize =E2=80=9CMobile Node=E2=80=9D (as per =C2=A7 1), =E2=80=9CCoresp= ondent Node=E2=80=9D, etc.

Similar within this same =C2=A7 2, =E2=80=9Cmobile router=E2=80=9D, etc. Same throughout the document (e.g., =E2=80=9Crouter advertisement (RA)=E2= =80=9D)

4.3.=C2=A0 Mobility case, anchor relocation

=C2=A0 =C2=A0The IP prefix/address anchoring may move without changing the = IP
=C2=A0 =C2=A0prefix/address of the flow.=C2=A0 Here the LM and FM functions= in Figure 1
=C2=A0 =C2=A0in Section 3.1 are implemented as shown in Figure 7.

=E2=80=9CFigure 1 in Section 3.1.1 are implemented=E2=80=9D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Figure 7: Anchor mobility

Should this figure=E2=80=99s label be =E2=80=9CAnchor Relocation=E2=80=9D i= nstead of =E2=80=98Anchor mobility=E2=80=9D?

5.=C2=A0 Security Considerations

=C2=A0 =C2=A0As stated in [RFC7333], "a DMM solution MUST supportany s= ecurity

s/supportany/support any/

8.2. Informative References

The relationship of this document and draft-ietf-dmm-deployment-models is m= ostly clear, thank you for that.

I hope you fid these comments useful.

Carlos Pignataro.


https://tools.ietf.org/html/draft-ietf-dm= m-pmipv6-dlif-05

I am an assigned INT directorate reviewer for this Internet-Draft.=C2=A0 Th= ese
comments were written primarily for the benefit of the Internet Area Direct= ors.
Document editors and shepherd(s) should treat these comments just like they=
would treat comments from any other IETF contributors and resolve them alon= g
with any other Last Call comments that have been received. For more details= on
the INT Directorate, see http://www.ietf.org/iesg/directora= te.html.

I hope these comments are clear and useful.

As requested, from the Internet area Directorate review, these two DMM
documents are being reviewed together:
* draft-ietf-dmm-distributed-mobility-anchoring-14
* draft-ietf-dmm-pmipv6-dlif-05

This document provides an approach to distributed mobility management
by extending network-based mobility protocols (like Proxy Mobile IPv6). In<= br> this solution, mobility sessions are anchored at the last IP hop router.
This document=E2=80=99s intended status is Experimental. It is well written= for such a complex comprehensive document, and technically complete and se= nsible.

No major or minor issues.

Nits:

Please find some small comments for your consideration:


4.1.=C2=A0 Proxy Binding Update

=C2=A0 =C2=A0A new flag (D) is included in the Proxy Binding Update to indi= cate
=C2=A0 =C2=A0that the Proxy Binding Update is coming from a Mobility Anchor= and
=C2=A0 =C2=A0Access Router and not from a mobile access gateway.=C2=A0 The = rest of the
=C2=A0 =C2=A0Proxy Binding Update format remains the same as defined in [RF= C5213].

=C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Sequence #=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|A|H|L|K|M|R|P|F|T|B|S|D| Reser |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Lifetime=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

However, for RFC 5213 S 8.1:

=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |A|H|L|K|M|R|P|=C2=A0 Reserved=C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lifetime=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+

So, therefore, seems like:
1. The definition of Flags F, T, B, and S is missing.
2. =E2=80=9CReser=E2=80=9D is not really clear and =E2=80=9CRsrvd=E2=80=9D = seems to fit and be more unambiguous.

[= CB] I've replaced "Reser" with "Rsrvd". The other f= lags are defined in other RFCs, published after RFC 5213. Do I need to expl= ain what each of these flags do in this document? In any case, there might = be additional flags defined in the future, so I think it is not needed.
=C2=A0

4.2.=C2=A0 Proxy Binding Acknowledgment

=E2=80=A6
=C2=A0 The rest of the Proxy Binding Acknowledgment format
=C2=A0 =C2=A0remains the same as defined in [RFC5213].

=C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A03
=C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0Status=C2= =A0 =C2=A0 =C2=A0 |K|R|P|T|B|S|D| |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

However, from RFC 5213:

=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0S= tatus=C2=A0 =C2=A0 =C2=A0 |K|R|P|Reserved |
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+

And thus, Flags T, B, S are not defined.

[CB] Same as before. Additional flags were defined and added to IANA regi= stry after RFC 5213 was published. I refer to RFC 5213 as it is where the a= ctual=C2=A0PBU/PBA format was specified (although they are basically BU/BA = with P flag set to 1).


4.3.=C2=A0 Anchored Prefix Option

=C2=A0 =C2=A0Anchored Prefix

=C2=A0 =C2=A0 =C2=A0 A sixteen-byte field containing the mobile node's = IPv6 Anchored
=C2=A0 =C2=A0 =C2=A0 Prefix.=C2=A0 Only the first Prefix Length bytes are v= alid for the
=C2=A0 =C2=A0 =C2=A0 Anchored Prefix.=C2=A0 The rest of the bytes MUST be i= gnored.

Not being pedantic, but:
s/byte/octet/g // throughout.
Or=E2=80=A6 "128-bit=E2=80=9D instead of =E2=80=9Csixteen-octet=E2=80= =9D.

[CB] OK, I see that RFC 6275 uses = only "octet", while RFC 5213 uses both "octet" and &quo= t;byte". But I agree that using only one is the right thing to do. I&#= 39;ve chosen "octet" as you suggested.



5.=C2=A0 IANA Considerations

=C2=A0 =C2=A0This document defines six new mobility options that need to be=
=C2=A0 =C2=A0registered in the Mobility Options registry on the Mobile IPv6=
=C2=A0 =C2=A0parameters registry.=C2=A0 The required IANA actions are marke= d as IANA-1
=C2=A0 =C2=A0to IANA-6.

It would be useful to breakout the specific IANA requests in a table, secti= ons, or other structure detailing how it should look in the IANA registries= .

[CB] I've added some additional t= ext, but following the approach of RFC 5213, which keeps it simple. I hope = this is sufficient.


6. Security Considerations

Is there underlying protection against spoofing that can be called out? Thi= s should be addressed in the Security Dir review, so I will not mention it = here =F0=9F=99=82

[CB] We assume that u= sing the mechanisms described for RFC 5213 is enough. We have added some ad= ditional considerations for the risks/procedures that are specific to the= =C2=A0distributed solution.


8.2.=C2=A0 Informative References

=C2=A0 =C2=A0[I-D.ietf-dmm-deployment-models]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gundavelli, S. and S. Jeon= , "DMM Deployment Models and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Architectural Consideratio= ns", draft-ietf-dmm-deployment-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 models-04 (work in progres= s), May 2018.

Since there are key definitions from this document, should this be Normativ= e?

[CB] Since this document is not goin= g to be progressed any further, we have included the relevant terms in the = terminology section and remove the reference.
=C2=A0

=C2=A0 =C2=A0[RFC7333]=C2=A0 Chan, H., Ed., Liu, D., Seite, P., Yokota, H.,= and J.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Korhonen, "Requiremen= ts for Distributed Mobility
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Management", RFC 7333= , DOI 10.17487/RFC7333, August 2014,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://= www.rfc-editor.org/info/rfc7333>.

Similarly, should this reference be Normative instead of Informative?

[CB] I don't have a strong opinion here.= I've moved it to Normative, but I think it could stay as Informative a= s well.


Appendix B.=C2=A0 Implementation experience

Should this really be an Implementation Status section [RFC7942], as it des= cribes a point in time rather than learnings?

Should the Appendices clarify they make no normative specs?

[CB] Based also on other comments we have remove both = appendixes.


I hope these comments are useful.

[CB] = Yes, they are indeed. Thanks!

Carlos
=C2= =A0

Thank you very much,

Carlos Pignataro.
--0000000000008472f305a05c429d-- From nobody Sun Mar 8 11:46:09 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5B3A05A6; Sun, 8 Mar 2020 11:45:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <158369314867.6767.10256933842971130620@ietfa.amsl.com> Date: Sun, 08 Mar 2020 11:45:48 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-pmipv6-dlif-06.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 18:46:04 -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 WG of the IETF. Title : Proxy Mobile IPv6 extensions for Distributed Mobility Management Authors : Carlos J. Bernardos Antonio de la Oliva Fabio Giust Juan Carlos Zuniga Alain Mourad Filename : draft-ietf-dmm-pmipv6-dlif-06.txt Pages : 29 Date : 2020-03-08 Abstract: Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centrally deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (like Mobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called mobility anchor and access router). The mobility anchor and access router is an enhanced access router which is also able to operate as a local mobility anchor or mobility access gateway, on a per prefix basis. The document focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif-06 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-pmipv6-dlif-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-pmipv6-dlif-06 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 Sun Mar 8 14:31:43 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D5E3A0763; Sun, 8 Mar 2020 14:31:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , max.ldp@alibaba-inc.com X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158370309419.6811.16312588326673584159@ietfa.amsl.com> Date: Sun, 08 Mar 2020 14:31:34 -0700 Archived-At: Subject: [DMM] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?dmm-pmipv6-dlif-06=3A_=28with_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 21:31:42 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-dmm-pmipv6-dlif-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. And congratulations for the many advanced ASCII art ! Except for section 3.6, the text is really easy to read. Thank you also for fixing my previous DISCUSS as well as replying by email to my comments. I have kept the original DISCUSS & COMMENT below. Please also address the points raised by Carlos during the INT directorate review. Thank you again Carlos ! https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28/ Happy that my comments have helped to improve the document Regards, -éric == OLD DISCUSS == -- Section 4.3 & 4.4 & 4.5 -- Probably trivial to fix but is "Prefix Length" expressed in bits (/64) or in bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? The definition of the "Prefix length" field should be specific about the unit (bits/bytes) and be aligned with the definition of "Anchored prefix" (as this one seems to assert that the prefix length must be a multiple of 8). == COMMENTS == A generic question, can a MN be attached to multiple MAAR at the same time? I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR at any time. -- Section 3.1 -- Should the length of the prefix assigned to the MN be specified? Adding a /64 would make things clearer without using too much of text. For my own curiosity, the text is about "IPv6 global prefix", but, would ULA also work ? -- Section 3.6 -- This section is so different than the previous ones in section 3, that I would have created a section on its own. This section also uses EUI-64 for the link-local address; and, this is no more advised for privacy reason. Not really important in the DMM context though. Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ ;-) The text of this section is really difficult to parse. After 2 readings I am not even sure that I got it... I was about to open a DISCUSS for the point 2) but I am unsure whether I am reading the text correctly. 1) If the MAC and LLA for the 'virtual router' mn1mar2 are different than the one for mn1mar2, why is there a need for different interface? Multiple routers can exist on the same link. 2) For packets sourced by MN1 with prefix1 how can we ensure that they are sent to mn1mar1 and not to mn1mar? PvD could help there and should be mentionned draft-ietf-intarea-provisioning-domains. -- Section 4.2 -- Bit 31 is not described, it is probably reserved but you should really described it. With this PBA packet format, all flags / bits are used and assigned for an experimental document. Isn't it a waste of bits? I will really appreciate an answer on this question. == NITS == -- Section 3 (and possibly others) -- The CMD and MAAR acronyms are expanded multiple times. This makes the reading easier for newcomers of course. From nobody Sun Mar 8 14:33:58 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF213A0755; Sun, 8 Mar 2020 14:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fYEmpG3n; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QzrggpUs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwmwGwvJYc5e; Sun, 8 Mar 2020 14:33:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1613A074E; Sun, 8 Mar 2020 14:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41047; q=dns/txt; s=iport; t=1583703229; x=1584912829; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pr1ZXvNU3w99P1GptZkmOTPQFdrKri1CQLWX577/fTk=; b=fYEmpG3nvoIB1yZrHU6evVlCKxxQ/NSVQCCK5unMSS2Lo2lE+Ipyzlzj xEsj88Zc3RWl7gQyFvXCzLFDQHMCKSrQsVw0qXMlnRc7+N7IX06Q/d3zW Qq7MEYr2b+gsFFGEbXeMnR/Uits61km6dKldNZdBj18KGjPgYX+vzubvp w=; IronPort-PHdr: =?us-ascii?q?9a23=3AUgknrRPw7x491WBSLC8l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2Mu/sZC83NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXCgByY2Ve/5xdJa1kHgELHIMgL1A?= =?us-ascii?q?FbFggBAsqhBWDRgOKbIJfmBWBQoEQA1QJAQEBDAEBJQgCBAEBhEMCF4F3JDg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQUEbYVWDIVjAQEBAQMSER0BASoKAwEPAgEGAhEDAQI?= =?us-ascii?q?hBwMCAgIwFAYDCAIEDgUbB4MEAYF9TQMuAQ6LOpBnAoE5iGJ1gTKCfwEBBYE?= =?us-ascii?q?zAgENQYMEGIIMAwaBOIUhhwsagUE/gREnIIJNPoJkAgECAYEjCQESAQcxCQw?= =?us-ascii?q?BCYJbMoIsjXOCOjuFcooPjk9wCoI8h1KKYoQyHIJJiCGETot9g0yMd4cvklU?= =?us-ascii?q?CBAIEBQIOAQEFgWkiZ1gRCHAVZQGCQVAYDY4dCRoVgzuFFIVBdAKBJ40/AQE?= X-IronPort-AV: E=Sophos;i="5.70,530,1574121600"; d="scan'208,217";a="723230844" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Mar 2020 21:33:48 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 028LXmsw028548 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 8 Mar 2020 21:33:48 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 8 Mar 2020 16:33:47 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 8 Mar 2020 17:33:46 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 8 Mar 2020 17:33:46 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JeaCyY6TrpZwiNTy0I4lpBHfreeoj//1lfSxyBQRlT3tSSdgA+08Tz0I9nmtQ5MODcypjU1rR4Y3+DY6tQ1cqcp4ySrVKooVU7kSgoSuNkDdDCweegEPr2SoxnqznJ2RhdnjUJnI2DxtMO4RGU3HgbmsNel1bX++LCf8wXtivUdoRIKf6/5T1AjorukokWNnwEwN69/nTo6cci8A9G6JfWmI8O3zEHP4nzno8Z4o+5csRMNbdBpuLdY2QPmA2ctOdmmX4P5UcJtgxDnlCSAsX/dlsleMKcwX78doS2wokEdaYaxKzma4fhB4gfy0H5EqSVNRgUeHgIDzgkf/KEakjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pr1ZXvNU3w99P1GptZkmOTPQFdrKri1CQLWX577/fTk=; b=JrWbKHmth20bO3ykdt5KfTqGwqTRKUfd3iV41k8RYBjYQD4Ug/PWYPax4mBlDy5yNBnkAzFSq2T3WC4HsVv9k9lAYTpI0WJuLFnRdkEil34+BTMRUtu1s7+33L4pgQYI5qYDdpyD0WzN6+cwjySfqtyQZXxkYxN+lzDGd1thba6SlXyLlz1seJVFzsu4ep0AWpQ8NYgWtlMJEaVTzn0NWV1jm05Wk4qKW4obvKORfy4T2MzI/jN9rk+XCEgLqzHeVMRKK6t4DNPayzlsijwTw+/uBYtILxbhsStJpwj58tDMDpNBGUZ37xUSQ751DFg7GkiBi/0IVul4guJTwdvkUg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pr1ZXvNU3w99P1GptZkmOTPQFdrKri1CQLWX577/fTk=; b=QzrggpUsGXGkeieKUD/Sic2oIMYYb9j12NvRiCOtn4+fsMGXYzEt0flxw5KFurm4dqOHfTf04IURLkFT5o48KbNpA6BNBvTrhPyrWIm0c9Ssq9LWMn1sCDjsSswHiKXZ2y4JtPOG5DVHMCVkiqQfc1xk11nEbFnrhV5dKctjxQw= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1866.namprd11.prod.outlook.com (2603:10b6:3:10a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Sun, 8 Mar 2020 21:33:45 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2793.013; Sun, 8 Mar 2020 21:33:45 +0000 From: "Eric Vyncke (evyncke)" To: CARLOS JESUS BERNARDOS CANO CC: "Carlos Pignataro (cpignata)" , "draft-ietf-dmm-pmipv6-dlif@ietf.org" , Dapeng Liu , dmm-chairs , "The IESG" , dmm Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWRtbS1wbWlw?= =?utf-8?Q?v6-dlif-05:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHV9UKD8fp8Th1ZGkO52mUpmI7waqg/SLoA Date: Sun, 8 Mar 2020 21:33:45 +0000 Message-ID: <3D8BA7D2-DEB7-4F3D-89B9-08633F44F974@cisco.com> References: <158318249840.27483.9051628354202166127@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:d844:aa4b:3f35:9f44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b6ea943-0fb8-4089-267f-08d7c3a8616e x-ms-traffictypediagnostic: DM5PR11MB1866: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(376002)(346002)(396003)(189003)(199004)(4326008)(5660300002)(53546011)(6506007)(64756008)(66556008)(66446008)(316002)(66946007)(66476007)(6916009)(6486002)(6512007)(66574012)(21615005)(86362001)(36756003)(2906002)(966005)(2616005)(33656002)(54906003)(186003)(71200400001)(478600001)(8936002)(81156014)(81166006)(76116006)(224303003)(91956017)(473944003)(414714003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1866; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dysy0KA9roi9vpdQLujzC5nY5Mwm89v2e8CZEeA6uKypY4MYlhLAXLbfLyHEF0JAmCSwK0pbDSxcuUBO4bsOwObgoSqd3BMre49M1qBgLPSOPnRrsmVKQrU+/AuG8hNMq9iXIl9Qf0pQWNyxZGaIHnYz73GQ4zkTCFVGgAdndMQnoex5J+DkS91AuV35f0NIWQAuRvguAzhQH5AtPt6TpRzmqvoAgTJsoj7UKaCq2W8PhcxcvZ0I0O/ePQn/ot2pS24azxnLYMYGgwxm6N3t82M2DICL8sVi4DdCBFQEQML5ZGMQrBz5qWivhO4PhCaxxnHdTVO4X79HI/Ko9EDzU+DpDvDdL6xaDe+EqP1gcB9DP3h7WiemX30UMxX6hl1Jd4SgRxvvej7T/ZLSOATsMULAPWkZqXco51xu4h61I6jxpBbN+qGlRMaEn4Nf4PVIeFdLwSSdkeSmchWr6b77A0PA8a6aRk9q/QAIk2xmCFbD7UWNIFskSfkf1d35TndSbzULVPqtlBdoKrvtFPtffpDFOjR13GoppN4crTe4oIHLDqyTNtfqltgvbC+5S8DeFr59kn03N6jezlRaWe5C3DOJif4SOVmjXxNSd0Nq/I8= x-ms-exchange-antispam-messagedata: 1MCQRRRMHlyZn7SUSImVEAXBorl78bupfiKguysWhF8Ea54Cv6spHijxMKasTGvNhDZgpoKcrTu86xRN1ucQTlhV4qlazivcV+WT/BzyK1P8Ymd/8V8OaXEZaD2UtSrx66NGK6mTAmvgpk8ccRgTXVgsneluvrhxi17+swUvUeoNgaaQolZFcfMtSe/UxCtInaMP78som6rjYwsyTMzqhQ== Content-Type: multipart/alternative; boundary="_000_3D8BA7D2DEB74F3D89B908633F44F974ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0b6ea943-0fb8-4089-267f-08d7c3a8616e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2020 21:33:45.1206 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZtJ62nVer/4zgt+F/OWMb6DdJ125w4FwWUQ2trLu7FR6bkXor+p6iL/1rUONbAhjkl4TReKzc3vfKPZ7YrhlPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1866 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [DMM] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-dmm-p?= =?utf-8?q?mipv6-dlif-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 21:33:54 -0000 --_000_3D8BA7D2DEB74F3D89B908633F44F974ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQ2FybG9zLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJlcGx5LCB0aGUg YW5zd2VycywgYW5kIHRoZSByZXZpc2VkLUlELiBJIHdpbGwgY2xlYXIgbXkgRElTQ1VTUyBpbiBh IGNvdXBsZSBvZiBtaW51dGVzLg0KDQpXaGlsZSBJIGFtIHNsaWdodGx5IGRpc2FwcG9pbnRlZCBi eSBzb21lIGFuc3dlcnMgKGUuZy4sIG5vIG11bHRpLWhvbWUpLCBJIHVuZGVyc3RhbmQgdGhhdCB0 aGlzIGlzIGFuIGV4cGVyaW1lbnRhbCBkb2N1bWVudCBhbmQgbGV04oCZcyBzdGFydCB0byB3YWxr IGJlZm9yZSBydW5uaW5nLg0KDQpGb3IgdGhlIGJpdCAzMSBpbiBzZWN0aW9uIDQuMiwgSSB3b3Vs ZCBzaW1wbHkgcHV0IGEg4oCYMOKAmQ0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQpGcm9tOiBpZXNn IDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDQVJMT1MgSkVTVVMgQkVSTkFS RE9TIENBTk8gPGNqYmNAaXQudWMzbS5lcz4NCkRhdGU6IFN1bmRheSwgOCBNYXJjaCAyMDIwIGF0 IDEzOjEwDQpUbzogRXJpYyBWeW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPg0KQ2M6ICJDYXJsb3Mg UGlnbmF0YXJvIChjcGlnbmF0YSkiIDxjcGlnbmF0YUBjaXNjby5jb20+LCAiZHJhZnQtaWV0Zi1k bW0tcG1pcHY2LWRsaWZAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWRtbS1wbWlwdjYtZGxpZkBpZXRm Lm9yZz4sIERhcGVuZyBMaXUgPG1heC5sZHBAYWxpYmFiYS1pbmMuY29tPiwgZG1tLWNoYWlycyA8 ZG1tLWNoYWlyc0BpZXRmLm9yZz4sIFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiwgZG1tIDxkbW1A aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogw4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1p ZXRmLWRtbS1wbWlwdjYtZGxpZi0wNTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KSGkg w4lyaWMsDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5l IGJlbG93IG15IGNvbW1lbnRzLg0KDQpPbiBNb24sIE1hciAyLCAyMDIwIGF0IDk6NTUgUE0gw4ly aWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBs eUBpZXRmLm9yZz4+IHdyb3RlOg0Kw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1kbW0tcG1pcHY2LWRsaWYtMDU6IERp c2N1c3MNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRv IGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRp b24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9j dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhl cmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRtbS1wbWlw djYtZGxpZi8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN ClRoYW5rIHlvdSBmb3IgdGhlIHdvcmsgcHV0IGludG8gdGhpcyBkb2N1bWVudC4gQW5kIGNvbmdy YXR1bGF0aW9ucyBmb3IgdGhlIG1hbnkNCmFkdmFuY2VkIEFTQ0lJIGFydCAhIEV4Y2VwdCBmb3Ig c2VjdGlvbiAzLjYsIHRoZSB0ZXh0IGlzIHJlYWxseSBlYXN5IHRvIHJlYWQuDQoNCkkgaGF2ZSBh IGJsb2NrIERJU0NVU1MgYmVsb3cgYnV0IGl0IHNob3VsZCBiZSB0cml2aWFsIHRvIGZpeC4NCg0K UGxlYXNlIGFsc28gYWRkcmVzcyB0aGUgcG9pbnRzIHJhaXNlZCBieSBDYXJsb3MgZHVyaW5nIHRo ZSBJTlQgZGlyZWN0b3JhdGUNCnJldmlldy4gVGhhbmsgeW91IGFnYWluIENhcmxvcyAhDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZXZpZXctaWV0Zi1kbW0tcG1pcHY2LWRsaWYt MDUtaW50ZGlyLXRlbGVjaGF0LXBpZ25hdGFyby0yMDIwLTAyLTI4Lw0KDQpJIGhvcGUgdGhhdCB0 aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LA0KDQpbQ0JdIFRoYW5rcy4gSSd2ZSBh ZGRyZXNzZWQgdGhlIGNvbW1lbnRzIGZyb20gQ2FybG9zIGluIHZlcnNpb24gLTA2ICh0byBiZSBz dWJtaXR0ZWQgc29vbikuDQoNCg0KUmVnYXJkcywNCg0KLcOpcmljDQoNCj09IERJU0NVU1MgPT0N Cg0KLS0gU2VjdGlvbiA0LjMgJiA0LjQgJiA0LjUgLS0NClByb2JhYmx5IHRyaXZpYWwgdG8gZml4 IGJ1dCBpcyAiUHJlZml4IExlbmd0aCIgZXhwcmVzc2VkIGluIGJpdHMgKC82NCkgb3IgaW4NCmJ5 dGVzICg4IGJ5dGVzKS4gSWYgdGhlIGxhdHRlciwgdGhlbiBob3cgY2FuIHdlIGhhdmUgYSBwcmVm aXggb2YgLzU3ID8gVGhlDQpkZWZpbml0aW9uIG9mIHRoZSAiUHJlZml4IGxlbmd0aCIgZmllbGQg c2hvdWxkIGJlIHNwZWNpZmljIGFib3V0IHRoZSB1bml0DQooYml0cy9ieXRlcykgYW5kIGJlIGFs aWduZWQgd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiAiQW5jaG9yZWQgcHJlZml4IiAoYXMgdGhpcw0K b25lIHNlZW1zIHRvIGFzc2VydCB0aGF0IHRoZSBwcmVmaXggbGVuZ3RoIG11c3QgYmUgYSBtdWx0 aXBsZSBvZiA4KS4NCltDQl0gVGhlIHByZWZpeCBsZW5ndGggaXMgZXhwcmVzc2VkIGluIGJpdHMu IEkndmUgY2xhcmlmaWVkIHRoaXMgaW4gdGhlIHRleHQuIEkndmUgYWxzbyBmaXhlZCB0aGlzIGlu IHRoZSAiQW5jaG9yZWQgcHJlZml4IiBkZWZpbml0aW9uLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNP TU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj09IENPTU1FTlRTID09DQoNCkEgZ2VuZXJpYyBxdWVz dGlvbiwgY2FuIGEgTU4gYmUgYXR0YWNoZWQgdG8gbXVsdGlwbGUgTUFBUiBhdCB0aGUgc2FtZSB0 aW1lPw0KSS5lLiwgb25jZSBvdmVyIFdpRmkgYW5kIG9uY2Ugb2YgM0dQUCA/IFRoZXJlIHNlZW1z IHRvIGJlIG9ubHkgb25lIFMtTUFBUiBhdA0KYW55IHRpbWUuDQoNCltDQl0gVGhlIGRvY3VtZW50 IGFzc3VtZXMgb25seSBTLU1BQVIgYXQgYSB0aW1lLiBBZGRpbmcgc3VwcG9ydCBmb3IgbXVsdGlw bGUgUy1NQUFScyBhdCB0aGUgc2FtZSB0aW1lIGNvdWxkIGJlIGZlYXNpYmxlLCBidXQgaXQnZCBh ZGQgY29tcGxleGl0eS4gSU1ITyBpdCdzIGJldHRlciB0byBzZWUgdGhlIHBvdGVudGlhbCBhZG9w dGlvbiBvZiB0aGlzIHNvbHV0aW9uIGFuZCBnYWluIGZyb20gaW1wbGVtZW50YXRpb24gZXhwZXJp ZW5jZSBiZWZvcmUgZ29pbmcgaW50byBhZGRpbmcgc3VwcG9ydCBmb3IgbXVsdGlwbGUgUy1NQUFS cy4NCg0KDQotLSBTZWN0aW9uIDMuMSAtLQ0KU2hvdWxkIHRoZSBsZW5ndGggb2YgdGhlIHByZWZp eCBhc3NpZ25lZCB0byB0aGUgTU4gYmUgc3BlY2lmaWVkPyBBZGRpbmcgYSAvNjQNCndvdWxkIG1h a2UgdGhpbmdzIGNsZWFyZXIgd2l0aG91dCB1c2luZyB0b28gbXVjaCBvZiB0ZXh0Lg0KDQpbQ0Jd IEkgYWdyZWUgaXQgY291bGQgYmUgYWRkZWQgYW5kIGJlIGhlbHBmdWwsIGJ1dCBzaW5jZSB0aGUg bWVzc2FnZSBvcHRpb25zIGRlZmluZWQgY291bGQgc3VwcG9ydCBvdGhlciBwcmVmaXggbGVuZ3Ro cyAodGhvdWdoIEkgYWdyZWUgLzY0IHdvdWxkIGJlIG9uZSBtb3N0IG9mIHRoZSB0aW1lcyksIHVz aW5nIC82NCBpbiBTZWN0aW9uIDMuMSBjb3VsZCBsZWFkIHRvIGFzc3VtZSB0aGF0IG9ubHkgdGhh dCBwcmVmaXggbGVuZ3RoIGlzIHZhbGlkLiBCdXQgaWYgeW91IHRoaW5rIGl0J3MgYmV0dGVyIHRv IGFkZCBpdCwgSSBjYW4gZG8gaXQgKEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIGFnYWlu c3QpLg0KDQoNCkZvciBteSBvd24gY3VyaW9zaXR5LCB0aGUgdGV4dCBpcyBhYm91dCAiSVB2NiBn bG9iYWwgcHJlZml4IiwgYnV0LCB3b3VsZCBVTEENCmFsc28gd29yayA/DQoNCltDQl0gSSB0aGlu ayBpdCB3b3VsZCBhcyB3ZWxsLiBJIGFsd2F5cyB0ZW5kIHRvIHRoaW5rIHRoYXQgbW9iaWxpdHkg c29sdXRpb25zIG9ubHkgbWFrZSBzZW5zZSBpbiBnbG9iYWwgc2NlbmFyaW9zLCBidXQgdGhlcmUg aXMgbm90aGluZyBwcmV2ZW50aW5nIGl0IHRvIHVzZSB0aGUgbWVjaGFuaXNtcyB3aXRoIFVMQS4g SSBhbHNvIHRyaWVkIHRvIGZvbGxvdyBhcyBtdWNoIGFzIHBvc3NpYmxlIFJGQyA1MjEzIHRlcm1p bm9sb2d5IGFuZCB0aGVyZSAiZ2xvYmFsIiBpcyB1c2VkLiBJJ3ZlIGtlcHQgdGhlICJnbG9iYWwi IGZvciB0aGUgdGltZSBiZWluZywgYnV0IGl0IGNhbiBiZSByZW1vdmVkLg0KDQoNCi0tIFNlY3Rp b24gMy42IC0tDQpUaGlzIHNlY3Rpb24gaXMgc28gZGlmZmVyZW50IHRoYW4gdGhlIHByZXZpb3Vz IG9uZXMgaW4gc2VjdGlvbiAzLCB0aGF0IEkgd291bGQNCmhhdmUgY3JlYXRlZCBhIHNlY3Rpb24g b24gaXRzIG93bi4NCg0KW0NCXSBJIGFncmVlIHNlY3Rpb24gMy42ICh3aGljaCBpcyBzZWN0aW9u IDMuNyBpbiB2ZXJzaW9uIC0wNikgaXMgZGlmZmVyZW50IGZyb20gdGhlIG90aGVyIDMueCwgYnV0 IGl0IGlzIGFib3V0IFBNSVB2NiBETU0gZXh0ZW5zaW9ucywgYW5kIHRoYXQncyB3aHkgSSBiZWxp ZXZlIGl0IGJlbG9uZ3MgdG8gU2VjdGlvbiAzLiBDcmVhdGluZyBhIHNlY3Rpb24gb24gaXRzIG93 biB3b3VsZCBwcm9iYWJseSBnaXZlIGl0IHRvbyBtdWNoIGZvY3VzLg0KDQoNClRoaXMgc2VjdGlv biBhbHNvIHVzZXMgRVVJLTY0IGZvciB0aGUgbGluay1sb2NhbCBhZGRyZXNzOyBhbmQsIHRoaXMg aXMgbm8gbW9yZQ0KYWR2aXNlZCBmb3IgcHJpdmFjeSByZWFzb24uIE5vdCByZWFsbHkgaW1wb3J0 YW50IGluIHRoZSBETU0gY29udGV4dCB0aG91Z2guDQoNCltDQl0gWWVzLCBJIGFncmVlLiBTaW5j ZSB0aGUgZXhlbXBsYXJ5IGFkZHJlc3NlcyBhcmUgbm90IHRoYXQgaW1wb3J0YW50LCBJJ3ZlIHJl bW92ZWQgdGhlbSBieSByZXdyaXRpbmcgdGhlIHRleHQgYXMgZm9sbG93czoNCg0KT0xEOg0KWy4u Ll0gcm91dGVyIHdpdGggYSBzcGVjaWZpYyBNQUMgKGUuZy4sIDAwOjExOjIyOjMzOjAxOjAxKSBh bmQgSVB2Ng0KYWRkcmVzc2VzIChlLmcuLCBwcmVmQTo6TUFBUjEvNjQgYW5kIGZlODA6MjExOjIy ZmY6ZmUzMzoxMDEvNjQpIHVzaW5nIFsuLi5dDQoNCk5FVzoNClsuLi5dIHJvdXRlciB3aXRoIGEg c3BlY2lmaWMgTUFDIGFuZCBJUHY2DQphZGRyZXNzZXMgKGUuZy4sIHByZWZBOjpNQUFSMS82NCBh bmQgZmU4MDo6TUFBUjEvNjQpIHVzaW5nIFsuLi5dDQoNCg0KSW1wb3J0YW50IHRoaW5nIHRvIGZp eCwgcy9mZTgwOjIxMToyMmZmOmZlMzM6MTAxL2ZlODA6OjIxMToyMmZmOmZlMzM6MTAxLyA7LSkN Cg0KW0NCXSBSaWdodCEgRml4ZWQgaW4gbXkgbmV3IHByb3Bvc2VkIHRleHQgYWJvdmUgKGZlODA6 Ok1BQVIxLzY0KS4NCg0KDQpUaGUgdGV4dCBvZiB0aGlzIHNlY3Rpb24gaXMgcmVhbGx5IGRpZmZp Y3VsdCB0byBwYXJzZS4gQWZ0ZXIgMiByZWFkaW5ncyBJIGFtDQpub3QgZXZlbiBzdXJlIHRoYXQg SSBnb3QgaXQuLi4gSSB3YXMgYWJvdXQgdG8gb3BlbiBhIERJU0NVU1MgZm9yIHRoZSBwb2ludCAy KQ0KYnV0IEkgYW0gdW5zdXJlIHdoZXRoZXIgSSBhbSByZWFkaW5nIHRoZSB0ZXh0IGNvcnJlY3Rs eS4NCg0KMSkgSWYgdGhlIE1BQyBhbmQgTExBIGZvciB0aGUgJ3ZpcnR1YWwgcm91dGVyJyBtbjFt YXIyIGFyZSBkaWZmZXJlbnQgdGhhbiB0aGUNCm9uZSBmb3IgbW4xbWFyMiwgd2h5IGlzIHRoZXJl IGEgbmVlZCBmb3IgZGlmZmVyZW50IGludGVyZmFjZT8gTXVsdGlwbGUgcm91dGVycw0KY2FuIGV4 aXN0IG9uIHRoZSBzYW1lIGxpbmsuDQoNCltDQl0gU2luY2UgbW4xbWFyMSBhbmQgbW4xbWFyMiBo YXZlIGRpZmZlcmVudCBNQUMgYWRkcmVzc2VzLCB3ZSBuZWVkIHRvIGhhdmUgYSBkaWZmZXJlbnQg ImxvZ2ljYWwiIGludGVyZmFjZSBvdmVyIHRoZSBzYW1lIHBoeXNpY2FsIGludGVyZmFjZSAoYXMg b25lIGludGVyZmFjZSBjYW4gb25seSBoYXZlIG9uZSBNQUMgYWRkcmVzcykuIFRoZXkgYWN0dWFs bHkgY28tZXhpc3Qgb24gdGhlIHNhbWUgbGluaywgYXMgdGhlIGRpc3RyaWJ1dGVkIGxvZ2ljYWwg aW50ZXJmYWNlIGlzIGp1c3QgYSBtZWNoYW5pc20gdG8gaGlkZSB0aGUgY2hhbmdlIG9mIGFuY2hv cnMgZnJvbSB0aGUgbW9iaWxlIG5vZGUuIFRoZSBtb2JpbGUgbm9kZSBhY3R1YWxseSAic2VlcyIg bXVsdGlwbGUgcm91dGVycyBvbiB0aGUgc2FtZSBsaW5rLCBldmVuIHRob3VnaCB0aGUgYW5jaG9y cyAoTUFBUnMpIGFyZSBub3QgYWN0dWFsbHkgb24gdGhhdCBzYW1lIGxpbmsuDQoNCg0KMikgRm9y IHBhY2tldHMgc291cmNlZCBieSBNTjEgd2l0aCBwcmVmaXgxIGhvdyBjYW4gd2UgZW5zdXJlIHRo YXQgdGhleSBhcmUgc2VudA0KdG8gbW4xbWFyMSBhbmQgbm90IHRvIG1uMW1hcj8gUHZEIGNvdWxk IGhlbHAgdGhlcmUgYW5kIHNob3VsZCBiZSBtZW50aW9ubmVkDQpkcmFmdC1pZXRmLWludGFyZWEt cHJvdmlzaW9uaW5nLWRvbWFpbnMuDQoNCltDQl0gVGhlIE1OLCBmb3IgZWFjaCBDTiBpdCBpcyBj b21tdW5pY2F0ZXMsIHVzZXMgdGhlIHNvdXJjZSBhZGRyZXNzIHRoYXQgd2FzIHNlbGVjdGVkIHdo ZW4gdGhlIGNvbW11bmljYXRpb24gd2FzIGluaXRpYXRlZCB3aXRoIHRoYXQgQ04uIEF0IGVhY2gg Z2l2ZW4gdGltZSwgb25seSBvbmUgKGdsb2JhbCkgSVB2NiBhZGRyZXNzIGlzIG5vdCBkZXByZWNh dGVkLCBhbmQgdGhlcmVmb3JlIHdoZW4gdGhlIE1OIGlzIGF0dGFjaGVkIHRvIE1BQVJYLCBvbmx5 IHRoZSBhZGRyZXNzIGFsbG9jYXRlZCBmcm9tIHRoZSBwcmVmaXggYW5jaG9yZWQgYXQgTUFBUlgg KGUuZy4gUHJlZlg6Ok1OKSBpcyBub24tZGVwcmVjYXRlZC4gSWYgdGhlIE1OIHZpc2l0ZWQgYmVm b3JlIG90aGVyIE1BQVJzIChlLmcuLCBNQUFSWSkgYW5kIGhhcyBhbiBhY3RpdmUgY29tbXVuaWNh dGlvbiB3aXRoIGEgQ04gdGhhdCB3YXMgZXN0YWJsaXNoZWQgd2hpbGUgTU4gd2FzIGF0dGFjaGVk IHRvIE1BQVJZIChlLmcuLCBQcmVmWTo6TU4pLCB0aGVuIHRoYXQgY29tbXVuaWNhdGlvbiB3aWxs IGNvbnRpbnVlIHVzaW5nIHRoZSBkZXByZWNhdGVkIGFkZHJlc3MgKFByZWZZOjpNTikuIERlcHJl Y2F0ZWQgYWRkcmVzc2VzIGNhbiBiZSB1c2VkIHdoaWxlIHRoZXJlIGFyZSBvbmdvaW5nIGNvbW11 bmljYXRpb25zIHVzaW5nIHRoZW0sIGJ1dCBmb3IgbmV3IGNvbW11bmljYXRpb25zIGEgbm9uLWRl cHJlY2F0ZWQgYWRkcmVzcyBpcyBwcmVmZXJyZWQgKGFjY29yZGluZyB0byBSRkMgNjcyNCkuIFRo ZW4sIGFjY29yZGluZyB0byBSRkMgMjQ2MSwgbmV4dC1ob3AgZGV0ZXJtaW5hdGlvbiBpcyBub3Qg cGVyZm9ybWVkIG9uIGV2ZXJ5IHBhY2tldCB0aGF0IGlzIHNlbnQsIGJ1dCB0aGUgcmVzdWx0cyBv ZiBuZXh0LWhvcA0KZGV0ZXJtaW5hdGlvbiBjb21wdXRhdGlvbnMgYXJlIHNhdmVkIGluIHRoZSBE ZXN0aW5hdGlvbiBDYWNoZSAod2hpY2ggd2lsbCBjb250YWluIHRoZSByaWdodCBtbjFtYXJYIGZv ciB0aGUgdXNlZCBzb3VyY2UgYWRkcmVzcyBpbiBhIGdpdmVuIGNvbW11bmljYXRpb24pLg0KDQoN Ci0tIFNlY3Rpb24gNC4yIC0tDQpCaXQgMzEgaXMgbm90IGRlc2NyaWJlZCwgaXQgaXMgcHJvYmFi bHkgcmVzZXJ2ZWQgYnV0IHlvdSBzaG91bGQgcmVhbGx5DQpkZXNjcmliZWQgaXQuDQoNCltDQl0g WWVzLCBpdCBpcyByZXNlcnZlZCBhbmQgdGhhdCdzIHdoeSB3ZSBkaWRuJ3QgZGVzY3JpYmUgaXQu IFNpbmNlIHRoZXJlIGlzIGEgYml0ICdSJyBkZWZpbmVkIGluIFJGQyAzOTYzLCBhbmQgdGhlcmUg aXMgb25seSBvbmUgYml0IGxlZnQgcmVzZXJ2ZWQgSSB3YXMgbm90IHN1cmUgaG93IHRvIHJlZmVy IHRvIGl0IGluIHRoZSBtZXNzYWdlIGZvcm1hdC4gT3RoZXIgbW9iaWxpdHkgUkZDcyBkZWZpbmlu ZyBuZXcgZmxhZ3MganVzdCBkZXNjcmliZSB0aGUgbmV3IG9uZXMgYW5kIHJlZmVyIHRvIFJGQyA2 Mjc1LCBidXQgSSBhZ3JlZSB0aGF0IHdoZW4gdGhlcmUgYXJlIG11bHRpcGxlIHJlc2VydmVkIGJp dHMgYW5kIHRoZSBtZXNzYWdlIGZvcm1hdCBmaWd1cmUgc2hvd3MgIlJlc2VyIiBvciBzb21ldGhp bmcgbGlrZSB0aGF0IGl0IGlzIG11Y2ggZWFzaWVyIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGVzZSBh cmUgbm90IHlldCBhc3NpZ25lZCBhbmQgeW91IGRvbid0IG5lZWQgdGV4dCB0byBleHBsYWluIGl0 LiBBbnkgYWR2aWNlIG9uIGhvdyB0byBkbyB0aGlzIGluIHRoaXMgY2FzZSBpbiB3aGljaCBvbmx5 IG9uZSBiaXQgaXMgbGVmdCByZXNlcnZlZD8NCg0KDQpXaXRoIHRoaXMgUEJBIHBhY2tldCBmb3Jt YXQsIGFsbCBmbGFncyAvIGJpdHMgYXJlIHVzZWQgYW5kIGFzc2lnbmVkIGZvciBhbg0KZXhwZXJp bWVudGFsIGRvY3VtZW50LiBJc24ndCBpdCBhIHdhc3RlIG9mIGJpdHM/IEkgd2lsbCByZWFsbHkg YXBwcmVjaWF0ZSBhbg0KYW5zd2VyIG9uIHRoaXMgcXVlc3Rpb24uDQoNCltDQl0gV2VsbCwgdGhp cyBpcyBhIGdvb2QgcXVlc3Rpb24uIEknbSBub3QgYXdhcmUgb2YgYW55IHBvbGljeSBhYm91dCBo b3cgdG8gYXNzaWduIGZsYWdzIHRvIHByb3RvY29scy4gSSBjYW4gb25seSBzYXkgdGhhdCB0aGVy ZSBhcmUgb3RoZXIgZXhwZXJpbWVudGFsIHByb3RvY29scyB1c2luZyBmbGFncyBvZiB0aGUgQmlu ZGluZyBVcGRhdGUgLyBCaW5kaW5nIEFja25vd2xlZGdlbWVudCBtZXNzYWdlcyByZWdpc3RlcmVk IGJ5IHRoZSBJQU5BLiBJIHRoaW5rIHRoZSB1c2Ugb2YgdGhlICdEJyBmbGFnIGlzIHdlbGwganVz dGlmaWVkLCBidXQgSSdtIG9mIGNvdXJzZSBiaWFzZWQgaGVyZSA6KQ0KDQoNCj09IE5JVFMgPT0N Cg0KLS0gU2VjdGlvbiAzIChhbmQgcG9zc2libHkgb3RoZXJzKSAtLQ0KVGhlIENNRCBhbmQgTUFB UiBhY3JvbnltcyBhcmUgZXhwYW5kZWQgbXVsdGlwbGUgdGltZXMuIFRoaXMgbWFrZXMgdGhlIHJl YWRpbmcNCmVhc2llciBmb3IgbmV3Y29tZXJzIG9mIGNvdXJzZS4NCg0KW0NCXSBJJ3ZlIHJlbW92 ZWQgc29tZSBvZiB0aGUgZHVwbGljYXRlZCBleHBhbnNpb25zLiBJIHN0aWxsIGtlcHQgdHdvIGJl Y2F1c2UgSSB0aGluayBpdCBtYWtlcyB0aGUgcmVhZGluZyBlYXNpZXIuIEl0IGlzIHByb2JhYmx5 IG5vdCB2ZXJ5IHJlbGV2YW50LCBidXQgSSB0aGluayBvbmUgb2YgdGhlIHJlYXNvbnMgd2UgZXhw YW5kIHRoZSB0ZXJtcyBzZXZlcmFsIHRpbWVzIGlzIGJlY2F1c2Ugd2UgZ290IGEgcmVxdWVzdCBp biBzb21lIG9mIHRoZSByZXZpZXdzIGF0IHRoZSBXRyB0byBkbyBzbywgYnV0IEknbSAxMDAlIHN1 cmUgYWJvdXQgdGhhdC4NCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzIQ0KDQpDYXJs b3MNCg== --_000_3D8BA7D2DEB74F3D89B908633F44F974ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tQkUi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5IZWxsbyBDYXJsb3MsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJlcGx5LCB0aGUgYW5zd2Vy cywgYW5kIHRoZSByZXZpc2VkLUlELiBJIHdpbGwgY2xlYXIgbXkgRElTQ1VTUyBpbiBhIGNvdXBs ZSBvZiBtaW51dGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hpbGUgSSBhbSBzbGlnaHRseSBkaXNh cHBvaW50ZWQgYnkgc29tZSBhbnN3ZXJzIChlLmcuLCBubyBtdWx0aS1ob21lKSwgSSB1bmRlcnN0 YW5kIHRoYXQgdGhpcyBpcyBhbiBleHBlcmltZW50YWwgZG9jdW1lbnQgYW5kIGxldOKAmXMgc3Rh cnQgdG8gd2FsayBiZWZvcmUgcnVubmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciB0aGUgYml0 IDMxIGluIHNlY3Rpb24gNC4yLCBJIHdvdWxkIHNpbXBseSBwdXQgYSDigJgw4oCZPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tw6lyaWM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+aWVzZyAmbHQ7aWVzZy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg Q0FSTE9TIEpFU1VTIEJFUk5BUkRPUyBDQU5PICZsdDtjamJjQGl0LnVjM20uZXMmZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPlN1bmRheSwgOCBNYXJjaCAyMDIwIGF0IDEzOjEwPGJyPg0KPGI+VG86IDwv Yj5FcmljIFZ5bmNrZSAmbHQ7ZXZ5bmNrZUBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4m cXVvdDtDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkmcXVvdDsgJmx0O2NwaWduYXRhQGNpc2Nv LmNvbSZndDssICZxdW90O2RyYWZ0LWlldGYtZG1tLXBtaXB2Ni1kbGlmQGlldGYub3JnJnF1b3Q7 ICZsdDtkcmFmdC1pZXRmLWRtbS1wbWlwdjYtZGxpZkBpZXRmLm9yZyZndDssIERhcGVuZyBMaXUg Jmx0O21heC5sZHBAYWxpYmFiYS1pbmMuY29tJmd0OywgZG1tLWNoYWlycyAmbHQ7ZG1tLWNoYWly c0BpZXRmLm9yZyZndDssIFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OywgZG1tICZsdDtk bW1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiDDiXJpYyBWeW5ja2UncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtZG1tLXBtaXB2Ni1kbGlmLTA1OiAod2l0aCBESVNDVVNTIGFu ZCBDT01NRU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPkhpIMOJcmljLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPlRoYW5rcyBhIGxvdCBmb3IgeW91ciByZXZpZXcuIFBsZWFzZSBzZWUg aW5saW5lIGJlbG93IG15IGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBNb24sIE1hciAyLCAyMDIwIGF0IDk6NTUgUE0gw4lyaWMg VnluY2tlIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5v cmciPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPsOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLWRtbS1wbWlwdjYtZGxpZi0wNTogRGlzY3Vzczxicj4N Cjxicj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRh Y3QgYW5kIHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg VG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJyPg0KaW50cm9kdWN0b3J5 IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIHJlZmVyIHRvIDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0 ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCmZvciBtb3JlIGluZm9ybWF0aW9u IGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJyPg0KPGJyPg0KPGJy Pg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtZG1tLXBtaXB2Ni1kbGlmLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG1tLXBtaXB2Ni1kbGlmLzwvYT48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KRElTQ1VTUzo8YnI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KVGhhbmsgeW91IGZvciB0aGUgd29yayBwdXQgaW50byB0 aGlzIGRvY3VtZW50LiBBbmQgY29uZ3JhdHVsYXRpb25zIGZvciB0aGUgbWFueTxicj4NCmFkdmFu Y2VkIEFTQ0lJIGFydCAhIEV4Y2VwdCBmb3Igc2VjdGlvbiAzLjYsIHRoZSB0ZXh0IGlzIHJlYWxs eSBlYXN5IHRvIHJlYWQuPGJyPg0KPGJyPg0KSSBoYXZlIGEgYmxvY2sgRElTQ1VTUyBiZWxvdyBi dXQgaXQgc2hvdWxkIGJlIHRyaXZpYWwgdG8gZml4Ljxicj4NCjxicj4NClBsZWFzZSBhbHNvIGFk ZHJlc3MgdGhlIHBvaW50cyByYWlzZWQgYnkgQ2FybG9zIGR1cmluZyB0aGUgSU5UIGRpcmVjdG9y YXRlPGJyPg0KcmV2aWV3LiBUaGFuayB5b3UgYWdhaW4gQ2FybG9zICE8YnI+DQo8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZXZpZXctaWV0Zi1kbW0tcG1pcHY2LWRs aWYtMDUtaW50ZGlyLXRlbGVjaGF0LXBpZ25hdGFyby0yMDIwLTAyLTI4LyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3Jldmlldy1pZXRmLWRtbS1wbWlw djYtZGxpZi0wNS1pbnRkaXItdGVsZWNoYXQtcGlnbmF0YXJvLTIwMjAtMDItMjgvPC9hPjxicj4N Cjxicj4NCkkgaG9wZSB0aGF0IHRoaXMgaGVscHMgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQsPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5b Q0JdIFRoYW5rcy4gSSd2ZSBhZGRyZXNzZWQgdGhlIGNvbW1lbnRzIGZyb20gQ2FybG9zIGluIHZl cnNpb24gLTA2ICh0byBiZSBzdWJtaXR0ZWQgc29vbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxicj4NClJlZ2FyZHMsPGJy Pg0KPGJyPg0KLcOpcmljPGJyPg0KPGJyPg0KPT0gRElTQ1VTUyA9PTxicj4NCjxicj4NCi0tIFNl Y3Rpb24gNC4zICZhbXA7IDQuNCAmYW1wOyA0LjUgLS08YnI+DQpQcm9iYWJseSB0cml2aWFsIHRv IGZpeCBidXQgaXMgJnF1b3Q7UHJlZml4IExlbmd0aCZxdW90OyBleHByZXNzZWQgaW4gYml0cyAo LzY0KSBvciBpbjxicj4NCmJ5dGVzICg4IGJ5dGVzKS4gSWYgdGhlIGxhdHRlciwgdGhlbiBob3cg Y2FuIHdlIGhhdmUgYSBwcmVmaXggb2YgLzU3ID8gVGhlPGJyPg0KZGVmaW5pdGlvbiBvZiB0aGUg JnF1b3Q7UHJlZml4IGxlbmd0aCZxdW90OyBmaWVsZCBzaG91bGQgYmUgc3BlY2lmaWMgYWJvdXQg dGhlIHVuaXQ8YnI+DQooYml0cy9ieXRlcykgYW5kIGJlIGFsaWduZWQgd2l0aCB0aGUgZGVmaW5p dGlvbiBvZiAmcXVvdDtBbmNob3JlZCBwcmVmaXgmcXVvdDsgKGFzIHRoaXM8YnI+DQpvbmUgc2Vl bXMgdG8gYXNzZXJ0IHRoYXQgdGhlIHByZWZpeCBsZW5ndGggbXVzdCBiZSBhIG11bHRpcGxlIG9m IDgpLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPltDQl0gVGhlIHByZWZpeCBsZW5ndGgg aXMgZXhwcmVzc2VkIGluIGJpdHMuIEkndmUgY2xhcmlmaWVkIHRoaXMgaW4gdGhlIHRleHQuIEkn dmUgYWxzbyBmaXhlZCB0aGlzIGluIHRoZSAmcXVvdDtBbmNob3JlZCBwcmVmaXgmcXVvdDsgZGVm aW5pdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkNPTU1FTlQ6PGJyPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCjxicj4NCj09IENPTU1FTlRTID09PGJyPg0KPGJyPg0KQSBnZW5lcmljIHF1ZXN0 aW9uLCBjYW4gYSBNTiBiZSBhdHRhY2hlZCB0byBtdWx0aXBsZSBNQUFSIGF0IHRoZSBzYW1lIHRp bWU/PGJyPg0KSS5lLiwgb25jZSBvdmVyIFdpRmkgYW5kIG9uY2Ugb2YgM0dQUCA/IFRoZXJlIHNl ZW1zIHRvIGJlIG9ubHkgb25lIFMtTUFBUiBhdDxicj4NCmFueSB0aW1lLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+W0NCXSBUaGUgZG9j dW1lbnQgYXNzdW1lcyBvbmx5IFMtTUFBUiBhdCBhIHRpbWUuIEFkZGluZyBzdXBwb3J0IGZvciBt dWx0aXBsZSBTLU1BQVJzIGF0IHRoZSBzYW1lIHRpbWUgY291bGQgYmUgZmVhc2libGUsIGJ1dCBp dCdkIGFkZCBjb21wbGV4aXR5LiBJTUhPIGl0J3MgYmV0dGVyIHRvIHNlZSB0aGUgcG90ZW50aWFs IGFkb3B0aW9uIG9mIHRoaXMgc29sdXRpb24NCiBhbmQgZ2FpbiBmcm9tIGltcGxlbWVudGF0aW9u IGV4cGVyaWVuY2UgYmVmb3JlIGdvaW5nIGludG8gYWRkaW5nIHN1cHBvcnQgZm9yIG11bHRpcGxl IFMtTUFBUnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxicj4NCi0tIFNlY3Rpb24gMy4xIC0tPGJyPg0KU2hvdWxkIHRoZSBsZW5ndGgg b2YgdGhlIHByZWZpeCBhc3NpZ25lZCB0byB0aGUgTU4gYmUgc3BlY2lmaWVkPyBBZGRpbmcgYSAv NjQ8YnI+DQp3b3VsZCBtYWtlIHRoaW5ncyBjbGVhcmVyIHdpdGhvdXQgdXNpbmcgdG9vIG11Y2gg b2YgdGV4dC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPltDQl0gSSBhZ3JlZSBpdCBjb3VsZCBiZSBhZGRlZCBhbmQgYmUgaGVscGZ1bCwg YnV0IHNpbmNlIHRoZSBtZXNzYWdlIG9wdGlvbnMgZGVmaW5lZCBjb3VsZCBzdXBwb3J0IG90aGVy IHByZWZpeCBsZW5ndGhzICh0aG91Z2ggSSBhZ3JlZSAvNjQgd291bGQgYmUgb25lIG1vc3Qgb2Yg dGhlIHRpbWVzKSwgdXNpbmcgLzY0IGluIFNlY3Rpb24gMy4xIGNvdWxkIGxlYWQNCiB0byBhc3N1 bWUgdGhhdCBvbmx5IHRoYXQgcHJlZml4IGxlbmd0aCBpcyB2YWxpZC4gQnV0IGlmIHlvdSB0aGlu ayBpdCdzIGJldHRlciB0byBhZGQgaXQsIEkgY2FuIGRvIGl0IChJIGRvbid0IGhhdmUgYSBzdHJv bmcgb3BpbmlvbiBhZ2FpbnN0KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KRm9yIG15IG93biBjdXJpb3NpdHksIHRoZSB0ZXh0 IGlzIGFib3V0ICZxdW90O0lQdjYgZ2xvYmFsIHByZWZpeCZxdW90OywgYnV0LCB3b3VsZCBVTEE8 YnI+DQphbHNvIHdvcmsgPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+W0NCXSBJIHRoaW5rIGl0IHdvdWxkIGFzIHdlbGwuIEkgYWx3YXlz IHRlbmQgdG8gdGhpbmsgdGhhdCBtb2JpbGl0eSBzb2x1dGlvbnMgb25seSBtYWtlIHNlbnNlIGlu IGdsb2JhbCBzY2VuYXJpb3MsIGJ1dCB0aGVyZSBpcyBub3RoaW5nIHByZXZlbnRpbmcgaXQgdG8g dXNlIHRoZSBtZWNoYW5pc21zIHdpdGggVUxBLiBJIGFsc28gdHJpZWQgdG8gZm9sbG93IGFzIG11 Y2gNCiBhcyBwb3NzaWJsZSBSRkMgNTIxMyB0ZXJtaW5vbG9neSBhbmQgdGhlcmUgJnF1b3Q7Z2xv YmFsJnF1b3Q7IGlzIHVzZWQuIEkndmUga2VwdCB0aGUgJnF1b3Q7Z2xvYmFsJnF1b3Q7IGZvciB0 aGUgdGltZSBiZWluZywgYnV0IGl0IGNhbiBiZSByZW1vdmVkLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQotLSBTZWN0 aW9uIDMuNiAtLTxicj4NClRoaXMgc2VjdGlvbiBpcyBzbyBkaWZmZXJlbnQgdGhhbiB0aGUgcHJl dmlvdXMgb25lcyBpbiBzZWN0aW9uIDMsIHRoYXQgSSB3b3VsZDxicj4NCmhhdmUgY3JlYXRlZCBh IHNlY3Rpb24gb24gaXRzIG93bi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPltDQl0gSSBhZ3JlZSBzZWN0aW9uIDMuNiAod2hpY2ggaXMg c2VjdGlvbiAzLjcgaW4gdmVyc2lvbiAtMDYpIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBvdGhlciAz LngsIGJ1dCBpdCBpcyBhYm91dCBQTUlQdjYgRE1NIGV4dGVuc2lvbnMsIGFuZCB0aGF0J3Mgd2h5 IEkgYmVsaWV2ZSBpdCBiZWxvbmdzIHRvIFNlY3Rpb24gMy4gQ3JlYXRpbmcgYSBzZWN0aW9uIG9u IGl0cw0KIG93biB3b3VsZCBwcm9iYWJseSBnaXZlIGl0IHRvbyBtdWNoIGZvY3VzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQpU aGlzIHNlY3Rpb24gYWxzbyB1c2VzIEVVSS02NCBmb3IgdGhlIGxpbmstbG9jYWwgYWRkcmVzczsg YW5kLCB0aGlzIGlzIG5vIG1vcmU8YnI+DQphZHZpc2VkIGZvciBwcml2YWN5IHJlYXNvbi4gTm90 IHJlYWxseSBpbXBvcnRhbnQgaW4gdGhlIERNTSBjb250ZXh0IHRob3VnaC48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPltDQl0gWWVzLCBJ IGFncmVlLiBTaW5jZSB0aGUgZXhlbXBsYXJ5IGFkZHJlc3NlcyBhcmUgbm90IHRoYXQgaW1wb3J0 YW50LCBJJ3ZlIHJlbW92ZWQgdGhlbSBieSByZXdyaXRpbmcgdGhlIHRleHQgYXMgZm9sbG93czo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T0xEOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Wy4uLl0gcm91dGVyIHdpdGggYSBzcGVjaWZpYyBNQUMgKGUu Zy4sIDAwOjExOjIyOjMzOjAxOjAxKSBhbmQgSVB2NjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+YWRk cmVzc2VzIChlLmcuLCBwcmVmQTo6TUFBUjEvNjQgYW5kIGZlODA6MjExOjIyZmY6ZmUzMzoxMDEv NjQpIHVzaW5nIFsuLi5dPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPk5FVzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlsuLi5dIHJvdXRlciB3aXRoIGEg c3BlY2lmaWMgTUFDIGFuZCBJUHY2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmFkZHJlc3NlcyAoZS5nLiwgcHJl ZkE6Ok1BQVIxLzY0IGFuZCBmZTgwOjpNQUFSMS82NCkgdXNpbmcgWy4uLl0NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KSW1wb3J0YW50IHRo aW5nIHRvIGZpeCwgcy9mZTgwOjIxMToyMmZmOmZlMzM6MTAxL2ZlODA6OjIxMToyMmZmOmZlMzM6 MTAxLyA7LSk8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPltDQl0gUmlnaHQhIEZpeGVkIGluIG15IG5ldyBwcm9wb3NlZCB0ZXh0IGFib3Zl IChmZTgwOjpNQUFSMS82NCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxicj4NClRoZSB0ZXh0IG9mIHRoaXMgc2VjdGlvbiBpcyByZWFs bHkgZGlmZmljdWx0IHRvIHBhcnNlLiBBZnRlciAyIHJlYWRpbmdzIEkgYW08YnI+DQpub3QgZXZl biBzdXJlIHRoYXQgSSBnb3QgaXQuLi4gSSB3YXMgYWJvdXQgdG8gb3BlbiBhIERJU0NVU1MgZm9y IHRoZSBwb2ludCAyKTxicj4NCmJ1dCBJIGFtIHVuc3VyZSB3aGV0aGVyIEkgYW0gcmVhZGluZyB0 aGUgdGV4dCBjb3JyZWN0bHkuPGJyPg0KPGJyPg0KMSkgSWYgdGhlIE1BQyBhbmQgTExBIGZvciB0 aGUgJ3ZpcnR1YWwgcm91dGVyJyBtbjFtYXIyIGFyZSBkaWZmZXJlbnQgdGhhbiB0aGU8YnI+DQpv bmUgZm9yIG1uMW1hcjIsIHdoeSBpcyB0aGVyZSBhIG5lZWQgZm9yIGRpZmZlcmVudCBpbnRlcmZh Y2U/IE11bHRpcGxlIHJvdXRlcnM8YnI+DQpjYW4gZXhpc3Qgb24gdGhlIHNhbWUgbGluay48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPltD Ql0gU2luY2UgbW4xbWFyMSBhbmQgbW4xbWFyMiBoYXZlIGRpZmZlcmVudCBNQUMgYWRkcmVzc2Vz LCB3ZSBuZWVkIHRvIGhhdmUgYSBkaWZmZXJlbnQgJnF1b3Q7bG9naWNhbCZxdW90OyBpbnRlcmZh Y2Ugb3ZlciB0aGUgc2FtZSBwaHlzaWNhbCBpbnRlcmZhY2UgKGFzIG9uZSBpbnRlcmZhY2UgY2Fu IG9ubHkgaGF2ZSBvbmUgTUFDIGFkZHJlc3MpLiBUaGV5IGFjdHVhbGx5IGNvLWV4aXN0DQogb24g dGhlIHNhbWUgbGluaywgYXMgdGhlIGRpc3RyaWJ1dGVkIGxvZ2ljYWwgaW50ZXJmYWNlIGlzIGp1 c3QgYSBtZWNoYW5pc20gdG8gaGlkZSB0aGUgY2hhbmdlIG9mIGFuY2hvcnMgZnJvbSB0aGUgbW9i aWxlIG5vZGUuIFRoZSBtb2JpbGUgbm9kZSBhY3R1YWxseSAmcXVvdDtzZWVzJnF1b3Q7IG11bHRp cGxlIHJvdXRlcnMgb24gdGhlIHNhbWUgbGluaywgZXZlbiB0aG91Z2ggdGhlIGFuY2hvcnMgKE1B QVJzKSBhcmUgbm90IGFjdHVhbGx5IG9uIHRoYXQgc2FtZQ0KIGxpbmsuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjIpIEZvciBw YWNrZXRzIHNvdXJjZWQgYnkgTU4xIHdpdGggcHJlZml4MSBob3cgY2FuIHdlIGVuc3VyZSB0aGF0 IHRoZXkgYXJlIHNlbnQ8YnI+DQp0byBtbjFtYXIxIGFuZCBub3QgdG8gbW4xbWFyPyBQdkQgY291 bGQgaGVscCB0aGVyZSBhbmQgc2hvdWxkIGJlIG1lbnRpb25uZWQ8YnI+DQpkcmFmdC1pZXRmLWlu dGFyZWEtcHJvdmlzaW9uaW5nLWRvbWFpbnMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5bQ0JdIFRoZSBNTiwgZm9yIGVhY2ggQ04gaXQg aXMgY29tbXVuaWNhdGVzLCB1c2VzIHRoZSBzb3VyY2UgYWRkcmVzcyB0aGF0IHdhcyBzZWxlY3Rl ZCB3aGVuIHRoZSBjb21tdW5pY2F0aW9uIHdhcyBpbml0aWF0ZWQgd2l0aCB0aGF0IENOLiBBdCBl YWNoIGdpdmVuIHRpbWUsIG9ubHkgb25lIChnbG9iYWwpIElQdjYgYWRkcmVzcyBpcyBub3QgZGVw cmVjYXRlZCwgYW5kDQogdGhlcmVmb3JlIHdoZW4gdGhlIE1OIGlzIGF0dGFjaGVkIHRvIE1BQVJY LCBvbmx5IHRoZSBhZGRyZXNzIGFsbG9jYXRlZCBmcm9tIHRoZSBwcmVmaXggYW5jaG9yZWQgYXQg TUFBUlggKGUuZy4gUHJlZlg6Ok1OKSBpcyBub24tZGVwcmVjYXRlZC4gSWYgdGhlIE1OIHZpc2l0 ZWQgYmVmb3JlIG90aGVyIE1BQVJzIChlLmcuLCBNQUFSWSkgYW5kIGhhcyBhbiBhY3RpdmUgY29t bXVuaWNhdGlvbiB3aXRoIGEgQ04gdGhhdCB3YXMgZXN0YWJsaXNoZWQgd2hpbGUNCiBNTiB3YXMg YXR0YWNoZWQgdG8gTUFBUlkmbmJzcDsoZS5nLiwgUHJlZlk6Ok1OKSwgdGhlbiB0aGF0IGNvbW11 bmljYXRpb24gd2lsbCBjb250aW51ZSB1c2luZyB0aGUgZGVwcmVjYXRlZCBhZGRyZXNzIChQcmVm WTo6TU4pLiBEZXByZWNhdGVkIGFkZHJlc3NlcyBjYW4gYmUgdXNlZCB3aGlsZSB0aGVyZSBhcmUg b25nb2luZyBjb21tdW5pY2F0aW9ucyB1c2luZyB0aGVtLCBidXQgZm9yIG5ldyBjb21tdW5pY2F0 aW9ucyBhIG5vbi1kZXByZWNhdGVkIGFkZHJlc3MNCiBpcyBwcmVmZXJyZWQgKGFjY29yZGluZyB0 byBSRkMgNjcyNCkuIFRoZW4sIGFjY29yZGluZyB0byBSRkMgMjQ2MSwgbmV4dC1ob3AgZGV0ZXJt aW5hdGlvbiBpcyBub3QgcGVyZm9ybWVkIG9uIGV2ZXJ5IHBhY2tldCB0aGF0IGlzIHNlbnQsIGJ1 dCB0aGUgcmVzdWx0cyBvZiBuZXh0LWhvcDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5kZXRlcm1pbmF0aW9uIGNv bXB1dGF0aW9ucyBhcmUgc2F2ZWQgaW4gdGhlIERlc3RpbmF0aW9uIENhY2hlICh3aGljaCB3aWxs IGNvbnRhaW4gdGhlIHJpZ2h0IG1uMW1hclggZm9yIHRoZSB1c2VkIHNvdXJjZSBhZGRyZXNzIGlu IGEgZ2l2ZW4gY29tbXVuaWNhdGlvbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48YnI+DQotLSBTZWN0aW9uIDQuMiAtLTxicj4NCkJpdCAzMSBpcyBu b3QgZGVzY3JpYmVkLCBpdCBpcyBwcm9iYWJseSByZXNlcnZlZCBidXQgeW91IHNob3VsZCByZWFs bHk8YnI+DQpkZXNjcmliZWQgaXQuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5bQ0JdIFllcywgaXQgaXMgcmVzZXJ2ZWQgYW5kIHRoYXQn cyB3aHkgd2UgZGlkbid0IGRlc2NyaWJlIGl0LiBTaW5jZSB0aGVyZSBpcyBhIGJpdCAnUicgZGVm aW5lZCBpbiBSRkMgMzk2MywgYW5kIHRoZXJlIGlzIG9ubHkgb25lIGJpdCBsZWZ0IHJlc2VydmVk IEkgd2FzIG5vdCBzdXJlIGhvdyB0byByZWZlciB0byBpdCBpbiB0aGUgbWVzc2FnZSBmb3JtYXQu IE90aGVyDQogbW9iaWxpdHkgUkZDcyBkZWZpbmluZyBuZXcgZmxhZ3MganVzdCBkZXNjcmliZSB0 aGUgbmV3IG9uZXMgYW5kIHJlZmVyIHRvIFJGQyA2Mjc1LCBidXQgSSBhZ3JlZSB0aGF0IHdoZW4g dGhlcmUgYXJlIG11bHRpcGxlIHJlc2VydmVkIGJpdHMgYW5kIHRoZSBtZXNzYWdlIGZvcm1hdCBm aWd1cmUgc2hvd3MgJnF1b3Q7UmVzZXImcXVvdDsgb3Igc29tZXRoaW5nIGxpa2UgdGhhdCBpdCBp cyBtdWNoIGVhc2llciB0byB1bmRlcnN0YW5kIHRoYXQgdGhlc2UgYXJlIG5vdA0KIHlldCBhc3Np Z25lZCBhbmQgeW91IGRvbid0IG5lZWQgdGV4dCB0byBleHBsYWluIGl0LiBBbnkgYWR2aWNlIG9u IGhvdyB0byBkbyB0aGlzIGluIHRoaXMgY2FzZSBpbiB3aGljaCBvbmx5IG9uZSBiaXQgaXMgbGVm dCByZXNlcnZlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PGJyPg0KV2l0aCB0aGlzIFBCQSBwYWNrZXQgZm9ybWF0LCBhbGwgZmxhZ3Mg LyBiaXRzIGFyZSB1c2VkIGFuZCBhc3NpZ25lZCBmb3IgYW48YnI+DQpleHBlcmltZW50YWwgZG9j dW1lbnQuIElzbid0IGl0IGEgd2FzdGUgb2YgYml0cz8gSSB3aWxsIHJlYWxseSBhcHByZWNpYXRl IGFuPGJyPg0KYW5zd2VyIG9uIHRoaXMgcXVlc3Rpb24uPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5bQ0JdIFdlbGwsIHRoaXMgaXMgYSBn b29kIHF1ZXN0aW9uLiBJJ20gbm90IGF3YXJlIG9mIGFueSBwb2xpY3kgYWJvdXQgaG93IHRvIGFz c2lnbiBmbGFncyB0byBwcm90b2NvbHMuIEkgY2FuIG9ubHkgc2F5IHRoYXQgdGhlcmUgYXJlIG90 aGVyIGV4cGVyaW1lbnRhbCBwcm90b2NvbHMgdXNpbmcgZmxhZ3Mgb2YgdGhlIEJpbmRpbmcgVXBk YXRlIC8gQmluZGluZyBBY2tub3dsZWRnZW1lbnQNCiBtZXNzYWdlcyByZWdpc3RlcmVkIGJ5IHRo ZSBJQU5BLiBJIHRoaW5rIHRoZSB1c2Ugb2YgdGhlICdEJyBmbGFnIGlzIHdlbGwganVzdGlmaWVk LCBidXQgSSdtIG9mIGNvdXJzZSBiaWFzZWQgaGVyZSA6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo9PSBOSVRTID09PGJyPg0K PGJyPg0KLS0gU2VjdGlvbiAzIChhbmQgcG9zc2libHkgb3RoZXJzKSAtLTxicj4NClRoZSBDTUQg YW5kIE1BQVIgYWNyb255bXMgYXJlIGV4cGFuZGVkIG11bHRpcGxlIHRpbWVzLiBUaGlzIG1ha2Vz IHRoZSByZWFkaW5nPGJyPg0KZWFzaWVyIGZvciBuZXdjb21lcnMgb2YgY291cnNlLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+W0NCXSBJ J3ZlIHJlbW92ZWQgc29tZSBvZiB0aGUgZHVwbGljYXRlZCBleHBhbnNpb25zLiBJIHN0aWxsIGtl cHQgdHdvIGJlY2F1c2UgSSB0aGluayBpdCBtYWtlcyB0aGUgcmVhZGluZyBlYXNpZXIuIEl0IGlz IHByb2JhYmx5IG5vdCB2ZXJ5IHJlbGV2YW50LCBidXQgSSB0aGluayBvbmUgb2YgdGhlIHJlYXNv bnMgd2UgZXhwYW5kIHRoZSB0ZXJtcyBzZXZlcmFsIHRpbWVzDQogaXMgYmVjYXVzZSB3ZSBnb3Qg YSByZXF1ZXN0IGluIHNvbWUgb2YgdGhlIHJldmlld3MgYXQgdGhlIFdHIHRvIGRvIHNvLCBidXQg SSdtIDEwMCUgc3VyZSBhYm91dCB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMhPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkNhcmxvczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3D8BA7D2DEB74F3D89B908633F44F974ciscocom_-- From nobody Sun Mar 8 16:50:33 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A597D3A0BC5 for ; Sun, 8 Mar 2020 16:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey15angtkhcM for ; Sun, 8 Mar 2020 16:50:28 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EA03A0BC1 for ; Sun, 8 Mar 2020 16:50:27 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id a13so9964902edh.3 for ; Sun, 08 Mar 2020 16:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xTeiaW9jz6xkYiFX43P+w0tI9z01ASH/mWaSqZO61KQ=; b=ZquaFJaLSr4vEM9PkrmJNZdP+XksBD0awEaVKZPdHjS6h/Etx7U18cVp5+3F2VgFll qV4QjWMyTsiPS+SoRGy69VZHBJml/Xr41hPtUB4A+v8Yb8ndb1l3EMaqfq56yJFXYejO k3FifuYmb5LQrLHLzk4leTcn8Dpx3Pn6KQt5a568r7H6G2X+qGiswOWSxtiW2FNt14TJ PBO0/UiLZ3jTVuwT88EtUjWjnGgJNZuF90P7W3hbZk5IjxDcwhisFV3TW0haK/SZTUXM NEiYhtpHR9FVInOIZ0IE2NL3JGvkLDKACmRqoZIZMSl/ewU3I7sq8eRZQSh/bZfEEzPY 8i+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xTeiaW9jz6xkYiFX43P+w0tI9z01ASH/mWaSqZO61KQ=; b=FkcV3uK2PgEU1eWaEPXcZBP9+W4cM/Q61zPnaVM5lKC5pAlkK/c5z7M5HyTh1G0hXy xmm+LB2DdQuXKGAlyPC6K8YHGa3lG2KkDRd7Pl2zVjlGCw3LM1C5aTN5x21vh2BCubGW Zpbk6YHGpVky/GnOBjx2qLZQt/jP+jlKCoH7E9AfD3QY4Ae4hBE4t/rBenXMMiGReC4r TUJ6SevKj6E4yZj3jKIHXPy+5GNz5LvoqBY6RCa4WLUHygymHapIT4nxARHgiR9z1uIk rxC0X/skFfrbCqjxNv5eOyO+/cGDG6QTxo0S8H6QMXqTlXvKuJG3A4yF8T0O5+dClP57 EfNw== X-Gm-Message-State: ANhLgQ2WWpyt0D5PF0+P66hU6eDhznpFNjqwqvhpqLlUGyeaa0ilz8Xd IMpEoOh11CUAu7vGWrWZBeT2agO0rFFL0E66Rf6S+A== X-Google-Smtp-Source: ADFU+vtUCRAsSP0fiIoTrzbGHiR/SadPK1EnpEpsTJLGsRPq/h1IafjHBuZvv2MQpgtgZzDaGmLW0C1PvOCFuxWFqeU= X-Received: by 2002:a05:6402:549:: with SMTP id i9mr14144145edx.323.1583711425535; Sun, 08 Mar 2020 16:50:25 -0700 (PDT) MIME-Version: 1.0 References: <158318249840.27483.9051628354202166127@ietfa.amsl.com> <3D8BA7D2-DEB7-4F3D-89B9-08633F44F974@cisco.com> In-Reply-To: <3D8BA7D2-DEB7-4F3D-89B9-08633F44F974@cisco.com> From: CARLOS JESUS BERNARDOS CANO Date: Mon, 9 Mar 2020 00:50:09 +0100 Message-ID: To: "Eric Vyncke (evyncke)" Cc: "Carlos Pignataro (cpignata)" , "draft-ietf-dmm-pmipv6-dlif@ietf.org" , Dapeng Liu , dmm-chairs , The IESG , dmm Content-Type: multipart/alternative; boundary="000000000000f23bdd05a0608c04" Archived-At: Subject: Re: [DMM] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-dmm-p?= =?utf-8?q?mipv6-dlif-05=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 23:50:31 -0000 --000000000000f23bdd05a0608c04 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks =C3=89ric! I've put '0' for bit 31 in Section 4.2 in future version -07. Carlos On Sun, Mar 8, 2020 at 10:33 PM Eric Vyncke (evyncke) wrote: > Hello Carlos, > > > > Thank you very much for your reply, the answers, and the revised-ID. I > will clear my DISCUSS in a couple of minutes. > > > > While I am slightly disappointed by some answers (e.g., no multi-home), I > understand that this is an experimental document and let=E2=80=99s start = to walk > before running. > > > > For the bit 31 in section 4.2, I would simply put a =E2=80=980=E2=80=99 > > > > Regards > > > > -=C3=A9ric > > > > *From: *iesg on behalf of CARLOS JESUS BERNARDOS > CANO > *Date: *Sunday, 8 March 2020 at 13:10 > *To: *Eric Vyncke > *Cc: *"Carlos Pignataro (cpignata)" , " > draft-ietf-dmm-pmipv6-dlif@ietf.org" , > Dapeng Liu , dmm-chairs , > The IESG , dmm > *Subject: *Re: =C3=89ric Vyncke's Discuss on draft-ietf-dmm-pmipv6-dlif-0= 5: > (with DISCUSS and COMMENT) > > > > Hi =C3=89ric, > > > > Thanks a lot for your review. Please see inline below my comments. > > > > On Mon, Mar 2, 2020 at 9:55 PM =C3=89ric Vyncke via Datatracker < > noreply@ietf.org> wrote: > > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-dmm-pmipv6-dlif-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. And congratulations for th= e > many > advanced ASCII art ! Except for section 3.6, the text is really easy to > read. > > I have a block DISCUSS below but it should be trivial to fix. > > Please also address the points raised by Carlos during the INT directorat= e > review. Thank you again Carlos ! > > https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-te= lechat-pignataro-2020-02-28/ > > I hope that this helps to improve the document, > > > > [CB] Thanks. I've addressed the comments from Carlos in version -06 (to b= e > submitted soon). > > > > > Regards, > > -=C3=A9ric > > =3D=3D DISCUSS =3D=3D > > -- Section 4.3 & 4.4 & 4.5 -- > Probably trivial to fix but is "Prefix Length" expressed in bits (/64) or > in > bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? Th= e > definition of the "Prefix length" field should be specific about the unit > (bits/bytes) and be aligned with the definition of "Anchored prefix" (as > this > one seems to assert that the prefix length must be a multiple of 8). > > [CB] The prefix length is expressed in bits. I've clarified this in the > text. I've also fixed this in the "Anchored prefix" definition. > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > =3D=3D COMMENTS =3D=3D > > A generic question, can a MN be attached to multiple MAAR at the same tim= e? > I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR > at > any time. > > > > [CB] The document assumes only S-MAAR at a time. Adding support for > multiple S-MAARs at the same time could be feasible, but it'd add > complexity. IMHO it's better to see the potential adoption of this soluti= on > and gain from implementation experience before going into adding support > for multiple S-MAARs. > > > > > -- Section 3.1 -- > Should the length of the prefix assigned to the MN be specified? Adding a > /64 > would make things clearer without using too much of text. > > > > [CB] I agree it could be added and be helpful, but since the message > options defined could support other prefix lengths (though I agree /64 > would be one most of the times), using /64 in Section 3.1 could lead to > assume that only that prefix length is valid. But if you think it's bette= r > to add it, I can do it (I don't have a strong opinion against). > > > > > For my own curiosity, the text is about "IPv6 global prefix", but, would > ULA > also work ? > > > > [CB] I think it would as well. I always tend to think that mobility > solutions only make sense in global scenarios, but there is nothing > preventing it to use the mechanisms with ULA. I also tried to follow as > much as possible RFC 5213 terminology and there "global" is used. I've ke= pt > the "global" for the time being, but it can be removed. > > > > > -- Section 3.6 -- > This section is so different than the previous ones in section 3, that I > would > have created a section on its own. > > > > [CB] I agree section 3.6 (which is section 3.7 in version -06) is > different from the other 3.x, but it is about PMIPv6 DMM extensions, and > that's why I believe it belongs to Section 3. Creating a section on its o= wn > would probably give it too much focus. > > > > > This section also uses EUI-64 for the link-local address; and, this is no > more > advised for privacy reason. Not really important in the DMM context thoug= h. > > > > [CB] Yes, I agree. Since the exemplary addresses are not that important, > I've removed them by rewriting the text as follows: > > > > OLD: > > [...] router with a specific MAC (e.g., 00:11:22:33:01:01) and IPv6 > > addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using [..= .] > > > > NEW: > > [...] router with a specific MAC and IPv6 > > addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using [...] > > > > > Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ > ;-) > > > > [CB] Right! Fixed in my new proposed text above (fe80::MAAR1/64). > > > > > The text of this section is really difficult to parse. After 2 readings I > am > not even sure that I got it... I was about to open a DISCUSS for the poin= t > 2) > but I am unsure whether I am reading the text correctly. > > 1) If the MAC and LLA for the 'virtual router' mn1mar2 are different than > the > one for mn1mar2, why is there a need for different interface? Multiple > routers > can exist on the same link. > > > > [CB] Since mn1mar1 and mn1mar2 have different MAC addresses, we need to > have a different "logical" interface over the same physical interface (as > one interface can only have one MAC address). They actually co-exist on t= he > same link, as the distributed logical interface is just a mechanism to hi= de > the change of anchors from the mobile node. The mobile node actually "see= s" > multiple routers on the same link, even though the anchors (MAARs) are no= t > actually on that same link. > > > > > 2) For packets sourced by MN1 with prefix1 how can we ensure that they ar= e > sent > to mn1mar1 and not to mn1mar? PvD could help there and should be mentionn= ed > draft-ietf-intarea-provisioning-domains. > > > > [CB] The MN, for each CN it is communicates, uses the source address that > was selected when the communication was initiated with that CN. At each > given time, only one (global) IPv6 address is not deprecated, and therefo= re > when the MN is attached to MAARX, only the address allocated from the > prefix anchored at MAARX (e.g. PrefX::MN) is non-deprecated. If the MN > visited before other MAARs (e.g., MAARY) and has an active communication > with a CN that was established while MN was attached to MAARY (e.g., > PrefY::MN), then that communication will continue using the deprecated > address (PrefY::MN). Deprecated addresses can be used while there are > ongoing communications using them, but for new communications a > non-deprecated address is preferred (according to RFC 6724). Then, > according to RFC 2461, next-hop determination is not performed on every > packet that is sent, but the results of next-hop > > determination computations are saved in the Destination Cache (which will > contain the right mn1marX for the used source address in a given > communication). > > > > > -- Section 4.2 -- > Bit 31 is not described, it is probably reserved but you should really > described it. > > > > [CB] Yes, it is reserved and that's why we didn't describe it. Since ther= e > is a bit 'R' defined in RFC 3963, and there is only one bit left reserved= I > was not sure how to refer to it in the message format. Other mobility RFC= s > defining new flags just describe the new ones and refer to RFC 6275, but = I > agree that when there are multiple reserved bits and the message format > figure shows "Reser" or something like that it is much easier to understa= nd > that these are not yet assigned and you don't need text to explain it. An= y > advice on how to do this in this case in which only one bit is left > reserved? > > > > > With this PBA packet format, all flags / bits are used and assigned for a= n > experimental document. Isn't it a waste of bits? I will really appreciate > an > answer on this question. > > > > [CB] Well, this is a good question. I'm not aware of any policy about how > to assign flags to protocols. I can only say that there are other > experimental protocols using flags of the Binding Update / Binding > Acknowledgement messages registered by the IANA. I think the use of the '= D' > flag is well justified, but I'm of course biased here :) > > > > > =3D=3D NITS =3D=3D > > -- Section 3 (and possibly others) -- > The CMD and MAAR acronyms are expanded multiple times. This makes the > reading > easier for newcomers of course. > > > > [CB] I've removed some of the duplicated expansions. I still kept two > because I think it makes the reading easier. It is probably not very > relevant, but I think one of the reasons we expand the terms several time= s > is because we got a request in some of the reviews at the WG to do so, bu= t > I'm 100% sure about that. > > > > Thanks a lot for your comments! > > > > Carlos > --000000000000f23bdd05a0608c04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks =C3=89ric!

I've put '0&#= 39; for bit 31 in Section 4.2 in future version -07.

Carlos

On Sun, Mar 8, 2020 at 10:33 PM Eric Vyncke (evyncke) <<= a href=3D"mailto:evyncke@cisco.com">evyncke@cisco.com> wrote:

Hello Carlos,=

=C2=A0

Thank you very much for your re= ply, the answers, and the revised-ID. I will clear my DISCUSS in a couple o= f minutes.

=C2=A0

While I am slightly disappointe= d by some answers (e.g., no multi-home), I understand that this is an exper= imental document and let=E2=80=99s start to walk before running.<= /u>

=C2=A0

For the bit 31 in section 4.2, = I would simply put a =E2=80=980=E2=80=99

=C2=A0

Regards

=C2=A0

-=C3=A9ric=

=C2=A0

From: iesg <iesg-bounces@ietf.org>= ; on behalf of CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Sunday, 8 March 2020 at 13:10
To: Eric Vyncke <evyncke@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "draft-i= etf-dmm-pmipv6-dlif@ietf.org" <draft-ietf-dmm-pmipv6-dlif@ietf.or= g>, Dapeng Liu <max.ldp@alibaba-inc.com>, dmm-chairs <dmm-chairs@ietf.org>, The = IESG <iesg@ietf.org>, dmm <dmm@ietf.= org>
Subject: Re: =C3=89ric Vyncke's Discuss on draft-ietf-dmm-pmipv6= -dlif-05: (with DISCUSS and COMMENT)

=C2=A0

Hi =C3=89ric, <= /u>

=C2=A0

Thanks a lot for your rev= iew. Please see inline below my comments.

=C2=A0

On Mon, Mar 2, 2020 at 9:= 55 PM =C3=89ric Vyncke via Datatracker <noreply@ietf.org> wrote:

=C3=89ric Vyncke has ente= red the following ballot position for
draft-ietf-dmm-pmipv6-dlif-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. And congratulations for the = many
advanced ASCII art ! Except for section 3.6, the text is really easy to rea= d.

I have a block DISCUSS below but it should be trivial to fix.

Please also address the points raised by Carlos during the INT directorate<= br> review. Thank you again Carlos !
https://datatracke= r.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-202= 0-02-28/

I hope that this helps to improve the document,

=C2=A0

[CB] Thanks. I've add= ressed the comments from Carlos in version -06 (to be submitted soon).

=C2=A0


Regards,

-=C3=A9ric

=3D=3D DISCUSS =3D=3D

-- Section 4.3 & 4.4 & 4.5 --
Probably trivial to fix but is "Prefix Length" expressed in bits = (/64) or in
bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? The<= br> definition of the "Prefix length" field should be specific about = the unit
(bits/bytes) and be aligned with the definition of "Anchored prefix&qu= ot; (as this
one seems to assert that the prefix length must be a multiple of 8).=

[CB] The prefix length is= expressed in bits. I've clarified this in the text. I've also fixe= d this in the "Anchored prefix" definition.

=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

=3D=3D COMMENTS =3D=3D

A generic question, can a MN be attached to multiple MAAR at the same time?=
I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR a= t
any time.

=C2=A0

[CB] The document assumes= only S-MAAR at a time. Adding support for multiple S-MAARs at the same tim= e could be feasible, but it'd add complexity. IMHO it's better to s= ee the potential adoption of this solution and gain from implementation experience before going into adding support f= or multiple S-MAARs.

=C2=A0


-- Section 3.1 --
Should the length of the prefix assigned to the MN be specified? Adding a /= 64
would make things clearer without using too much of text.

=C2=A0

[CB] I agree it could be = added and be helpful, but since the message options defined could support o= ther prefix lengths (though I agree /64 would be one most of the times), us= ing /64 in Section 3.1 could lead to assume that only that prefix length is valid. But if you think it's= better to add it, I can do it (I don't have a strong opinion against).=

=C2=A0


For my own curiosity, the text is about "IPv6 global prefix", but= , would ULA
also work ?

=C2=A0

[CB] I think it would as = well. I always tend to think that mobility solutions only make sense in glo= bal scenarios, but there is nothing preventing it to use the mechanisms wit= h ULA. I also tried to follow as much as possible RFC 5213 terminology and there "global" is used. I&#= 39;ve kept the "global" for the time being, but it can be removed= .=C2=A0

=C2=A0


-- Section 3.6 --
This section is so different than the previous ones in section 3, that I wo= uld
have created a section on its own.

=C2=A0

[CB] I agree section 3.6 = (which is section 3.7 in version -06) is different from the other 3.x, but = it is about PMIPv6 DMM extensions, and that's why I believe it belongs = to Section 3. Creating a section on its own would probably give it too much focus.

=C2=A0


This section also uses EUI-64 for the link-local address; and, this is no m= ore
advised for privacy reason. Not really important in the DMM context though.=

=C2=A0

[CB] Yes, I agree. Since = the exemplary addresses are not that important, I've removed them by re= writing the text as follows:

=C2=A0

OLD:

[...] router with a speci= fic MAC (e.g., 00:11:22:33:01:01) and IPv6

addresses (e.g., prefA::M= AAR1/64 and fe80:211:22ff:fe33:101/64) using [...]

=C2=A0

NEW:

[...] router with a speci= fic MAC and IPv6

addresses (e.g., prefA::M= AAR1/64 and fe80::MAAR1/64) using [...]

=C2=A0


Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ ;= -)

=C2=A0

[CB] Right! Fixed in my n= ew proposed text above (fe80::MAAR1/64).

=C2=A0


The text of this section is really difficult to parse. After 2 readings I a= m
not even sure that I got it... I was about to open a DISCUSS for the point = 2)
but I am unsure whether I am reading the text correctly.

1) If the MAC and LLA for the 'virtual router' mn1mar2 are differen= t than the
one for mn1mar2, why is there a need for different interface? Multiple rout= ers
can exist on the same link.

=C2=A0

[CB] Since mn1mar1 and mn= 1mar2 have different MAC addresses, we need to have a different "logic= al" interface over the same physical interface (as one interface can o= nly have one MAC address). They actually co-exist on the same link, as the distributed logical interface is just a mechanism= to hide the change of anchors from the mobile node. The mobile node actual= ly "sees" multiple routers on the same link, even though the anch= ors (MAARs) are not actually on that same link.

=C2=A0


2) For packets sourced by MN1 with prefix1 how can we ensure that they are = sent
to mn1mar1 and not to mn1mar? PvD could help there and should be mentionned=
draft-ietf-intarea-provisioning-domains.

=C2=A0

[CB] The MN, for each CN = it is communicates, uses the source address that was selected when the comm= unication was initiated with that CN. At each given time, only one (global)= IPv6 address is not deprecated, and therefore when the MN is attached to MAARX, only the address allocated fro= m the prefix anchored at MAARX (e.g. PrefX::MN) is non-deprecated. If the M= N visited before other MAARs (e.g., MAARY) and has an active communication = with a CN that was established while MN was attached to MAARY=C2=A0(e.g., PrefY::MN), then that communication w= ill continue using the deprecated address (PrefY::MN). Deprecated addresses= can be used while there are ongoing communications using them, but for new= communications a non-deprecated address is preferred (according to RFC 6724). Then, according to RFC 2461, next-ho= p determination is not performed on every packet that is sent, but the resu= lts of next-hop

determination computation= s are saved in the Destination Cache (which will contain the right mn1marX = for the used source address in a given communication).

=C2=A0


-- Section 4.2 --
Bit 31 is not described, it is probably reserved but you should really
described it.

=C2=A0

[CB] Yes, it is reserved = and that's why we didn't describe it. Since there is a bit 'R&#= 39; defined in RFC 3963, and there is only one bit left reserved I was not = sure how to refer to it in the message format. Other mobility RFCs defining new flags just describe the new ones and refer to R= FC 6275, but I agree that when there are multiple reserved bits and the mes= sage format figure shows "Reser" or something like that it is muc= h easier to understand that these are not yet assigned and you don't need text to explain it. Any advice on how = to do this in this case in which only one bit is left reserved?

=C2=A0


With this PBA packet format, all flags / bits are used and assigned for an<= br> experimental document. Isn't it a waste of bits? I will really apprecia= te an
answer on this question.

=C2=A0

[CB] Well, this is a good= question. I'm not aware of any policy about how to assign flags to pro= tocols. I can only say that there are other experimental protocols using fl= ags of the Binding Update / Binding Acknowledgement messages registered by the IANA. I think the use of the 'D' flag i= s well justified, but I'm of course biased here :)

=C2=A0


=3D=3D NITS =3D=3D

-- Section 3 (and possibly others) --
The CMD and MAAR acronyms are expanded multiple times. This makes the readi= ng
easier for newcomers of course.

=C2=A0

[CB] I've removed som= e of the duplicated expansions. I still kept two because I think it makes t= he reading easier. It is probably not very relevant, but I think one of the= reasons we expand the terms several times is because we got a request in some of the reviews at the WG to do so, but= I'm 100% sure about that.

=C2=A0

Thanks a lot for your com= ments!

=C2=A0

Carlos

--000000000000f23bdd05a0608c04-- From nobody Sun Mar 8 19:21:14 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A283A0E34; Sun, 8 Mar 2020 19:21:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <158372046477.6875.6642686964660459000@ietfa.amsl.com> Date: Sun, 08 Mar 2020 19:21:04 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-13.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 02:21:05 -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 WG of the IETF. Title : Protocol for Forwarding Policy Configuration (FPC) in DMM Authors : Satoru Matsushima Lyle Bertz Marco Liebsch Sri Gundavelli Danny Moses Charles E. Perkins Filename : draft-ietf-dmm-fpc-cpdp-13.txt Pages : 33 Date : 2020-03-08 Abstract: This document describes a way, called Forwarding Policy Configuration (FPC) to manage the separation of data-plane and control-plane. FPC defines a flexible mobility management system using FPC agent and FPC client functions. A FPC agent provides an abstract interface to the data-plane. The FPC client configures data-plane nodes by using the functions and abstractions provided by the FPC agent for the data- plane nodes. The data-plane abstractions presented in this document are extensible in order to support many different types of mobility management systems and data-plane functions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-13 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-fpc-cpdp-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-fpc-cpdp-13 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 Mar 11 22:00:59 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD2C3A0E0F; Wed, 11 Mar 2020 22:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Osrnerok; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sruwng55 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRrdROdKRv7z; Wed, 11 Mar 2020 22:00:46 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A4B3A0E0C; Wed, 11 Mar 2020 22:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51367; q=dns/txt; s=iport; t=1583989246; x=1585198846; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5vX7ADgzRlrnCOfYjQGSp2wJI4zoJIDguoSJL3IUKOY=; b=OsrnerokmHVGhOLbwA8PA7ZW8k2xPyI42SSkMHZv6FlbYxsI/C7tlA1s O0iqC128yJFpkXMKRFpn8eMDVRC8Fpd08TOWmoikGPwvqarw/C52cJ8/o DvE+OJyUwKnTluXuwjWXgSoBkBqLxrRZnr4DY/X6RqlbJ1l4ung3kKMLP 8=; IronPort-PHdr: =?us-ascii?q?9a23=3ANPVKERTJNWY0fOhEnDQqaaMTY9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiciHctEXUNs13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAgDiwGle/5FdJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4ElLyQsBWxYIAQLKoQVg0UDim6COpg6glIDVAkBAQE?= =?us-ascii?q?MAQElCAIEAQGBLgGDFAIXgXYkOBMCAwEBCwEBBQEBAQIBBQRthVYMhWQCAQM?= =?us-ascii?q?SER0BATAHAQ8CAQYCOAEGAwICAjAUEQIEDgUJEgeDBAGBfU0DLgEOjyeQZwK?= =?us-ascii?q?BOYhidYEygn8BAQWBMwKDYRiCDAmBOIwsGoFBP4ERJwwUgk0+glkLAQEBAQG?= =?us-ascii?q?BYRgWgmQygiyHWIYKgwmFc4oTjlJwCoI8h1aPFh2CSoglkEyQTIUqggaPI4M?= =?us-ascii?q?zAgQCBAUCDgEBBYFpIoFYcBVlAYJBCTUSGA2OHQkDF4NQhRSFQAF0AoEnjTI?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.70,543,1574121600"; d="scan'208,217";a="445948104" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2020 05:00:44 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 02C50iDW016295 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Mar 2020 05:00:44 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Mar 2020 00:00:44 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Mar 2020 00:00:43 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Mar 2020 00:00:43 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AcZ4CHwGkTxHEczFQwqVirujaVRpCXKZP0/pll7ISbb2uxDTpINPk14URqegGPES8kAPD+ErAkleLuEErORVPXz7rQ/YjLozIY/Gv3mEDqZtetR02k4HmdDuavbuxpM8smW2OKSKfg+FR6DlmruUwzqJJgBDn+jSphDPuk+3AuhEu9fanzGI0hR/hQajAVjNEa7NzVi7+ItOfFMpSKszoZdKvDFzT+mZM09FZ+QcshLzWU4KLRFzzDtqpv5Xr8en2XqI81SIPSZRRdY5KaKV/iw4W2a6u+Wjz2afQYX15rcdrsg1msm9nYajXQRlLD33jJ8MkWKh/MAJOHXwaQ1XWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5vX7ADgzRlrnCOfYjQGSp2wJI4zoJIDguoSJL3IUKOY=; b=ZNE2Bcei3VLR/TzWlyC95OgO6oFl/WAvLjv9kxEx+Y56f74LVKMY+qouDKQGNXfnQu/Q+UvaeClGfH1tANll0r64nNhHKpkVkrRPJBxfEvGTCCKxBFfbvadsRt94OXMtwvQ6hUgEMK6OL8nrSwvPSJWwVTRQy28G6u1LKd29OUWdwyatySOXp+o0LzbndA45wb+S8jJ+Bt6GUSBnUmJyKv7Raf/bd5PuoVt+qKEz83rzmrC0zR4twSGO0HrOz0uJRZSIonUlvo3yfzzXm6RNYdk6+WFY00niaePqO1j6etHTDB3rpbdos4tA2TC3F0WlwiPvOMzAJpPAIDlm3ZBOHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5vX7ADgzRlrnCOfYjQGSp2wJI4zoJIDguoSJL3IUKOY=; b=sruwng55lKtteV5TjZpga+hanfCRrChUAj3pVBFyr/Un6kTPipdRhE5Y22lfNpgcVEKJEfRz9lTsNFdMxRbl8FEiSzzHoaeooa3s4i1SoH5MIfxZg1BWvFxffxLBz8PInQE5ZGFl5WqyPVY+D7icOj9d6wgtPDDo5Nl6w09P6uM= Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3603.namprd11.prod.outlook.com (2603:10b6:408:8b::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.15; Thu, 12 Mar 2020 05:00:32 +0000 Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74%7]) with mapi id 15.20.2793.018; Thu, 12 Mar 2020 05:00:32 +0000 From: "Carlos Pignataro (cpignata)" To: CARLOS JESUS BERNARDOS CANO CC: "int-dir@ietf.org" , "last-call@ietf.org" , "draft-ietf-dmm-pmipv6-dlif.all@ietf.org" , "dmm@ietf.org" Thread-Topic: [Last-Call] Intdir telechat review of draft-ietf-dmm-pmipv6-dlif -05 Thread-Index: AQHV7q6FPaDeUcCKfk2s8DdKgaEjLag/FWsAgAVjh4A= Date: Thu, 12 Mar 2020 05:00:31 +0000 Message-ID: <473EA3D0-688D-4047-83B9-ED351937232A@cisco.com> References: <5480B86B-3D6B-490B-9CAC-609EE7A41278@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.60.0.2.5) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [2001:420:c0c8:1002::6b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ea32aa9f-d374-4668-0ad1-08d7c6424abf x-ms-traffictypediagnostic: BN8PR11MB3603: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0340850FCD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(136003)(366004)(396003)(199004)(4326008)(4743002)(478600001)(81156014)(71200400001)(2906002)(36756003)(6486002)(186003)(54906003)(66574012)(66476007)(8936002)(316002)(21615005)(66946007)(66446008)(6916009)(6512007)(2616005)(5660300002)(86362001)(19273905006)(76116006)(66556008)(91956017)(8676002)(33656002)(53546011)(6506007)(64756008)(966005)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3603; H:BN8PR11MB3635.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O/DX5qnkcs7xc/bo7rUy7sAzKuCV0T1hgAIV7qQVYjjyBNtj56sssxDfQ/6WzAN/59jnXWSvi4M7uorV+BNXOk81Nh94annHA9nFYZiCB69hJQ4jOpV89SW0JPxocvCxCVE8SeLxG185nMHG0IN91kEVououe59dqac5rViFtXo3ResZaV6mJKCHQyIVHtPB+YYhgsh6fqM1TzFY9r7BstoYMY1B6KNE97zELwvgS+058ZImm0uy2PSdgS2OciILLdXH0qILnnxIAYWrDBitroWJW61Kk84Kxx+1egOSVLPOnlIIIUpcz2AY1r4TStn1tA93NzrnXGlZpDc+EF+dRx0rB9x9JX/YG2BcSsND7MgzybdfOfpwH6jRbf2b/DxuttbfFaKY5wpi0/o58dwAerNupf0/bJfNCXW9PuY1ZWTtd4GI+r5WodPm/sIX3eN3ySeXnQX1ZsoYHbjZVMgCukpsfd4rhE1GFeAcPK1FodQzG43Ll1TvKSo2QX1637diJhWyIVa8QtVksfWNYyk0DQ== x-ms-exchange-antispam-messagedata: WWQXQR8zfnr2YCCuHgIIdgm7y/Gz9AZ6o8iNDmceTzvd1wgI/MQn4CJkCLICQZ21Ul47wfixnWjPOoMZ51IohSuJJz+z2ftS6y8ZRWDoUX3kGph6b7TxNKt6TgvjaHe0WpnwQRCGmpurlWXmaN9j/Wdo1gIxT9tsK0X0Hjpf7q8= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_473EA3D0688D404783B9ED351937232Aciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ea32aa9f-d374-4668-0ad1-08d7c6424abf X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 05:00:31.9030 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EnAJ4T3nDWZNpTJPmgYSUvMTbaAJRbxRpkesguaFq0/dyWGp8DXEZctEr6iumk1X9onokPr7an8kEtpYoydS7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3603 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [DMM] [Last-Call] Intdir telechat review of draft-ietf-dmm-pmipv6-dlif -05 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 05:00:50 -0000 --_000_473EA3D0688D404783B9ED351937232Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIENhcmxvcywNCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UhIFBsZWFzZSBzZWUgaW5saW5l LCBwcmVmYWNlZCB3aXRoIENNUC4NCg0KMjAyMC8wMy8wOCDljYjlvowwOjQz44CBQ0FSTE9TIEpF U1VTIEJFUk5BUkRPUyBDQU5PIDxjamJjQGl0LnVjM20uZXM8bWFpbHRvOmNqYmNAaXQudWMzbS5l cz4+44Gu44Oh44O844OrOg0KDQpIaSBDYXJsb3MsDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcu IFBsZWFzZSBmaW5kIGlubGluZSBiZWxvdyBteSBjb21tZW50cy4NCg0KT24gU2F0LCBGZWIgMjks IDIwMjAgYXQgNDoxNSBBTSBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNp c2NvLmNvbTxtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPj4gd3JvdGU6DQpSZXZpZXdlcjogQ2Fy bG9zIFBpZ25hdGFybw0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQoNCkkgYW0gYW4g YXNzaWduZWQgSU5UIGRpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIEludGVybmV0LURyYWZ0 LiAgVGhlc2UNCmNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0 IG9mIHRoZSBJbnRlcm5ldCBBcmVhIERpcmVjdG9ycy4NCkRvY3VtZW50IGVkaXRvcnMgYW5kIHNo ZXBoZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgdGhleQ0Kd291 bGQgdHJlYXQgY29tbWVudHMgZnJvbSBhbnkgb3RoZXIgSUVURiBjb250cmlidXRvcnMgYW5kIHJl c29sdmUgdGhlbSBhbG9uZw0Kd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQg aGF2ZSBiZWVuIHJlY2VpdmVkLiBGb3IgbW9yZSBkZXRhaWxzIG9uDQp0aGUgSU5UIERpcmVjdG9y YXRlLCBzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlLmh0bWwuDQoNCkkg aG9wZSB0aGVzZSBjb21tZW50cyBhcmUgY2xlYXIgYW5kIHVzZWZ1bC4NCg0KQXMgcmVxdWVzdGVk LCBmcm9tIHRoZSBJbnRlcm5ldCBhcmVhIERpcmVjdG9yYXRlIHJldmlldywgdGhlc2UgdHdvIERN TQ0KZG9jdW1lbnRzIGFyZSBiZWluZyByZXZpZXdlZCB0b2dldGhlcjoNCiogZHJhZnQtaWV0Zi1k bW0tZGlzdHJpYnV0ZWQtbW9iaWxpdHktYW5jaG9yaW5nLTE0DQoqIGRyYWZ0LWlldGYtZG1tLXBt aXB2Ni1kbGlmLTA1DQoNClRoaXMgZG9jdW1lbnQgZGVmaW5lcyBkaXN0cmlidXRlZCBtb2JpbGl0 eSBhbmNob3JpbmcsIGluIHRlcm1zIG9mIHRoZQ0KZGlmZmVyZW50IGNvbmZpZ3VyYXRpb25zIGFu ZCBmdW5jdGlvbnMgdG8gcHJvdmlkZSBJUCBtb2JpbGl0eSBzdXBwb3J0LA0KaW5jbHVkaW5nIG5l dHdvcmstYmFzZWQgb3IgaG9zdC1iYXNlZCBtb2JpbGl0eSBzdXBwb3J0Lg0KDQpUaGUgaW50ZW5k ZWQgc3RhdHVzIGlzIEluZm9ybWF0aW9uYWwuIEl0IGlzIGEgdmVyeSB3ZWxsIHdyaXR0ZW4gYW5k IGNvbXByZWhlbnNpdmUNCmRvY3VtZW50LiBJdCBpcyB0ZWNobmljYWxseSBzb3VuZC4NCg0KTm8g bWFqb3Igb3IgbWlub3IgaXNzdWVzLg0KDQpOaXRzOg0KDQpBIHNldCBvZiBzbWFsbCBuaXRzIGZv ciB5b3VyIGNvbnNpZGVyYXRpb24uDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgQXMgYSBNb2Jp bGUgTm9kZSAoTU4pIGF0dGFjaGVzIHRvIGFuIGFjY2VzcyByb3V0ZXIgYW5kIGVzdGFibGlzaGVz IGENCiAgIGxpbmsgYmV0d2VlbiB0aGVtLCBhIC82NCBJUHY2IHByZWZpeCBhbmNob3JlZCB0byB0 aGUgcm91dGVyIG1heSBiZQ0KICAgYXNzaWduZWQgdG8gdGhlIGxpbmsgZm9yIGV4Y2x1c2l2ZSB1 c2UgYnkgdGhlIE1OIFtSRkM2NDU5XS4gIFRoZSBNTg0KICAgbWF5IHRoZW4gY29uZmlndXJlIGEg Z2xvYmFsIElQdjYgYWRkcmVzcyBmcm9tIHRoaXMgcHJlZml4IGFuZCB1c2UgaXQNCiAgIGFzIHRo ZSBzb3VyY2UgSVAgYWRkcmVzcyBpbiBhIGZsb3cgdG8gY29tbXVuaWNhdGUgd2l0aCBpdHMNCiAg IGNvcnJlc3BvbmRlbnQgbm9kZSAoQ04pLg0KDQpDYXBpdGFsaXplOg0Kcy9jb3JyZXNwb25kZW50 IG5vZGUvQ29ycmVzcG9uZGVudCBOb2RlLw0KDQoyLiAgQ29udmVudGlvbnMgYW5kIFRlcm1pbm9s b2d5DQoNCiAgIFRoZXNlIGluY2x1ZGUgdGVybXMgc3VjaCBhcyBtb2JpbGUgbm9kZSAoTU4pLCBj b3JyZXNwb25kZW50IG5vZGUNCiAgIChDTiksIGhvbWUgYWdlbnQgKEhBKSwgaG9tZSBhZGRyZXNz IChIb0EpLCBjYXJlLW9mLWFkZHJlc3MgKENvQSksDQogICBsb2NhbCBtb2JpbGl0eSBhbmNob3Ig KExNQSksIGFuZCBtb2JpbGUgYWNjZXNzIGdhdGV3YXkgKE1BRykuDQoNCkNhcGl0YWxpemUg4oCc TW9iaWxlIE5vZGXigJ0gKGFzIHBlciDCpyAxKSwg4oCcQ29yZXNwb25kZW50IE5vZGXigJ0sIGV0 Yy4NCg0KU2ltaWxhciB3aXRoaW4gdGhpcyBzYW1lIMKnIDIsIOKAnG1vYmlsZSByb3V0ZXLigJ0s IGV0Yy4NClNhbWUgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgKGUuZy4sIOKAnHJvdXRlciBhZHZl cnRpc2VtZW50IChSQSnigJ0pDQoNCjQuMy4gIE1vYmlsaXR5IGNhc2UsIGFuY2hvciByZWxvY2F0 aW9uDQoNCiAgIFRoZSBJUCBwcmVmaXgvYWRkcmVzcyBhbmNob3JpbmcgbWF5IG1vdmUgd2l0aG91 dCBjaGFuZ2luZyB0aGUgSVANCiAgIHByZWZpeC9hZGRyZXNzIG9mIHRoZSBmbG93LiAgSGVyZSB0 aGUgTE0gYW5kIEZNIGZ1bmN0aW9ucyBpbiBGaWd1cmUgMQ0KICAgaW4gU2VjdGlvbiAzLjEgYXJl IGltcGxlbWVudGVkIGFzIHNob3duIGluIEZpZ3VyZSA3Lg0KDQrigJxGaWd1cmUgMSBpbiBTZWN0 aW9uIDMuMS4xIGFyZSBpbXBsZW1lbnRlZOKAnQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAg RmlndXJlIDc6IEFuY2hvciBtb2JpbGl0eQ0KDQpTaG91bGQgdGhpcyBmaWd1cmXigJlzIGxhYmVs IGJlIOKAnEFuY2hvciBSZWxvY2F0aW9u4oCdIGluc3RlYWQgb2Yg4oCYQW5jaG9yIG1vYmlsaXR5 4oCdPw0KDQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgQXMgc3RhdGVkIGluIFtS RkM3MzMzXSwgImEgRE1NIHNvbHV0aW9uIE1VU1Qgc3VwcG9ydGFueSBzZWN1cml0eQ0KDQpzL3N1 cHBvcnRhbnkvc3VwcG9ydCBhbnkvDQoNCjguMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQpU aGUgcmVsYXRpb25zaGlwIG9mIHRoaXMgZG9jdW1lbnQgYW5kIGRyYWZ0LWlldGYtZG1tLWRlcGxv eW1lbnQtbW9kZWxzIGlzIG1vc3RseSBjbGVhciwgdGhhbmsgeW91IGZvciB0aGF0Lg0KDQpJIGhv cGUgeW91IGZpZCB0aGVzZSBjb21tZW50cyB1c2VmdWwuDQoNCkNhcmxvcyBQaWduYXRhcm8uDQoN Cg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG1tLXBtaXB2Ni1kbGlm LTA1DQoNCkkgYW0gYW4gYXNzaWduZWQgSU5UIGRpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlz IEludGVybmV0LURyYWZ0LiAgVGhlc2UNCmNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkg Zm9yIHRoZSBiZW5lZml0IG9mIHRoZSBJbnRlcm5ldCBBcmVhIERpcmVjdG9ycy4NCkRvY3VtZW50 IGVkaXRvcnMgYW5kIHNoZXBoZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 IGxpa2UgdGhleQ0Kd291bGQgdHJlYXQgY29tbWVudHMgZnJvbSBhbnkgb3RoZXIgSUVURiBjb250 cmlidXRvcnMgYW5kIHJlc29sdmUgdGhlbSBhbG9uZw0Kd2l0aCBhbnkgb3RoZXIgTGFzdCBDYWxs IGNvbW1lbnRzIHRoYXQgaGF2ZSBiZWVuIHJlY2VpdmVkLiBGb3IgbW9yZSBkZXRhaWxzIG9uDQp0 aGUgSU5UIERpcmVjdG9yYXRlLCBzZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9y YXRlLmh0bWwuDQoNCkkgaG9wZSB0aGVzZSBjb21tZW50cyBhcmUgY2xlYXIgYW5kIHVzZWZ1bC4N Cg0KQXMgcmVxdWVzdGVkLCBmcm9tIHRoZSBJbnRlcm5ldCBhcmVhIERpcmVjdG9yYXRlIHJldmll dywgdGhlc2UgdHdvIERNTQ0KZG9jdW1lbnRzIGFyZSBiZWluZyByZXZpZXdlZCB0b2dldGhlcjoN CiogZHJhZnQtaWV0Zi1kbW0tZGlzdHJpYnV0ZWQtbW9iaWxpdHktYW5jaG9yaW5nLTE0DQoqIGRy YWZ0LWlldGYtZG1tLXBtaXB2Ni1kbGlmLTA1DQoNClRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYW4g YXBwcm9hY2ggdG8gZGlzdHJpYnV0ZWQgbW9iaWxpdHkgbWFuYWdlbWVudA0KYnkgZXh0ZW5kaW5n IG5ldHdvcmstYmFzZWQgbW9iaWxpdHkgcHJvdG9jb2xzIChsaWtlIFByb3h5IE1vYmlsZSBJUHY2 KS4gSW4NCnRoaXMgc29sdXRpb24sIG1vYmlsaXR5IHNlc3Npb25zIGFyZSBhbmNob3JlZCBhdCB0 aGUgbGFzdCBJUCBob3Agcm91dGVyLg0KDQpUaGlzIGRvY3VtZW504oCZcyBpbnRlbmRlZCBzdGF0 dXMgaXMgRXhwZXJpbWVudGFsLiBJdCBpcyB3ZWxsIHdyaXR0ZW4gZm9yIHN1Y2ggYSBjb21wbGV4 IGNvbXByZWhlbnNpdmUgZG9jdW1lbnQsIGFuZCB0ZWNobmljYWxseSBjb21wbGV0ZSBhbmQgc2Vu c2libGUuDQoNCk5vIG1ham9yIG9yIG1pbm9yIGlzc3Vlcy4NCg0KTml0czoNCg0KUGxlYXNlIGZp bmQgc29tZSBzbWFsbCBjb21tZW50cyBmb3IgeW91ciBjb25zaWRlcmF0aW9uOg0KDQoNCjQuMS4g IFByb3h5IEJpbmRpbmcgVXBkYXRlDQoNCiAgIEEgbmV3IGZsYWcgKEQpIGlzIGluY2x1ZGVkIGlu IHRoZSBQcm94eSBCaW5kaW5nIFVwZGF0ZSB0byBpbmRpY2F0ZQ0KICAgdGhhdCB0aGUgUHJveHkg QmluZGluZyBVcGRhdGUgaXMgY29taW5nIGZyb20gYSBNb2JpbGl0eSBBbmNob3IgYW5kDQogICBB Y2Nlc3MgUm91dGVyIGFuZCBub3QgZnJvbSBhIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheS4gIFRoZSBy ZXN0IG9mIHRoZQ0KICAgUHJveHkgQmluZGluZyBVcGRhdGUgZm9ybWF0IHJlbWFpbnMgdGhlIHNh bWUgYXMgZGVmaW5lZCBpbiBbUkZDNTIxM10uDQoNCiAgIDAgICAgICAgICAgICAgICAxICAgICAg ICAgICAgICAgMiAgICAgICAgICAgICAgIDMNCiAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgIFNlcXVlbmNlICMgICAg ICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgfEF8SHxMfEt8TXxSfFB8RnxUfEJ8U3xEfCBSZXNlciB8 ICAgICAgICAgICAgTGlmZXRpbWUgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCkhvd2V2ZXIs IGZvciBSRkMgNTIxMyBTIDguMToNCg0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHxBfEh8THxLfE18 UnxQfCAgUmVzZXJ2ZWQgICAgICAgfCAgICAgICAgICAgIExpZmV0aW1lICAgICAgICAgICB8DQog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQpTbywgdGhlcmVmb3JlLCBzZWVtcyBsaWtlOg0KMS4gVGhlIGRlZmlu aXRpb24gb2YgRmxhZ3MgRiwgVCwgQiwgYW5kIFMgaXMgbWlzc2luZy4NCjIuIOKAnFJlc2Vy4oCd IGlzIG5vdCByZWFsbHkgY2xlYXIgYW5kIOKAnFJzcnZk4oCdIHNlZW1zIHRvIGZpdCBhbmQgYmUg bW9yZSB1bmFtYmlndW91cy4NCg0KW0NCXSBJJ3ZlIHJlcGxhY2VkICJSZXNlciIgd2l0aCAiUnNy dmQiLiBUaGUgb3RoZXIgZmxhZ3MgYXJlIGRlZmluZWQgaW4gb3RoZXIgUkZDcywgcHVibGlzaGVk IGFmdGVyIFJGQyA1MjEzLiBEbyBJIG5lZWQgdG8gZXhwbGFpbiB3aGF0IGVhY2ggb2YgdGhlc2Ug ZmxhZ3MgZG8gaW4gdGhpcyBkb2N1bWVudD8gSW4gYW55IGNhc2UsIHRoZXJlIG1pZ2h0IGJlIGFk ZGl0aW9uYWwgZmxhZ3MgZGVmaW5lZCBpbiB0aGUgZnV0dXJlLCBzbyBJIHRoaW5rIGl0IGlzIG5v dCBuZWVkZWQuDQoNCg0KQ01QOiBUaGUgcHJvYmxlbSBJIHNlZSBpcyB0aGF0IHRoZSBkb2N1bWVu dCBjdXJyZW50bHkgc2F5czoNCiAgIFRoZSByZXN0IG9mIHRoZQ0KICAgUHJveHkgQmluZGluZyBV cGRhdGUgZm9ybWF0IHJlbWFpbnMgdGhlIHNhbWUgYXMgZGVmaW5lZCBpbiBbUkZDNTIxM10NCg0K QnV0IGJhc2VkIG9uIHdoYXQgeW91IHdyaXRlLCB0aGF0IGlzIG5vdCB0aGUgY2FzZS4NCg0KTm8s IHlvdSBkbyBub3QgbmVlZCB0byBleHBsYWluIHdoYXQgZWFjaCBmbGFnIGRvZXMg4oCUIGJ1dCBJ 4oCZZCBzdWdnZXN0IGVpdGhlciBub3Qgc2F5IHdoZXJlIHRoZXkgYXJlIGRlZmluZWQsIG9yIGlu Y2x1ZGUgdGhlIG90aGVyIFJGQ3MuDQoNCkkgY2hlY2tlZCBJQU5BIGFuZCBmb3VuZDoNCmh0dHBz Oi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL21vYmlsaXR5LXBhcmFtZXRlcnMvbW9iaWxpdHkt cGFyYW1ldGVycy54aHRtbCNtb2JpbGl0eS1wYXJhbWV0ZXJzLTExDQoNCg0KDQo0LjIuICBQcm94 eSBCaW5kaW5nIEFja25vd2xlZGdtZW50DQoNCuKApg0KICBUaGUgcmVzdCBvZiB0aGUgUHJveHkg QmluZGluZyBBY2tub3dsZWRnbWVudCBmb3JtYXQNCiAgIHJlbWFpbnMgdGhlIHNhbWUgYXMgZGVm aW5lZCBpbiBbUkZDNTIxM10uDQoNCiAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIFN0YXR1cyAgICAgIHxLfFJ8UHxU fEJ8U3xEfCB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpIb3dldmVyLCBmcm9tIFJGQyA1MjEzOg0KDQogICAg ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg ICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgIFN0YXR1cyAgICAgIHxLfFJ8UHxSZXNlcnZlZCB8DQog ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQpBbmQgdGh1cywgRmxhZ3MgVCwgQiwgUyBhcmUgbm90IGRlZmluZWQu DQoNCltDQl0gU2FtZSBhcyBiZWZvcmUuIEFkZGl0aW9uYWwgZmxhZ3Mgd2VyZSBkZWZpbmVkIGFu ZCBhZGRlZCB0byBJQU5BIHJlZ2lzdHJ5IGFmdGVyIFJGQyA1MjEzIHdhcyBwdWJsaXNoZWQuIEkg cmVmZXIgdG8gUkZDIDUyMTMgYXMgaXQgaXMgd2hlcmUgdGhlIGFjdHVhbCBQQlUvUEJBIGZvcm1h dCB3YXMgc3BlY2lmaWVkIChhbHRob3VnaCB0aGV5IGFyZSBiYXNpY2FsbHkgQlUvQkEgd2l0aCBQ IGZsYWcgc2V0IHRvIDEpLg0KDQoNClRIYW5rcywgSSB1bmRlcnN0YW5kLiBJIHdhcyBjb21tZW50 aW5nIG9uIHRoZSB0ZXh0IHRoYXQgc2F5cyDigJx0aGUgcmVzdCBpcyBkZWZpbmVkIGluIFJGQzUy MTPigJ0uDQoNCg0KNC4zLiAgQW5jaG9yZWQgUHJlZml4IE9wdGlvbg0KDQogICBBbmNob3JlZCBQ cmVmaXgNCg0KICAgICAgQSBzaXh0ZWVuLWJ5dGUgZmllbGQgY29udGFpbmluZyB0aGUgbW9iaWxl IG5vZGUncyBJUHY2IEFuY2hvcmVkDQogICAgICBQcmVmaXguICBPbmx5IHRoZSBmaXJzdCBQcmVm aXggTGVuZ3RoIGJ5dGVzIGFyZSB2YWxpZCBmb3IgdGhlDQogICAgICBBbmNob3JlZCBQcmVmaXgu ICBUaGUgcmVzdCBvZiB0aGUgYnl0ZXMgTVVTVCBiZSBpZ25vcmVkLg0KDQpOb3QgYmVpbmcgcGVk YW50aWMsIGJ1dDoNCnMvYnl0ZS9vY3RldC9nIC8vIHRocm91Z2hvdXQuDQpPcuKApiAiMTI4LWJp dOKAnSBpbnN0ZWFkIG9mIOKAnHNpeHRlZW4tb2N0ZXTigJ0uDQoNCltDQl0gT0ssIEkgc2VlIHRo YXQgUkZDIDYyNzUgdXNlcyBvbmx5ICJvY3RldCIsIHdoaWxlIFJGQyA1MjEzIHVzZXMgYm90aCAi b2N0ZXQiIGFuZCAiYnl0ZSIuIEJ1dCBJIGFncmVlIHRoYXQgdXNpbmcgb25seSBvbmUgaXMgdGhl IHJpZ2h0IHRoaW5nIHRvIGRvLiBJJ3ZlIGNob3NlbiAib2N0ZXQiIGFzIHlvdSBzdWdnZXN0ZWQu DQoNCg0KVGhhbmtzISBBcyBzdHJpY3RseSB0aGVyZSBjYW4gYmUgbm9uLW9jdGV0IGJ5dGVzLg0K DQoNCg0KNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVz IHNpeCBuZXcgbW9iaWxpdHkgb3B0aW9ucyB0aGF0IG5lZWQgdG8gYmUNCiAgIHJlZ2lzdGVyZWQg aW4gdGhlIE1vYmlsaXR5IE9wdGlvbnMgcmVnaXN0cnkgb24gdGhlIE1vYmlsZSBJUHY2DQogICBw YXJhbWV0ZXJzIHJlZ2lzdHJ5LiAgVGhlIHJlcXVpcmVkIElBTkEgYWN0aW9ucyBhcmUgbWFya2Vk IGFzIElBTkEtMQ0KICAgdG8gSUFOQS02Lg0KDQpJdCB3b3VsZCBiZSB1c2VmdWwgdG8gYnJlYWtv dXQgdGhlIHNwZWNpZmljIElBTkEgcmVxdWVzdHMgaW4gYSB0YWJsZSwgc2VjdGlvbnMsIG9yIG90 aGVyIHN0cnVjdHVyZSBkZXRhaWxpbmcgaG93IGl0IHNob3VsZCBsb29rIGluIHRoZSBJQU5BIHJl Z2lzdHJpZXMuDQoNCltDQl0gSSd2ZSBhZGRlZCBzb21lIGFkZGl0aW9uYWwgdGV4dCwgYnV0IGZv bGxvd2luZyB0aGUgYXBwcm9hY2ggb2YgUkZDIDUyMTMsIHdoaWNoIGtlZXBzIGl0IHNpbXBsZS4g SSBob3BlIHRoaXMgaXMgc3VmZmljaWVudC4NCg0KDQpUaGFuayB5b3UuDQoNCg0KNi4gU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMNCg0KSXMgdGhlcmUgdW5kZXJseWluZyBwcm90ZWN0aW9uIGFnYWlu c3Qgc3Bvb2ZpbmcgdGhhdCBjYW4gYmUgY2FsbGVkIG91dD8gVGhpcyBzaG91bGQgYmUgYWRkcmVz c2VkIGluIHRoZSBTZWN1cml0eSBEaXIgcmV2aWV3LCBzbyBJIHdpbGwgbm90IG1lbnRpb24gaXQg aGVyZSDwn5mCDQoNCltDQl0gV2UgYXNzdW1lIHRoYXQgdXNpbmcgdGhlIG1lY2hhbmlzbXMgZGVz Y3JpYmVkIGZvciBSRkMgNTIxMyBpcyBlbm91Z2guIFdlIGhhdmUgYWRkZWQgc29tZSBhZGRpdGlv bmFsIGNvbnNpZGVyYXRpb25zIGZvciB0aGUgcmlza3MvcHJvY2VkdXJlcyB0aGF0IGFyZSBzcGVj aWZpYyB0byB0aGUgZGlzdHJpYnV0ZWQgc29sdXRpb24uDQoNCg0KQWNrLg0KDQoNCjguMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW0ktRC5pZXRmLWRtbS1kZXBsb3ltZW50LW1vZGVs c10NCiAgICAgICAgICAgICAgR3VuZGF2ZWxsaSwgUy4gYW5kIFMuIEplb24sICJETU0gRGVwbG95 bWVudCBNb2RlbHMgYW5kDQogICAgICAgICAgICAgIEFyY2hpdGVjdHVyYWwgQ29uc2lkZXJhdGlv bnMiLCBkcmFmdC1pZXRmLWRtbS1kZXBsb3ltZW50LQ0KICAgICAgICAgICAgICBtb2RlbHMtMDQg KHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXkgMjAxOC4NCg0KU2luY2UgdGhlcmUgYXJlIGtleSBkZWZp bml0aW9ucyBmcm9tIHRoaXMgZG9jdW1lbnQsIHNob3VsZCB0aGlzIGJlIE5vcm1hdGl2ZT8NCg0K W0NCXSBTaW5jZSB0aGlzIGRvY3VtZW50IGlzIG5vdCBnb2luZyB0byBiZSBwcm9ncmVzc2VkIGFu eSBmdXJ0aGVyLCB3ZSBoYXZlIGluY2x1ZGVkIHRoZSByZWxldmFudCB0ZXJtcyBpbiB0aGUgdGVy bWlub2xvZ3kgc2VjdGlvbiBhbmQgcmVtb3ZlIHRoZSByZWZlcmVuY2UuDQoNCkdvdCBpdC4NCg0K DQoNCiAgIFtSRkM3MzMzXSAgQ2hhbiwgSC4sIEVkLiwgTGl1LCBELiwgU2VpdGUsIFAuLCBZb2tv dGEsIEguLCBhbmQgSi4NCiAgICAgICAgICAgICAgS29yaG9uZW4sICJSZXF1aXJlbWVudHMgZm9y IERpc3RyaWJ1dGVkIE1vYmlsaXR5DQogICAgICAgICAgICAgIE1hbmFnZW1lbnQiLCBSRkMgNzMz MywgRE9JIDEwLjE3NDg3L1JGQzczMzMsIEF1Z3VzdCAyMDE0LA0KICAgICAgICAgICAgICA8aHR0 cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3MzMzPi4NCg0KU2ltaWxhcmx5LCBzaG91 bGQgdGhpcyByZWZlcmVuY2UgYmUgTm9ybWF0aXZlIGluc3RlYWQgb2YgSW5mb3JtYXRpdmU/DQoN CltDQl0gSSBkb24ndCBoYXZlIGEgc3Ryb25nIG9waW5pb24gaGVyZS4gSSd2ZSBtb3ZlZCBpdCB0 byBOb3JtYXRpdmUsIGJ1dCBJIHRoaW5rIGl0IGNvdWxkIHN0YXkgYXMgSW5mb3JtYXRpdmUgYXMg d2VsbC4NCg0KDQpZb3VyIGNhbGwuIFRoYW5rcyBmb3IgY29uc2lkZXJpbmcuDQoNCg0KQXBwZW5k aXggQi4gIEltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2UNCg0KU2hvdWxkIHRoaXMgcmVhbGx5IGJl IGFuIEltcGxlbWVudGF0aW9uIFN0YXR1cyBzZWN0aW9uIFtSRkM3OTQyXSwgYXMgaXQgZGVzY3Jp YmVzIGEgcG9pbnQgaW4gdGltZSByYXRoZXIgdGhhbiBsZWFybmluZ3M/DQoNClNob3VsZCB0aGUg QXBwZW5kaWNlcyBjbGFyaWZ5IHRoZXkgbWFrZSBubyBub3JtYXRpdmUgc3BlY3M/DQoNCltDQl0g QmFzZWQgYWxzbyBvbiBvdGhlciBjb21tZW50cyB3ZSBoYXZlIHJlbW92ZSBib3RoIGFwcGVuZGl4 ZXMuDQoNCg0KQWNrLg0KDQoNCkkgaG9wZSB0aGVzZSBjb21tZW50cyBhcmUgdXNlZnVsLg0KDQpb Q0JdIFllcywgdGhleSBhcmUgaW5kZWVkLiBUaGFua3MhDQoNCjotKSBTdXBlci4NCg0KKEFub3Ro ZXIpIENhcmxvcy4NCg0KDQpDYXJsb3MNCg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoLA0KDQpDYXJs b3MgUGlnbmF0YXJvLg0KDQo= --_000_473EA3D0688D404783B9ED351937232Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <72708041CA913142B40F978B85935AB7@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpLCBDYXJsb3MsDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MgZm9yIHRoZSByZXNwb25z ZSEgUGxlYXNlIHNlZSBpbmxpbmUsIHByZWZhY2VkIHdpdGggQ01QLjxiciBjbGFzcz0iIj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPjIwMjAvMDMvMDgg5Y2I5b6MMDo0M+OAgUNBUkxPUyBKRVNVUyBCRVJOQVJET1Mg Q0FOTyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNqYmNAaXQudWMzbS5lcyIgY2xhc3M9IiI+Y2piY0Bp dC51YzNtLmVzPC9hPiZndDvjga7jg6Hjg7zjg6s6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPkhpIENhcmxvcywNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3IgeW91ciByZXZpZXcuIFBsZWFzZSBmaW5kIGlubGlu ZSBiZWxvdyBteSBjb21tZW50cy48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9u IFNhdCwgRmViIDI5LCAyMDIwIGF0IDQ6MTUgQU0gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp ICZsdDs8YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIiBjbGFzcz0iIj5jcGlnbmF0 YUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDog MXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0 LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyIgY2xhc3M9ImdtYWlsX3F1b3RlIj4NClJl dmlld2VyOiBDYXJsb3MgUGlnbmF0YXJvPGJyIGNsYXNzPSIiPg0KUmV2aWV3IHJlc3VsdDogUmVh ZHkgd2l0aCBOaXRzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbSBhbiBhc3NpZ25l ZCBJTlQgZGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQuJm5ic3A7 IFRoZXNlPGJyIGNsYXNzPSIiPg0KY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3Ig dGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0IEFyZWEgRGlyZWN0b3JzLjxiciBjbGFzcz0iIj4N CkRvY3VtZW50IGVkaXRvcnMgYW5kIHNoZXBoZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVzZSBjb21t ZW50cyBqdXN0IGxpa2UgdGhleTxiciBjbGFzcz0iIj4NCndvdWxkIHRyZWF0IGNvbW1lbnRzIGZy b20gYW55IG90aGVyIElFVEYgY29udHJpYnV0b3JzIGFuZCByZXNvbHZlIHRoZW0gYWxvbmc8YnIg Y2xhc3M9IiI+DQp3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCBoYXZlIGJl ZW4gcmVjZWl2ZWQuIEZvciBtb3JlIGRldGFpbHMgb248YnIgY2xhc3M9IiI+DQp0aGUgSU5UIERp cmVjdG9yYXRlLCBzZWU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlLmh0bWwi IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS5odG1sPC9hPi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpJIGhvcGUgdGhlc2UgY29tbWVudHMgYXJlIGNsZWFyIGFuZCB1c2VmdWwuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KQXMgcmVxdWVzdGVkLCBmcm9tIHRoZSBJbnRlcm5ldCBhcmVh IERpcmVjdG9yYXRlIHJldmlldywgdGhlc2UgdHdvIERNTTxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpkb2N1bWVudHMgYXJlIGJl aW5nIHJldmlld2VkIHRvZ2V0aGVyOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQoqIGRyYWZ0LWlldGYtZG1tLWRpc3RyaWJ1dGVk LW1vYmlsaXR5LWFuY2hvcmluZy0xNDxiciBjbGFzcz0iIj4NCiogZHJhZnQtaWV0Zi1kbW0tcG1p cHY2LWRsaWYtMDU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGRvY3VtZW50IGRl ZmluZXMgZGlzdHJpYnV0ZWQgbW9iaWxpdHkgYW5jaG9yaW5nLCBpbiB0ZXJtcyBvZiB0aGU8c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIi Pg0KZGlmZmVyZW50IGNvbmZpZ3VyYXRpb25zIGFuZCBmdW5jdGlvbnMgdG8gcHJvdmlkZSBJUCBt b2JpbGl0eSBzdXBwb3J0LDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQppbmNsdWRpbmcgbmV0d29yay1iYXNlZCBvciBob3N0LWJh c2VkIG1vYmlsaXR5IHN1cHBvcnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIGlu dGVuZGVkIHN0YXR1cyBpcyBJbmZvcm1hdGlvbmFsLiBJdCBpcyBhIHZlcnkgd2VsbCB3cml0dGVu IGFuZCBjb21wcmVoZW5zaXZlPGJyIGNsYXNzPSIiPg0KZG9jdW1lbnQuIEl0IGlzIHRlY2huaWNh bGx5IHNvdW5kLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5vIG1ham9yIG9yIG1pbm9y IGlzc3Vlcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOaXRzOjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCkEgc2V0IG9mIHNtYWxsIG5pdHMgZm9yIHlvdXIgY29uc2lkZXJhdGlv bi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoxLiZuYnNwOyBJbnRyb2R1Y3Rpb248YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7QXMgYSBNb2JpbGUgTm9kZSAo TU4pIGF0dGFjaGVzIHRvIGFuIGFjY2VzcyByb3V0ZXIgYW5kIGVzdGFibGlzaGVzIGE8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7bGluayBiZXR3ZWVuIHRoZW0sIGEgLzY0IElQdjYgcHJlZml4 IGFuY2hvcmVkIHRvIHRoZSByb3V0ZXIgbWF5IGJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNw O2Fzc2lnbmVkIHRvIHRoZSBsaW5rIGZvciBleGNsdXNpdmUgdXNlIGJ5IHRoZSBNTiBbUkZDNjQ1 OV0uJm5ic3A7IFRoZSBNTjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDttYXkgdGhlbiBjb25m aWd1cmUgYSBnbG9iYWwgSVB2NiBhZGRyZXNzIGZyb20gdGhpcyBwcmVmaXggYW5kIHVzZSBpdDxi ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthcyB0aGUgc291cmNlIElQIGFkZHJlc3MgaW4gYSBm bG93IHRvIGNvbW11bmljYXRlIHdpdGggaXRzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2Nv cnJlc3BvbmRlbnQgbm9kZSAoQ04pLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNhcGl0 YWxpemU6PGJyIGNsYXNzPSIiPg0Kcy9jb3JyZXNwb25kZW50IG5vZGUvQ29ycmVzcG9uZGVudCBO b2RlLzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjIuJm5ic3A7IENvbnZlbnRpb25zIGFu ZCBUZXJtaW5vbG9neTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtU aGVzZSBpbmNsdWRlIHRlcm1zIHN1Y2ggYXMgbW9iaWxlIG5vZGUgKE1OKSwgY29ycmVzcG9uZGVu dCBub2RlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyhDTiksIGhvbWUgYWdlbnQgKEhBKSwg aG9tZSBhZGRyZXNzIChIb0EpLCBjYXJlLW9mLWFkZHJlc3MgKENvQSksPGJyIGNsYXNzPSIiPg0K Jm5ic3A7ICZuYnNwO2xvY2FsIG1vYmlsaXR5IGFuY2hvciAoTE1BKSwgYW5kIG1vYmlsZSBhY2Nl c3MgZ2F0ZXdheSAoTUFHKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDYXBpdGFsaXpl IOKAnE1vYmlsZSBOb2Rl4oCdIChhcyBwZXIgwqcgMSksIOKAnENvcmVzcG9uZGVudCBOb2Rl4oCd LCBldGMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2ltaWxhciB3aXRoaW4gdGhpcyBz YW1lIMKnIDIsIOKAnG1vYmlsZSByb3V0ZXLigJ0sIGV0Yy48YnIgY2xhc3M9IiI+DQpTYW1lIHRo cm91Z2hvdXQgdGhlIGRvY3VtZW50IChlLmcuLCDigJxyb3V0ZXIgYWR2ZXJ0aXNlbWVudCAoUkEp 4oCdKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjQuMy4mbmJzcDsgTW9iaWxpdHkgY2Fz ZSwgYW5jaG9yIHJlbG9jYXRpb248YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7VGhlIElQIHByZWZpeC9hZGRyZXNzIGFuY2hvcmluZyBtYXkgbW92ZSB3aXRob3V0IGNo YW5naW5nIHRoZSBJUDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtwcmVmaXgvYWRkcmVzcyBv ZiB0aGUgZmxvdy4mbmJzcDsgSGVyZSB0aGUgTE0gYW5kIEZNIGZ1bmN0aW9ucyBpbiBGaWd1cmUg MTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtpbiBTZWN0aW9uIDMuMSBhcmUgaW1wbGVtZW50 ZWQgYXMgc2hvd24gaW4gRmlndXJlIDcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K4oCc RmlndXJlIDEgaW4gU2VjdGlvbiAzLjEuMSBhcmUgaW1wbGVtZW50ZWTigJ08YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWd1cmUg NzogQW5jaG9yIG1vYmlsaXR5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2hvdWxkIHRo aXMgZmlndXJl4oCZcyBsYWJlbCBiZSDigJxBbmNob3IgUmVsb2NhdGlvbuKAnSBpbnN0ZWFkIG9m IOKAmEFuY2hvciBtb2JpbGl0eeKAnT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo1LiZu YnNwOyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDtBcyBzdGF0ZWQgaW4gW1JGQzczMzNdLCAmcXVvdDthIERNTSBzb2x1dGlv biBNVVNUIHN1cHBvcnRhbnkgc2VjdXJpdHk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpz L3N1cHBvcnRhbnkvc3VwcG9ydCBhbnkvPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KOC4y LiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhl IHJlbGF0aW9uc2hpcCBvZiB0aGlzIGRvY3VtZW50IGFuZCBkcmFmdC1pZXRmLWRtbS1kZXBsb3lt ZW50LW1vZGVscyBpcyBtb3N0bHkgY2xlYXIsIHRoYW5rIHlvdSBmb3IgdGhhdC48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGhvcGUgeW91IGZpZCB0aGVzZSBjb21tZW50cyB1c2VmdWwu PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2FybG9zIFBpZ25hdGFyby48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbW0tcG1pcHY2LWRsaWYtMDUiIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWRtbS1wbWlwdjYtZGxpZi0wNTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpJIGFtIGFuIGFzc2lnbmVkIElOVCBkaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhp cyBJbnRlcm5ldC1EcmFmdC4mbmJzcDsgVGhlc2U8YnIgY2xhc3M9IiI+DQpjb21tZW50cyB3ZXJl IHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgSW50ZXJuZXQgQXJlYSBE aXJlY3RvcnMuPGJyIGNsYXNzPSIiPg0KRG9jdW1lbnQgZWRpdG9ycyBhbmQgc2hlcGhlcmQocykg c2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSB0aGV5PGJyIGNsYXNzPSIiPg0K d291bGQgdHJlYXQgY29tbWVudHMgZnJvbSBhbnkgb3RoZXIgSUVURiBjb250cmlidXRvcnMgYW5k IHJlc29sdmUgdGhlbSBhbG9uZzxiciBjbGFzcz0iIj4NCndpdGggYW55IG90aGVyIExhc3QgQ2Fs bCBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiByZWNlaXZlZC4gRm9yIG1vcmUgZGV0YWlscyBvbjxi ciBjbGFzcz0iIj4NCnRoZSBJTlQgRGlyZWN0b3JhdGUsIHNlZTxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L2llc2cvZGlyZWN0b3JhdGUuaHRtbCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlLmh0bWw8L2E+Ljxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgaG9wZSB0aGVzZSBjb21tZW50cyBhcmUgY2xl YXIgYW5kIHVzZWZ1bC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBcyByZXF1ZXN0ZWQs IGZyb20gdGhlIEludGVybmV0IGFyZWEgRGlyZWN0b3JhdGUgcmV2aWV3LCB0aGVzZSB0d28gRE1N PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFz cz0iIj4NCmRvY3VtZW50cyBhcmUgYmVpbmcgcmV2aWV3ZWQgdG9nZXRoZXI6PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiogZHJh ZnQtaWV0Zi1kbW0tZGlzdHJpYnV0ZWQtbW9iaWxpdHktYW5jaG9yaW5nLTE0PGJyIGNsYXNzPSIi Pg0KKiBkcmFmdC1pZXRmLWRtbS1wbWlwdjYtZGxpZi0wNTxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NClRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYW4gYXBwcm9hY2ggdG8gZGlzdHJpYnV0ZWQg bW9iaWxpdHkgbWFuYWdlbWVudDxiciBjbGFzcz0iIj4NCmJ5IGV4dGVuZGluZyBuZXR3b3JrLWJh c2VkIG1vYmlsaXR5IHByb3RvY29scyAobGlrZSBQcm94eSBNb2JpbGUgSVB2NikuIEluPGJyIGNs YXNzPSIiPg0KdGhpcyBzb2x1dGlvbiwgbW9iaWxpdHkgc2Vzc2lvbnMgYXJlIGFuY2hvcmVkIGF0 IHRoZSBsYXN0IElQIGhvcCByb3V0ZXIuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMgZG9jdW1l bnTigJlzIGludGVuZGVkIHN0YXR1cyBpcyBFeHBlcmltZW50YWwuIEl0IGlzIHdlbGwgd3JpdHRl biBmb3Igc3VjaCBhIGNvbXBsZXggY29tcHJlaGVuc2l2ZSBkb2N1bWVudCwgYW5kIHRlY2huaWNh bGx5IGNvbXBsZXRlIGFuZCBzZW5zaWJsZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpO byBtYWpvciBvciBtaW5vciBpc3N1ZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTml0 czo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2UgZmluZCBzb21lIHNtYWxsIGNv bW1lbnRzIGZvciB5b3VyIGNvbnNpZGVyYXRpb246PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KNC4xLiZuYnNwOyBQcm94eSBCaW5kaW5nIFVwZGF0ZTxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtBIG5ldyBmbGFnIChEKSBpcyBpbmNs dWRlZCBpbiB0aGUgUHJveHkgQmluZGluZyBVcGRhdGUgdG8gaW5kaWNhdGU8YnIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7dGhhdCB0aGUgUHJveHkgQmluZGluZyBVcGRhdGUgaXMgY29taW5nIGZy b20gYSBNb2JpbGl0eSBBbmNob3IgYW5kPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO0FjY2Vz cyBSb3V0ZXIgYW5kIG5vdCBmcm9tIGEgbW9iaWxlIGFjY2VzcyBnYXRld2F5LiZuYnNwOyBUaGUg cmVzdCBvZiB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7UHJveHkgQmluZGluZyBVcGRh dGUgZm9ybWF0IHJlbWFpbnMgdGhlIHNhbWUgYXMgZGVmaW5lZCBpbiBbUkZDNTIxM10uPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOzAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzM8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNlcXVlbmNlICMmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsmIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDt8QXxIfEx8 S3xNfFJ8UHxGfFR8QnxTfER8IFJlc2VyIHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBMaWZldGltZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkhvd2V2ZXIsIGZvciBSRkMgNTIxMyBTIDgu MTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IHxBfEh8THxLfE18UnxQfCZuYnNwOyBSZXNlcnZlZCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBMaWZldGltZSZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxiciBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KU28sIHRoZXJlZm9yZSwgc2VlbXMgbGlrZTo8YnIgY2xhc3M9IiI+DQox LiBUaGUgZGVmaW5pdGlvbiBvZiBGbGFncyBGLCBULCBCLCBhbmQgUyBpcyBtaXNzaW5nLjxiciBj bGFzcz0iIj4NCjIuIOKAnFJlc2Vy4oCdIGlzIG5vdCByZWFsbHkgY2xlYXIgYW5kIOKAnFJzcnZk 4oCdIHNlZW1zIHRvIGZpdCBhbmQgYmUgbW9yZSB1bmFtYmlndW91cy48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5bQ0JdIEkndmUgcmVwbGFjZWQgJnF1b3Q7UmVzZXImcXVvdDsgd2l0aCAmcXVvdDtS c3J2ZCZxdW90Oy4gVGhlIG90aGVyIGZsYWdzIGFyZSBkZWZpbmVkIGluIG90aGVyIFJGQ3MsIHB1 Ymxpc2hlZCBhZnRlciBSRkMgNTIxMy4gRG8gSSBuZWVkIHRvIGV4cGxhaW4gd2hhdCBlYWNoIG9m IHRoZXNlIGZsYWdzIGRvIGluIHRoaXMgZG9jdW1lbnQ/IEluIGFueSBjYXNlLCB0aGVyZSBtaWdo dCBiZSBhZGRpdGlvbmFsIGZsYWdzIGRlZmluZWQgaW4gdGhlIGZ1dHVyZSwNCiBzbyBJIHRoaW5r IGl0IGlzIG5vdCBuZWVkZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+Q01QOiBUaGUgcHJvYmxlbSBJIHNlZSBpcyB0aGF0IHRoZSBkb2N1bWVudCBj dXJyZW50bHkgc2F5czo8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO1RoZSByZXN0IG9mIHRoZTxi ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtQcm94eSBCaW5kaW5nIFVwZGF0ZSBmb3JtYXQgcmVt YWlucyB0aGUgc2FtZSBhcyBkZWZpbmVkIGluIFtSRkM1MjEzXTwvZGl2Pg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXY+QnV0IGJhc2VkIG9uIHdoYXQgeW91IHdyaXRlLCB0aGF0IGlz IG5vdCB0aGUgY2FzZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pk5v LCB5b3UgZG8gbm90IG5lZWQgdG8gZXhwbGFpbiB3aGF0IGVhY2ggZmxhZyBkb2VzIOKAlCBidXQg SeKAmWQgc3VnZ2VzdCBlaXRoZXIgbm90IHNheSB3aGVyZSB0aGV5IGFyZSBkZWZpbmVkLCBvciBp bmNsdWRlIHRoZSBvdGhlciBSRkNzLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+SSBjaGVja2VkIElBTkEgYW5kIGZvdW5kOjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRw czovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9tb2JpbGl0eS1wYXJhbWV0ZXJzL21vYmlsaXR5 LXBhcmFtZXRlcnMueGh0bWwjbW9iaWxpdHktcGFyYW1ldGVycy0xMSIgY2xhc3M9IiI+aHR0cHM6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvbW9iaWxpdHktcGFyYW1ldGVycy9tb2JpbGl0eS1w YXJhbWV0ZXJzLnhodG1sI21vYmlsaXR5LXBhcmFtZXRlcnMtMTE8L2E+PC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRl ci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQt Y29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7IiBjbGFzcz0iZ21h aWxfcXVvdGUiPg0KPGJyIGNsYXNzPSIiPg0KNC4yLiZuYnNwOyBQcm94eSBCaW5kaW5nIEFja25v d2xlZGdtZW50PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K4oCmPGJyIGNsYXNzPSIiPg0K Jm5ic3A7IFRoZSByZXN0IG9mIHRoZSBQcm94eSBCaW5kaW5nIEFja25vd2xlZGdtZW50IGZvcm1h dDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtyZW1haW5zIHRoZSBzYW1lIGFzIGRlZmluZWQg aW4gW1JGQzUyMTNdLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsw Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7MSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwOzAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wm bmJzcDsgJm5ic3A7U3RhdHVzJm5ic3A7ICZuYnNwOyAmbmJzcDsgfEt8UnxQfFR8QnxTfER8IHw8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIb3dldmVyLCBmcm9tIFJGQyA1MjEzOjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsxJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7MiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDswIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8YnIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDtTdGF0dXMmbmJzcDsgJm5ic3A7ICZu YnNwOyB8S3xSfFB8UmVzZXJ2ZWQgfDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K QW5kIHRodXMsIEZsYWdzIFQsIEIsIFMgYXJlIG5vdCBkZWZpbmVkLjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPltDQl0gU2FtZSBhcyBiZWZvcmUuIEFkZGl0aW9uYWwgZmxhZ3Mgd2VyZSBkZWZpbmVk IGFuZCBhZGRlZCB0byBJQU5BIHJlZ2lzdHJ5IGFmdGVyIFJGQyA1MjEzIHdhcyBwdWJsaXNoZWQu IEkgcmVmZXIgdG8gUkZDIDUyMTMgYXMgaXQgaXMgd2hlcmUgdGhlIGFjdHVhbCZuYnNwO1BCVS9Q QkEgZm9ybWF0IHdhcyBzcGVjaWZpZWQgKGFsdGhvdWdoIHRoZXkgYXJlIGJhc2ljYWxseSBCVS9C QSB3aXRoIFAgZmxhZyBzZXQgdG8gMSkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VEhhbmtzLCBJIHVuZGVyc3RhbmQuIEkgd2FzIGNv bW1lbnRpbmcgb24gdGhlIHRleHQgdGhhdCBzYXlzIOKAnHRoZSByZXN0IGlzIGRlZmluZWQgaW4g UkZDNTIxM+KAnS48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXIt bGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNv bG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyIgY2xhc3M9ImdtYWls X3F1b3RlIj4NCjxiciBjbGFzcz0iIj4NCjQuMy4mbmJzcDsgQW5jaG9yZWQgUHJlZml4IE9wdGlv bjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtBbmNob3JlZCBQcmVm aXg8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBBIHNp eHRlZW4tYnl0ZSBmaWVsZCBjb250YWluaW5nIHRoZSBtb2JpbGUgbm9kZSdzIElQdjYgQW5jaG9y ZWQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBQcmVmaXguJm5ic3A7IE9ubHkg dGhlIGZpcnN0IFByZWZpeCBMZW5ndGggYnl0ZXMgYXJlIHZhbGlkIGZvciB0aGU8YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBBbmNob3JlZCBQcmVmaXguJm5ic3A7IFRoZSByZXN0 IG9mIHRoZSBieXRlcyBNVVNUIGJlIGlnbm9yZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KTm90IGJlaW5nIHBlZGFudGljLCBidXQ6PGJyIGNsYXNzPSIiPg0Kcy9ieXRlL29jdGV0L2cg Ly8gdGhyb3VnaG91dC48YnIgY2xhc3M9IiI+DQpPcuKApiAmcXVvdDsxMjgtYml04oCdIGluc3Rl YWQgb2Yg4oCcc2l4dGVlbi1vY3RldOKAnS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5bQ0JdIE9L LCBJIHNlZSB0aGF0IFJGQyA2Mjc1IHVzZXMgb25seSAmcXVvdDtvY3RldCZxdW90Oywgd2hpbGUg UkZDIDUyMTMgdXNlcyBib3RoICZxdW90O29jdGV0JnF1b3Q7IGFuZCAmcXVvdDtieXRlJnF1b3Q7 LiBCdXQgSSBhZ3JlZSB0aGF0IHVzaW5nIG9ubHkgb25lIGlzIHRoZSByaWdodCB0aGluZyB0byBk by4gSSd2ZSBjaG9zZW4gJnF1b3Q7b2N0ZXQmcXVvdDsgYXMgeW91IHN1Z2dlc3RlZC48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGFu a3MhIEFzIHN0cmljdGx5IHRoZXJlIGNhbiBiZSBub24tb2N0ZXQgYnl0ZXMuPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVy LWxlZnQtc3R5bGU6IHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQp OyBwYWRkaW5nLWxlZnQ6IDFleDsiIGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo1LiZuYnNwOyBJQU5BIENvbnNpZGVyYXRpb25zPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVmaW5lcyBzaXgg bmV3IG1vYmlsaXR5IG9wdGlvbnMgdGhhdCBuZWVkIHRvIGJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwO3JlZ2lzdGVyZWQgaW4gdGhlIE1vYmlsaXR5IE9wdGlvbnMgcmVnaXN0cnkgb24gdGhl IE1vYmlsZSBJUHY2PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3BhcmFtZXRlcnMgcmVnaXN0 cnkuJm5ic3A7IFRoZSByZXF1aXJlZCBJQU5BIGFjdGlvbnMgYXJlIG1hcmtlZCBhcyBJQU5BLTE8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7dG8gSUFOQS02LjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkl0IHdvdWxkIGJlIHVzZWZ1bCB0byBicmVha291dCB0aGUgc3BlY2lmaWMgSUFO QSByZXF1ZXN0cyBpbiBhIHRhYmxlLCBzZWN0aW9ucywgb3Igb3RoZXIgc3RydWN0dXJlIGRldGFp bGluZyBob3cgaXQgc2hvdWxkIGxvb2sgaW4gdGhlIElBTkEgcmVnaXN0cmllcy48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5bQ0JdIEkndmUgYWRkZWQgc29tZSBhZGRpdGlvbmFsIHRleHQsIGJ1dCBm b2xsb3dpbmcgdGhlIGFwcHJvYWNoIG9mIFJGQyA1MjEzLCB3aGljaCBrZWVwcyBpdCBzaW1wbGUu IEkgaG9wZSB0aGlzIGlzIHN1ZmZpY2llbnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoYW5rIHlvdS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0 LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFk ZGluZy1sZWZ0OiAxZXg7IiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJyIGNsYXNzPSIiPg0KNi4g U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJcyB0 aGVyZSB1bmRlcmx5aW5nIHByb3RlY3Rpb24gYWdhaW5zdCBzcG9vZmluZyB0aGF0IGNhbiBiZSBj YWxsZWQgb3V0PyBUaGlzIHNob3VsZCBiZSBhZGRyZXNzZWQgaW4gdGhlIFNlY3VyaXR5IERpciBy ZXZpZXcsIHNvIEkgd2lsbCBub3QgbWVudGlvbiBpdCBoZXJlIPCfmYI8YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5bQ0JdIFdlIGFzc3VtZSB0aGF0IHVzaW5nIHRoZSBtZWNoYW5pc21zIGRlc2NyaWJl ZCBmb3IgUkZDIDUyMTMgaXMgZW5vdWdoLiBXZSBoYXZlIGFkZGVkIHNvbWUgYWRkaXRpb25hbCBj b25zaWRlcmF0aW9ucyBmb3IgdGhlIHJpc2tzL3Byb2NlZHVyZXMgdGhhdCBhcmUgc3BlY2lmaWMg dG8gdGhlJm5ic3A7ZGlzdHJpYnV0ZWQgc29sdXRpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkFjay48L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0 LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFk ZGluZy1sZWZ0OiAxZXg7IiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJyIGNsYXNzPSIiPg0KOC4y LiZuYnNwOyBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KJm5ic3A7ICZuYnNwO1tJLUQuaWV0Zi1kbW0tZGVwbG95bWVudC1tb2RlbHNdPGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEd1 bmRhdmVsbGksIFMuIGFuZCBTLiBKZW9uLCAmcXVvdDtETU0gRGVwbG95bWVudCBNb2RlbHMgYW5k PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEFyY2hpdGVjdHVyYWwgQ29uc2lkZXJhdGlvbnMmcXVvdDssIGRyYWZ0LWlldGYtZG1t LWRlcGxveW1lbnQtPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IG1vZGVscy0wNCAod29yayBpbiBwcm9ncmVzcyksIE1heSAyMDE4 LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNpbmNlIHRoZXJlIGFyZSBrZXkgZGVmaW5p dGlvbnMgZnJvbSB0aGlzIGRvY3VtZW50LCBzaG91bGQgdGhpcyBiZSBOb3JtYXRpdmU/PGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+W0NCXSBTaW5jZSB0aGlzIGRvY3VtZW50IGlzIG5vdCBnb2luZyB0 byBiZSBwcm9ncmVzc2VkIGFueSBmdXJ0aGVyLCB3ZSBoYXZlIGluY2x1ZGVkIHRoZSByZWxldmFu dCB0ZXJtcyBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBhbmQgcmVtb3ZlIHRoZSByZWZlcmVu Y2UuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KR290IGl0LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRp cj0ibHRyIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdp ZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJn YigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7IiBjbGFzcz0iZ21haWxfcXVvdGUi Pg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1tSRkM3MzMzXSZuYnNwOyBDaGFuLCBILiwg RWQuLCBMaXUsIEQuLCBTZWl0ZSwgUC4sIFlva290YSwgSC4sIGFuZCBKLjxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBLb3Job25l biwgJnF1b3Q7UmVxdWlyZW1lbnRzIGZvciBEaXN0cmlidXRlZCBNb2JpbGl0eTxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNYW5h Z2VtZW50JnF1b3Q7LCBSRkMgNzMzMywgRE9JIDEwLjE3NDg3L1JGQzczMzMsIEF1Z3VzdCAyMDE0 LDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3 MzMzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzczMzM8L2E+Jmd0Oy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpTaW1pbGFybHksIHNob3VsZCB0aGlzIHJlZmVyZW5jZSBiZSBOb3JtYXRpdmUg aW5zdGVhZCBvZiBJbmZvcm1hdGl2ZT88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5bQ0JdIEkgZG9u J3QgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIGhlcmUuIEkndmUgbW92ZWQgaXQgdG8gTm9ybWF0aXZl LCBidXQgSSB0aGluayBpdCBjb3VsZCBzdGF5IGFzIEluZm9ybWF0aXZlIGFzIHdlbGwuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+WW91 ciBjYWxsLiBUaGFua3MgZm9yIGNvbnNpZGVyaW5nLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjogMHB4IDBw eCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBz b2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0 OiAxZXg7IiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJyIGNsYXNzPSIiPg0KQXBwZW5kaXggQi4m bmJzcDsgSW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NClNob3VsZCB0aGlzIHJlYWxseSBiZSBhbiBJbXBsZW1lbnRhdGlvbiBTdGF0dXMgc2VjdGlv biBbUkZDNzk0Ml0sIGFzIGl0IGRlc2NyaWJlcyBhIHBvaW50IGluIHRpbWUgcmF0aGVyIHRoYW4g bGVhcm5pbmdzPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNob3VsZCB0aGUgQXBwZW5k aWNlcyBjbGFyaWZ5IHRoZXkgbWFrZSBubyBub3JtYXRpdmUgc3BlY3M/PGJyIGNsYXNzPSIiPg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+W0NCXSBCYXNlZCBhbHNvIG9uIG90aGVyIGNvbW1lbnRzIHdlIGhhdmUgcmVtb3Zl IGJvdGggYXBwZW5kaXhlcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdj5BY2suPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBkaXI9Imx0ciIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjog MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0 eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGlu Zy1sZWZ0OiAxZXg7IiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJyIGNsYXNzPSIiPg0KSSBob3Bl IHRoZXNlIGNvbW1lbnRzIGFyZSB1c2VmdWwuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+W0NCXSBZ ZXMsIHRoZXkgYXJlIGluZGVlZC4gVGhhbmtzITwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjotKSBTdXBlci48 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PihBbm90aGVyKSBDYXJsb3Mu PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkNhcmxvczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDog MXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0 LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyIgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxi ciBjbGFzcz0iIj4NClRoYW5rIHlvdSB2ZXJ5IG11Y2gsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KQ2FybG9zIFBpZ25hdGFyby48L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_473EA3D0688D404783B9ED351937232Aciscocom_-- From nobody Thu Mar 12 01:56:33 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77913A13A5 for ; Thu, 12 Mar 2020 01:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqgyTMB0OHIG for ; Thu, 12 Mar 2020 01:56:27 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495083A13A1 for ; Thu, 12 Mar 2020 01:56:27 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id m25so6418248edq.8 for ; Thu, 12 Mar 2020 01:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CNhpAK02/ITEu69vpMVr7/RIDtwfyS6eNsOQWQollgI=; b=XnFU3yhkhHyA6PLJ3JB7BTG1cDaUSVMmrm2mB4y4NdhiE3FHVLnswRTxHKBmyU4dEE Wzp15WewNYehsZQGLzX8foZR6dzfi23Pqx4QrAInom/uh+2n4j1nXRSRyX/Z/5HKSVN3 dMdB460iiVVjNvHrZi2w8gyRORU31EwNoShJLi978jcBx4v7TQfZG9VVCdaV7rhONm7T UE6zUylS1NZdTL96EVBDgGripOe7/Croyov7VJ2hwH3QGqDxW65yzWfcKzI2ZGOFqOGs kD0MXHxAcM/3nf56SLOvDmNqKpUuAcYuYGF8CMFSPg5I3KvpOP5CQgmvwiHUaYWHh1pS 3TBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CNhpAK02/ITEu69vpMVr7/RIDtwfyS6eNsOQWQollgI=; b=tvfUD/K8hGqcm6EhGGZbMB9VoMpqkllYZi4hKisZsxNQjHx5D/ZdZdUk6zVvBepq9m R6aqAVVn6oHqdvY6mkWJljMvNvkGwTzw/gcFHB3v1b7RmOfJklAd73wJyZ104HhYbJet ENvDBqv6ZaEfwUiyJIU5D9M0y7NzUxUrpKvbuWtG+uGJaNEPMHgOihdCrI9H0tqOWiA2 ldimpG+STO4EYQVhrDI5/wfAxBOiCQToKIblDa2AlrY7S74RJ/kziVZU3cgoS5gVU/aa 1/VbUQPyPQEj3ptk7rE4M2rrw0FldER/3gx7EWct9+xAijjprR4dIwFzMMvmK6Z4ku7O vhNg== X-Gm-Message-State: ANhLgQ34aIcZyl14+6QjenMkQ8kD4G4RhFIjRwSUGhW9kPxok5ZXQbJN i2tjMU7XiZmsje9WPedziiwGwfRCg8SyRyFDkA8x2XcALcY= X-Google-Smtp-Source: ADFU+vsp9cg0I2efmduxQv+xHQWgMnMOv99OUnlo8C183SjZgGrWzxMOCmyn3Qvv4EQPzijeV1Akftr9arEaXpb7foI= X-Received: by 2002:a17:906:eb83:: with SMTP id mh3mr5674028ejb.329.1584003385168; Thu, 12 Mar 2020 01:56:25 -0700 (PDT) MIME-Version: 1.0 References: <5480B86B-3D6B-490B-9CAC-609EE7A41278@cisco.com> <473EA3D0-688D-4047-83B9-ED351937232A@cisco.com> In-Reply-To: <473EA3D0-688D-4047-83B9-ED351937232A@cisco.com> From: CARLOS JESUS BERNARDOS CANO Date: Thu, 12 Mar 2020 09:56:09 +0100 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: "int-dir@ietf.org" , "last-call@ietf.org" , "draft-ietf-dmm-pmipv6-dlif.all@ietf.org" , "dmm@ietf.org" Content-Type: multipart/alternative; boundary="00000000000018bfac05a0a48796" Archived-At: Subject: Re: [DMM] [Last-Call] Intdir telechat review of draft-ietf-dmm-pmipv6-dlif -05 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 08:56:31 -0000 --00000000000018bfac05a0a48796 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, Thanks again. Short comment below. On Thu, Mar 12, 2020 at 6:00 AM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Carlos, > > Thanks for the response! Please see inline, prefaced with CMP. > > 2020/03/08 =E5=8D=88=E5=BE=8C0:43=E3=80=81CARLOS JESUS BERNARDOS CANO =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > Hi Carlos, > > Thanks for your review. Please find inline below my comments. > > On Sat, Feb 29, 2020 at 4:15 AM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Reviewer: Carlos Pignataro >> Review result: Ready with Nits >> >> I am an assigned INT directorate reviewer for this Internet-Draft. Thes= e >> comments were written primarily for the benefit of the Internet Area >> Directors. >> Document editors and shepherd(s) should treat these comments just like >> they >> would treat comments from any other IETF contributors and resolve them >> along >> with any other Last Call comments that have been received. For more >> details on >> the INT Directorate, see http://www.ietf.org/iesg/directorate.html. >> >> I hope these comments are clear and useful. >> >> As requested, from the Internet area Directorate review, these two DMM >> documents are being reviewed together: >> * draft-ietf-dmm-distributed-mobility-anchoring-14 >> * draft-ietf-dmm-pmipv6-dlif-05 >> >> This document defines distributed mobility anchoring, in terms of the >> different configurations and functions to provide IP mobility support, >> including network-based or host-based mobility support. >> >> The intended status is Informational. It is a very well written and >> comprehensive >> document. It is technically sound. >> >> No major or minor issues. >> >> Nits: >> >> A set of small nits for your consideration. >> >> 1. Introduction >> >> As a Mobile Node (MN) attaches to an access router and establishes a >> link between them, a /64 IPv6 prefix anchored to the router may be >> assigned to the link for exclusive use by the MN [RFC6459]. The MN >> may then configure a global IPv6 address from this prefix and use it >> as the source IP address in a flow to communicate with its >> correspondent node (CN). >> >> Capitalize: >> s/correspondent node/Correspondent Node/ >> >> 2. Conventions and Terminology >> >> These include terms such as mobile node (MN), correspondent node >> (CN), home agent (HA), home address (HoA), care-of-address (CoA), >> local mobility anchor (LMA), and mobile access gateway (MAG). >> >> Capitalize =E2=80=9CMobile Node=E2=80=9D (as per =C2=A7 1), =E2=80=9CCor= espondent Node=E2=80=9D, etc. >> >> Similar within this same =C2=A7 2, =E2=80=9Cmobile router=E2=80=9D, etc. >> Same throughout the document (e.g., =E2=80=9Crouter advertisement (RA)= =E2=80=9D) >> >> 4.3. Mobility case, anchor relocation >> >> The IP prefix/address anchoring may move without changing the IP >> prefix/address of the flow. Here the LM and FM functions in Figure 1 >> in Section 3.1 are implemented as shown in Figure 7. >> >> =E2=80=9CFigure 1 in Section 3.1.1 are implemented=E2=80=9D >> >> Figure 7: Anchor mobility >> >> Should this figure=E2=80=99s label be =E2=80=9CAnchor Relocation=E2=80= =9D instead of =E2=80=98Anchor >> mobility=E2=80=9D? >> >> 5. Security Considerations >> >> As stated in [RFC7333], "a DMM solution MUST supportany security >> >> s/supportany/support any/ >> >> 8.2. Informative References >> >> The relationship of this document and draft-ietf-dmm-deployment-models i= s >> mostly clear, thank you for that. >> >> I hope you fid these comments useful. >> >> Carlos Pignataro. >> >> >> https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif-05 >> >> I am an assigned INT directorate reviewer for this Internet-Draft. Thes= e >> comments were written primarily for the benefit of the Internet Area >> Directors. >> Document editors and shepherd(s) should treat these comments just like >> they >> would treat comments from any other IETF contributors and resolve them >> along >> with any other Last Call comments that have been received. For more >> details on >> the INT Directorate, see http://www.ietf.org/iesg/directorate.html. >> >> I hope these comments are clear and useful. >> >> As requested, from the Internet area Directorate review, these two DMM >> documents are being reviewed together: >> * draft-ietf-dmm-distributed-mobility-anchoring-14 >> * draft-ietf-dmm-pmipv6-dlif-05 >> >> This document provides an approach to distributed mobility management >> by extending network-based mobility protocols (like Proxy Mobile IPv6). = In >> this solution, mobility sessions are anchored at the last IP hop router. >> >> This document=E2=80=99s intended status is Experimental. It is well writ= ten for >> such a complex comprehensive document, and technically complete and >> sensible. >> >> No major or minor issues. >> >> Nits: >> >> Please find some small comments for your consideration: >> >> >> 4.1. Proxy Binding Update >> >> A new flag (D) is included in the Proxy Binding Update to indicate >> that the Proxy Binding Update is coming from a Mobility Anchor and >> Access Router and not from a mobile access gateway. The rest of the >> Proxy Binding Update format remains the same as defined in [RFC5213]. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence # | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A|H|L|K|M|R|P|F|T|B|S|D| Reser | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> However, for RFC 5213 S 8.1: >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |A|H|L|K|M|R|P| Reserved | Lifetime | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> So, therefore, seems like: >> 1. The definition of Flags F, T, B, and S is missing. >> 2. =E2=80=9CReser=E2=80=9D is not really clear and =E2=80=9CRsrvd=E2=80= =9D seems to fit and be more >> unambiguous. >> > > [CB] I've replaced "Reser" with "Rsrvd". The other flags are defined in > other RFCs, published after RFC 5213. Do I need to explain what each of > these flags do in this document? In any case, there might be additional > flags defined in the future, so I think it is not needed. > > > > CMP: The problem I see is that the document currently says: > The rest of the > Proxy Binding Update format remains the same as defined in [RFC5213] > > But based on what you write, that is not the case. > > No, you do not need to explain what each flag does =E2=80=94 but I=E2=80= =99d suggest > either not say where they are defined, or include the other RFCs. > > I checked IANA and found: > > https://www.iana.org/assignments/mobility-parameters/mobility-parameters.= xhtml#mobility-parameters-11 > > [CB] OK, I was referring to the rest of the PBU format in general. I can add that a note referring to the IANA registry for the definition and references of the flags. Would that work? Thanks, Carlos > > >> 4.2. Proxy Binding Acknowledgment >> >> =E2=80=A6 >> The rest of the Proxy Binding Acknowledgment format >> remains the same as defined in [RFC5213]. >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status |K|R|P|T|B|S|D| | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> However, from RFC 5213: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status |K|R|P|Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> And thus, Flags T, B, S are not defined. >> > > [CB] Same as before. Additional flags were defined and added to IANA > registry after RFC 5213 was published. I refer to RFC 5213 as it is where > the actual PBU/PBA format was specified (although they are basically BU/B= A > with P flag set to 1). > > > THanks, I understand. I was commenting on the text that says =E2=80=9Cthe= rest is > defined in RFC5213=E2=80=9D. > > >> 4.3. Anchored Prefix Option >> >> Anchored Prefix >> >> A sixteen-byte field containing the mobile node's IPv6 Anchored >> Prefix. Only the first Prefix Length bytes are valid for the >> Anchored Prefix. The rest of the bytes MUST be ignored. >> >> Not being pedantic, but: >> s/byte/octet/g // throughout. >> Or=E2=80=A6 "128-bit=E2=80=9D instead of =E2=80=9Csixteen-octet=E2=80=9D= . >> > > [CB] OK, I see that RFC 6275 uses only "octet", while RFC 5213 uses both > "octet" and "byte". But I agree that using only one is the right thing to > do. I've chosen "octet" as you suggested. > > > Thanks! As strictly there can be non-octet bytes. > > >> >> 5. IANA Considerations >> >> This document defines six new mobility options that need to be >> registered in the Mobility Options registry on the Mobile IPv6 >> parameters registry. The required IANA actions are marked as IANA-1 >> to IANA-6. >> >> It would be useful to breakout the specific IANA requests in a table, >> sections, or other structure detailing how it should look in the IANA >> registries. >> > > [CB] I've added some additional text, but following the approach of RFC > 5213, which keeps it simple. I hope this is sufficient. > > > Thank you. > > >> 6. Security Considerations >> >> Is there underlying protection against spoofing that can be called out? >> This should be addressed in the Security Dir review, so I will not menti= on >> it here =F0=9F=99=82 >> > > [CB] We assume that using the mechanisms described for RFC 5213 is enough= . > We have added some additional considerations for the risks/procedures tha= t > are specific to the distributed solution. > > > Ack. > > >> 8.2. Informative References >> >> [I-D.ietf-dmm-deployment-models] >> Gundavelli, S. and S. Jeon, "DMM Deployment Models and >> Architectural Considerations", draft-ietf-dmm-deployment- >> models-04 (work in progress), May 2018. >> >> Since there are key definitions from this document, should this be >> Normative? >> > > [CB] Since this document is not going to be progressed any further, we > have included the relevant terms in the terminology section and remove th= e > reference. > > > Got it. > > > >> >> [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. >> Korhonen, "Requirements for Distributed Mobility >> Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, >> . >> >> Similarly, should this reference be Normative instead of Informative? >> > > [CB] I don't have a strong opinion here. I've moved it to Normative, but = I > think it could stay as Informative as well. > > > Your call. Thanks for considering. > > >> Appendix B. Implementation experience >> >> Should this really be an Implementation Status section [RFC7942], as it >> describes a point in time rather than learnings? >> >> Should the Appendices clarify they make no normative specs? >> > > [CB] Based also on other comments we have remove both appendixes. > > > Ack. > > >> I hope these comments are useful. >> > > [CB] Yes, they are indeed. Thanks! > > > :-) Super. > > (Another) Carlos. > > > Carlos > > >> >> Thank you very much, >> >> Carlos Pignataro. > > > --00000000000018bfac05a0a48796 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,

Thanks agai= n. Short comment below.

On Thu, Mar 12, 2020 at 6:00 AM Carlos Pignat= aro (cpignata) <cpignata@cisco.com= > wrote:
Hi, Carlos,

Thanks for the response! Please see inline, prefaced with CMP.

2020/03/08 =E5=8D=88=E5=BE=8C0:43=E3=80=81CARLOS JESUS BERNARDOS CANO = <cjbc@it.uc3m.es>=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:

Hi Carlos,

Thanks for your review. Please find inline below my comments.

On Sat, Feb 29, 2020 at 4:15 AM Carlo= s Pignataro (cpignata) <cpignata@cisco.com> wrote:
Reviewer: Carlos Pignataro
Review result: Ready with Nits

I am an assigned INT directorate reviewer for this Internet-Draft.=C2=A0 Th= ese
comments were written primarily for the benefit of the Internet Area Direct= ors.
Document editors and shepherd(s) should treat these comments just like they=
would treat comments from any other IETF contributors and resolve them alon= g
with any other Last Call comments that have been received. For more details= on
the INT Directorate, see=C2=A0http://www.ietf.= org/iesg/directorate.html.

I hope these comments are clear and useful.

As requested, from the Internet area Directorate review, these two DMM=C2=A0
documents are being reviewed together:=C2=A0
* draft-ietf-dmm-distributed-mobility-anchoring-14
* draft-ietf-dmm-pmipv6-dlif-05

This document defines distributed mobility anchoring, in terms of the= =C2=A0
different configurations and functions to provide IP mobility support,=C2=A0
including network-based or host-based mobility support.

The intended status is Informational. It is a very well written and compreh= ensive
document. It is technically sound.

No major or minor issues.

Nits:

A set of small nits for your consideration.

1.=C2=A0 Introduction

=C2=A0 =C2=A0As a Mobile Node (MN) attaches to an access router and establi= shes a
=C2=A0 =C2=A0link between them, a /64 IPv6 prefix anchored to the router ma= y be
=C2=A0 =C2=A0assigned to the link for exclusive use by the MN [RFC6459].=C2= =A0 The MN
=C2=A0 =C2=A0may then configure a global IPv6 address from this prefix and = use it
=C2=A0 =C2=A0as the source IP address in a flow to communicate with its
=C2=A0 =C2=A0correspondent node (CN).

Capitalize:
s/correspondent node/Correspondent Node/

2.=C2=A0 Conventions and Terminology

=C2=A0 =C2=A0These include terms such as mobile node (MN), correspondent no= de
=C2=A0 =C2=A0(CN), home agent (HA), home address (HoA), care-of-address (Co= A),
=C2=A0 =C2=A0local mobility anchor (LMA), and mobile access gateway (MAG).<= br>
Capitalize =E2=80=9CMobile Node=E2=80=9D (as per =C2=A7 1), =E2=80=9CCoresp= ondent Node=E2=80=9D, etc.

Similar within this same =C2=A7 2, =E2=80=9Cmobile router=E2=80=9D, etc. Same throughout the document (e.g., =E2=80=9Crouter advertisement (RA)=E2= =80=9D)

4.3.=C2=A0 Mobility case, anchor relocation

=C2=A0 =C2=A0The IP prefix/address anchoring may move without changing the = IP
=C2=A0 =C2=A0prefix/address of the flow.=C2=A0 Here the LM and FM functions= in Figure 1
=C2=A0 =C2=A0in Section 3.1 are implemented as shown in Figure 7.

=E2=80=9CFigure 1 in Section 3.1.1 are implemented=E2=80=9D

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Figure 7: Anchor mobility

Should this figure=E2=80=99s label be =E2=80=9CAnchor Relocation=E2=80=9D i= nstead of =E2=80=98Anchor mobility=E2=80=9D?

5.=C2=A0 Security Considerations

=C2=A0 =C2=A0As stated in [RFC7333], "a DMM solution MUST supportany s= ecurity

s/supportany/support any/

8.2. Informative References

The relationship of this document and draft-ietf-dmm-deployment-models is m= ostly clear, thank you for that.

I hope you fid these comments useful.

Carlos Pignataro.


https://tools.ietf.org/html/draft-ietf-dm= m-pmipv6-dlif-05

I am an assigned INT directorate reviewer for this Internet-Draft.=C2=A0 Th= ese
comments were written primarily for the benefit of the Internet Area Direct= ors.
Document editors and shepherd(s) should treat these comments just like they=
would treat comments from any other IETF contributors and resolve them alon= g
with any other Last Call comments that have been received. For more details= on
the INT Directorate, see=C2=A0http://www.ietf.= org/iesg/directorate.html.

I hope these comments are clear and useful.

As requested, from the Internet area Directorate review, these two DMM=C2=A0
documents are being reviewed together:=C2=A0
* draft-ietf-dmm-distributed-mobility-anchoring-14
* draft-ietf-dmm-pmipv6-dlif-05

This document provides an approach to distributed mobility management
by extending network-based mobility protocols (like Proxy Mobile IPv6). In<= br> this solution, mobility sessions are anchored at the last IP hop router.=C2=A0

This document=E2=80=99s intended status is Experimental. It is well written= for such a complex comprehensive document, and technically complete and se= nsible.

No major or minor issues.

Nits:

Please find some small comments for your consideration:


4.1.=C2=A0 Proxy Binding Update

=C2=A0 =C2=A0A new flag (D) is included in the Proxy Binding Update to indi= cate
=C2=A0 =C2=A0that the Proxy Binding Update is coming from a Mobility Anchor= and
=C2=A0 =C2=A0Access Router and not from a mobile access gateway.=C2=A0 The = rest of the
=C2=A0 =C2=A0Proxy Binding Update format remains the same as defined in [RF= C5213].

=C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Sequence #=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|A|H|L|K|M|R|P|F|T|B|S|D| Reser |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Lifetime=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

However, for RFC 5213 S 8.1:

=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |A|H|L|K|M|R|P|=C2=A0 Reserved=C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lifetime=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+

So, therefore, seems like:
1. The definition of Flags F, T, B, and S is missing.
2. =E2=80=9CReser=E2=80=9D is not really clear and =E2=80=9CRsrvd=E2=80=9D = seems to fit and be more unambiguous.

[CB] I've replaced "Reser" with "Rsrvd". The o= ther flags are defined in other RFCs, published after RFC 5213. Do I need t= o explain what each of these flags do in this document? In any case, there = might be additional flags defined in the future, so I think it is not needed.
=C2=A0

CMP: The problem I see is that the document currently says:
=C2=A0 =C2=A0The rest of the
=C2=A0 =C2=A0Proxy Binding Update format remains the same as defined in [RF= C5213]

But based on what you write, that is not the case.

No, you do not need to explain what each flag does =E2=80=94 but I=E2= =80=99d suggest either not say where they are defined, or include the other= RFCs.

I checked IANA and found:

[CB] OK, I was referring= to the rest of the PBU format in general. I can add that a note referring = to the IANA registry for the definition and references of the flags. Would = that work?

Thanks,

Carlos=
=C2=A0


4.2.=C2=A0 Proxy Binding Acknowledgment

=E2=80=A6
=C2=A0 The rest of the Proxy Binding Acknowledgment format
=C2=A0 =C2=A0remains the same as defined in [RFC5213].

=C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A03
=C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0Status=C2= =A0 =C2=A0 =C2=A0 |K|R|P|T|B|S|D| |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

However, from RFC 5213:

=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0S= tatus=C2=A0 =C2=A0 =C2=A0 |K|R|P|Reserved |
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+

And thus, Flags T, B, S are not defined.

[CB] Same as before. Additional flags were defined and added to IANA r= egistry after RFC 5213 was published. I refer to RFC 5213 as it is where th= e actual=C2=A0PBU/PBA format was specified (although they are basically BU/= BA with P flag set to 1).


THanks, I understand. I was commenting on the text that says =E2=80=9C= the rest is defined in RFC5213=E2=80=9D.


4.3.=C2=A0 Anchored Prefix Option

=C2=A0 =C2=A0Anchored Prefix

=C2=A0 =C2=A0 =C2=A0 A sixteen-byte field containing the mobile node's = IPv6 Anchored
=C2=A0 =C2=A0 =C2=A0 Prefix.=C2=A0 Only the first Prefix Length bytes are v= alid for the
=C2=A0 =C2=A0 =C2=A0 Anchored Prefix.=C2=A0 The rest of the bytes MUST be i= gnored.

Not being pedantic, but:
s/byte/octet/g // throughout.
Or=E2=80=A6 "128-bit=E2=80=9D instead of =E2=80=9Csixteen-octet=E2=80= =9D.

[CB] OK, I see that RFC 6275 uses only "octet", while RFC 52= 13 uses both "octet" and "byte". But I agree that using= only one is the right thing to do. I've chosen "octet" as yo= u suggested.


Thanks! As strictly there can be non-octet bytes.



5.=C2=A0 IANA Considerations

=C2=A0 =C2=A0This document defines six new mobility options that need to be=
=C2=A0 =C2=A0registered in the Mobility Options registry on the Mobile IPv6=
=C2=A0 =C2=A0parameters registry.=C2=A0 The required IANA actions are marke= d as IANA-1
=C2=A0 =C2=A0to IANA-6.

It would be useful to breakout the specific IANA requests in a table, secti= ons, or other structure detailing how it should look in the IANA registries= .

[CB] I've added some additional text, but following the approach o= f RFC 5213, which keeps it simple. I hope this is sufficient.


Thank you.


6. Security Considerations

Is there underlying protection against spoofing that can be called out? Thi= s should be addressed in the Security Dir review, so I will not mention it = here =F0=9F=99=82

[CB] We assume that using the mechanisms described for RFC 5213 is eno= ugh. We have added some additional considerations for the risks/procedures = that are specific to the=C2=A0distributed solution.


Ack.


8.2.=C2=A0 Informative References

=C2=A0 =C2=A0[I-D.ietf-dmm-deployment-models]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gundavelli, S. and S. Jeon= , "DMM Deployment Models and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Architectural Consideratio= ns", draft-ietf-dmm-deployment-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 models-04 (work in progres= s), May 2018.

Since there are key definitions from this document, should this be Normativ= e?

[CB] Since this document is not going to be progressed any further, we= have included the relevant terms in the terminology section and remove the= reference.

Got it.

=C2=A0

=C2=A0 =C2=A0[RFC7333]=C2=A0 Chan, H., Ed., Liu, D., Seite, P., Yokota, H.,= and J.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Korhonen, "Requiremen= ts for Distributed Mobility
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Management", RFC 7333= , DOI 10.17487/RFC7333, August 2014,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://= www.rfc-editor.org/info/rfc7333>.

Similarly, should this reference be Normative instead of Informative?

[CB] I don't have a strong opinion here. I've moved it to Norm= ative, but I think it could stay as Informative as well.


Your call. Thanks for considering.


Appendix B.=C2=A0 Implementation experience

Should this really be an Implementation Status section [RFC7942], as it des= cribes a point in time rather than learnings?

Should the Appendices clarify they make no normative specs?

[CB] Based also on other comments we have remove both appendixes.


Ack.


I hope these comments are useful.

[CB] Yes, they are indeed. Thanks!

:-) Super.

(Another) Carlos.


Carlos
=C2=A0

Thank you very much,

Carlos Pignataro.

--00000000000018bfac05a0a48796-- From nobody Thu Mar 12 06:00:07 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429FB3A044F; Thu, 12 Mar 2020 06:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DXgX0Wuu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VifdNItV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-K_e2iUtTo6; Thu, 12 Mar 2020 06:00:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CFD23A045E; Thu, 12 Mar 2020 06:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54513; q=dns/txt; s=iport; t=1584018001; x=1585227601; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vWUrlfdHmdH29jwhonmNO9trj+S2Sug4QD1SIuvFET8=; b=DXgX0Wuu49yyEKOuX72yqYePUkKUV6DKFeWgb8pX/nQJGKGJcHG6HRIj RE44A7PYO2EW4T8jxpFBclPw82RoMb8hUeMFLlIkjvQCUPCFAuQ3YYx3W 8lB/Iq/YFEDeSij9w5z+GeLDvslNUDbTCZ1jqFNncSjLGZDZ2Ed+YLL1I M=; IronPort-PHdr: =?us-ascii?q?9a23=3ARyaWtRV0CqYcRS2sHHmAC90mXFLV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankxBMVNUlZ59lmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAwAkMWpe/4UNJK1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4ElLyQFJwVsWCAECyoKhAuDRQOKb5p1glIDVAkBAQE?= =?us-ascii?q?MAQElCAIEAQGBLgGDFAIXgX8kOBMCAwEBCwEBBQEBAQIBBQRthVYMhWQCAQM?= =?us-ascii?q?SCAkdAQEwBwEPAgEGAjgBBgMCAgIwFBECBA4FCRIHgwQBgX1NAy4BDo9KkGc?= =?us-ascii?q?CgTmIYnWBMoJ/AQEFgTMCg3MYggwJgTiMLxqBQT+BEScggk0+glkLAQEBAQG?= =?us-ascii?q?BYRgWgmQygiyHWoYLgwmFdYoUjlJwCoI8h1aPFx2CSogmkE6QT4UqggiPJoM?= =?us-ascii?q?zAgQCBAUCDgEBBYFpIoFYcBVlAYJBCTUSGA2OHQkDF4EEAQiCQ4UUhUABdAK?= =?us-ascii?q?BJ4wBAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.70,544,1574121600"; d="scan'208,217";a="732192717" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2020 13:00:00 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 02CD00PD016532 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Mar 2020 13:00:00 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Mar 2020 07:59:59 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Mar 2020 08:59:57 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Mar 2020 08:59:58 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QuCS+Au+aXzC87y9ixf69SHciEoesNBzO38b6MYkI/59zWzrkgio/DOjmvGH/t0/EKguQm5WCzdEIWKZF8nVemEdKt4uYQHJxvTf4csJWy5dQY/bc25Q2JvJvPwdEnuKM2NbyUdR5gJ5sjk8hcfZu7Y5uBfJGxAFePTYcHGetat5hLEoqVDNRZfsf+xz32DzRGmenBMxM6OzDLfr/3IFW5HPc1SyI4+Tq3JxhtVsaXt2BS4SKj6M8uZ8ONdOAOtuFliYWbHTH8QMVnlmydUZMIAnZM6LxbNacYO7XhB0Hu1Y6WqjJTi/PXYDooT48tzT+re0gZAV8ZNW8W9P92sEvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vWUrlfdHmdH29jwhonmNO9trj+S2Sug4QD1SIuvFET8=; b=Zx7UaOdMqdjulH0xzn8oqdKApeQc/Y3UTWeZl7O+X23QVBwKUKNLi+slyG9QxaQf8n0qfkojde87sYkc/Jj+4WMMtSEHum2TScJgzYuh5R1/iGJuEXf1ruKvY2KWgqr427Fm+8ybErIwrb1XwX1cDodjGs5jdiYoqeke++hhuU1BUqIFGLGRZF6c9enVypD6QSQKosPegYPAH25qS5ubFNYjRgq81HO1NmuvABeBPgVyzoLjtvXNhCSLJoA6CoP+OzJLRGKrmwrBBO0748LVBLaKwWv+7Dj1uLvAWTd7NbCpplSlFEn9R1kug6d7H9EO3RYp7f+Zg5GprUJ8ErwQow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vWUrlfdHmdH29jwhonmNO9trj+S2Sug4QD1SIuvFET8=; b=VifdNItVgJBl096ZhAEqwLJa5sh1rwrIstYTEWKasgU3GbTbGStHHPpSICEqki9UMhe0KdqeCKWTxi4JI9ZMjjD+fxl0EXT4bEdAkzaZe+uQy3VT/lRvsBnO0DDzad8cPgZ+nr8N341lY9xTsU4O+59tlM1PDelO7QtCH2dkCeI= Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3684.namprd11.prod.outlook.com (2603:10b6:408:86::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.15; Thu, 12 Mar 2020 12:59:57 +0000 Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74%7]) with mapi id 15.20.2793.018; Thu, 12 Mar 2020 12:59:57 +0000 From: "Carlos Pignataro (cpignata)" To: CARLOS JESUS BERNARDOS CANO CC: "int-dir@ietf.org" , "last-call@ietf.org" , "draft-ietf-dmm-pmipv6-dlif.all@ietf.org" , "dmm@ietf.org" Thread-Topic: [Last-Call] Intdir telechat review of draft-ietf-dmm-pmipv6-dlif -05 Thread-Index: AQHV7q6FPaDeUcCKfk2s8DdKgaEjLag/FWsAgAVjh4CAAEHWgIAARBwA Date: Thu, 12 Mar 2020 12:59:57 +0000 Message-ID: <1731D29F-3C82-45C0-AED6-C0983CD8AD05@cisco.com> References: <5480B86B-3D6B-490B-9CAC-609EE7A41278@cisco.com> <473EA3D0-688D-4047-83B9-ED351937232A@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.60.0.2.5) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [108.203.7.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0f61180c-e375-4aa7-0981-08d7c6854437 x-ms-traffictypediagnostic: BN8PR11MB3684: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0340850FCD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(376002)(366004)(396003)(136003)(199004)(6486002)(5660300002)(71200400001)(6916009)(86362001)(4743002)(316002)(54906003)(6512007)(6506007)(19273905006)(2616005)(4326008)(53546011)(2906002)(66946007)(66476007)(66556008)(64756008)(76116006)(966005)(66574012)(66446008)(81166006)(81156014)(8936002)(8676002)(21615005)(33656002)(26005)(478600001)(30864003)(186003)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3684; H:BN8PR11MB3635.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: A/b6CYQQ/E5LaUvjp2El3ShyXmuHeYg7iPiGky+vYyXnQWjq1PTJhK/+ee9Uo1aDLIejyVVhjg6MroY7ydm+UdZOurOtq4cvNH7xo9I1qmHjRf913kl7N4wCP01Rb1PnYHauvlp9bIVwa9Rvs3LjvUgAP2vE8pADyP1pT3lwn/oIDqOP7pSmokfSAYstxIcpN5VM32s5wLK9GQBS7hCQCXFNwGwDGqGoVqtNF7br+k4r1FyBWyrpkvMcuG0TlkRBE2KwB2xETXP7DRTzRfuBMn19CrvYPeH7ATHyrO09/knEP3OvWcnXnoUpoGG7Gpet4TrrXJV41FZTZXAOMp028wETJPFTGHgAkV37whdEaqrh7ox4cE0KGtnO1AOaZnvCt20TpT02rDNYY1Y2NBwgwh7qAXpE3FEhfUHAkrwt05GlzZHvhjlbJGUtx3n5slC589HT2PNlmsFjGW7ky8jok2YDTu/Mje4X4oSxcrFpf8noKP5zodgeqSNf9EAMhZaQGDRHpBh5XoU0YN60Zoe/qw== x-ms-exchange-antispam-messagedata: qDBF+W30kfykS+Btryj6uWjb59rJJ4ImSg0P5x0+HYo/ye+eOLhFGg5D76CE5YjDvv+17BE6foePKmIDTCJMzMMKciyNjBQFWLoi3QUcSZVQUksK4W8o2hi5KTnev9bjR02mygKmu7tDbvld4LNzuw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1731D29F3C8245C0AED6C0983CD8AD05ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0f61180c-e375-4aa7-0981-08d7c6854437 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2020 12:59:57.2193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cRw0SHn/Z/PDjAHG7P9SoWvC2pY/FVX2MYnhRU7mVuShYx/+bSrh7CkM41WnH81jDuyhrlvgpr0j8dbqA0bWBQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3684 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [DMM] [Last-Call] Intdir telechat review of draft-ietf-dmm-pmipv6-dlif -05 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 13:00:06 -0000 --_000_1731D29F3C8245C0AED6C0983CD8AD05ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCB3b3VsZCB3b3JrIGdyZWF0LCBDYXJsb3MuIE1hbnkgdGhhbmtzIGZvciB0aGUgcXVpY2sg cmVzcG9uc2UsIGFuZCBhZGRyZXNzaW5nIGFsbCBteSByZXZpZXcgY29tbWVudHMhDQoNCkNhcmxv cy4NCg0KMjAyMC8wMy8xMiDljYjliY00OjU244CBQ0FSTE9TIEpFU1VTIEJFUk5BUkRPUyBDQU5P IDxjamJjQGl0LnVjM20uZXM8bWFpbHRvOmNqYmNAaXQudWMzbS5lcz4+44Gu44Oh44O844OrOg0K DQpIaSBDYXJsb3MsDQoNClRoYW5rcyBhZ2Fpbi4gU2hvcnQgY29tbWVudCBiZWxvdy4NCg0KT24g VGh1LCBNYXIgMTIsIDIwMjAgYXQgNjowMCBBTSBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkg PGNwaWduYXRhQGNpc2NvLmNvbTxtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPj4gd3JvdGU6DQpI aSwgQ2FybG9zLA0KDQpUaGFua3MgZm9yIHRoZSByZXNwb25zZSEgUGxlYXNlIHNlZSBpbmxpbmUs IHByZWZhY2VkIHdpdGggQ01QLg0KDQoyMDIwLzAzLzA4IOWNiOW+jDA6NDPjgIFDQVJMT1MgSkVT VVMgQkVSTkFSRE9TIENBTk8gPGNqYmNAaXQudWMzbS5lczxtYWlsdG86Y2piY0BpdC51YzNtLmVz Pj7jga7jg6Hjg7zjg6s6DQoNCkhpIENhcmxvcywNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4g UGxlYXNlIGZpbmQgaW5saW5lIGJlbG93IG15IGNvbW1lbnRzLg0KDQpPbiBTYXQsIEZlYiAyOSwg MjAyMCBhdCA0OjE1IEFNIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lz Y28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiB3cm90ZToNClJldmlld2VyOiBDYXJs b3MgUGlnbmF0YXJvDQpSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5pdHMNCg0KSSBhbSBhbiBh c3NpZ25lZCBJTlQgZGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQu ICBUaGVzZQ0KY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQg b2YgdGhlIEludGVybmV0IEFyZWEgRGlyZWN0b3JzLg0KRG9jdW1lbnQgZWRpdG9ycyBhbmQgc2hl cGhlcmQocykgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSB0aGV5DQp3b3Vs ZCB0cmVhdCBjb21tZW50cyBmcm9tIGFueSBvdGhlciBJRVRGIGNvbnRyaWJ1dG9ycyBhbmQgcmVz b2x2ZSB0aGVtIGFsb25nDQp3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCBo YXZlIGJlZW4gcmVjZWl2ZWQuIEZvciBtb3JlIGRldGFpbHMgb24NCnRoZSBJTlQgRGlyZWN0b3Jh dGUsIHNlZSBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUuaHRtbC4NCg0KSSBo b3BlIHRoZXNlIGNvbW1lbnRzIGFyZSBjbGVhciBhbmQgdXNlZnVsLg0KDQpBcyByZXF1ZXN0ZWQs IGZyb20gdGhlIEludGVybmV0IGFyZWEgRGlyZWN0b3JhdGUgcmV2aWV3LCB0aGVzZSB0d28gRE1N DQpkb2N1bWVudHMgYXJlIGJlaW5nIHJldmlld2VkIHRvZ2V0aGVyOg0KKiBkcmFmdC1pZXRmLWRt bS1kaXN0cmlidXRlZC1tb2JpbGl0eS1hbmNob3JpbmctMTQNCiogZHJhZnQtaWV0Zi1kbW0tcG1p cHY2LWRsaWYtMDUNCg0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIGRpc3RyaWJ1dGVkIG1vYmlsaXR5 IGFuY2hvcmluZywgaW4gdGVybXMgb2YgdGhlDQpkaWZmZXJlbnQgY29uZmlndXJhdGlvbnMgYW5k IGZ1bmN0aW9ucyB0byBwcm92aWRlIElQIG1vYmlsaXR5IHN1cHBvcnQsDQppbmNsdWRpbmcgbmV0 d29yay1iYXNlZCBvciBob3N0LWJhc2VkIG1vYmlsaXR5IHN1cHBvcnQuDQoNClRoZSBpbnRlbmRl ZCBzdGF0dXMgaXMgSW5mb3JtYXRpb25hbC4gSXQgaXMgYSB2ZXJ5IHdlbGwgd3JpdHRlbiBhbmQg Y29tcHJlaGVuc2l2ZQ0KZG9jdW1lbnQuIEl0IGlzIHRlY2huaWNhbGx5IHNvdW5kLg0KDQpObyBt YWpvciBvciBtaW5vciBpc3N1ZXMuDQoNCk5pdHM6DQoNCkEgc2V0IG9mIHNtYWxsIG5pdHMgZm9y IHlvdXIgY29uc2lkZXJhdGlvbi4NCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBBcyBhIE1vYmls ZSBOb2RlIChNTikgYXR0YWNoZXMgdG8gYW4gYWNjZXNzIHJvdXRlciBhbmQgZXN0YWJsaXNoZXMg YQ0KICAgbGluayBiZXR3ZWVuIHRoZW0sIGEgLzY0IElQdjYgcHJlZml4IGFuY2hvcmVkIHRvIHRo ZSByb3V0ZXIgbWF5IGJlDQogICBhc3NpZ25lZCB0byB0aGUgbGluayBmb3IgZXhjbHVzaXZlIHVz ZSBieSB0aGUgTU4gW1JGQzY0NTldLiAgVGhlIE1ODQogICBtYXkgdGhlbiBjb25maWd1cmUgYSBn bG9iYWwgSVB2NiBhZGRyZXNzIGZyb20gdGhpcyBwcmVmaXggYW5kIHVzZSBpdA0KICAgYXMgdGhl IHNvdXJjZSBJUCBhZGRyZXNzIGluIGEgZmxvdyB0byBjb21tdW5pY2F0ZSB3aXRoIGl0cw0KICAg Y29ycmVzcG9uZGVudCBub2RlIChDTikuDQoNCkNhcGl0YWxpemU6DQpzL2NvcnJlc3BvbmRlbnQg bm9kZS9Db3JyZXNwb25kZW50IE5vZGUvDQoNCjIuICBDb252ZW50aW9ucyBhbmQgVGVybWlub2xv Z3kNCg0KICAgVGhlc2UgaW5jbHVkZSB0ZXJtcyBzdWNoIGFzIG1vYmlsZSBub2RlIChNTiksIGNv cnJlc3BvbmRlbnQgbm9kZQ0KICAgKENOKSwgaG9tZSBhZ2VudCAoSEEpLCBob21lIGFkZHJlc3Mg KEhvQSksIGNhcmUtb2YtYWRkcmVzcyAoQ29BKSwNCiAgIGxvY2FsIG1vYmlsaXR5IGFuY2hvciAo TE1BKSwgYW5kIG1vYmlsZSBhY2Nlc3MgZ2F0ZXdheSAoTUFHKS4NCg0KQ2FwaXRhbGl6ZSDigJxN b2JpbGUgTm9kZeKAnSAoYXMgcGVyIMKnIDEpLCDigJxDb3Jlc3BvbmRlbnQgTm9kZeKAnSwgZXRj Lg0KDQpTaW1pbGFyIHdpdGhpbiB0aGlzIHNhbWUgwqcgMiwg4oCcbW9iaWxlIHJvdXRlcuKAnSwg ZXRjLg0KU2FtZSB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCAoZS5nLiwg4oCccm91dGVyIGFkdmVy dGlzZW1lbnQgKFJBKeKAnSkNCg0KNC4zLiAgTW9iaWxpdHkgY2FzZSwgYW5jaG9yIHJlbG9jYXRp b24NCg0KICAgVGhlIElQIHByZWZpeC9hZGRyZXNzIGFuY2hvcmluZyBtYXkgbW92ZSB3aXRob3V0 IGNoYW5naW5nIHRoZSBJUA0KICAgcHJlZml4L2FkZHJlc3Mgb2YgdGhlIGZsb3cuICBIZXJlIHRo ZSBMTSBhbmQgRk0gZnVuY3Rpb25zIGluIEZpZ3VyZSAxDQogICBpbiBTZWN0aW9uIDMuMSBhcmUg aW1wbGVtZW50ZWQgYXMgc2hvd24gaW4gRmlndXJlIDcuDQoNCuKAnEZpZ3VyZSAxIGluIFNlY3Rp b24gMy4xLjEgYXJlIGltcGxlbWVudGVk4oCdDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICBG aWd1cmUgNzogQW5jaG9yIG1vYmlsaXR5DQoNClNob3VsZCB0aGlzIGZpZ3VyZeKAmXMgbGFiZWwg YmUg4oCcQW5jaG9yIFJlbG9jYXRpb27igJ0gaW5zdGVhZCBvZiDigJhBbmNob3IgbW9iaWxpdHni gJ0/DQoNCjUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBBcyBzdGF0ZWQgaW4gW1JG QzczMzNdLCAiYSBETU0gc29sdXRpb24gTVVTVCBzdXBwb3J0YW55IHNlY3VyaXR5DQoNCnMvc3Vw cG9ydGFueS9zdXBwb3J0IGFueS8NCg0KOC4yLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNClRo ZSByZWxhdGlvbnNoaXAgb2YgdGhpcyBkb2N1bWVudCBhbmQgZHJhZnQtaWV0Zi1kbW0tZGVwbG95 bWVudC1tb2RlbHMgaXMgbW9zdGx5IGNsZWFyLCB0aGFuayB5b3UgZm9yIHRoYXQuDQoNCkkgaG9w ZSB5b3UgZmlkIHRoZXNlIGNvbW1lbnRzIHVzZWZ1bC4NCg0KQ2FybG9zIFBpZ25hdGFyby4NCg0K DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbW0tcG1pcHY2LWRsaWYt MDUNCg0KSSBhbSBhbiBhc3NpZ25lZCBJTlQgZGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMg SW50ZXJuZXQtRHJhZnQuICBUaGVzZQ0KY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBm b3IgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0IEFyZWEgRGlyZWN0b3JzLg0KRG9jdW1lbnQg ZWRpdG9ycyBhbmQgc2hlcGhlcmQocykgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSB0aGV5DQp3b3VsZCB0cmVhdCBjb21tZW50cyBmcm9tIGFueSBvdGhlciBJRVRGIGNvbnRy aWJ1dG9ycyBhbmQgcmVzb2x2ZSB0aGVtIGFsb25nDQp3aXRoIGFueSBvdGhlciBMYXN0IENhbGwg Y29tbWVudHMgdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQuIEZvciBtb3JlIGRldGFpbHMgb24NCnRo ZSBJTlQgRGlyZWN0b3JhdGUsIHNlZSBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3Jh dGUuaHRtbC4NCg0KSSBob3BlIHRoZXNlIGNvbW1lbnRzIGFyZSBjbGVhciBhbmQgdXNlZnVsLg0K DQpBcyByZXF1ZXN0ZWQsIGZyb20gdGhlIEludGVybmV0IGFyZWEgRGlyZWN0b3JhdGUgcmV2aWV3 LCB0aGVzZSB0d28gRE1NDQpkb2N1bWVudHMgYXJlIGJlaW5nIHJldmlld2VkIHRvZ2V0aGVyOg0K KiBkcmFmdC1pZXRmLWRtbS1kaXN0cmlidXRlZC1tb2JpbGl0eS1hbmNob3JpbmctMTQNCiogZHJh ZnQtaWV0Zi1kbW0tcG1pcHY2LWRsaWYtMDUNCg0KVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhbiBh cHByb2FjaCB0byBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50DQpieSBleHRlbmRpbmcg bmV0d29yay1iYXNlZCBtb2JpbGl0eSBwcm90b2NvbHMgKGxpa2UgUHJveHkgTW9iaWxlIElQdjYp LiBJbg0KdGhpcyBzb2x1dGlvbiwgbW9iaWxpdHkgc2Vzc2lvbnMgYXJlIGFuY2hvcmVkIGF0IHRo ZSBsYXN0IElQIGhvcCByb3V0ZXIuDQoNClRoaXMgZG9jdW1lbnTigJlzIGludGVuZGVkIHN0YXR1 cyBpcyBFeHBlcmltZW50YWwuIEl0IGlzIHdlbGwgd3JpdHRlbiBmb3Igc3VjaCBhIGNvbXBsZXgg Y29tcHJlaGVuc2l2ZSBkb2N1bWVudCwgYW5kIHRlY2huaWNhbGx5IGNvbXBsZXRlIGFuZCBzZW5z aWJsZS4NCg0KTm8gbWFqb3Igb3IgbWlub3IgaXNzdWVzLg0KDQpOaXRzOg0KDQpQbGVhc2UgZmlu ZCBzb21lIHNtYWxsIGNvbW1lbnRzIGZvciB5b3VyIGNvbnNpZGVyYXRpb246DQoNCg0KNC4xLiAg UHJveHkgQmluZGluZyBVcGRhdGUNCg0KICAgQSBuZXcgZmxhZyAoRCkgaXMgaW5jbHVkZWQgaW4g dGhlIFByb3h5IEJpbmRpbmcgVXBkYXRlIHRvIGluZGljYXRlDQogICB0aGF0IHRoZSBQcm94eSBC aW5kaW5nIFVwZGF0ZSBpcyBjb21pbmcgZnJvbSBhIE1vYmlsaXR5IEFuY2hvciBhbmQNCiAgIEFj Y2VzcyBSb3V0ZXIgYW5kIG5vdCBmcm9tIGEgbW9iaWxlIGFjY2VzcyBnYXRld2F5LiAgVGhlIHJl c3Qgb2YgdGhlDQogICBQcm94eSBCaW5kaW5nIFVwZGF0ZSBmb3JtYXQgcmVtYWlucyB0aGUgc2Ft ZSBhcyBkZWZpbmVkIGluIFtSRkM1MjEzXS4NCg0KICAgMCAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgMw0KICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgU2VxdWVuY2UgIyAgICAg ICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICB8QXxIfEx8S3xNfFJ8UHxGfFR8QnxTfER8IFJlc2VyIHwg ICAgICAgICAgICBMaWZldGltZSAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KSG93ZXZlciwg Zm9yIFJGQyA1MjEzIFMgOC4xOg0KDQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfEF8SHxMfEt8TXxS fFB8ICBSZXNlcnZlZCAgICAgICB8ICAgICAgICAgICAgTGlmZXRpbWUgICAgICAgICAgIHwNCiAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQoNClNvLCB0aGVyZWZvcmUsIHNlZW1zIGxpa2U6DQoxLiBUaGUgZGVmaW5p dGlvbiBvZiBGbGFncyBGLCBULCBCLCBhbmQgUyBpcyBtaXNzaW5nLg0KMi4g4oCcUmVzZXLigJ0g aXMgbm90IHJlYWxseSBjbGVhciBhbmQg4oCcUnNydmTigJ0gc2VlbXMgdG8gZml0IGFuZCBiZSBt b3JlIHVuYW1iaWd1b3VzLg0KDQpbQ0JdIEkndmUgcmVwbGFjZWQgIlJlc2VyIiB3aXRoICJSc3J2 ZCIuIFRoZSBvdGhlciBmbGFncyBhcmUgZGVmaW5lZCBpbiBvdGhlciBSRkNzLCBwdWJsaXNoZWQg YWZ0ZXIgUkZDIDUyMTMuIERvIEkgbmVlZCB0byBleHBsYWluIHdoYXQgZWFjaCBvZiB0aGVzZSBm bGFncyBkbyBpbiB0aGlzIGRvY3VtZW50PyBJbiBhbnkgY2FzZSwgdGhlcmUgbWlnaHQgYmUgYWRk aXRpb25hbCBmbGFncyBkZWZpbmVkIGluIHRoZSBmdXR1cmUsIHNvIEkgdGhpbmsgaXQgaXMgbm90 IG5lZWRlZC4NCg0KDQpDTVA6IFRoZSBwcm9ibGVtIEkgc2VlIGlzIHRoYXQgdGhlIGRvY3VtZW50 IGN1cnJlbnRseSBzYXlzOg0KICAgVGhlIHJlc3Qgb2YgdGhlDQogICBQcm94eSBCaW5kaW5nIFVw ZGF0ZSBmb3JtYXQgcmVtYWlucyB0aGUgc2FtZSBhcyBkZWZpbmVkIGluIFtSRkM1MjEzXQ0KDQpC dXQgYmFzZWQgb24gd2hhdCB5b3Ugd3JpdGUsIHRoYXQgaXMgbm90IHRoZSBjYXNlLg0KDQpObywg eW91IGRvIG5vdCBuZWVkIHRvIGV4cGxhaW4gd2hhdCBlYWNoIGZsYWcgZG9lcyDigJQgYnV0IEni gJlkIHN1Z2dlc3QgZWl0aGVyIG5vdCBzYXkgd2hlcmUgdGhleSBhcmUgZGVmaW5lZCwgb3IgaW5j bHVkZSB0aGUgb3RoZXIgUkZDcy4NCg0KSSBjaGVja2VkIElBTkEgYW5kIGZvdW5kOg0KaHR0cHM6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvbW9iaWxpdHktcGFyYW1ldGVycy9tb2JpbGl0eS1w YXJhbWV0ZXJzLnhodG1sI21vYmlsaXR5LXBhcmFtZXRlcnMtMTENCg0KW0NCXSBPSywgSSB3YXMg cmVmZXJyaW5nIHRvIHRoZSByZXN0IG9mIHRoZSBQQlUgZm9ybWF0IGluIGdlbmVyYWwuIEkgY2Fu IGFkZCB0aGF0IGEgbm90ZSByZWZlcnJpbmcgdG8gdGhlIElBTkEgcmVnaXN0cnkgZm9yIHRoZSBk ZWZpbml0aW9uIGFuZCByZWZlcmVuY2VzIG9mIHRoZSBmbGFncy4gV291bGQgdGhhdCB3b3JrPw0K DQpUaGFua3MsDQoNCkNhcmxvcw0KDQoNCg0KNC4yLiAgUHJveHkgQmluZGluZyBBY2tub3dsZWRn bWVudA0KDQrigKYNCiAgVGhlIHJlc3Qgb2YgdGhlIFByb3h5IEJpbmRpbmcgQWNrbm93bGVkZ21l bnQgZm9ybWF0DQogICByZW1haW5zIHRoZSBzYW1lIGFzIGRlZmluZWQgaW4gW1JGQzUyMTNdLg0K DQogICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzDQogICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICBTdGF0dXMgICAgICB8S3xSfFB8VHxCfFN8RHwgfA0KICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCg0KSG93ZXZlciwgZnJvbSBSRkMgNTIxMzoNCg0KICAgICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgICAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICBTdGF0dXMgICAgICB8S3xSfFB8UmVzZXJ2ZWQgfA0KICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KQW5k IHRodXMsIEZsYWdzIFQsIEIsIFMgYXJlIG5vdCBkZWZpbmVkLg0KDQpbQ0JdIFNhbWUgYXMgYmVm b3JlLiBBZGRpdGlvbmFsIGZsYWdzIHdlcmUgZGVmaW5lZCBhbmQgYWRkZWQgdG8gSUFOQSByZWdp c3RyeSBhZnRlciBSRkMgNTIxMyB3YXMgcHVibGlzaGVkLiBJIHJlZmVyIHRvIFJGQyA1MjEzIGFz IGl0IGlzIHdoZXJlIHRoZSBhY3R1YWwgUEJVL1BCQSBmb3JtYXQgd2FzIHNwZWNpZmllZCAoYWx0 aG91Z2ggdGhleSBhcmUgYmFzaWNhbGx5IEJVL0JBIHdpdGggUCBmbGFnIHNldCB0byAxKS4NCg0K DQpUSGFua3MsIEkgdW5kZXJzdGFuZC4gSSB3YXMgY29tbWVudGluZyBvbiB0aGUgdGV4dCB0aGF0 IHNheXMg4oCcdGhlIHJlc3QgaXMgZGVmaW5lZCBpbiBSRkM1MjEz4oCdLg0KDQoNCjQuMy4gIEFu Y2hvcmVkIFByZWZpeCBPcHRpb24NCg0KICAgQW5jaG9yZWQgUHJlZml4DQoNCiAgICAgIEEgc2l4 dGVlbi1ieXRlIGZpZWxkIGNvbnRhaW5pbmcgdGhlIG1vYmlsZSBub2RlJ3MgSVB2NiBBbmNob3Jl ZA0KICAgICAgUHJlZml4LiAgT25seSB0aGUgZmlyc3QgUHJlZml4IExlbmd0aCBieXRlcyBhcmUg dmFsaWQgZm9yIHRoZQ0KICAgICAgQW5jaG9yZWQgUHJlZml4LiAgVGhlIHJlc3Qgb2YgdGhlIGJ5 dGVzIE1VU1QgYmUgaWdub3JlZC4NCg0KTm90IGJlaW5nIHBlZGFudGljLCBidXQ6DQpzL2J5dGUv b2N0ZXQvZyAvLyB0aHJvdWdob3V0Lg0KT3LigKYgIjEyOC1iaXTigJ0gaW5zdGVhZCBvZiDigJxz aXh0ZWVuLW9jdGV04oCdLg0KDQpbQ0JdIE9LLCBJIHNlZSB0aGF0IFJGQyA2Mjc1IHVzZXMgb25s eSAib2N0ZXQiLCB3aGlsZSBSRkMgNTIxMyB1c2VzIGJvdGggIm9jdGV0IiBhbmQgImJ5dGUiLiBC dXQgSSBhZ3JlZSB0aGF0IHVzaW5nIG9ubHkgb25lIGlzIHRoZSByaWdodCB0aGluZyB0byBkby4g SSd2ZSBjaG9zZW4gIm9jdGV0IiBhcyB5b3Ugc3VnZ2VzdGVkLg0KDQoNClRoYW5rcyEgQXMgc3Ry aWN0bHkgdGhlcmUgY2FuIGJlIG5vbi1vY3RldCBieXRlcy4NCg0KDQoNCjUuICBJQU5BIENvbnNp ZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBzaXggbmV3IG1vYmlsaXR5IG9w dGlvbnMgdGhhdCBuZWVkIHRvIGJlDQogICByZWdpc3RlcmVkIGluIHRoZSBNb2JpbGl0eSBPcHRp b25zIHJlZ2lzdHJ5IG9uIHRoZSBNb2JpbGUgSVB2Ng0KICAgcGFyYW1ldGVycyByZWdpc3RyeS4g IFRoZSByZXF1aXJlZCBJQU5BIGFjdGlvbnMgYXJlIG1hcmtlZCBhcyBJQU5BLTENCiAgIHRvIElB TkEtNi4NCg0KSXQgd291bGQgYmUgdXNlZnVsIHRvIGJyZWFrb3V0IHRoZSBzcGVjaWZpYyBJQU5B IHJlcXVlc3RzIGluIGEgdGFibGUsIHNlY3Rpb25zLCBvciBvdGhlciBzdHJ1Y3R1cmUgZGV0YWls aW5nIGhvdyBpdCBzaG91bGQgbG9vayBpbiB0aGUgSUFOQSByZWdpc3RyaWVzLg0KDQpbQ0JdIEkn dmUgYWRkZWQgc29tZSBhZGRpdGlvbmFsIHRleHQsIGJ1dCBmb2xsb3dpbmcgdGhlIGFwcHJvYWNo IG9mIFJGQyA1MjEzLCB3aGljaCBrZWVwcyBpdCBzaW1wbGUuIEkgaG9wZSB0aGlzIGlzIHN1ZmZp Y2llbnQuDQoNCg0KVGhhbmsgeW91Lg0KDQoNCjYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoN CklzIHRoZXJlIHVuZGVybHlpbmcgcHJvdGVjdGlvbiBhZ2FpbnN0IHNwb29maW5nIHRoYXQgY2Fu IGJlIGNhbGxlZCBvdXQ/IFRoaXMgc2hvdWxkIGJlIGFkZHJlc3NlZCBpbiB0aGUgU2VjdXJpdHkg RGlyIHJldmlldywgc28gSSB3aWxsIG5vdCBtZW50aW9uIGl0IGhlcmUg8J+Zgg0KDQpbQ0JdIFdl IGFzc3VtZSB0aGF0IHVzaW5nIHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBmb3IgUkZDIDUyMTMg aXMgZW5vdWdoLiBXZSBoYXZlIGFkZGVkIHNvbWUgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBm b3IgdGhlIHJpc2tzL3Byb2NlZHVyZXMgdGhhdCBhcmUgc3BlY2lmaWMgdG8gdGhlIGRpc3RyaWJ1 dGVkIHNvbHV0aW9uLg0KDQoNCkFjay4NCg0KDQo4LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz DQoNCiAgIFtJLUQuaWV0Zi1kbW0tZGVwbG95bWVudC1tb2RlbHNdDQogICAgICAgICAgICAgIEd1 bmRhdmVsbGksIFMuIGFuZCBTLiBKZW9uLCAiRE1NIERlcGxveW1lbnQgTW9kZWxzIGFuZA0KICAg ICAgICAgICAgICBBcmNoaXRlY3R1cmFsIENvbnNpZGVyYXRpb25zIiwgZHJhZnQtaWV0Zi1kbW0t ZGVwbG95bWVudC0NCiAgICAgICAgICAgICAgbW9kZWxzLTA0ICh3b3JrIGluIHByb2dyZXNzKSwg TWF5IDIwMTguDQoNClNpbmNlIHRoZXJlIGFyZSBrZXkgZGVmaW5pdGlvbnMgZnJvbSB0aGlzIGRv Y3VtZW50LCBzaG91bGQgdGhpcyBiZSBOb3JtYXRpdmU/DQoNCltDQl0gU2luY2UgdGhpcyBkb2N1 bWVudCBpcyBub3QgZ29pbmcgdG8gYmUgcHJvZ3Jlc3NlZCBhbnkgZnVydGhlciwgd2UgaGF2ZSBp bmNsdWRlZCB0aGUgcmVsZXZhbnQgdGVybXMgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gYW5k IHJlbW92ZSB0aGUgcmVmZXJlbmNlLg0KDQpHb3QgaXQuDQoNCg0KDQogICBbUkZDNzMzM10gIENo YW4sIEguLCBFZC4sIExpdSwgRC4sIFNlaXRlLCBQLiwgWW9rb3RhLCBILiwgYW5kIEouDQogICAg ICAgICAgICAgIEtvcmhvbmVuLCAiUmVxdWlyZW1lbnRzIGZvciBEaXN0cmlidXRlZCBNb2JpbGl0 eQ0KICAgICAgICAgICAgICBNYW5hZ2VtZW50IiwgUkZDIDczMzMsIERPSSAxMC4xNzQ4Ny9SRkM3 MzMzLCBBdWd1c3QgMjAxNCwNCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2luZm8vcmZjNzMzMz4uDQoNClNpbWlsYXJseSwgc2hvdWxkIHRoaXMgcmVmZXJlbmNlIGJl IE5vcm1hdGl2ZSBpbnN0ZWFkIG9mIEluZm9ybWF0aXZlPw0KDQpbQ0JdIEkgZG9uJ3QgaGF2ZSBh IHN0cm9uZyBvcGluaW9uIGhlcmUuIEkndmUgbW92ZWQgaXQgdG8gTm9ybWF0aXZlLCBidXQgSSB0 aGluayBpdCBjb3VsZCBzdGF5IGFzIEluZm9ybWF0aXZlIGFzIHdlbGwuDQoNCg0KWW91ciBjYWxs LiBUaGFua3MgZm9yIGNvbnNpZGVyaW5nLg0KDQoNCkFwcGVuZGl4IEIuICBJbXBsZW1lbnRhdGlv biBleHBlcmllbmNlDQoNClNob3VsZCB0aGlzIHJlYWxseSBiZSBhbiBJbXBsZW1lbnRhdGlvbiBT dGF0dXMgc2VjdGlvbiBbUkZDNzk0Ml0sIGFzIGl0IGRlc2NyaWJlcyBhIHBvaW50IGluIHRpbWUg cmF0aGVyIHRoYW4gbGVhcm5pbmdzPw0KDQpTaG91bGQgdGhlIEFwcGVuZGljZXMgY2xhcmlmeSB0 aGV5IG1ha2Ugbm8gbm9ybWF0aXZlIHNwZWNzPw0KDQpbQ0JdIEJhc2VkIGFsc28gb24gb3RoZXIg Y29tbWVudHMgd2UgaGF2ZSByZW1vdmUgYm90aCBhcHBlbmRpeGVzLg0KDQoNCkFjay4NCg0KDQpJ IGhvcGUgdGhlc2UgY29tbWVudHMgYXJlIHVzZWZ1bC4NCg0KW0NCXSBZZXMsIHRoZXkgYXJlIGlu ZGVlZC4gVGhhbmtzIQ0KDQo6LSkgU3VwZXIuDQoNCihBbm90aGVyKSBDYXJsb3MuDQoNCg0KQ2Fy bG9zDQoNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCwNCg0KQ2FybG9zIFBpZ25hdGFyby4NCg0K --_000_1731D29F3C8245C0AED6C0983CD8AD05ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4A67860A9B7A5F48B4E255D73EC84A18@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRoYXQgd291bGQgd29yayBncmVhdCwgQ2FybG9z LiBNYW55IHRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLCBhbmQgYWRkcmVzc2luZyBhbGwg bXkgcmV2aWV3IGNvbW1lbnRzIQ0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Q2FybG9zLjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjIwMjAvMDMv MTIg5Y2I5YmNNDo1NuOAgUNBUkxPUyBKRVNVUyBCRVJOQVJET1MgQ0FOTyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNqYmNAaXQudWMzbS5lcyIgY2xhc3M9IiI+Y2piY0BpdC51YzNtLmVzPC9hPiZndDvj ga7jg6Hjg7zjg6s6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkhpIENhcmxv cywNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRo YW5rcyBhZ2Fpbi4gU2hvcnQgY29tbWVudCBiZWxvdy48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9Imdt YWlsX2F0dHIiPk9uIFRodSwgTWFyIDEyLCAyMDIwIGF0IDY6MDAgQU0gQ2FybG9zIFBpZ25hdGFy byAoY3BpZ25hdGEpICZsdDs8YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIiBjbGFz cz0iIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBw eCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBz b2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij4NCjxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7IiBjbGFzcz0i Ij5IaSwgQ2FybG9zLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+VGhhbmtzIGZvciB0aGUgcmVzcG9uc2UhIFBsZWFzZSBzZWUgaW5saW5lLCBwcmVm YWNlZCB3aXRoIENNUC48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4yMDIwLzAz LzA4IOWNiOW+jDA6NDPjgIFDQVJMT1MgSkVTVVMgQkVSTkFSRE9TIENBTk8gJmx0OzxhIGhyZWY9 Im1haWx0bzpjamJjQGl0LnVjM20uZXMiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5jamJjQGl0 LnVjM20uZXM8L2E+Jmd0O+OBruODoeODvOODqzo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGkgQ2FybG9zLA0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzIGZvciB5 b3VyIHJldmlldy4gUGxlYXNlIGZpbmQgaW5saW5lIGJlbG93IG15IGNvbW1lbnRzLjwvZGl2Pg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRp cj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gU2F0LCBGZWIgMjksIDIwMjAgYXQgNDoxNSBB TSBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0 YUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5jcGlnbmF0YUBjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0 LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6 IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NClJldmlld2VyOiBDYXJs b3MgUGlnbmF0YXJvPGJyIGNsYXNzPSIiPg0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRz PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbSBhbiBhc3NpZ25lZCBJTlQgZGlyZWN0 b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQuJm5ic3A7IFRoZXNlPGJyIGNs YXNzPSIiPg0KY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQg b2YgdGhlIEludGVybmV0IEFyZWEgRGlyZWN0b3JzLjxiciBjbGFzcz0iIj4NCkRvY3VtZW50IGVk aXRvcnMgYW5kIHNoZXBoZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxp a2UgdGhleTxiciBjbGFzcz0iIj4NCndvdWxkIHRyZWF0IGNvbW1lbnRzIGZyb20gYW55IG90aGVy IElFVEYgY29udHJpYnV0b3JzIGFuZCByZXNvbHZlIHRoZW0gYWxvbmc8YnIgY2xhc3M9IiI+DQp3 aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQu IEZvciBtb3JlIGRldGFpbHMgb248YnIgY2xhc3M9IiI+DQp0aGUgSU5UIERpcmVjdG9yYXRlLCBz ZWU8c3BhbiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9pZXNnL2RpcmVjdG9yYXRlLmh0bWwiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi IGNsYXNzPSIiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS5odG1sPC9hPi48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGhvcGUgdGhlc2UgY29tbWVudHMgYXJlIGNs ZWFyIGFuZCB1c2VmdWwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQXMgcmVxdWVzdGVk LCBmcm9tIHRoZSBJbnRlcm5ldCBhcmVhIERpcmVjdG9yYXRlIHJldmlldywgdGhlc2UgdHdvIERN TTxzcGFuIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpkb2N1bWVudHMgYXJl IGJlaW5nIHJldmlld2VkIHRvZ2V0aGVyOjxzcGFuIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48YnIg Y2xhc3M9IiI+DQoqIGRyYWZ0LWlldGYtZG1tLWRpc3RyaWJ1dGVkLW1vYmlsaXR5LWFuY2hvcmlu Zy0xNDxiciBjbGFzcz0iIj4NCiogZHJhZnQtaWV0Zi1kbW0tcG1pcHY2LWRsaWYtMDU8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgZGlzdHJpYnV0ZWQg bW9iaWxpdHkgYW5jaG9yaW5nLCBpbiB0ZXJtcyBvZiB0aGU8c3BhbiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PGJyIGNsYXNzPSIiPg0KZGlmZmVyZW50IGNvbmZpZ3VyYXRpb25zIGFuZCBmdW5jdGlv bnMgdG8gcHJvdmlkZSBJUCBtb2JpbGl0eSBzdXBwb3J0LDxzcGFuIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48YnIgY2xhc3M9IiI+DQppbmNsdWRpbmcgbmV0d29yay1iYXNlZCBvciBob3N0LWJhc2Vk IG1vYmlsaXR5IHN1cHBvcnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIGludGVu ZGVkIHN0YXR1cyBpcyBJbmZvcm1hdGlvbmFsLiBJdCBpcyBhIHZlcnkgd2VsbCB3cml0dGVuIGFu ZCBjb21wcmVoZW5zaXZlPGJyIGNsYXNzPSIiPg0KZG9jdW1lbnQuIEl0IGlzIHRlY2huaWNhbGx5 IHNvdW5kLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5vIG1ham9yIG9yIG1pbm9yIGlz c3Vlcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOaXRzOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkEgc2V0IG9mIHNtYWxsIG5pdHMgZm9yIHlvdXIgY29uc2lkZXJhdGlvbi48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoxLiZuYnNwOyBJbnRyb2R1Y3Rpb248YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7QXMgYSBNb2JpbGUgTm9kZSAoTU4p IGF0dGFjaGVzIHRvIGFuIGFjY2VzcyByb3V0ZXIgYW5kIGVzdGFibGlzaGVzIGE8YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7bGluayBiZXR3ZWVuIHRoZW0sIGEgLzY0IElQdjYgcHJlZml4IGFu Y2hvcmVkIHRvIHRoZSByb3V0ZXIgbWF5IGJlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2Fz c2lnbmVkIHRvIHRoZSBsaW5rIGZvciBleGNsdXNpdmUgdXNlIGJ5IHRoZSBNTiBbUkZDNjQ1OV0u Jm5ic3A7IFRoZSBNTjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDttYXkgdGhlbiBjb25maWd1 cmUgYSBnbG9iYWwgSVB2NiBhZGRyZXNzIGZyb20gdGhpcyBwcmVmaXggYW5kIHVzZSBpdDxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthcyB0aGUgc291cmNlIElQIGFkZHJlc3MgaW4gYSBmbG93 IHRvIGNvbW11bmljYXRlIHdpdGggaXRzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2NvcnJl c3BvbmRlbnQgbm9kZSAoQ04pLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNhcGl0YWxp emU6PGJyIGNsYXNzPSIiPg0Kcy9jb3JyZXNwb25kZW50IG5vZGUvQ29ycmVzcG9uZGVudCBOb2Rl LzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjIuJm5ic3A7IENvbnZlbnRpb25zIGFuZCBU ZXJtaW5vbG9neTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtUaGVz ZSBpbmNsdWRlIHRlcm1zIHN1Y2ggYXMgbW9iaWxlIG5vZGUgKE1OKSwgY29ycmVzcG9uZGVudCBu b2RlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyhDTiksIGhvbWUgYWdlbnQgKEhBKSwgaG9t ZSBhZGRyZXNzIChIb0EpLCBjYXJlLW9mLWFkZHJlc3MgKENvQSksPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwO2xvY2FsIG1vYmlsaXR5IGFuY2hvciAoTE1BKSwgYW5kIG1vYmlsZSBhY2Nlc3Mg Z2F0ZXdheSAoTUFHKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDYXBpdGFsaXplIOKA nE1vYmlsZSBOb2Rl4oCdIChhcyBwZXIgwqcgMSksIOKAnENvcmVzcG9uZGVudCBOb2Rl4oCdLCBl dGMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2ltaWxhciB3aXRoaW4gdGhpcyBzYW1l IMKnIDIsIOKAnG1vYmlsZSByb3V0ZXLigJ0sIGV0Yy48YnIgY2xhc3M9IiI+DQpTYW1lIHRocm91 Z2hvdXQgdGhlIGRvY3VtZW50IChlLmcuLCDigJxyb3V0ZXIgYWR2ZXJ0aXNlbWVudCAoUkEp4oCd KTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjQuMy4mbmJzcDsgTW9iaWxpdHkgY2FzZSwg YW5jaG9yIHJlbG9jYXRpb248YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7VGhlIElQIHByZWZpeC9hZGRyZXNzIGFuY2hvcmluZyBtYXkgbW92ZSB3aXRob3V0IGNoYW5n aW5nIHRoZSBJUDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtwcmVmaXgvYWRkcmVzcyBvZiB0 aGUgZmxvdy4mbmJzcDsgSGVyZSB0aGUgTE0gYW5kIEZNIGZ1bmN0aW9ucyBpbiBGaWd1cmUgMTxi ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtpbiBTZWN0aW9uIDMuMSBhcmUgaW1wbGVtZW50ZWQg YXMgc2hvd24gaW4gRmlndXJlIDcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K4oCcRmln dXJlIDEgaW4gU2VjdGlvbiAzLjEuMSBhcmUgaW1wbGVtZW50ZWTigJ08YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGaWd1cmUgNzog QW5jaG9yIG1vYmlsaXR5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2hvdWxkIHRoaXMg ZmlndXJl4oCZcyBsYWJlbCBiZSDigJxBbmNob3IgUmVsb2NhdGlvbuKAnSBpbnN0ZWFkIG9mIOKA mEFuY2hvciBtb2JpbGl0eeKAnT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo1LiZuYnNw OyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDtBcyBzdGF0ZWQgaW4gW1JGQzczMzNdLCAmcXVvdDthIERNTSBzb2x1dGlvbiBN VVNUIHN1cHBvcnRhbnkgc2VjdXJpdHk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpzL3N1 cHBvcnRhbnkvc3VwcG9ydCBhbnkvPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KOC4yLiBJ bmZvcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHJl bGF0aW9uc2hpcCBvZiB0aGlzIGRvY3VtZW50IGFuZCBkcmFmdC1pZXRmLWRtbS1kZXBsb3ltZW50 LW1vZGVscyBpcyBtb3N0bHkgY2xlYXIsIHRoYW5rIHlvdSBmb3IgdGhhdC48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpJIGhvcGUgeW91IGZpZCB0aGVzZSBjb21tZW50cyB1c2VmdWwuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2FybG9zIFBpZ25hdGFyby48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbW0tcG1pcHY2LWRsaWYtMDUiIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWRtbS1wbWlwdjYtZGxpZi0wNTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpJIGFtIGFuIGFzc2lnbmVkIElOVCBkaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBJ bnRlcm5ldC1EcmFmdC4mbmJzcDsgVGhlc2U8YnIgY2xhc3M9IiI+DQpjb21tZW50cyB3ZXJlIHdy aXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgSW50ZXJuZXQgQXJlYSBEaXJl Y3RvcnMuPGJyIGNsYXNzPSIiPg0KRG9jdW1lbnQgZWRpdG9ycyBhbmQgc2hlcGhlcmQocykgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSB0aGV5PGJyIGNsYXNzPSIiPg0Kd291 bGQgdHJlYXQgY29tbWVudHMgZnJvbSBhbnkgb3RoZXIgSUVURiBjb250cmlidXRvcnMgYW5kIHJl c29sdmUgdGhlbSBhbG9uZzxiciBjbGFzcz0iIj4NCndpdGggYW55IG90aGVyIExhc3QgQ2FsbCBj b21tZW50cyB0aGF0IGhhdmUgYmVlbiByZWNlaXZlZC4gRm9yIG1vcmUgZGV0YWlscyBvbjxiciBj bGFzcz0iIj4NCnRoZSBJTlQgRGlyZWN0b3JhdGUsIHNlZTxzcGFuIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUuaHRtbCIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cDovL3d3dy5pZXRm Lm9yZy9pZXNnL2RpcmVjdG9yYXRlLmh0bWw8L2E+LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkkgaG9wZSB0aGVzZSBjb21tZW50cyBhcmUgY2xlYXIgYW5kIHVzZWZ1bC48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpBcyByZXF1ZXN0ZWQsIGZyb20gdGhlIEludGVybmV0IGFyZWEg RGlyZWN0b3JhdGUgcmV2aWV3LCB0aGVzZSB0d28gRE1NPHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjxiciBjbGFzcz0iIj4NCmRvY3VtZW50cyBhcmUgYmVpbmcgcmV2aWV3ZWQgdG9nZXRoZXI6 PHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiogZHJhZnQtaWV0Zi1k bW0tZGlzdHJpYnV0ZWQtbW9iaWxpdHktYW5jaG9yaW5nLTE0PGJyIGNsYXNzPSIiPg0KKiBkcmFm dC1pZXRmLWRtbS1wbWlwdjYtZGxpZi0wNTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRo aXMgZG9jdW1lbnQgcHJvdmlkZXMgYW4gYXBwcm9hY2ggdG8gZGlzdHJpYnV0ZWQgbW9iaWxpdHkg bWFuYWdlbWVudDxiciBjbGFzcz0iIj4NCmJ5IGV4dGVuZGluZyBuZXR3b3JrLWJhc2VkIG1vYmls aXR5IHByb3RvY29scyAobGlrZSBQcm94eSBNb2JpbGUgSVB2NikuIEluPGJyIGNsYXNzPSIiPg0K dGhpcyBzb2x1dGlvbiwgbW9iaWxpdHkgc2Vzc2lvbnMgYXJlIGFuY2hvcmVkIGF0IHRoZSBsYXN0 IElQIGhvcCByb3V0ZXIuPHNwYW4gY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClRoaXMgZG9jdW1lbnTigJlzIGludGVuZGVkIHN0YXR1cyBpcyBFeHBl cmltZW50YWwuIEl0IGlzIHdlbGwgd3JpdHRlbiBmb3Igc3VjaCBhIGNvbXBsZXggY29tcHJlaGVu c2l2ZSBkb2N1bWVudCwgYW5kIHRlY2huaWNhbGx5IGNvbXBsZXRlIGFuZCBzZW5zaWJsZS48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpObyBtYWpvciBvciBtaW5vciBpc3N1ZXMuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTml0czo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpQbGVhc2UgZmluZCBzb21lIHNtYWxsIGNvbW1lbnRzIGZvciB5b3VyIGNvbnNpZGVyYXRpb246 PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KNC4xLiZuYnNwOyBQ cm94eSBCaW5kaW5nIFVwZGF0ZTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDtBIG5ldyBmbGFnIChEKSBpcyBpbmNsdWRlZCBpbiB0aGUgUHJveHkgQmluZGluZyBVcGRh dGUgdG8gaW5kaWNhdGU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7dGhhdCB0aGUgUHJveHkg QmluZGluZyBVcGRhdGUgaXMgY29taW5nIGZyb20gYSBNb2JpbGl0eSBBbmNob3IgYW5kPGJyIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwO0FjY2VzcyBSb3V0ZXIgYW5kIG5vdCBmcm9tIGEgbW9iaWxl IGFjY2VzcyBnYXRld2F5LiZuYnNwOyBUaGUgcmVzdCBvZiB0aGU8YnIgY2xhc3M9IiI+DQombmJz cDsgJm5ic3A7UHJveHkgQmluZGluZyBVcGRhdGUgZm9ybWF0IHJlbWFpbnMgdGhlIHNhbWUgYXMg ZGVmaW5lZCBpbiBbUkZDNTIxM10uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwOzAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7MSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFNlcXVlbmNlICMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxiciBjbGFz cz0iIj4NCiZuYnNwOyAmbmJzcDt8QXxIfEx8S3xNfFJ8UHxGfFR8QnxTfER8IFJlc2VyIHwmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBMaWZldGltZSZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Ckhvd2V2ZXIsIGZvciBSRkMgNTIxMyBTIDguMTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxiciBjbGFz cz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHxBfEh8THxLfE18UnxQfCZuYnNwOyBSZXNlcnZl ZCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBMaWZldGltZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU28sIHRoZXJlZm9yZSwg c2VlbXMgbGlrZTo8YnIgY2xhc3M9IiI+DQoxLiBUaGUgZGVmaW5pdGlvbiBvZiBGbGFncyBGLCBU LCBCLCBhbmQgUyBpcyBtaXNzaW5nLjxiciBjbGFzcz0iIj4NCjIuIOKAnFJlc2Vy4oCdIGlzIG5v dCByZWFsbHkgY2xlYXIgYW5kIOKAnFJzcnZk4oCdIHNlZW1zIHRvIGZpdCBhbmQgYmUgbW9yZSB1 bmFtYmlndW91cy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5bQ0JdIEkndmUgcmVwbGFjZWQgJnF1 b3Q7UmVzZXImcXVvdDsgd2l0aCAmcXVvdDtSc3J2ZCZxdW90Oy4gVGhlIG90aGVyIGZsYWdzIGFy ZSBkZWZpbmVkIGluIG90aGVyIFJGQ3MsIHB1Ymxpc2hlZCBhZnRlciBSRkMgNTIxMy4gRG8gSSBu ZWVkIHRvIGV4cGxhaW4gd2hhdCBlYWNoIG9mIHRoZXNlIGZsYWdzIGRvIGluIHRoaXMgZG9jdW1l bnQ/IEluIGFueSBjYXNlLCB0aGVyZSBtaWdodCBiZSBhZGRpdGlvbmFsIGZsYWdzIGRlZmluZWQg aW4gdGhlIGZ1dHVyZSwNCiBzbyBJIHRoaW5rIGl0IGlzIG5vdCBuZWVkZWQuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Q01QOiBUaGUgcHJvYmxlbSBJIHNlZSBpcyB0aGF0IHRoZSBkb2N1bWVudCBjdXJyZW50bHkgc2F5 czo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO1RoZSByZXN0IG9mIHRoZTxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtQcm94eSBCaW5kaW5nIFVwZGF0ZSBmb3JtYXQgcmVtYWlu cyB0aGUgc2FtZSBhcyBkZWZpbmVkIGluIFtSRkM1MjEzXTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QnV0IGJhc2VkIG9uIHdoYXQgeW91 IHdyaXRlLCB0aGF0IGlzIG5vdCB0aGUgY2FzZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk5vLCB5b3UgZG8gbm90IG5lZWQgdG8gZXhw bGFpbiB3aGF0IGVhY2ggZmxhZyBkb2VzIOKAlCBidXQgSeKAmWQgc3VnZ2VzdCBlaXRoZXIgbm90 IHNheSB3aGVyZSB0aGV5IGFyZSBkZWZpbmVkLCBvciBpbmNsdWRlIHRoZSBvdGhlciBSRkNzLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ SSBjaGVja2VkIElBTkEgYW5kIGZvdW5kOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJo dHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9tb2JpbGl0eS1wYXJhbWV0ZXJzL21vYmls aXR5LXBhcmFtZXRlcnMueGh0bWwjbW9iaWxpdHktcGFyYW1ldGVycy0xMSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL21vYmlsaXR5LXBh cmFtZXRlcnMvbW9iaWxpdHktcGFyYW1ldGVycy54aHRtbCNtb2JpbGl0eS1wYXJhbWV0ZXJzLTEx PC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+W0NCXSBPSywgSSB3 YXMgcmVmZXJyaW5nIHRvIHRoZSByZXN0IG9mIHRoZSBQQlUgZm9ybWF0IGluIGdlbmVyYWwuIEkg Y2FuIGFkZCB0aGF0IGEgbm90ZSByZWZlcnJpbmcgdG8gdGhlIElBTkEgcmVnaXN0cnkgZm9yIHRo ZSBkZWZpbml0aW9uIGFuZCByZWZlcmVuY2VzIG9mIHRoZSBmbGFncy4gV291bGQgdGhhdCB3b3Jr PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Q2FybG9zPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAw LjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBi b3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsi Pg0KPGRpdiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDsiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdp ZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJn YigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NCjxiciBjbGFzcz0iIj4NCjQu Mi4mbmJzcDsgUHJveHkgQmluZGluZyBBY2tub3dsZWRnbWVudDxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCuKApjxiciBjbGFzcz0iIj4NCiZuYnNwOyBUaGUgcmVzdCBvZiB0aGUgUHJveHkg QmluZGluZyBBY2tub3dsZWRnbWVudCBmb3JtYXQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7 cmVtYWlucyB0aGUgc2FtZSBhcyBkZWZpbmVkIGluIFtSRkM1MjEzXS48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7MCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7MzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDswIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8YnIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwO1N0YXR1cyZuYnNwOyAmbmJz cDsgJm5ic3A7IHxLfFJ8UHxUfEJ8U3xEfCB8PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSG93 ZXZlciwgZnJvbSBSRkMgNTIxMzo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDswJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzImbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDszPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPGJyIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsg Jm5ic3A7U3RhdHVzJm5ic3A7ICZuYnNwOyAmbmJzcDsgfEt8UnxQfFJlc2VydmVkIHw8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFuZCB0aHVzLCBGbGFncyBULCBCLCBTIGFyZSBu b3QgZGVmaW5lZC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5bQ0JdIFNhbWUgYXMgYmVmb3JlLiBB ZGRpdGlvbmFsIGZsYWdzIHdlcmUgZGVmaW5lZCBhbmQgYWRkZWQgdG8gSUFOQSByZWdpc3RyeSBh ZnRlciBSRkMgNTIxMyB3YXMgcHVibGlzaGVkLiBJIHJlZmVyIHRvIFJGQyA1MjEzIGFzIGl0IGlz IHdoZXJlIHRoZSBhY3R1YWwmbmJzcDtQQlUvUEJBIGZvcm1hdCB3YXMgc3BlY2lmaWVkIChhbHRo b3VnaCB0aGV5IGFyZSBiYXNpY2FsbHkgQlUvQkEgd2l0aCBQIGZsYWcgc2V0IHRvIDEpLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlRIYW5rcywgSSB1bmRlcnN0YW5kLiBJIHdhcyBjb21tZW50aW5nIG9u IHRoZSB0ZXh0IHRoYXQgc2F5cyDigJx0aGUgcmVzdCBpcyBkZWZpbmVkIGluIFJGQzUyMTPigJ0u PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsg Ym9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBib3JkZXIt bGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPg0KPGJy IGNsYXNzPSIiPg0KNC4zLiZuYnNwOyBBbmNob3JlZCBQcmVmaXggT3B0aW9uPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO0FuY2hvcmVkIFByZWZpeDxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IEEgc2l4dGVlbi1ieXRlIGZp ZWxkIGNvbnRhaW5pbmcgdGhlIG1vYmlsZSBub2RlJ3MgSVB2NiBBbmNob3JlZDxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFByZWZpeC4mbmJzcDsgT25seSB0aGUgZmlyc3QgUHJl Zml4IExlbmd0aCBieXRlcyBhcmUgdmFsaWQgZm9yIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IEFuY2hvcmVkIFByZWZpeC4mbmJzcDsgVGhlIHJlc3Qgb2YgdGhlIGJ5dGVz IE1VU1QgYmUgaWdub3JlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOb3QgYmVpbmcg cGVkYW50aWMsIGJ1dDo8YnIgY2xhc3M9IiI+DQpzL2J5dGUvb2N0ZXQvZyAvLyB0aHJvdWdob3V0 LjxiciBjbGFzcz0iIj4NCk9y4oCmICZxdW90OzEyOC1iaXTigJ0gaW5zdGVhZCBvZiDigJxzaXh0 ZWVuLW9jdGV04oCdLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPltDQl0gT0ssIEkgc2VlIHRoYXQg UkZDIDYyNzUgdXNlcyBvbmx5ICZxdW90O29jdGV0JnF1b3Q7LCB3aGlsZSBSRkMgNTIxMyB1c2Vz IGJvdGggJnF1b3Q7b2N0ZXQmcXVvdDsgYW5kICZxdW90O2J5dGUmcXVvdDsuIEJ1dCBJIGFncmVl IHRoYXQgdXNpbmcgb25seSBvbmUgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLiBJJ3ZlIGNob3Nl biAmcXVvdDtvY3RldCZxdW90OyBhcyB5b3Ugc3VnZ2VzdGVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlRoYW5rcyEgQXMgc3RyaWN0bHkgdGhlcmUgY2FuIGJlIG5vbi1vY3RldCBieXRlcy48L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXIt bGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNv bG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo1LiZuYnNwOyBJQU5BIENvbnNpZGVyYXRpb25zPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVmaW5lcyBz aXggbmV3IG1vYmlsaXR5IG9wdGlvbnMgdGhhdCBuZWVkIHRvIGJlPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwO3JlZ2lzdGVyZWQgaW4gdGhlIE1vYmlsaXR5IE9wdGlvbnMgcmVnaXN0cnkgb24g dGhlIE1vYmlsZSBJUHY2PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3BhcmFtZXRlcnMgcmVn aXN0cnkuJm5ic3A7IFRoZSByZXF1aXJlZCBJQU5BIGFjdGlvbnMgYXJlIG1hcmtlZCBhcyBJQU5B LTE8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7dG8gSUFOQS02LjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkl0IHdvdWxkIGJlIHVzZWZ1bCB0byBicmVha291dCB0aGUgc3BlY2lmaWMg SUFOQSByZXF1ZXN0cyBpbiBhIHRhYmxlLCBzZWN0aW9ucywgb3Igb3RoZXIgc3RydWN0dXJlIGRl dGFpbGluZyBob3cgaXQgc2hvdWxkIGxvb2sgaW4gdGhlIElBTkEgcmVnaXN0cmllcy48YnIgY2xh c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5bQ0JdIEkndmUgYWRkZWQgc29tZSBhZGRpdGlvbmFsIHRleHQsIGJ1 dCBmb2xsb3dpbmcgdGhlIGFwcHJvYWNoIG9mIFJGQyA1MjEzLCB3aGljaCBrZWVwcyBpdCBzaW1w bGUuIEkgaG9wZSB0aGlzIGlzIHN1ZmZpY2llbnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoYW5rIHlvdS48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9j a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44 ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9y ZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4N CjxiciBjbGFzcz0iIj4NCjYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KSXMgdGhlcmUgdW5kZXJseWluZyBwcm90ZWN0aW9uIGFnYWluc3Qgc3Bv b2ZpbmcgdGhhdCBjYW4gYmUgY2FsbGVkIG91dD8gVGhpcyBzaG91bGQgYmUgYWRkcmVzc2VkIGlu IHRoZSBTZWN1cml0eSBEaXIgcmV2aWV3LCBzbyBJIHdpbGwgbm90IG1lbnRpb24gaXQgaGVyZSDw n5mCPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+W0NCXSBXZSBhc3N1bWUgdGhhdCB1c2luZyB0aGUg bWVjaGFuaXNtcyBkZXNjcmliZWQgZm9yIFJGQyA1MjEzIGlzIGVub3VnaC4gV2UgaGF2ZSBhZGRl ZCBzb21lIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgZm9yIHRoZSByaXNrcy9wcm9jZWR1cmVz IHRoYXQgYXJlIHNwZWNpZmljIHRvIHRoZSZuYnNwO2Rpc3RyaWJ1dGVkIHNvbHV0aW9uLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQpBY2suPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1z dHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRp bmctbGVmdDogMWV4OyI+DQo8YnIgY2xhc3M9IiI+DQo4LjIuJm5ic3A7IEluZm9ybWF0aXZlIFJl ZmVyZW5jZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7W0ktRC5p ZXRmLWRtbS1kZXBsb3ltZW50LW1vZGVsc108YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgR3VuZGF2ZWxsaSwgUy4gYW5kIFMuIEpl b24sICZxdW90O0RNTSBEZXBsb3ltZW50IE1vZGVscyBhbmQ8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXJjaGl0ZWN0dXJhbCBD b25zaWRlcmF0aW9ucyZxdW90OywgZHJhZnQtaWV0Zi1kbW0tZGVwbG95bWVudC08YnIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbW9k ZWxzLTA0ICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMTguPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KU2luY2UgdGhlcmUgYXJlIGtleSBkZWZpbml0aW9ucyBmcm9tIHRoaXMgZG9jdW1l bnQsIHNob3VsZCB0aGlzIGJlIE5vcm1hdGl2ZT88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5bQ0Jd IFNpbmNlIHRoaXMgZG9jdW1lbnQgaXMgbm90IGdvaW5nIHRvIGJlIHByb2dyZXNzZWQgYW55IGZ1 cnRoZXIsIHdlIGhhdmUgaW5jbHVkZWQgdGhlIHJlbGV2YW50IHRlcm1zIGluIHRoZSB0ZXJtaW5v bG9neSBzZWN0aW9uIGFuZCByZW1vdmUgdGhlIHJlZmVyZW5jZS48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQpHb3QgaXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJs dHIiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsg Ym9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBib3JkZXIt bGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPg0KPGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO1tSRkM3MzMzXSZuYnNwOyBDaGFuLCBILiwgRWQuLCBM aXUsIEQuLCBTZWl0ZSwgUC4sIFlva290YSwgSC4sIGFuZCBKLjxiciBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBLb3Job25lbiwgJnF1 b3Q7UmVxdWlyZW1lbnRzIGZvciBEaXN0cmlidXRlZCBNb2JpbGl0eTxiciBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNYW5hZ2VtZW50 JnF1b3Q7LCBSRkMgNzMzMywgRE9JIDEwLjE3NDg3L1JGQzczMzMsIEF1Z3VzdCAyMDE0LDxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3MzMzIiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9pbmZvL3JmYzczMzM8L2E+Jmd0Oy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpTaW1pbGFybHksIHNob3VsZCB0aGlzIHJlZmVyZW5jZSBiZSBOb3JtYXRpdmUgaW5zdGVh ZCBvZiBJbmZvcm1hdGl2ZT88YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5bQ0JdIEkgZG9uJ3QgaGF2 ZSBhIHN0cm9uZyBvcGluaW9uIGhlcmUuIEkndmUgbW92ZWQgaXQgdG8gTm9ybWF0aXZlLCBidXQg SSB0aGluayBpdCBjb3VsZCBzdGF5IGFzIEluZm9ybWF0aXZlIGFzIHdlbGwuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+WW91ciBjYWxsLiBUaGFua3MgZm9yIGNvbnNpZGVyaW5nLjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdp ZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJn YigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NCjxiciBjbGFzcz0iIj4NCkFw cGVuZGl4IEIuJm5ic3A7IEltcGxlbWVudGF0aW9uIGV4cGVyaWVuY2U8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpTaG91bGQgdGhpcyByZWFsbHkgYmUgYW4gSW1wbGVtZW50YXRpb24gU3Rh dHVzIHNlY3Rpb24gW1JGQzc5NDJdLCBhcyBpdCBkZXNjcmliZXMgYSBwb2ludCBpbiB0aW1lIHJh dGhlciB0aGFuIGxlYXJuaW5ncz88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpTaG91bGQg dGhlIEFwcGVuZGljZXMgY2xhcmlmeSB0aGV5IG1ha2Ugbm8gbm9ybWF0aXZlIHNwZWNzPzxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPltDQl0gQmFzZWQgYWxzbyBvbiBvdGhlciBjb21tZW50cyB3ZSBo YXZlIHJlbW92ZSBib3RoIGFwcGVuZGl4ZXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWNrLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBw eCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHls ZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmct bGVmdDogMWV4OyI+DQo8YnIgY2xhc3M9IiI+DQpJIGhvcGUgdGhlc2UgY29tbWVudHMgYXJlIHVz ZWZ1bC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5bQ0JdIFllcywgdGhleSBhcmUgaW5kZWVkLiBU aGFua3MhPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KOi0pIFN1cGVyLjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KEFub3RoZXIpIENh cmxvcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNhcmxvczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4m bmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0 LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFk ZGluZy1sZWZ0OiAxZXg7Ij4NCjxiciBjbGFzcz0iIj4NClRoYW5rIHlvdSB2ZXJ5IG11Y2gsPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2FybG9zIFBpZ25hdGFyby48L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1731D29F3C8245C0AED6C0983CD8AD05ciscocom_-- From nobody Tue Mar 17 15:39:55 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE7C3A0931; Tue, 17 Mar 2020 15:39:50 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S56kmIzTKUN5; Tue, 17 Mar 2020 15:39:48 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 86E253A092F; Tue, 17 Mar 2020 15:39:47 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02HMdYjO025524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Mar 2020 18:39:38 -0400 Date: Tue, 17 Mar 2020 15:39:34 -0700 From: Benjamin Kaduk To: CARLOS JESUS BERNARDOS CANO Cc: The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs , dmm , Dapeng Liu Message-ID: <20200317223934.GU50174@kduck.mit.edu> References: <158337360559.29429.15629947241139453126@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-distributed-mobility-anchoring-14: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 22:39:52 -0000 Hi Carlos, Sorry for the slow reply; it's been a crazy couple weeks. On Sat, Mar 07, 2020 at 05:55:59PM +0100, CARLOS JESUS BERNARDOS CANO wrote: > Hi Benjamin, > > Thanks a lot for your comments. Please find below my answers. > > On Thu, Mar 5, 2020 at 3:00 AM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dmm-distributed-mobility-anchoring-14: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for discussing the need to secure the various control-plane > > interactions as part of the Security Considerations. In addition to the > > integrity and source-authentication properties already mentioned, we > > need to say that the control-plane functionality will apply > > authorization checks to any commands or updates that are made by the > > control-plane protocol. > > > > [CB] Thanks. I've added that to version -15 (to be submitted soon). > > > > > > Similarly, I didn't see any discussion of authorization for applying or > > making changes to the "rules" that are mentioned as needing to be > > applied by a data-plane node (as mentioned in the COMMENT where I ask > > for clarification on the nature of such rules). > > > > [CB] Thanks. Even though we have changed a bit the writing to avoid the > term "rule", we have added some text regarding the use of authentication > and authorization mechanisms when doing traffic indirection in version -15. > > > > > > Also, we should reference RFCs 8221 and 8247 for the current guidance on > > IPsec and IKEv2 usage. > > > > [CB] Thanks. Added. Thanks! I think the current placement of these references in the -15 make it sound like they are references for IPsec and IKEv2 respectively, and not "just" the best-practices for configuring them. Just moving the references later in the sentences would probably help, though I'd recommend adding another sentence "The current guidance for IPsec and IKEv2 usage is given in [RFC8221] and [RFC8247], respectively" to be fully clear about why they are being referenced. That said, I'm going to change my ballot position to No Objection after I send this mail, so no need to check back on the precise wording. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > While I see the value in having this document to crystallize thinking > > about the various mobility anchoring techniques that are possible, it's > > not clear to me how much archival value this document would add to the > > RFC series in the absence of specific protocol mechanisms to implement > > the functionality described therein. As such, I expect to change my > > ballot position to Abstain after my Discuss points are resolved. > > > > Section 1 > > > > When the MN wants to continue using its assigned prefix to complete > > ongoing data sessions after it has moved to a new network, the > > network needs to provide support for the MN's IP address -- and > > > > The new network, right? > > > > > [CB] The new network and the old one, understanding "old" by the one > anchoring the prefix used by the MN. That's why we just use the generic > term "network" without prepending "new". Ah, I see now; thanks. > Section 2 > > > > Anchoring (of an IP prefix/address): An IP prefix, i.e., Home > > Network Prefix (HNP), or address, i.e., HoA, assigned for use by > > an MN is topologically anchored to an anchor node when the anchor > > node is able to advertise a connected route into the routing > > > > Is "connected route" a term of art I should be looking up? > > > > > [CB] I agree it's probably better to just use "route". We have changed this > in version -15 (to be submitted soon). > > > > and manages the network location information of an MN. The > > location information may be a binding of the advertised IP > > address/prefix, e.g., HoA or HNP, to the IP routing address of the > > MN or of a node that can forward packets destined to the MN. > > > > I assume this ("may be [...] or") is not intended to be an exhaustive > > list? > > > > [CB] Right. Though the cases listed are the ones I can think of now as > making sense. But we don't want to close the door for other options that > might also work there. Sometimes a list of two options like this can be misread as intended to be exhaustive, in which case a phrase like "may be (for example)" can help, or adding some generic catch-all clause to the end of the list. > > > > > In a client-server protocol model, location query and update > > messages may be exchanged between a Location Management client > > (LMc) and a Location Management server (LMs), where the location > > information can be updated to or queried from the LMc. > > > > nit: s/updated to/updated from/? > > > > [CB] Right, thanks. > > > > > > Do we want to discuss the authentication/authorization for such location > > management functions here? (Including both MN/LMc and LMc/LMs > > interactions.) > > > > [CB] I've added "secure (i.e., authenticated and authorized)" before > "location query and update messages may be > exchanged between [...]" to make it clear that of course these signalling > needs to be properly secured. I think going into more details there will > deviate the focus from the main point of this document. Anyway, the > security considerations section should cover all these parts as well. Sounds good, thanks. > > > > > Section 4 > > > > There may be multiple IP prefixes/addresses that an MN can select > > when initiating a flow. They may be from the same access network or > > different access networks. The network may advertise these prefixes > > with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node > > may choose the one with the least cost. In addition, these IP > > > > This draft has not been updated since 2016. Is it still expected to > > progress, such that a reference to it remains valuable? > > > > [CB] We use this reference as an example of approach. There are other > examples that we could reference, but I wanted to give the credit to the > guys that I think first proposed this. That's why I kept the reference, but > I can very easily replace it with another one if you think it would be > best. My personal preference for picking references is biased towards referencing documents that can be used to build deployable solutions, but I see no flaw in your reasoning here. > > > prefixes/addresses may be of different types regarding whether > > mobility support is needed [RFC8653]. A MN will need to choose which > > IP prefix/address to use for each flow according to whether it needs > > IP mobility support or not, using for example the mechanisms > > described in [RFC8653]. > > > > I'm confused. "these prefixes/addresses" seems to refer to the ones > > advertised by the network, but the question of whether mobility support > > is needed seems like a matter local to the MN and not a need of the > > network. (Perhaps the network might *provide* different mobility > > services for different prefixes/addresses, but that's not what this text > > currently says.) > > > > [CB] The prefixes/addresses refer to the one provided by the network. The > question of whether the MN needs mobility or not is local to the MN, but if > the MN actually need it, support from the network might be needed > (depending on the type of mobility support of the MN and network). I've > reworded it to: > > "In addition, the IP prefixes/addresses provided by the network may be of > different types regarding whether mobility support is supported [RFC 8653] > ." > > I hope now the text is clearer. I think so, thanks. > > > Section 4.1 > > > > I suggest to expand access router or list it in the terminology section. > > > > [CB] Done (expanded first time it appears in the text). > > > > > > When IP session continuity is needed, even if a flow is ongoing as > > the MN moves, it may still be desirable for the flow to change to > > using the new IP prefix configured in the new network. The flow may > > then close and then restart using a new IP address configured in the > > new network. Such a change in the IP address of the flow may be > > > > It's perhaps a little confusing, in a rhetorical sense, to talk about > > "the flow changing to use the new prefix" but doing that by having the > > flow "close and then restart" -- is it really the same flow after it has > > closed? > > > > [CB] You are right. If we are picky with the terminology, the flow is > indeed different. I've reworded to use "application flow" instead of > "flow". Hope this is a bit better. Current text (some other small changes > performed) read as follows: > > "When IP session continuity is needed, even if an application flow is > ongoing as > the MN moves, it may still be desirable for the application flow to change > to > using the new IP prefix configured in the new network. The application flow > may > then be closed at IP level and then be restarted using a new IP address > configured in the new network. Such a change in the IP address used by the > application flow may be enabled using a higher layer mobility support which > is > not in the scope of this document." Thank you! > > > > > Note that in this scenarios, if there is no mobility support provided > > by L4 or above, an application might be able to stop before changing > > point of attachement, and therefore the traffic would stop. > > > > I'm not sure what "might be able to stop" is intended to mean. > > Regardless, it's quite clear that the traffic will stop upon the > > mobility event in this scenario, since the network does not provide > > continuity services! > > > > [CB] That sentence was definitely not good. I've just simplified it to: > > "Note that in these scenarios, if there is no mobility support provided by > L4 or > above, application traffic would stop." > > which is kind of clear, but I think it doesn't harm keeping it. > > > > Section 4.2 > > > > prefix. The latter enables optimized routes but requires some data > > plane node that enforces rules for traffic indirection. Next, we > > > > I'm not sure I understand the role this rule-enforcment is meant to > > play. What sort of rules would it be enforcing? > > > > [CB] We mean routing updates that enable the anchor mobility. I probably > used the term "rules" because one example of approach to use in a local > domain is OpenFlow. I've reworded it to the following: > > "The latter enables optimized routes but requires some data plane node that > enforces > traffic indirection." > > > > > > to AR1 per default routing). The LM and FM functions are implemented > > as shown in Figure 6. > > > > Where is FM indicated in Figure 6? I cannot find it. > > > > [CB] Ooops. Thanks. Fixed! > > > > > > Also, should there be any control-plane anchoring indicated in Figure 6? > > > > [CB] There is the LM part indicated in AR2. > > > > > > Section 4.3 > > > > We focus next on the case where the mobility anchor (data plane > > function) is changed but binds the MN's transferred IP address/ > > prefix. This enables optimized routes but requires some data plane > > node that enforces rules for traffic indirection. > > > > [same question as above about the rules] > > > > [CB] Same resolution as before. > > > > > > IP mobility is invoked to enable IP session continuity for an ongoing > > flow as the MN moves to a new network. Here the anchoring of the IP > > address of the flow is in the home network of the flow (i.e., > > different from the current network of attachment). A centralized > > > > nit(?): this usage of "here" is surprising, in that it seems to discuss > > the same case as the previous section, and not the new mechanism that > > we're describing in this section. > > > > [CB] OK, I've removed "here". > > > > > The IP prefix/address anchoring may move without changing the IP > > prefix/address of the flow. Here the LM and FM functions in Figure 1 > > in Section 3.1 are implemented as shown in Figure 7. > > > > Where is the FM function indicated in Figure 7? I cannot find it. > > > > [CB] FM is not involved here. I've fixed the text. When we wrote the text I > was thinking on a generic way of referring to LM and FM functions, not > implying that they need to be implemented in all the cases. But I agree it > is not very clear. > > > > > > [I-D.ietf-rtgwg-atn-bgp]. When a mobile associates with an anchor > > the anchor injects the mobile's prefix into the global routing > > system. If the mobile moves to a new anchor, the old anchor > > > > nit: "mobile node" or just "MN" (twice)? > > > > [CB] Probably better to use MN. I've fixed it. > > > > > > withdraws the /64 and the new anchor injects it instead. > > > > What kind of synchronization and/or serialization is needed between the > > withdrawl and injection of the /64 in question? > > > > [CB] That'd be part of the control plane signalling, which would depend on > the actual solution being used. Since this document does not go into the > specifics of an actual solution, we don't go further. Hmm, okay. > > > > > Section 5 > > > > As stated in [RFC7333], "a DMM solution MUST supportany security > > > > nit: s/supportany/support any/ > > > > [CB] Fixed, thanks. > > Thanks again for all the good comments. And thanks for the updates! -Ben From nobody Tue Mar 17 15:40:45 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF3C3A092F; Tue, 17 Mar 2020 15:40:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , maxpassion@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158448482815.32043.12661861503952267644@ietfa.amsl.com> Date: Tue, 17 Mar 2020 15:40:28 -0700 Archived-At: Subject: [DMM] Benjamin Kaduk's No Objection on draft-ietf-dmm-distributed-mobility-anchoring-15: (with COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 22:40:40 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dmm-distributed-mobility-anchoring-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my Discuss and Comment points! I think the current placement of the references to RFCs 8221 and 8247 make it sound like they are references for IPsec and IKEv2 respectively, and not "just" the best-practices for configuring them. Moving the references later in the sentences would probably help, though I'd recommend adding another sentence "The current guidance for IPsec and IKEv2 usage is given in [RFC8221] and [RFC8247], respectively" to be fully clear about why they are being referenced. From nobody Wed Mar 18 02:26:07 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6B33A08E8 for ; Wed, 18 Mar 2020 02:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNaZgn4Jxl3I for ; Wed, 18 Mar 2020 02:26:03 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24E03A08DB for ; Wed, 18 Mar 2020 02:26:02 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id v6so14934812edw.8 for ; Wed, 18 Mar 2020 02:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kv1Wdz64HLCIYdnN0gmNYWYdtXHuKemUoGt8gVWJSs8=; b=XHg/CELo2A/N1geVOAlP1M+7Be24gmM3HrJdmNpw9ZdS9UoH88s7Uv9oYwlZIBWoqi gxkGG8OJHFlNdcNlk+ENZVf98epby9Av6evVufkAqrnpiUp/fQ8+oAHjohtpAR7SjtDU ElbCRuUjVz8bDBmhyJQPmw6tsUJ7bgvXqGeV6BUMeBkUsJHFuhFDBfaSJB8ToYzX9Pvp u41++4lAM1JKhpRFTLoEOZyW5q0w/GPz94/Kt1egup/4+3jZLZ8WYyZktj7ExjevUdY5 8XvZjW+MvLo9Jtiheqbkg/Nkr4yOtAJZezCjM+nE77+2aUUtAsUZkOA42zNUHrpEAlf7 0m/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kv1Wdz64HLCIYdnN0gmNYWYdtXHuKemUoGt8gVWJSs8=; b=cOcJ32A6oBf24gaPCJMYEqDn8CrWQcHlEXkCYBGkvRAj2BAoq/GwywC/+o8Fgc1pDz hEpsObSG2QB9RkX/BuuBi70Wovaby0gZSVhO85TlDwDsDADGscrkrM4n3Efg1c+6aVyN d+dmofgDk3/HR8X8VFtZwev91zU/Niyvjz6l5ArVqVdgCBjYlgf9OJhqYlJhXuYP2M2p D3fVp44GIGlSMjONHccprNnkwjVbAaozi/wdMRBhIuUmcPCN1Wu0v6Pul5nAbI/MMl92 EF7jZVA6aZeWEFMQiwmWb7lI4Yf98RmIrNxaStXNX2ds2bANLXuFncQySlpfeYutsaWz mM3g== X-Gm-Message-State: ANhLgQ0yOgcj9JhSXnD/ODf1ogKnOPAF4bICyyD3qJtZwX1ubAzH0G9W urOdiJc1nV1no5I5+9JTti/ddRCrxL8A2U7soP7toQ== X-Google-Smtp-Source: ADFU+vtoKsM63dTS1y5Wiq+x2i4IFyB0UbkeLbLHkGjyHHsZw2fQk/65OiO13LD+VU3I0m9QG0edCnZpBxEwwh5Y5i4= X-Received: by 2002:a17:906:2f15:: with SMTP id v21mr3175966eji.329.1584523560597; Wed, 18 Mar 2020 02:26:00 -0700 (PDT) MIME-Version: 1.0 References: <158337360559.29429.15629947241139453126@ietfa.amsl.com> <20200317223934.GU50174@kduck.mit.edu> In-Reply-To: <20200317223934.GU50174@kduck.mit.edu> From: CARLOS JESUS BERNARDOS CANO Date: Wed, 18 Mar 2020 10:25:44 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs , dmm , Dapeng Liu Content-Type: multipart/alternative; boundary="000000000000f7f2d805a11da30f" Archived-At: Subject: Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-distributed-mobility-anchoring-14: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 09:26:07 -0000 --000000000000f7f2d805a11da30f Content-Type: text/plain; charset="UTF-8" Thanks a lot Benjamin! We'll implement your wording suggestions in the next revision! Carlos On Tue, Mar 17, 2020 at 11:39 PM Benjamin Kaduk wrote: > Hi Carlos, > > Sorry for the slow reply; it's been a crazy couple weeks. > > On Sat, Mar 07, 2020 at 05:55:59PM +0100, CARLOS JESUS BERNARDOS CANO > wrote: > > Hi Benjamin, > > > > Thanks a lot for your comments. Please find below my answers. > > > > On Thu, Mar 5, 2020 at 3:00 AM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-dmm-distributed-mobility-anchoring-14: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > Thanks for discussing the need to secure the various control-plane > > > interactions as part of the Security Considerations. In addition to > the > > > integrity and source-authentication properties already mentioned, we > > > need to say that the control-plane functionality will apply > > > authorization checks to any commands or updates that are made by the > > > control-plane protocol. > > > > > > > [CB] Thanks. I've added that to version -15 (to be submitted soon). > > > > > > > > > > Similarly, I didn't see any discussion of authorization for applying or > > > making changes to the "rules" that are mentioned as needing to be > > > applied by a data-plane node (as mentioned in the COMMENT where I ask > > > for clarification on the nature of such rules). > > > > > > > [CB] Thanks. Even though we have changed a bit the writing to avoid the > > term "rule", we have added some text regarding the use of authentication > > and authorization mechanisms when doing traffic indirection in version > -15. > > > > > > > > > > Also, we should reference RFCs 8221 and 8247 for the current guidance > on > > > IPsec and IKEv2 usage. > > > > > > > [CB] Thanks. Added. > > Thanks! > I think the current placement of these references in the -15 make it sound > like they are references for IPsec and IKEv2 respectively, and not "just" > the best-practices for configuring them. Just moving the references later > in the sentences would probably help, though I'd recommend adding another > sentence "The current guidance for IPsec and IKEv2 usage is given in > [RFC8221] and [RFC8247], respectively" to be fully clear about why they are > being referenced. > > That said, I'm going to change my ballot position to No Objection after I > send this mail, so no need to check back on the precise wording. > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > While I see the value in having this document to crystallize thinking > > > about the various mobility anchoring techniques that are possible, it's > > > not clear to me how much archival value this document would add to the > > > RFC series in the absence of specific protocol mechanisms to implement > > > the functionality described therein. As such, I expect to change my > > > ballot position to Abstain after my Discuss points are resolved. > > > > > > Section 1 > > > > > > When the MN wants to continue using its assigned prefix to complete > > > ongoing data sessions after it has moved to a new network, the > > > network needs to provide support for the MN's IP address -- and > > > > > > The new network, right? > > > > > > > > [CB] The new network and the old one, understanding "old" by the one > > anchoring the prefix used by the MN. That's why we just use the generic > > term "network" without prepending "new". > > Ah, I see now; thanks. > > > Section 2 > > > > > > Anchoring (of an IP prefix/address): An IP prefix, i.e., Home > > > Network Prefix (HNP), or address, i.e., HoA, assigned for use by > > > an MN is topologically anchored to an anchor node when the anchor > > > node is able to advertise a connected route into the routing > > > > > > Is "connected route" a term of art I should be looking up? > > > > > > > > [CB] I agree it's probably better to just use "route". We have changed > this > > in version -15 (to be submitted soon). > > > > > > > and manages the network location information of an MN. The > > > location information may be a binding of the advertised IP > > > address/prefix, e.g., HoA or HNP, to the IP routing address of > the > > > MN or of a node that can forward packets destined to the MN. > > > > > > I assume this ("may be [...] or") is not intended to be an exhaustive > > > list? > > > > > > > [CB] Right. Though the cases listed are the ones I can think of now as > > making sense. But we don't want to close the door for other options that > > might also work there. > > Sometimes a list of two options like this can be misread as intended to be > exhaustive, in which case a phrase like "may be (for example)" can help, or > adding some generic catch-all clause to the end of the list. > > > > > > > > > In a client-server protocol model, location query and update > > > messages may be exchanged between a Location Management client > > > (LMc) and a Location Management server (LMs), where the location > > > information can be updated to or queried from the LMc. > > > > > > nit: s/updated to/updated from/? > > > > > > > [CB] Right, thanks. > > > > > > > > > > Do we want to discuss the authentication/authorization for such > location > > > management functions here? (Including both MN/LMc and LMc/LMs > > > interactions.) > > > > > > > [CB] I've added "secure (i.e., authenticated and authorized)" before > > "location query and update messages may be > > exchanged between [...]" to make it clear that of course these signalling > > needs to be properly secured. I think going into more details there will > > deviate the focus from the main point of this document. Anyway, the > > security considerations section should cover all these parts as well. > > Sounds good, thanks. > > > > > > > > > Section 4 > > > > > > There may be multiple IP prefixes/addresses that an MN can select > > > when initiating a flow. They may be from the same access network or > > > different access networks. The network may advertise these prefixes > > > with cost options [I-D.mccann-dmm-prefixcost] so that the mobile > node > > > may choose the one with the least cost. In addition, these IP > > > > > > This draft has not been updated since 2016. Is it still expected to > > > progress, such that a reference to it remains valuable? > > > > > > > [CB] We use this reference as an example of approach. There are other > > examples that we could reference, but I wanted to give the credit to the > > guys that I think first proposed this. That's why I kept the reference, > but > > I can very easily replace it with another one if you think it would be > > best. > > My personal preference for picking references is biased towards referencing > documents that can be used to build deployable solutions, but I see no flaw > in your reasoning here. > > > > > > prefixes/addresses may be of different types regarding whether > > > mobility support is needed [RFC8653]. A MN will need to choose > which > > > IP prefix/address to use for each flow according to whether it needs > > > IP mobility support or not, using for example the mechanisms > > > described in [RFC8653]. > > > > > > I'm confused. "these prefixes/addresses" seems to refer to the ones > > > advertised by the network, but the question of whether mobility support > > > is needed seems like a matter local to the MN and not a need of the > > > network. (Perhaps the network might *provide* different mobility > > > services for different prefixes/addresses, but that's not what this > text > > > currently says.) > > > > > > > [CB] The prefixes/addresses refer to the one provided by the network. The > > question of whether the MN needs mobility or not is local to the MN, but > if > > the MN actually need it, support from the network might be needed > > (depending on the type of mobility support of the MN and network). I've > > reworded it to: > > > > "In addition, the IP prefixes/addresses provided by the network may be of > > different types regarding whether mobility support is supported [RFC > 8653] > > ." > > > > I hope now the text is clearer. > > I think so, thanks. > > > > > > Section 4.1 > > > > > > I suggest to expand access router or list it in the terminology > section. > > > > > > > [CB] Done (expanded first time it appears in the text). > > > > > > > > > > When IP session continuity is needed, even if a flow is ongoing as > > > the MN moves, it may still be desirable for the flow to change to > > > using the new IP prefix configured in the new network. The flow may > > > then close and then restart using a new IP address configured in the > > > new network. Such a change in the IP address of the flow may be > > > > > > It's perhaps a little confusing, in a rhetorical sense, to talk about > > > "the flow changing to use the new prefix" but doing that by having the > > > flow "close and then restart" -- is it really the same flow after it > has > > > closed? > > > > > > > [CB] You are right. If we are picky with the terminology, the flow is > > indeed different. I've reworded to use "application flow" instead of > > "flow". Hope this is a bit better. Current text (some other small changes > > performed) read as follows: > > > > "When IP session continuity is needed, even if an application flow is > > ongoing as > > the MN moves, it may still be desirable for the application flow to > change > > to > > using the new IP prefix configured in the new network. The application > flow > > may > > then be closed at IP level and then be restarted using a new IP address > > configured in the new network. Such a change in the IP address used by > the > > application flow may be enabled using a higher layer mobility support > which > > is > > not in the scope of this document." > > Thank you! > > > > > > > > > Note that in this scenarios, if there is no mobility support > provided > > > by L4 or above, an application might be able to stop before changing > > > point of attachement, and therefore the traffic would stop. > > > > > > I'm not sure what "might be able to stop" is intended to mean. > > > Regardless, it's quite clear that the traffic will stop upon the > > > mobility event in this scenario, since the network does not provide > > > continuity services! > > > > > > > [CB] That sentence was definitely not good. I've just simplified it to: > > > > "Note that in these scenarios, if there is no mobility support provided > by > > L4 or > > above, application traffic would stop." > > > > which is kind of clear, but I think it doesn't harm keeping it. > > > > > > > Section 4.2 > > > > > > prefix. The latter enables optimized routes but requires some data > > > plane node that enforces rules for traffic indirection. Next, we > > > > > > I'm not sure I understand the role this rule-enforcment is meant to > > > play. What sort of rules would it be enforcing? > > > > > > > [CB] We mean routing updates that enable the anchor mobility. I probably > > used the term "rules" because one example of approach to use in a local > > domain is OpenFlow. I've reworded it to the following: > > > > "The latter enables optimized routes but requires some data plane node > that > > enforces > > traffic indirection." > > > > > > > > > > to AR1 per default routing). The LM and FM functions are > implemented > > > as shown in Figure 6. > > > > > > Where is FM indicated in Figure 6? I cannot find it. > > > > > > > [CB] Ooops. Thanks. Fixed! > > > > > > > > > > Also, should there be any control-plane anchoring indicated in Figure > 6? > > > > > > > [CB] There is the LM part indicated in AR2. > > > > > > > > > > Section 4.3 > > > > > > We focus next on the case where the mobility anchor (data plane > > > function) is changed but binds the MN's transferred IP address/ > > > prefix. This enables optimized routes but requires some data plane > > > node that enforces rules for traffic indirection. > > > > > > [same question as above about the rules] > > > > > > > [CB] Same resolution as before. > > > > > > > > > > IP mobility is invoked to enable IP session continuity for an > ongoing > > > flow as the MN moves to a new network. Here the anchoring of the IP > > > address of the flow is in the home network of the flow (i.e., > > > different from the current network of attachment). A centralized > > > > > > nit(?): this usage of "here" is surprising, in that it seems to discuss > > > the same case as the previous section, and not the new mechanism that > > > we're describing in this section. > > > > > > > [CB] OK, I've removed "here". > > > > > > > > The IP prefix/address anchoring may move without changing the IP > > > prefix/address of the flow. Here the LM and FM functions in Figure > 1 > > > in Section 3.1 are implemented as shown in Figure 7. > > > > > > Where is the FM function indicated in Figure 7? I cannot find it. > > > > > > > [CB] FM is not involved here. I've fixed the text. When we wrote the > text I > > was thinking on a generic way of referring to LM and FM functions, not > > implying that they need to be implemented in all the cases. But I agree > it > > is not very clear. > > > > > > > > > > [I-D.ietf-rtgwg-atn-bgp]. When a mobile associates with an anchor > > > the anchor injects the mobile's prefix into the global routing > > > system. If the mobile moves to a new anchor, the old anchor > > > > > > nit: "mobile node" or just "MN" (twice)? > > > > > > > [CB] Probably better to use MN. I've fixed it. > > > > > > > > > > withdraws the /64 and the new anchor injects it instead. > > > > > > What kind of synchronization and/or serialization is needed between the > > > withdrawl and injection of the /64 in question? > > > > > > > [CB] That'd be part of the control plane signalling, which would depend > on > > the actual solution being used. Since this document does not go into the > > specifics of an actual solution, we don't go further. > > Hmm, okay. > > > > > > > > > Section 5 > > > > > > As stated in [RFC7333], "a DMM solution MUST supportany security > > > > > > nit: s/supportany/support any/ > > > > > > > [CB] Fixed, thanks. > > > > Thanks again for all the good comments. > > And thanks for the updates! > > -Ben > --000000000000f7f2d805a11da30f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot Benjamin!

We'll implem= ent your wording suggestions in the next revision!

Carlos

On Tue, Mar 17, 2020 at 11:39 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Carlos,

Sorry for the slow reply; it's been a crazy couple weeks.

On Sat, Mar 07, 2020 at 05:55:59PM +0100, CARLOS JESUS BERNARDOS CANO wrote= :
> Hi Benjamin,
>
> Thanks a lot for your comments. Please find below my answers.
>
> On Thu, Mar 5, 2020 at 3:00 AM Benjamin Kaduk via Datatracker <
> noreply@ietf.org= > wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dmm-distributed-mobility-anchoring-14: Discuss
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> >
> > https://dat= atracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ > >
> >
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > Thanks for discussing the need to secure the various control-plan= e
> > interactions as part of the Security Considerations.=C2=A0 In add= ition to the
> > integrity and source-authentication properties already mentioned,= we
> > need to say that the control-plane functionality will apply
> > authorization checks to any commands or updates that are made by = the
> > control-plane protocol.
> >
>
> [CB] Thanks. I've added that to version -15 (to be submitted soon)= .
>
>
> >
> > Similarly, I didn't see any discussion of authorization for a= pplying or
> > making changes to the "rules" that are mentioned as nee= ding to be
> > applied by a data-plane node (as mentioned in the COMMENT where I= ask
> > for clarification on the nature of such rules).
> >
>
> [CB] Thanks. Even though we have changed a bit the writing to avoid th= e
> term "rule", we have added some text regarding the use of au= thentication
> and authorization mechanisms when doing traffic indirection=C2=A0 in v= ersion -15.
>
>
> >
> > Also, we should reference RFCs 8221 and 8247 for the current guid= ance on
> > IPsec and IKEv2 usage.
> >
>
> [CB] Thanks. Added.

Thanks!
I think the current placement of these references in the -15 make it sound<= br> like they are references for IPsec and IKEv2 respectively, and not "ju= st"
the best-practices for configuring them.=C2=A0 Just moving the references l= ater
in the sentences would probably help, though I'd recommend adding anoth= er
sentence "The current guidance for IPsec and IKEv2 usage is given in [RFC8221] and [RFC8247], respectively" to be fully clear about why the= y are
being referenced.

That said, I'm going to change my ballot position to No Objection after= I
send this mail, so no need to check back on the precise wording.

>
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > While I see the value in having this document to crystallize thin= king
> > about the various mobility anchoring techniques that are possible= , it's
> > not clear to me how much archival value this document would add t= o the
> > RFC series in the absence of specific protocol mechanisms to impl= ement
> > the functionality described therein.=C2=A0 As such, I expect to c= hange my
> > ballot position to Abstain after my Discuss points are resolved.<= br> > >
> > Section 1
> >
> >=C2=A0 =C2=A0 When the MN wants to continue using its assigned pre= fix to complete
> >=C2=A0 =C2=A0 ongoing data sessions after it has moved to a new ne= twork, the
> >=C2=A0 =C2=A0 network needs to provide support for the MN's IP= address -- and
> >
> > The new network, right?
> >
> >
> [CB] The new network and the old one, understanding "old" by= the one
> anchoring the prefix used by the MN. That's why we just use the ge= neric
> term "network" without prepending "new".

Ah, I see now; thanks.

> Section 2
> >
> >=C2=A0 =C2=A0 Anchoring (of an IP prefix/address):=C2=A0 An IP pre= fix, i.e., Home
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Network Prefix (HNP), or address, i.e.,= HoA, assigned for use by
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0an MN is topologically anchored to an a= nchor node when the anchor
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0node is able to advertise a connected r= oute into the routing
> >
> > Is "connected route" a term of art I should be looking = up?
> >
> >
> [CB] I agree it's probably better to just use "route". W= e have changed this
> in version -15 (to be submitted soon).
>
>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and manages the network location inform= ation of an MN.=C2=A0 The
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0location information may be a binding o= f the advertised IP
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0address/prefix, e.g., HoA or HNP, to th= e IP routing address of the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0MN or of a node that can forward packet= s destined to the MN.
> >
> > I assume this ("may be [...] or") is not intended to be= an exhaustive
> > list?
> >
>
> [CB] Right. Though the cases listed are the ones I can think of now as=
> making sense. But we don't want to close the door for other option= s that
> might also work there.

Sometimes a list of two options like this can be misread as intended to be<= br> exhaustive, in which case a phrase like "may be (for example)" ca= n help, or
adding some generic catch-all clause to the end of the list.

>
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0In a client-server protocol model, loca= tion query and update
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0messages may be exchanged between a Loc= ation Management client
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(LMc) and a Location Management server = (LMs), where the location
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0information can be updated to or querie= d from the LMc.
> >
> > nit: s/updated to/updated from/?
> >
>
> [CB] Right, thanks.
>
>
> >
> > Do we want to discuss the authentication/authorization for such l= ocation
> > management functions here?=C2=A0 (Including both MN/LMc and LMc/L= Ms
> > interactions.)
> >
>
> [CB] I've added "secure (i.e., authenticated and authorized)&= quot; before
> "location query and update messages may be
> exchanged between [...]" to make it clear that of course these si= gnalling
> needs to be properly secured. I think going into more details there wi= ll
> deviate the focus from the main point of this document. Anyway, the > security considerations section should cover all these parts as well.<= br>
Sounds good, thanks.

>
> >
> > Section 4
> >
> >=C2=A0 =C2=A0 There may be multiple IP prefixes/addresses that an = MN can select
> >=C2=A0 =C2=A0 when initiating a flow.=C2=A0 They may be from the s= ame access network or
> >=C2=A0 =C2=A0 different access networks.=C2=A0 The network may adv= ertise these prefixes
> >=C2=A0 =C2=A0 with cost options [I-D.mccann-dmm-prefixcost] so tha= t the mobile node
> >=C2=A0 =C2=A0 may choose the one with the least cost.=C2=A0 In add= ition, these IP
> >
> > This draft has not been updated since 2016.=C2=A0 Is it still exp= ected to
> > progress, such that a reference to it remains valuable?
> >
>
> [CB] We use this reference as an example of approach. There are other<= br> > examples that we could reference, but I wanted to give the credit to t= he
> guys that I think first proposed this. That's why I kept the refer= ence, but
> I can very easily replace it with another one if you think it would be=
> best.

My personal preference for picking references is biased towards referencing=
documents that can be used to build deployable solutions, but I see no flaw=
in your reasoning here.

>
> >=C2=A0 =C2=A0 prefixes/addresses may be of different types regardi= ng whether
> >=C2=A0 =C2=A0 mobility support is needed [RFC8653].=C2=A0 A MN wil= l need to choose which
> >=C2=A0 =C2=A0 IP prefix/address to use for each flow according to = whether it needs
> >=C2=A0 =C2=A0 IP mobility support or not, using for example the me= chanisms
> >=C2=A0 =C2=A0 described in [RFC8653].
> >
> > I'm confused.=C2=A0 "these prefixes/addresses" seem= s to refer to the ones
> > advertised by the network, but the question of whether mobility s= upport
> > is needed seems like a matter local to the MN and not a need of t= he
> > network.=C2=A0 (Perhaps the network might *provide* different mob= ility
> > services for different prefixes/addresses, but that's not wha= t this text
> > currently says.)
> >
>
> [CB] The prefixes/addresses refer to the one provided by the network. = The
> question of whether the MN needs mobility or not is local to the MN, b= ut if
> the MN actually need it, support from the network might be needed
> (depending on the type of mobility support of the MN and network). I&#= 39;ve
> reworded it to:
>
> "In addition, the IP prefixes/addresses provided by the network m= ay be of
> different types regarding whether mobility support is supported [RFC 8= 653]
> ."
>
> I hope now the text is clearer.

I think so, thanks.

>
> > Section 4.1
> >
> > I suggest to expand access router or list it in the terminology s= ection.
> >
>
> [CB] Done (expanded first time it appears in the text).
>
>
> >
> >=C2=A0 =C2=A0 When IP session continuity is needed, even if a flow= is ongoing as
> >=C2=A0 =C2=A0 the MN moves, it may still be desirable for the flow= to change to
> >=C2=A0 =C2=A0 using the new IP prefix configured in the new networ= k.=C2=A0 The flow may
> >=C2=A0 =C2=A0 then close and then restart using a new IP address c= onfigured in the
> >=C2=A0 =C2=A0 new network.=C2=A0 Such a change in the IP address o= f the flow may be
> >
> > It's perhaps a little confusing, in a rhetorical sense, to ta= lk about
> > "the flow changing to use the new prefix" but doing tha= t by having the
> > flow "close and then restart" -- is it really the same = flow after it has
> > closed?
> >
>
> [CB] You are right. If we are picky with the terminology, the flow is<= br> > indeed different. I've reworded to use "application flow"= ; instead of
> "flow". Hope this is a bit better. Current text (some other = small changes
> performed) read as follows:
>
> "When IP session continuity is needed, even if an application flo= w is
> ongoing as
> the MN moves, it may still be desirable for the application flow to ch= ange
> to
> using the new IP prefix configured in the new network. The application= flow
> may
> then be closed at IP level and then be restarted using a new IP addres= s
> configured in the new network. Such a change in the IP address used by= the
> application flow may be enabled using a higher layer mobility support = which
> is
> not in the scope of this document."

Thank you!

>
> >
> >=C2=A0 =C2=A0 Note that in this scenarios, if there is no mobility= support provided
> >=C2=A0 =C2=A0 by L4 or above, an application might be able to stop= before changing
> >=C2=A0 =C2=A0 point of attachement, and therefore the traffic woul= d stop.
> >
> > I'm not sure what "might be able to stop" is intend= ed to mean.
> > Regardless, it's quite clear that the traffic will stop upon = the
> > mobility event in this scenario, since the network does not provi= de
> > continuity services!
> >
>
> [CB] That sentence was definitely not good. I've just simplified i= t to:
>
> "Note that in these scenarios, if there is no mobility support pr= ovided by
> L4 or
> above, application traffic would stop."
>
> which is kind of clear, but I think it doesn't harm keeping it. >
>
> > Section 4.2
> >
> >=C2=A0 =C2=A0 prefix.=C2=A0 The latter enables optimized routes bu= t requires some data
> >=C2=A0 =C2=A0 plane node that enforces rules for traffic indirecti= on.=C2=A0 Next, we
> >
> > I'm not sure I understand the role this rule-enforcment is me= ant to
> > play.=C2=A0 What sort of rules would it be enforcing?
> >
>
> [CB] We mean routing updates that enable the anchor mobility. I probab= ly
> used the term "rules" because one example of approach to use= in a local
> domain is OpenFlow. I've reworded it to the following:
>
> "The latter enables optimized routes but requires some data plane= node that
> enforces
> traffic indirection."
>
>
> >
> >=C2=A0 =C2=A0 to AR1 per default routing).=C2=A0 The LM and FM fun= ctions are implemented
> >=C2=A0 =C2=A0 as shown in Figure 6.
> >
> > Where is FM indicated in Figure 6?=C2=A0 I cannot find it.
> >
>
> [CB] Ooops. Thanks. Fixed!
>
>
> >
> > Also, should there be any control-plane anchoring indicated in Fi= gure 6?
> >
>
> [CB] There is the LM part indicated in AR2.
>
>
> >
> > Section 4.3
> >
> >=C2=A0 =C2=A0 We focus next on the case where the mobility anchor = (data plane
> >=C2=A0 =C2=A0 function) is changed but binds the MN's transfer= red IP address/
> >=C2=A0 =C2=A0 prefix.=C2=A0 This enables optimized routes but requ= ires some data plane
> >=C2=A0 =C2=A0 node that enforces rules for traffic indirection. > >
> > [same question as above about the rules]
> >
>
> [CB] Same resolution as before.
>
>
> >
> >=C2=A0 =C2=A0 IP mobility is invoked to enable IP session continui= ty for an ongoing
> >=C2=A0 =C2=A0 flow as the MN moves to a new network.=C2=A0 Here th= e anchoring of the IP
> >=C2=A0 =C2=A0 address of the flow is in the home network of the fl= ow (i.e.,
> >=C2=A0 =C2=A0 different from the current network of attachment).= =C2=A0 A centralized
> >
> > nit(?): this usage of "here" is surprising, in that it = seems to discuss
> > the same case as the previous section, and not the new mechanism = that
> > we're describing in this section.
> >
>
> [CB] OK, I've removed "here".
>
> >
> >=C2=A0 =C2=A0 The IP prefix/address anchoring may move without cha= nging the IP
> >=C2=A0 =C2=A0 prefix/address of the flow.=C2=A0 Here the LM and FM= functions in Figure 1
> >=C2=A0 =C2=A0 in Section 3.1 are implemented as shown in Figure 7.=
> >
> > Where is the FM function indicated in Figure 7?=C2=A0 I cannot fi= nd it.
> >
>
> [CB] FM is not involved here. I've fixed the text. When we wrote t= he text I
> was thinking on a generic way of referring to LM and FM functions, not=
> implying that they need to be implemented in all the cases. But I agre= e it
> is not very clear.
>
>
> >
> >=C2=A0 =C2=A0 [I-D.ietf-rtgwg-atn-bgp].=C2=A0 When a mobile associ= ates with an anchor
> >=C2=A0 =C2=A0 the anchor injects the mobile's prefix into the = global routing
> >=C2=A0 =C2=A0 system.=C2=A0 If the mobile moves to a new anchor, t= he old anchor
> >
> > nit: "mobile node" or just "MN" (twice)?
> >
>
> [CB] Probably better to use MN. I've fixed it.
>
>
> >
> >=C2=A0 =C2=A0 withdraws the /64 and the new anchor injects it inst= ead.
> >
> > What kind of synchronization and/or serialization is needed betwe= en the
> > withdrawl and injection of the /64 in question?
> >
>
> [CB] That'd be part of the control plane signalling, which would d= epend on
> the actual solution being used. Since this document does not go into t= he
> specifics of an actual solution, we don't go further.

Hmm, okay.

>
> >
> > Section 5
> >
> >=C2=A0 =C2=A0 As stated in [RFC7333], "a DMM solution MUST su= pportany security
> >
> > nit: s/supportany/support any/
> >
>
> [CB] Fixed, thanks.
>
> Thanks again for all the good comments.

And thanks for the updates!

-Ben
--000000000000f7f2d805a11da30f-- From nobody Wed Mar 18 09:17:02 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AD63A0793; Wed, 18 Mar 2020 09:16:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Cc: suresh@kaloom.com, rfc-editor@rfc-editor.org, Dapeng Liu , maxpassion@gmail.com, dmm-chairs@ietf.org, dmm@ietf.org, The IESG , draft-ietf-dmm-distributed-mobility-anchoring@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <158454821571.30107.10355992993624514388@ietfa.amsl.com> Date: Wed, 18 Mar 2020 09:16:55 -0700 Archived-At: Subject: [DMM] Document Action: 'Distributed Mobility Anchoring' to Informational RFC (draft-ietf-dmm-distributed-mobility-anchoring-15.txt) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 16:16:57 -0000 The IESG has approved the following document: - 'Distributed Mobility Anchoring' (draft-ietf-dmm-distributed-mobility-anchoring-15.txt) as Informational RFC This document is the product of the Distributed Mobility Management Working Group. The IESG contact persons are Éric Vyncke and Suresh Krishnan. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/ Technical Summary This document describes architectural considerations and approaches for realizing distributed mobility management systems. These techniques can are applicable to any access specific and access agnostic mobility architectures. Working Group Summary This document has been in development, first as an individual submission in the DMM WG and later as a working group document. The document has gone through around 14 revisions. Document Quality The current version of the document is well-written. Some sections of the document can be drafted in a better way, but that just reflects a specific writing style. The work was completed by the authors in the earlier versions, however the chairs were not comfortable moving the document forward due to editorial issues. The chairs had to therefore appoint an editor for rewriting the document and had to put through WG reviews. We believe the quality of this document is good. Personnel Dapeng(Max) Liu is the document shepherd. Suresh Krishnan is the responsible AD. From nobody Thu Mar 19 02:47:11 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 583663A2602; Thu, 19 Mar 2020 02:47:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs@ietf.org, dmm@ietf.org, Dapeng Liu , max.ldp@alibaba-inc.com X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158461123033.13529.17028438404934146154@ietfa.amsl.com> Date: Thu, 19 Mar 2020 02:47:10 -0700 Archived-At: Subject: [DMM] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-dmm-pmipv6-dlif-06=3A_=28with_COMMENT=29?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 09:47:11 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dmm-pmipv6-dlif-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss and adding section 3.6. I know that the text there is inline with RFC6275 and therefore I'm clearing my discuss. However I just notice that its says " The node MAY continue to send these messages at this slower rate indefinitely." I think allowing to send something indefinitely is always a bad idea. This is a MAY but given there is no alternative provided, I guess it's not unlikely that people will implement it this way. It's always better to have a defined termination condition. This could be something like "SHOULD stop sending after X and log an error" where X is a super high value in e.g. days. This would implicitly also allow to send indefinitely because it's a SHOULD but would make it less likely people implement that. I personal would however even recommend a MUST. In any case, as RFC6275 has exactly the same sentence, so I'm not blocking on this, but maybe still worth reconsidering... --------- Old comments: I fully understand why the authors decided to not make changes but keeping these as for the record: 4) As section 3.6 talks mainly about implementation details, I suggest to move this section into the appendix. 7) One overall editorial comment which might be too late to address: I would have found it more easy to read if you would have first introduced the new messages and then used the concrete message names in the description in section 3. From nobody Fri Mar 20 10:48:45 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671B13A0CF0; Fri, 20 Mar 2020 10:47:48 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h1uDBH3Vj7q; Fri, 20 Mar 2020 10:47:35 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 F09A43A0C3E; Fri, 20 Mar 2020 10:47:11 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02KHiCcS003353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Mar 2020 13:44:15 -0400 Date: Fri, 20 Mar 2020 10:44:12 -0700 From: Benjamin Kaduk To: CARLOS JESUS BERNARDOS CANO Cc: The IESG , draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs , dmm , Dapeng Liu Message-ID: <20200320174412.GQ50174@kduck.mit.edu> References: <158338573858.29475.12173301575622176655@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 17:47:50 -0000 Hi Carlos, Also inline (but not much left to say!) On Sun, Mar 08, 2020 at 06:58:14PM +0100, CARLOS JESUS BERNARDOS CANO wrote: > Hi Benjamin, > > Thanks a lot for another very good review. Please find my comments inline > below. > > On Thu, Mar 5, 2020 at 6:22 AM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dmm-pmipv6-dlif-05: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have a very boring Discuss point and a somewhat boring point, and > > expect to change my ballot to Yes once they're resolved. > > > > In Section 3.2 we say that pacing mechanisms "MAY" be used to avoid > > bursts when the CMD is fanning out PBUs, but in Section 6 we say that > > pacing "SHOULD" be used; please resolve the inconsistency (preferrably > > with "MUST" as Mirja requests). > > > > [CB] Done in version -06 (to be submitted soon). > > > > > > Please also include some discussion of privacy considerations (I give > > some suggestions in the COMMENT). > > > > [CB] OK, I'll do. > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for this well-written document! It is clearly written, and when > > multiple approaches exist, does well at laying out the different options > > and their pros/cons, as befits an Experimental document. Also, several > > times I have started to write a comment only to realize that it is > > answered by the following text :) > > > > [CB] Thanks, very much appreciated. > > > > > > Section 1 > > > > The Distributed Mobility Management (DMM) paradigm aims at minimizing > > the impact of currently standardized mobility management solutions > > which are centralized (at least to a considerable extent). > > > > I'd consider saying a little more about which aspects of their operation > > are centralized. Perhaps the following paragraph suffices, though. > > > > [CB] I've added another reference to RFC 7333, where this is explained in > detail. As you mention below, we go a bit into these aspects of centralized > operation in the following paragraph, and I personally believe it is better > not to add too much text on this aspect (which is covered by RFC 7333). > Please, let me know if you are not happy with this resolution. > > > > > > Following this idea, in our proposal, the central anchor is moved to > > the edge of the network, being deployed in the default gateway of the > > mobile node. That is, the first elements that provide IP > > > > (side note: Using the singular "central anchor" poses an interesting > > rhetorical question: is the (formerly) single central anchor being > > duplicated and spread amongst all access routers, or does there remain a > > single central anchor (per MN), just one that moves around along with > > the MN.) > > > > [CB] The whole idea of the DMM approach specified in this document is that > we move from a "single central anchor" to a "multiple distributed anchors". > Note that the specified approach allows for a central anchor to be still > present (and used by an MN for communications where it is more > appropriate), but this is more an operational decision (probably more in > scope of RFC 8653). > > > > > > anchors to retrieve the MN's previous location(s). Also, a key- > > aspect of network-based DMM, is that a prefix pool belongs > > exclusively to each MAAR, in the sense that those prefixes are > > assigned by the MAAR to the MNs attached to it, and they are routable > > at that MAAR. > > > > It might be worth some statement relating this "ownership" of prefixes > > to actual mobility events -- e.g., they are assigned to MNs attached to > > it at that time, but remain with those MNs as mobility occurs, but > > always remain routable at that MAAR as well as towards the MN itself. > > > > [CB] OK, I've added a sentence adopting part of your text. Thanks. > > > > We consider partially distributed schemes, where the data plane only > > is distributed among access routers similar to MAGs, whereas the > > > > nit: I suggest s/the data plane only/only the data plane/ > > > > [CB] OK, thanks. > > > > > > control plane is kept centralized towards a cardinal node used as > > information store, but relieved from any route management and MN's > > data forwarding task. > > > > What's the scope of "single" here -- per deployment, per prefix, per > > MAAR, ...? > > > > [CB] Sorry, I don't get this comment. I don't see "single" mentioned in the > quoted textl Sorry! I was assuming that the "cardinal node" was a single centralized information store, and that's the "single" I was trying to ask about. Re-reading, I would assume that this "cardinal node" is per deployment, so it may not be worth changing the text if that's in fact the case. > > > > > P-MAAR (Previous MAAR). When a MN moves to a new point of attachment > > a new MAAR might be allocated as its anchor point for future IPv6 > > prefixes. The MAAR that served the MN prior to new attachment > > becomes the P-MAAR. It is still the anchor point for the IPv6 > > prefixes it had allocated to the MN in the past and serves as the > > > > (side note? Do we expect those previous allocations to eventually "time > > out" as sessions using them terminate? Or are the allocations more > > permanent, with intent to reuse if/when the MN returns to that MAAR?) > > > > [CB] The expectation is that previous allocations will eventually time-out > as sessions using them terminate. > > > > > > Section 3 > > > > interest and eventually take the appropriate action. The procedure > > adopted for the query and the messages exchange sequence might vary > > to optimize the update latency and/or the signaling overhead. Here > > > > nit: wrong pluralization in "messages exchange sequence" > > > > [CB] OK, fixed. > > > > > > Section 3.1 > > > > 3. Since this is an initial registration, the CMD stores a permanent > > BCE containing as primary fields the MN-ID, Pref1 and MAAR1's > > address as a Proxy-CoA. > > > > [how permanent is "permanent"?] > > > > [CB] I've removed "permanent" as it is not really needed. The BCE stays at > the CMD until the session is de-registered (it is "more permanent" that the > BCEs at the P-MAARs). > > > > > > Section 3.2 > > > > 1. When the MN moves from its current point of attachment and > > attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6 > > prefix (Pref2), it stores a temporary BCE, and it sends a plain > > PBU to the CMD for registration. > > > > It's not clear to me at this point how MAAR2 has enough information to > > determine that this will be a "plain" PBU vs. the the PBU used for > > initial registration. (That said, it's also not clear to me that the > > send PBU actually differs on the wire, so maybe this is just a > > rhetorical question. Er, a question of rhetoric, that is.) > > > > [CB] They are actually the same PBUs, as MAAR2 does not know at that point > if the MN had been already registered. Both PBUs would be "plain". I've > removed "plain" and "another" to make it clearer. > > > > > > 4. The CMD, after receiving the PBA, updates the BCE populating an > > instance of the P-MAAR list. The P-MAAR list is an additional > > field on the BCE that contains an element for each P-MAAR > > involved in the MN's mobility session. The list element contains > > the P-MAAR's global address and the prefix it has delegated (see > > Appendix B for further details). Also, the CMD sends a PBA to > > the new S-MAAR, containing the previous Proxy-CoA and the prefix > > anchored to it embedded into a new mobility option called > > Previous MAAR Option (defined in Section 4.5), so that, upon PBA > > arrival, a bi-directional tunnel can be established between the > > two MAARs and new routes are set appropriately to recover the IP > > flow(s) carrying Pref1. > > > > To check my understanding: there will only be one Previous MAAR Option > > present and it will describe only a single MAAR, which implies that if > > there are multiple P-MAARs, traffic directed to an arbitrary prefix > > based at one of them is expected to traverse multiple tunnels from > > P-MAAR to P-MAAR before making its way to the S-MAAR and the MN? > > [Hmm, looks like my understanding is wrong. I'd consider making > > "previous Proxy-CoA" and "the prefix anchored to it" plural to give the > > reader a hint as to what's coming, though I can understand if there is > > desire to keep the initial mobility example simple and only gradually > > introduce the complexity in question.] > > > > [CB] I've been looking at it and changing it back and forth several times. > I prefer to keep the initial mobility example. Just to answer your > question, in general there might be multiple options. This is what the text > you point below should indicate (among other things). > > > > For MN's next movements the process is repeated except the number of > > P-MAARs involved increases (accordingly to the number of prefixes > > that the MN wishes to maintain). Indeed, once the CMD receives the > > first PBU from the new S-MAAR, it forwards copies of the PBU to all > > the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR > > prior to handover) and in the P-MAARs list. They reply with a PBA to > > the CMD, which aggregates them into a single one to notify the > > S-MAAR, that finally can establish the tunnels with the P-MAARs. > > > > I'm not sure I understand the cardinality of P-CoA -- is it one, > > the single S-MAAR prior to handover, or many, all P-MAARs in the list? > > > > [CB] There are multiple P-CoAs, but current writing might lead to think > there is only one. One P-CoA is the one listed in the BCE (the one of the > previously visited MAAR) plus the P-CoAs listed in the P-MAAR list. I've > rewritten a bit the text trying to make this clearer: "Indeed, once the CMD > receives the first PBU from the new S-MAAR, it forwards copies of the PBU > to all the P-MAARs indicated in the BCE, namely the one registered as > current P-CoA (i.e., the MAAR prior to handover) plus the ones in the > P-MAARs list." Thanks, this helps a lot! > > > When there are multiple previous MAARs, e.g., k MAARs, a single PBU > > received by the CMD triggers k outgoing packets from a single > > incoming packet. This may lead to packet bursts originated from the > > CMD, albeit to different targets. Pacing mechanisms MAY be > > introduced to avoid bursts on the outgoing link. > > > > I'll defer to my TSV colleagues, but a "SHOULD" feels more comfortable > > than "MAY" to me, here. > > > > [CB] Actually, based on other comments we have decided to go for "MUST". Indeed. (It looks like I forgot to change this comment when I added a note to my discuss point after I read Mirja's position.) > > > Section 3.3 > > > > The handover latency experienced in the approach shown before can be > > reduced if the P-MAARs are allowed to signal directly their > > information to the new S-MAAR. This procedure reflects what was > > described in Section 3.2 up to the moment the P-MAAR receives the PBU > > with the P-MAAR option. At that point a P-MAAR is aware of the new > > > > nit(?): I think this is the S-MAAR option, not the P-MAAR option? > > > > [CB] Right! Thanks. > > > > > > S-MAAR including the prefix it is anchoring. This latter PBA does > > not need to include new options, as the prefix is embedded in the HNP > > option and the P-MAAR's address is taken from the message's source > > address. The CMD is relieved from forwarding the PBA to the S-MAAR, > > > > (side note: this assumes there's no NAT or tunneling or similar between > > MAARs, which seems like a plausible assumption, at least for now.) > > > > [CB] Yes, that's right. > > > > > > Section 3.4 > > > > side. When P-MAARs complete the update, they send a PBA to the CMD > > to indicate that the operation is concluded and the information is > > updated in all network nodes. This procedure is obtained from the > > > > Is there anything useful to say about behavior on timeout at the CMD > > (failing to reive a PBA from one or more P-MAARs)? > > > > [CB] A new Section 3.6 "Retransmissions and Rate Limiting" has been added > (to address also other received comments). I hope this addresses this > comment. It doesn't directly give guidance about the CMD's behavior as a recipient, but it does give some more context for the expected operation of the system, which should be enough. > > > Section 3.5 > > > > The de-registration mechanism devised for PMIPv6 cannot be used as is > > in this solution. The reason for this is that each MAAR handles an > > > > nit: s/as is/as-is/ > > > > [CB] Fixed, thanks. > > > > > > Indeed, when a previous MAAR initiates a de-registration procedure, > > because the MN is no longer present on the MAAR's access link, it > > removes the routing state for that (those) prefix(es), that would be > > deleted by the CMD as well, hence defeating any prefix continuity > > attempt. The simplest approach to overcome this limitation is to > > > > nit(?): s/when/if/. At least, this makes more sense to me if I do that > > ... maybe I'm just confused. > > > > [CB] OK, fixed. > > > > > > serving MAAR to de-register the whole MN session. This can be > > achieved by first removing any layer-2 detachment event, so that de- > > registration is triggered only when the session lifetime expires, > > > > I see that RFC 5213 has some mechanisms for lifetime management, but > > didn't get to look closely enough to understand how clear the necessary > > lifetime management will be in the DMM case when there are multiple > > prefixes registered to a given MN at different MAARs. (Also, 5213 > > doesn't seem to use the "session lifetime" phrase verbatim.) > > > > [CB] I've replaced "session lifetime" with "binding lifetime" to make it > more consistent with the terminology used in RFC 5213. Note that "mobility > session" is used in RFC 5213. Thanks! > > > > > Section 3.6 > > > > requiring special support from the mobile node's IP stack. This > > document defines the Distributed Logical Interface (DLIF), which is a > > software construct that allows to easily hide the change of > > associated anchors from the mobile node. > > > > A software construct in the MAAR, right? > > > > [CB] Yes, I've added "in the MAAR" to the text. > > > > > > > > How common is "HMAC" as an abbreviation for "hardware MAC address"? > > It's also an abbreviation for Hash-based Message Authentication Code, > > which confuses my poor security-focused brain, though I acknowledge that > > this does not necessarily extend to most of the target audience for this > > document... > > > > [CB] It is not common. To avoid potential confusions I've removed HMAC and > just used MAC, which I think it is sufficient in the scope of this document > (as we use LMAC for the logical one). > > > > and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two > > P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the > > > > Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)? > > > > [CB] You are right. Here there was a mistake, as P-MAAR was being mixed > with anchoring MAAR. I've removed that sentence to keep it clearer. > > > > role of anchoring MAAR for the attached (served) MNs. Each MAAR has > > one single physical wireless interface. > > > > Have we defined "anchoring MAAR" yet? > > > > [CB] We have added a definition to the terminology section. > > > > Also, I assume that the "single physical interface" is just "as depicted > > in this example" and not a protocol requirement :) > > > > [CB] Yes, right. > > > > > > As introduced before, each MN always "sees" multiple logical routers > > -- one per P-MAAR -- independently of its currently serving MAAR. > > > > [same P-MAAR vs. S-MAAR split as above] > > > > [CB] Right, fixed by replacing P-MAAR with anchoring MAAR. > > > > > > > by the serving MAAR (MAAR2) configuring an additional distributed > > logical interface: mn1mar1, which behaves exactly as the logical > > interface configured by MAAR1 when MN1 was attached to it. This > > > > nit(?): "exactly" is asking for pedants to try and poke holes in the > > claimed perfection. > > > > [CB] Right, I removed "exactly". > > > > > > deprecated). The goal is to deprecate the prefixes delegated by > > these MAARs (which will be no longer serving the MN). Note that on- > > > > nit(?): s/which will be no longer/so that they will no longer be/, IIUC > > > > [CB] Fixed. > > > > > > Section 4.1 > > > > The intdir reviewer's comments regarding the flag bits seem apropos (I > > presume they were allocated by other extensions to 5213, but we should > > say something about it). > > > > [CB] OK, I'll address this in my response to the intdir review. It looks like the plan is to reference the IANA registry for the flags? That sounds good, though I assume it's still only in the editor's copy. > > > > > > > A new flag (D) is included in the Proxy Binding Update to indicate > > that the Proxy Binding Update is coming from a Mobility Anchor and > > > > "D" is for "DMM", I trust? It could be worth mentioning. > > > [CB] Yes, done. > > > > > > > > Is the D bit set for the PBUs sent from CMD to P-MAAR as well? > > > > [CB] Yes, I've fixed that. > > > > (I see that the PBA description uses a slightly different formulation to > > cover the 'D' bit; is there a reason to diverge?) > > > > [CB] No reason. I've updated the text to use the same formulation. > > > > > > Mobility Options > > > > Variable-length field of such length that the complete Mobility > > Header is an integer multiple of 8 octets long. This field > > contains zero or more TLV-encoded mobility options. The encoding > > and format of defined options are described in Section 6.2 of > > [RFC6275]. The MAAR MUST ignore and skip any options that it does > > not understand. > > > > MAARs that *receive* PBUs must be P-MAARs, right? > > > > [CB] Yes, but also a CMD. Therefore I've replaced "MAAR" with "receiving > node". > > > > Section 4.2 > > > > MAAR (D) > > > > The D is set to indicate that the sender of the message supports > > operating as a Mobility Anchor and Access Router. When a MAG that > > does not support the extensions described in this document > > receives a message with the D-Flag set, it MUST ignore the message > > and an error MUST be returned. > > > > Is the CMD considered a MAAR for this purpose? > > > > [CB] I've replaced "operating as a Mobility Anchor and Access Router" with > "operating as a MAAR or a CMD". > > > > contains zero or more TLV-encoded mobility options. The encoding > > and format of defined options are described in Section 6.2 of > > [RFC6275]. The MAAR MUST ignore and skip any options that it does > > not understand. > > > > What about the CMD? > > > > [CB] Same.. Therefore I've replaced "MAAR" with "receiving node". > > > > > > Section 4.3, 4.4 > > > > Prefix Length > > > > 8-bit unsigned integer indicating the prefix length of the IPv6 > > prefix contained in the option. > > > > Anchored Prefix > > > > A sixteen-byte field containing the mobile node's IPv6 Anchored > > Prefix. Only the first Prefix Length bytes are valid for the > > Anchored Prefix. The rest of the bytes MUST be ignored. > > > > Is the prefix length bits or bytes? > > > > [CB] Bits. Fixed (also mentioned by another review). > > > > > > Section 4.4 > > > > Is this also used to convey "local" prefixes in the PBA from CMD to > > S-MAAR? (If not, how does the S-MAAR know to advertise them from its > > DLIF?) > > > > [CB] Yes, this is right. I've rewritten the text to reflect it. > > > > > Section 4.5 > > > > What's the alignment requirement? > > (There's no need to put in a Reserved octet to keep things word > > aligned?) > > > > [CB] You are right. And this is embarrassing, as the internal code we use > is actually using the format with the extra reserved byte that was not > reflected in the document. > > > > Prefix Length > > > > 8-bit unsigned integer indicating the prefix length of the IPv6 > > prefix contained in the option. > > [...] > > Home Network Prefix > > > > A sixteen-byte field containing the mobile node's IPv6 Home > > Network Prefix. Only the first Prefix Length bytes are valid for > > the mobile node's IPv6 Home Network Prefix. The rest of the bytes > > MUST be ignored. > > > > [is the prefix length bits or bytes?] > > > > [CB] Bits. Fixed. > > > > > > Section 4.6 > > > > Is there an alignment requirement for this option? > > > > [CB] Yes, added. > > > > > > This new option is defined for use with the Proxy Binding Update and > > Proxy Binding Acknowledgement messages exchanged between the CMD and > > > > When is this option used in a PBA? > > > > [CB] Right, it is only used in a PBU. Fixed. > > > > > > Section 4.7 > > > > A new DLIF Link-local Address option is defined for use with the > > Proxy Binding Update and Proxy Binding Acknowledgment messages > > exchanged between MAARs. This option is used for exchanging the > > > > MAARs but not CMDs? > > When is this used in the PBU? > > > > [CB] Also CMDs. And only in PBA. Fixed. > > > > > > Section 4.8 > > > > A new DLIF Link-layer Address option is defined for use with the > > Proxy Binding Update and Proxy Binding Acknowledgment messages > > exchanged between MAARs. This option is used for exchanging the > > > > MAARs but not CMDs? > > When is this used in the PBU? > > > > [CB] Same as before. > > > > > > Section 6 > > > > Unfortunately it seems that RFC 5213 does not include any privacy > > considerations discussion. While the privacy properties of this > > protocol bear similarities to those of RFC 5213, it seems that there are > > also some significant differences, so I do think it is important to > > produce some documentation of privacy considerations for this document. > > The main factor would, of cousre, be tracking which entities obtain > > updates/information about the location of the MN, what those entities > > are expected to do with that data, and how trusted they are to be proper > > custodians of it. Other factors may exist as well, including the > > potential for side-channel information leakage, e.g., due to traffic > > analysis. There might also be a reverse situation where exposing the > > link-layer address(es) of a P-MAAR have privacy considerations, though I > > don't have anything particular in mind at the moment. > > > > [CB] OK, I see your point. I've tried to add something in version -06. Let > me know if you think it is sufficient (I tried to keep it short and simple, > while still addressing your point). I think it covers the key points. Since all the parties are highly trusted anyway, we don't need to go into great detail. > > > > > security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended > > that the signaling messages, Proxy Binding Update and Proxy Binding > > Acknowledgment, exchanged between the MAARs are protected using IPsec > > using the established security association between them. This > > > > This is essentially unchanged from 5213, just with different names for > > the endpoints, right, and so the existing guidance/experiences apply? > > > > [CB] Yes, it should apply. We haven't identified anything different. > > > > > > I think we should also say something about all MAARs and the CMD being > > trusted parties. We should also say something about the authorization > > model (I assume it's just "all trusted parties are trusted to perform > > all operations relevant to their role", but that's still useful to say). > > > > [CB] OK, I've added a sentence on that. > > > > > > When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a > > single PBU to multiple previous MAARs. In situations of many fast > > handovers (e.g., with vehicular networks), there may exist multiple > > previous (e.g., k) MAARs exist. In this situation, the CMD creates k > > > > nit: remove the redundant "exist" > > > > [CB] Done. > > > > > > When the CMD acts as MAAR locator, mobility signaling (PBAs) is > > exchanged between P-MAARs and current S-MAAR. This requires security > > associations to exist between the involved MAARs (in addition to the > > ones needed with the CMD). > > > > Is this relevant because of scaling/resource-consumption concerns or > > keying/trust ones? > > > > [CB] This is relevant because RFC 5213 uses a model in which signalling is > exchanged only between LMA (the anchor) and MAGs (the access routers), > while in this document there are some operation modes that also involve > signalling between MAARs (the access routers). This was just to highlight > this point (it is related to the point you made before about the trust > model). Okay, thanks for the clarification. > > > > > Appendix A.5 > > > > not implement existing mobility protocols. Furthermore, a DMM > > solution SHOULD work across different networks, possibly operated as > > separate administrative domains, when the needed mobility management > > > > Hmm, separate administrative domains makes the risk of NAT relatively > > higher (per previous comment about NAT). > > > > intervention. The partially distributed DMM solution can be deployed > > across different domains with trust agreements if the CMDs of the > > operators are enabled to transfer context from one node to another. > > > > It would probably be worth expounding a bit more about this scenario and > > the necessary trust/authorization relationships, in the security > > considerations. > > > > [CB] As per other comment from IESG evaluation I've removed the two > appendixes. > > Huge thanks for your very good points! And thanks for all the updates! I will go update my ballot position now. -Ben From nobody Fri Mar 20 11:47:00 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446E13A0DB5 for ; Fri, 20 Mar 2020 11:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfV_REFqudVJ for ; Fri, 20 Mar 2020 11:46:35 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B590D3A0DAF for ; Fri, 20 Mar 2020 11:46:34 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id z65so8387558ede.0 for ; Fri, 20 Mar 2020 11:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=drscbpGtGlIfm6SiDv6RmCse6eLI7Fj5jNE62zrE1p4=; b=rCYytnriIzHCAAuZfP7wZGOFkwFFx6AAsJMYsmusXUqcHBpXBWtos/jW9P255Qs/n6 jeq6pbSeg78OI+Ccj6WeFZzTvS6/9ZYLVFkc56Wjb/pz3JHjwxQnrfVHbP8ZYpPFgGsO Ig/7dxnXdba+Dej8ilcP4l7ONsaappoSsK14Dstjz238E+Z4sEkib6wYHF/WKtUWCMzD doeMmrWX2QDxIfnEJK2smdhEtcGYhIQZZy+o7ptA3ohUgUMqzQhClzhEdNmeuuP73pC7 CTA5LSZTxzP2UhtGz5bFhMO2O/LdTC1meOMftQZ6XQZkSnV0yDLOjs2NdDumtffGIz4L lkDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=drscbpGtGlIfm6SiDv6RmCse6eLI7Fj5jNE62zrE1p4=; b=MC7GbpBTmgO2cbdbp7rs4LKEBzVo11L5ErwON4w0ntnlSCr5ieGE512Ps911EAd1KJ xWnp6VTxdr5j6fhGNfdEUHQohNdBYEKzmOcLArs1O5dyp3oIben5Wd7eAMZ2q9KNaVI5 qDrRfSmYVh6kqlgRFGF7MuDP5BhJ5VoNoRKuWWivs5NIHbx1vYz/m+p3zMVcDahTyLcv eLIO10pX72bwZ9jxJeZgoeSY18MzmHjdEgWcq5Pe6zzeeOEEhtlHfcfJitT9fC+WWdxd T50MyuXXAs+KUiDdJNRVSr4Jz/gphZJdILDqKamjVk4f1SUn9WQQGkfSSB5FPtwBFoxf W7gQ== X-Gm-Message-State: ANhLgQ0Zrr803Fel/Yoz5KVG4vf9oVeYT1alWvDje18yA5EYDgbGJ/UN Pjrbsq0+dJWktIoltVh3W7l6sQS28jIV43KU8CKJjA== X-Google-Smtp-Source: ADFU+vv1VTvrwil058iipZNsrS+eau/vBPcowv54JL4bEPh701fy8LZY8nvkQ0coJiot7QFSY8baLyS3voGoGUgwkW0= X-Received: by 2002:a50:8b41:: with SMTP id l59mr9301451edl.44.1584729992694; Fri, 20 Mar 2020 11:46:32 -0700 (PDT) MIME-Version: 1.0 References: <158338573858.29475.12173301575622176655@ietfa.amsl.com> <20200320174412.GQ50174@kduck.mit.edu> In-Reply-To: <20200320174412.GQ50174@kduck.mit.edu> From: CARLOS JESUS BERNARDOS CANO Date: Fri, 20 Mar 2020 19:46:16 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs , dmm , Dapeng Liu Content-Type: multipart/alternative; boundary="00000000000047c21605a14db499" Archived-At: Subject: Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2020 18:46:52 -0000 --00000000000047c21605a14db499 Content-Type: text/plain; charset="UTF-8" Thanks a lot Benjamin! Carlos On Fri, Mar 20, 2020 at 6:45 PM Benjamin Kaduk wrote: > Hi Carlos, > > Also inline (but not much left to say!) > > On Sun, Mar 08, 2020 at 06:58:14PM +0100, CARLOS JESUS BERNARDOS CANO > wrote: > > Hi Benjamin, > > > > Thanks a lot for another very good review. Please find my comments inline > > below. > > > > On Thu, Mar 5, 2020 at 6:22 AM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-dmm-pmipv6-dlif-05: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > I have a very boring Discuss point and a somewhat boring point, and > > > expect to change my ballot to Yes once they're resolved. > > > > > > In Section 3.2 we say that pacing mechanisms "MAY" be used to avoid > > > bursts when the CMD is fanning out PBUs, but in Section 6 we say that > > > pacing "SHOULD" be used; please resolve the inconsistency (preferrably > > > with "MUST" as Mirja requests). > > > > > > > [CB] Done in version -06 (to be submitted soon). > > > > > > > > > > Please also include some discussion of privacy considerations (I give > > > some suggestions in the COMMENT). > > > > > > > [CB] OK, I'll do. > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Thanks for this well-written document! It is clearly written, and when > > > multiple approaches exist, does well at laying out the different > options > > > and their pros/cons, as befits an Experimental document. Also, several > > > times I have started to write a comment only to realize that it is > > > answered by the following text :) > > > > > > > [CB] Thanks, very much appreciated. > > > > > > > > > > Section 1 > > > > > > The Distributed Mobility Management (DMM) paradigm aims at > minimizing > > > the impact of currently standardized mobility management solutions > > > which are centralized (at least to a considerable extent). > > > > > > I'd consider saying a little more about which aspects of their > operation > > > are centralized. Perhaps the following paragraph suffices, though. > > > > > > > [CB] I've added another reference to RFC 7333, where this is explained in > > detail. As you mention below, we go a bit into these aspects of > centralized > > operation in the following paragraph, and I personally believe it is > better > > not to add too much text on this aspect (which is covered by RFC 7333). > > Please, let me know if you are not happy with this resolution. > > > > > > > > > > Following this idea, in our proposal, the central anchor is moved to > > > the edge of the network, being deployed in the default gateway of > the > > > mobile node. That is, the first elements that provide IP > > > > > > (side note: Using the singular "central anchor" poses an interesting > > > rhetorical question: is the (formerly) single central anchor being > > > duplicated and spread amongst all access routers, or does there remain > a > > > single central anchor (per MN), just one that moves around along with > > > the MN.) > > > > > > > [CB] The whole idea of the DMM approach specified in this document is > that > > we move from a "single central anchor" to a "multiple distributed > anchors". > > Note that the specified approach allows for a central anchor to be still > > present (and used by an MN for communications where it is more > > appropriate), but this is more an operational decision (probably more in > > scope of RFC 8653). > > > > > > > > > > anchors to retrieve the MN's previous location(s). Also, a key- > > > aspect of network-based DMM, is that a prefix pool belongs > > > exclusively to each MAAR, in the sense that those prefixes are > > > assigned by the MAAR to the MNs attached to it, and they are > routable > > > at that MAAR. > > > > > > It might be worth some statement relating this "ownership" of prefixes > > > to actual mobility events -- e.g., they are assigned to MNs attached to > > > it at that time, but remain with those MNs as mobility occurs, but > > > always remain routable at that MAAR as well as towards the MN itself. > > > > > > [CB] OK, I've added a sentence adopting part of your text. Thanks. > > > > > > > We consider partially distributed schemes, where the data plane only > > > is distributed among access routers similar to MAGs, whereas the > > > > > > nit: I suggest s/the data plane only/only the data plane/ > > > > > > > [CB] OK, thanks. > > > > > > > > > > control plane is kept centralized towards a cardinal node used as > > > information store, but relieved from any route management and MN's > > > data forwarding task. > > > > > > What's the scope of "single" here -- per deployment, per prefix, per > > > MAAR, ...? > > > > > > > [CB] Sorry, I don't get this comment. I don't see "single" mentioned in > the > > quoted textl > > Sorry! I was assuming that the "cardinal node" was a single centralized > information store, and that's the "single" I was trying to ask about. > Re-reading, I would assume that this "cardinal node" is per deployment, so > it may not be worth changing the text if that's in fact the case. > > > > > > > > > P-MAAR (Previous MAAR). When a MN moves to a new point of > attachment > > > a new MAAR might be allocated as its anchor point for future IPv6 > > > prefixes. The MAAR that served the MN prior to new attachment > > > becomes the P-MAAR. It is still the anchor point for the IPv6 > > > prefixes it had allocated to the MN in the past and serves as the > > > > > > (side note? Do we expect those previous allocations to eventually "time > > > out" as sessions using them terminate? Or are the allocations more > > > permanent, with intent to reuse if/when the MN returns to that MAAR?) > > > > > > > [CB] The expectation is that previous allocations will eventually > time-out > > as sessions using them terminate. > > > > > > > > > > Section 3 > > > > > > interest and eventually take the appropriate action. The procedure > > > adopted for the query and the messages exchange sequence might vary > > > to optimize the update latency and/or the signaling overhead. Here > > > > > > nit: wrong pluralization in "messages exchange sequence" > > > > > > > [CB] OK, fixed. > > > > > > > > > > Section 3.1 > > > > > > 3. Since this is an initial registration, the CMD stores a > permanent > > > BCE containing as primary fields the MN-ID, Pref1 and MAAR1's > > > address as a Proxy-CoA. > > > > > > [how permanent is "permanent"?] > > > > > > > [CB] I've removed "permanent" as it is not really needed. The BCE stays > at > > the CMD until the session is de-registered (it is "more permanent" that > the > > BCEs at the P-MAARs). > > > > > > > > > > Section 3.2 > > > > > > 1. When the MN moves from its current point of attachment and > > > attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6 > > > prefix (Pref2), it stores a temporary BCE, and it sends a plain > > > PBU to the CMD for registration. > > > > > > It's not clear to me at this point how MAAR2 has enough information to > > > determine that this will be a "plain" PBU vs. the the PBU used for > > > initial registration. (That said, it's also not clear to me that the > > > send PBU actually differs on the wire, so maybe this is just a > > > rhetorical question. Er, a question of rhetoric, that is.) > > > > > > > [CB] They are actually the same PBUs, as MAAR2 does not know at that > point > > if the MN had been already registered. Both PBUs would be "plain". I've > > removed "plain" and "another" to make it clearer. > > > > > > > > > > 4. The CMD, after receiving the PBA, updates the BCE populating an > > > instance of the P-MAAR list. The P-MAAR list is an additional > > > field on the BCE that contains an element for each P-MAAR > > > involved in the MN's mobility session. The list element > contains > > > the P-MAAR's global address and the prefix it has delegated (see > > > Appendix B for further details). Also, the CMD sends a PBA to > > > the new S-MAAR, containing the previous Proxy-CoA and the prefix > > > anchored to it embedded into a new mobility option called > > > Previous MAAR Option (defined in Section 4.5), so that, upon PBA > > > arrival, a bi-directional tunnel can be established between the > > > two MAARs and new routes are set appropriately to recover the IP > > > flow(s) carrying Pref1. > > > > > > To check my understanding: there will only be one Previous MAAR Option > > > present and it will describe only a single MAAR, which implies that if > > > there are multiple P-MAARs, traffic directed to an arbitrary prefix > > > based at one of them is expected to traverse multiple tunnels from > > > P-MAAR to P-MAAR before making its way to the S-MAAR and the MN? > > > [Hmm, looks like my understanding is wrong. I'd consider making > > > "previous Proxy-CoA" and "the prefix anchored to it" plural to give the > > > reader a hint as to what's coming, though I can understand if there is > > > desire to keep the initial mobility example simple and only gradually > > > introduce the complexity in question.] > > > > > > > [CB] I've been looking at it and changing it back and forth several > times. > > I prefer to keep the initial mobility example. Just to answer your > > question, in general there might be multiple options. This is what the > text > > you point below should indicate (among other things). > > > > > > > For MN's next movements the process is repeated except the number of > > > P-MAARs involved increases (accordingly to the number of prefixes > > > that the MN wishes to maintain). Indeed, once the CMD receives the > > > first PBU from the new S-MAAR, it forwards copies of the PBU to all > > > the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR > > > prior to handover) and in the P-MAARs list. They reply with a PBA > to > > > the CMD, which aggregates them into a single one to notify the > > > S-MAAR, that finally can establish the tunnels with the P-MAARs. > > > > > > I'm not sure I understand the cardinality of P-CoA -- is it one, > > > the single S-MAAR prior to handover, or many, all P-MAARs in the list? > > > > > > > [CB] There are multiple P-CoAs, but current writing might lead to think > > there is only one. One P-CoA is the one listed in the BCE (the one of the > > previously visited MAAR) plus the P-CoAs listed in the P-MAAR list. I've > > rewritten a bit the text trying to make this clearer: "Indeed, once the > CMD > > receives the first PBU from the new S-MAAR, it forwards copies of the PBU > > to all the P-MAARs indicated in the BCE, namely the one registered as > > current P-CoA (i.e., the MAAR prior to handover) plus the ones in the > > P-MAARs list." > > Thanks, this helps a lot! > > > > > > When there are multiple previous MAARs, e.g., k MAARs, a single PBU > > > received by the CMD triggers k outgoing packets from a single > > > incoming packet. This may lead to packet bursts originated from the > > > CMD, albeit to different targets. Pacing mechanisms MAY be > > > introduced to avoid bursts on the outgoing link. > > > > > > I'll defer to my TSV colleagues, but a "SHOULD" feels more comfortable > > > than "MAY" to me, here. > > > > > > > [CB] Actually, based on other comments we have decided to go for "MUST". > > Indeed. (It looks like I forgot to change this comment when I added a note > to my discuss point after I read Mirja's position.) > > > > > > Section 3.3 > > > > > > The handover latency experienced in the approach shown before can be > > > reduced if the P-MAARs are allowed to signal directly their > > > information to the new S-MAAR. This procedure reflects what was > > > described in Section 3.2 up to the moment the P-MAAR receives the > PBU > > > with the P-MAAR option. At that point a P-MAAR is aware of the new > > > > > > nit(?): I think this is the S-MAAR option, not the P-MAAR option? > > > > > > > [CB] Right! Thanks. > > > > > > > > > > S-MAAR including the prefix it is anchoring. This latter PBA does > > > not need to include new options, as the prefix is embedded in the > HNP > > > option and the P-MAAR's address is taken from the message's source > > > address. The CMD is relieved from forwarding the PBA to the S-MAAR, > > > > > > (side note: this assumes there's no NAT or tunneling or similar between > > > MAARs, which seems like a plausible assumption, at least for now.) > > > > > > > [CB] Yes, that's right. > > > > > > > > > > Section 3.4 > > > > > > side. When P-MAARs complete the update, they send a PBA to the CMD > > > to indicate that the operation is concluded and the information is > > > updated in all network nodes. This procedure is obtained from the > > > > > > Is there anything useful to say about behavior on timeout at the CMD > > > (failing to reive a PBA from one or more P-MAARs)? > > > > > > [CB] A new Section 3.6 "Retransmissions and Rate Limiting" has been > added > > (to address also other received comments). I hope this addresses this > > comment. > > It doesn't directly give guidance about the CMD's behavior as a recipient, > but it does give some more context for the expected operation of the > system, which should be enough. > > > > > > Section 3.5 > > > > > > The de-registration mechanism devised for PMIPv6 cannot be used as > is > > > in this solution. The reason for this is that each MAAR handles an > > > > > > nit: s/as is/as-is/ > > > > > > > [CB] Fixed, thanks. > > > > > > > > > > Indeed, when a previous MAAR initiates a de-registration procedure, > > > because the MN is no longer present on the MAAR's access link, it > > > removes the routing state for that (those) prefix(es), that would be > > > deleted by the CMD as well, hence defeating any prefix continuity > > > attempt. The simplest approach to overcome this limitation is to > > > > > > nit(?): s/when/if/. At least, this makes more sense to me if I do that > > > ... maybe I'm just confused. > > > > > > > [CB] OK, fixed. > > > > > > > > > > serving MAAR to de-register the whole MN session. This can be > > > achieved by first removing any layer-2 detachment event, so that de- > > > registration is triggered only when the session lifetime expires, > > > > > > I see that RFC 5213 has some mechanisms for lifetime management, but > > > didn't get to look closely enough to understand how clear the necessary > > > lifetime management will be in the DMM case when there are multiple > > > prefixes registered to a given MN at different MAARs. (Also, 5213 > > > doesn't seem to use the "session lifetime" phrase verbatim.) > > > > > > > [CB] I've replaced "session lifetime" with "binding lifetime" to make it > > more consistent with the terminology used in RFC 5213. Note that > "mobility > > session" is used in RFC 5213. > > Thanks! > > > > > > > > > Section 3.6 > > > > > > requiring special support from the mobile node's IP stack. This > > > document defines the Distributed Logical Interface (DLIF), which is > a > > > software construct that allows to easily hide the change of > > > associated anchors from the mobile node. > > > > > > A software construct in the MAAR, right? > > > > > > > [CB] Yes, I've added "in the MAAR" to the text. > > > > > > > > > > > > > How common is "HMAC" as an abbreviation for "hardware MAC address"? > > > It's also an abbreviation for Hash-based Message Authentication Code, > > > which confuses my poor security-focused brain, though I acknowledge > that > > > this does not necessarily extend to most of the target audience for > this > > > document... > > > > > > > [CB] It is not common. To avoid potential confusions I've removed HMAC > and > > just used MAC, which I think it is sufficient in the scope of this > document > > (as we use LMAC for the logical one). > > > > > > > and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two > > > P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the > > > > > > Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)? > > > > > > > [CB] You are right. Here there was a mistake, as P-MAAR was being mixed > > with anchoring MAAR. I've removed that sentence to keep it clearer. > > > > > > > role of anchoring MAAR for the attached (served) MNs. Each MAAR has > > > one single physical wireless interface. > > > > > > Have we defined "anchoring MAAR" yet? > > > > > > > [CB] We have added a definition to the terminology section. > > > > > > > Also, I assume that the "single physical interface" is just "as > depicted > > > in this example" and not a protocol requirement :) > > > > > > > [CB] Yes, right. > > > > > > > > > > As introduced before, each MN always "sees" multiple logical routers > > > -- one per P-MAAR -- independently of its currently serving MAAR. > > > > > > [same P-MAAR vs. S-MAAR split as above] > > > > > > > [CB] Right, fixed by replacing P-MAAR with anchoring MAAR. > > > > > > > > > > > > by the serving MAAR (MAAR2) configuring an additional distributed > > > logical interface: mn1mar1, which behaves exactly as the logical > > > interface configured by MAAR1 when MN1 was attached to it. This > > > > > > nit(?): "exactly" is asking for pedants to try and poke holes in the > > > claimed perfection. > > > > > > > [CB] Right, I removed "exactly". > > > > > > > > > > deprecated). The goal is to deprecate the prefixes delegated by > > > these MAARs (which will be no longer serving the MN). Note that on- > > > > > > nit(?): s/which will be no longer/so that they will no longer be/, IIUC > > > > > > > [CB] Fixed. > > > > > > > > > > Section 4.1 > > > > > > The intdir reviewer's comments regarding the flag bits seem apropos (I > > > presume they were allocated by other extensions to 5213, but we should > > > say something about it). > > > > > > > [CB] OK, I'll address this in my response to the intdir review. > > It looks like the plan is to reference the IANA registry for the flags? > That sounds good, though I assume it's still only in the editor's copy. > > > > > > > > > > > > A new flag (D) is included in the Proxy Binding Update to indicate > > > that the Proxy Binding Update is coming from a Mobility Anchor and > > > > > > "D" is for "DMM", I trust? It could be worth mentioning. > > > > > > [CB] Yes, done. > > > > > > > > > > > > > > Is the D bit set for the PBUs sent from CMD to P-MAAR as well? > > > > > > > [CB] Yes, I've fixed that. > > > > > > > (I see that the PBA description uses a slightly different formulation > to > > > cover the 'D' bit; is there a reason to diverge?) > > > > > > > [CB] No reason. I've updated the text to use the same formulation. > > > > > > > > > > Mobility Options > > > > > > Variable-length field of such length that the complete Mobility > > > Header is an integer multiple of 8 octets long. This field > > > contains zero or more TLV-encoded mobility options. The encoding > > > and format of defined options are described in Section 6.2 of > > > [RFC6275]. The MAAR MUST ignore and skip any options that it > does > > > not understand. > > > > > > MAARs that *receive* PBUs must be P-MAARs, right? > > > > > > > [CB] Yes, but also a CMD. Therefore I've replaced "MAAR" with "receiving > > node". > > > > > > > Section 4.2 > > > > > > MAAR (D) > > > > > > The D is set to indicate that the sender of the message supports > > > operating as a Mobility Anchor and Access Router. When a MAG > that > > > does not support the extensions described in this document > > > receives a message with the D-Flag set, it MUST ignore the > message > > > and an error MUST be returned. > > > > > > Is the CMD considered a MAAR for this purpose? > > > > > > > [CB] I've replaced "operating as a Mobility Anchor and Access Router" > with > > "operating as a MAAR or a CMD". > > > > > > > contains zero or more TLV-encoded mobility options. The encoding > > > and format of defined options are described in Section 6.2 of > > > [RFC6275]. The MAAR MUST ignore and skip any options that it > does > > > not understand. > > > > > > What about the CMD? > > > > > > > [CB] Same.. Therefore I've replaced "MAAR" with "receiving node". > > > > > > > > > > Section 4.3, 4.4 > > > > > > Prefix Length > > > > > > 8-bit unsigned integer indicating the prefix length of the IPv6 > > > prefix contained in the option. > > > > > > Anchored Prefix > > > > > > A sixteen-byte field containing the mobile node's IPv6 Anchored > > > Prefix. Only the first Prefix Length bytes are valid for the > > > Anchored Prefix. The rest of the bytes MUST be ignored. > > > > > > Is the prefix length bits or bytes? > > > > > > > [CB] Bits. Fixed (also mentioned by another review). > > > > > > > > > > Section 4.4 > > > > > > Is this also used to convey "local" prefixes in the PBA from CMD to > > > S-MAAR? (If not, how does the S-MAAR know to advertise them from its > > > DLIF?) > > > > > > > [CB] Yes, this is right. I've rewritten the text to reflect it. > > > > > > > > Section 4.5 > > > > > > What's the alignment requirement? > > > (There's no need to put in a Reserved octet to keep things word > > > aligned?) > > > > > > > [CB] You are right. And this is embarrassing, as the internal code we use > > is actually using the format with the extra reserved byte that was not > > reflected in the document. > > > > > > > Prefix Length > > > > > > 8-bit unsigned integer indicating the prefix length of the IPv6 > > > prefix contained in the option. > > > [...] > > > Home Network Prefix > > > > > > A sixteen-byte field containing the mobile node's IPv6 Home > > > Network Prefix. Only the first Prefix Length bytes are valid for > > > the mobile node's IPv6 Home Network Prefix. The rest of the > bytes > > > MUST be ignored. > > > > > > [is the prefix length bits or bytes?] > > > > > > > [CB] Bits. Fixed. > > > > > > > > > > Section 4.6 > > > > > > Is there an alignment requirement for this option? > > > > > > > [CB] Yes, added. > > > > > > > > > > This new option is defined for use with the Proxy Binding Update and > > > Proxy Binding Acknowledgement messages exchanged between the CMD and > > > > > > When is this option used in a PBA? > > > > > > > [CB] Right, it is only used in a PBU. Fixed. > > > > > > > > > > Section 4.7 > > > > > > A new DLIF Link-local Address option is defined for use with the > > > Proxy Binding Update and Proxy Binding Acknowledgment messages > > > exchanged between MAARs. This option is used for exchanging the > > > > > > MAARs but not CMDs? > > > When is this used in the PBU? > > > > > > > [CB] Also CMDs. And only in PBA. Fixed. > > > > > > > > > > Section 4.8 > > > > > > A new DLIF Link-layer Address option is defined for use with the > > > Proxy Binding Update and Proxy Binding Acknowledgment messages > > > exchanged between MAARs. This option is used for exchanging the > > > > > > MAARs but not CMDs? > > > When is this used in the PBU? > > > > > > > [CB] Same as before. > > > > > > > > > > Section 6 > > > > > > Unfortunately it seems that RFC 5213 does not include any privacy > > > considerations discussion. While the privacy properties of this > > > protocol bear similarities to those of RFC 5213, it seems that there > are > > > also some significant differences, so I do think it is important to > > > produce some documentation of privacy considerations for this document. > > > The main factor would, of cousre, be tracking which entities obtain > > > updates/information about the location of the MN, what those entities > > > are expected to do with that data, and how trusted they are to be > proper > > > custodians of it. Other factors may exist as well, including the > > > potential for side-channel information leakage, e.g., due to traffic > > > analysis. There might also be a reverse situation where exposing the > > > link-layer address(es) of a P-MAAR have privacy considerations, though > I > > > don't have anything particular in mind at the moment. > > > > > > > [CB] OK, I see your point. I've tried to add something in version -06. > Let > > me know if you think it is sufficient (I tried to keep it short and > simple, > > while still addressing your point). > > I think it covers the key points. Since all the parties are highly trusted > anyway, we don't need to go into great detail. > > > > > > > > > security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended > > > that the signaling messages, Proxy Binding Update and Proxy Binding > > > Acknowledgment, exchanged between the MAARs are protected using > IPsec > > > using the established security association between them. This > > > > > > This is essentially unchanged from 5213, just with different names for > > > the endpoints, right, and so the existing guidance/experiences apply? > > > > > > > [CB] Yes, it should apply. We haven't identified anything different. > > > > > > > > > > I think we should also say something about all MAARs and the CMD being > > > trusted parties. We should also say something about the authorization > > > model (I assume it's just "all trusted parties are trusted to perform > > > all operations relevant to their role", but that's still useful to > say). > > > > > > > [CB] OK, I've added a sentence on that. > > > > > > > > > > When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of > a > > > single PBU to multiple previous MAARs. In situations of many fast > > > handovers (e.g., with vehicular networks), there may exist multiple > > > previous (e.g., k) MAARs exist. In this situation, the CMD creates > k > > > > > > nit: remove the redundant "exist" > > > > > > > [CB] Done. > > > > > > > > > > When the CMD acts as MAAR locator, mobility signaling (PBAs) is > > > exchanged between P-MAARs and current S-MAAR. This requires > security > > > associations to exist between the involved MAARs (in addition to the > > > ones needed with the CMD). > > > > > > Is this relevant because of scaling/resource-consumption concerns or > > > keying/trust ones? > > > > > > > [CB] This is relevant because RFC 5213 uses a model in which signalling > is > > exchanged only between LMA (the anchor) and MAGs (the access routers), > > while in this document there are some operation modes that also involve > > signalling between MAARs (the access routers). This was just to highlight > > this point (it is related to the point you made before about the trust > > model). > > Okay, thanks for the clarification. > > > > > > > > > Appendix A.5 > > > > > > not implement existing mobility protocols. Furthermore, a DMM > > > solution SHOULD work across different networks, possibly operated as > > > separate administrative domains, when the needed mobility management > > > > > > Hmm, separate administrative domains makes the risk of NAT relatively > > > higher (per previous comment about NAT). > > > > > > intervention. The partially distributed DMM solution can be > deployed > > > across different domains with trust agreements if the CMDs of the > > > operators are enabled to transfer context from one node to another. > > > > > > It would probably be worth expounding a bit more about this scenario > and > > > the necessary trust/authorization relationships, in the security > > > considerations. > > > > > > [CB] As per other comment from IESG evaluation I've removed the two > > appendixes. > > > > Huge thanks for your very good points! > > And thanks for all the updates! > I will go update my ballot position now. > > -Ben > --00000000000047c21605a14db499 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot Benjamin!

Carlos

On F= ri, Mar 20, 2020 at 6:45 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Carlos,

Also inline (but not much left to say!)

On Sun, Mar 08, 2020 at 06:58:14PM +0100, CARLOS JESUS BERNARDOS CANO wrote= :
> Hi Benjamin,
>
> Thanks a lot for another very good review. Please find my comments inl= ine
> below.
>
> On Thu, Mar 5, 2020 at 6:22 AM Benjamin Kaduk via Datatracker <
> noreply@ietf.org= > wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dmm-pmipv6-dlif-05: Discuss
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.org/d= oc/draft-ietf-dmm-pmipv6-dlif/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > I have a very boring Discuss point and a somewhat boring point, a= nd
> > expect to change my ballot to Yes once they're resolved.
> >
> > In Section 3.2 we say that pacing mechanisms "MAY" be u= sed to avoid
> > bursts when the CMD is fanning out PBUs, but in Section 6 we say = that
> > pacing "SHOULD" be used; please resolve the inconsisten= cy (preferrably
> > with "MUST" as Mirja requests).
> >
>
> [CB] Done in version -06 (to be submitted soon).
>
>
> >
> > Please also include some discussion of privacy considerations (I = give
> > some suggestions in the COMMENT).
> >
>
> [CB] OK, I'll do.
>
>
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > Thanks for this well-written document!=C2=A0 It is clearly writte= n, and when
> > multiple approaches exist, does well at laying out the different = options
> > and their pros/cons, as befits an Experimental document.=C2=A0 Al= so, several
> > times I have started to write a comment only to realize that it i= s
> > answered by the following text :)
> >
>
> [CB] Thanks, very much appreciated.
>
>
> >
> > Section 1
> >
> >=C2=A0 =C2=A0 The Distributed Mobility Management (DMM) paradigm a= ims at minimizing
> >=C2=A0 =C2=A0 the impact of currently standardized mobility manage= ment solutions
> >=C2=A0 =C2=A0 which are centralized (at least to a considerable ex= tent).
> >
> > I'd consider saying a little more about which aspects of thei= r operation
> > are centralized.=C2=A0 Perhaps the following paragraph suffices, = though.
> >
>
> [CB] I've added another reference to RFC 7333, where this is expla= ined in
> detail. As you mention below, we go a bit into these aspects of centra= lized
> operation in the following paragraph, and I personally believe it is b= etter
> not to add too much text on this aspect (which is covered by RFC 7333)= .
> Please, let me know if you are not happy with this resolution.
>
>
> >
> >=C2=A0 =C2=A0 Following this idea, in our proposal, the central an= chor is moved to
> >=C2=A0 =C2=A0 the edge of the network, being deployed in the defau= lt gateway of the
> >=C2=A0 =C2=A0 mobile node.=C2=A0 That is, the first elements that = provide IP
> >
> > (side note: Using the singular "central anchor" poses a= n interesting
> > rhetorical question: is the (formerly) single central anchor bein= g
> > duplicated and spread amongst all access routers, or does there r= emain a
> > single central anchor (per MN), just one that moves around along = with
> > the MN.)
> >
>
> [CB] The whole idea of the DMM approach specified in this document is = that
> we move from a "single central anchor" to a "multiple d= istributed anchors".
> Note that the specified approach allows for a central anchor to be sti= ll
> present (and used by an MN for communications where it is more
> appropriate), but this is more an operational decision (probably more = in
> scope of RFC 8653).
>
>
> >
> >=C2=A0 =C2=A0 anchors to retrieve the MN's previous location(s= ).=C2=A0 Also, a key-
> >=C2=A0 =C2=A0 aspect of network-based DMM, is that a prefix pool b= elongs
> >=C2=A0 =C2=A0 exclusively to each MAAR, in the sense that those pr= efixes are
> >=C2=A0 =C2=A0 assigned by the MAAR to the MNs attached to it, and = they are routable
> >=C2=A0 =C2=A0 at that MAAR.
> >
> > It might be worth some statement relating this "ownership&qu= ot; of prefixes
> > to actual mobility events -- e.g., they are assigned to MNs attac= hed to
> > it at that time, but remain with those MNs as mobility occurs, bu= t
> > always remain routable at that MAAR as well as towards the MN its= elf.
> >
> > [CB] OK, I've added a sentence adopting part of your text. Th= anks.
>
>
> >=C2=A0 =C2=A0 We consider partially distributed schemes, where the= data plane only
> >=C2=A0 =C2=A0 is distributed among access routers similar to MAGs,= whereas the
> >
> > nit: I suggest s/the data plane only/only the data plane/
> >
>
> [CB] OK, thanks.
>
>
> >
> >=C2=A0 =C2=A0 control plane is kept centralized towards a cardinal= node used as
> >=C2=A0 =C2=A0 information store, but relieved from any route manag= ement and MN's
> >=C2=A0 =C2=A0 data forwarding task.
> >
> > What's the scope of "single" here -- per deployment= , per prefix, per
> > MAAR, ...?
> >
>
> [CB] Sorry, I don't get this comment. I don't see "single= " mentioned in the
> quoted textl

Sorry!=C2=A0 I was assuming that the "cardinal node" was a single= centralized
information store, and that's the "single" I was trying to as= k about.
Re-reading, I would assume that this "cardinal node" is per deplo= yment, so
it may not be worth changing the text if that's in fact the case.

>
> >
> >=C2=A0 =C2=A0 P-MAAR (Previous MAAR).=C2=A0 When a MN moves to a n= ew point of attachment
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0a new MAAR might be allocated as its an= chor point for future IPv6
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefixes.=C2=A0 The MAAR that served th= e MN prior to new attachment
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0becomes the P-MAAR.=C2=A0 It is still t= he anchor point for the IPv6
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefixes it had allocated to the MN in = the past and serves as the
> >
> > (side note? Do we expect those previous allocations to eventually= "time
> > out" as sessions using them terminate?=C2=A0 Or are the allo= cations more
> > permanent, with intent to reuse if/when the MN returns to that MA= AR?)
> >
>
> [CB] The expectation is that previous allocations will eventually time= -out
> as sessions using them terminate.
>
>
> >
> > Section 3
> >
> >=C2=A0 =C2=A0 interest and eventually take the appropriate action.= =C2=A0 The procedure
> >=C2=A0 =C2=A0 adopted for the query and the messages exchange sequ= ence might vary
> >=C2=A0 =C2=A0 to optimize the update latency and/or the signaling = overhead.=C2=A0 Here
> >
> > nit: wrong pluralization in "messages exchange sequence"= ;
> >
>
> [CB] OK, fixed.
>
>
> >
> > Section 3.1
> >
> >=C2=A0 =C2=A0 3.=C2=A0 Since this is an initial registration, the = CMD stores a permanent
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 BCE containing as primary fields the M= N-ID, Pref1 and MAAR1's
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 address as a Proxy-CoA.
> >
> > [how permanent is "permanent"?]
> >
>
> [CB] I've removed "permanent" as it is not really needed= . The BCE stays at
> the CMD until the session is de-registered (it is "more permanent= " that the
> BCEs at the P-MAARs).
>
>
> >
> > Section 3.2
> >
> >=C2=A0 =C2=A0 1.=C2=A0 When the MN moves from its current point of= attachment and
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 attaches to MAAR2 (now the S-MAAR), MA= AR2 reserves another IPv6
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix (Pref2), it stores a temporary = BCE, and it sends a plain
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 PBU to the CMD for registration.
> >
> > It's not clear to me at this point how MAAR2 has enough infor= mation to
> > determine that this will be a "plain" PBU vs. the the P= BU used for
> > initial registration.=C2=A0 (That said, it's also not clear t= o me that the
> > send PBU actually differs on the wire, so maybe this is just a > > rhetorical question.=C2=A0 Er, a question of rhetoric, that is.)<= br> > >
>
> [CB] They are actually the same PBUs, as MAAR2 does not know at that p= oint
> if the MN had been already registered. Both PBUs would be "plain&= quot;. I've
> removed "plain" and "another" to make it clearer.<= br> >
>
> >
> >=C2=A0 =C2=A0 4.=C2=A0 The CMD, after receiving the PBA, updates t= he BCE populating an
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 instance of the P-MAAR list.=C2=A0 The= P-MAAR list is an additional
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 field on the BCE that contains an elem= ent for each P-MAAR
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 involved in the MN's mobility sess= ion.=C2=A0 The list element contains
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the P-MAAR's global address and th= e prefix it has delegated (see
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Appendix B for further details).=C2=A0= Also, the CMD sends a PBA to
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 the new S-MAAR, containing the previou= s Proxy-CoA and the prefix
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 anchored to it embedded into a new mob= ility option called
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Previous MAAR Option (defined in Secti= on 4.5), so that, upon PBA
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 arrival, a bi-directional tunnel can b= e established between the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 two MAARs and new routes are set appro= priately to recover the IP
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 flow(s) carrying Pref1.
> >
> > To check my understanding: there will only be one Previous MAAR O= ption
> > present and it will describe only a single MAAR, which implies th= at if
> > there are multiple P-MAARs, traffic directed to an arbitrary pref= ix
> > based at one of them is expected to traverse multiple tunnels fro= m
> > P-MAAR to P-MAAR before making its way to the S-MAAR and the MN?<= br> > > [Hmm, looks like my understanding is wrong.=C2=A0 I'd conside= r making
> > "previous Proxy-CoA" and "the prefix anchored to i= t" plural to give the
> > reader a hint as to what's coming, though I can understand if= there is
> > desire to keep the initial mobility example simple and only gradu= ally
> > introduce the complexity in question.]
> >
>
> [CB] I've been looking at it and changing it back and forth severa= l times.
> I prefer to keep the initial mobility example. Just to answer your
> question, in general there might be multiple options. This is what the= text
> you point below should indicate (among other things).
>
>
> >=C2=A0 =C2=A0 For MN's next movements the process is repeated = except the number of
> >=C2=A0 =C2=A0 P-MAARs involved increases (accordingly to the numbe= r of prefixes
> >=C2=A0 =C2=A0 that the MN wishes to maintain).=C2=A0 Indeed, once = the CMD receives the
> >=C2=A0 =C2=A0 first PBU from the new S-MAAR, it forwards copies of= the PBU to all
> >=C2=A0 =C2=A0 the P-MAARs indicated in the BCE as current P-CoA (i= .e., the MAAR
> >=C2=A0 =C2=A0 prior to handover) and in the P-MAARs list.=C2=A0 Th= ey reply with a PBA to
> >=C2=A0 =C2=A0 the CMD, which aggregates them into a single one to = notify the
> >=C2=A0 =C2=A0 S-MAAR, that finally can establish the tunnels with = the P-MAARs.
> >
> > I'm not sure I understand the cardinality of P-CoA -- is it o= ne,
> > the single S-MAAR prior to handover, or many, all P-MAARs in the = list?
> >
>
> [CB] There are multiple P-CoAs, but current writing might lead to thin= k
> there is only one. One P-CoA is the one listed in the BCE (the one of = the
> previously visited MAAR) plus the P-CoAs listed in the P-MAAR list. I&= #39;ve
> rewritten a bit the text trying to make this clearer: "Indeed, on= ce the CMD
> receives the first PBU from the new S-MAAR, it forwards copies of the = PBU
> to all the P-MAARs indicated in the BCE, namely the one registered as<= br> > current P-CoA (i.e., the MAAR prior to handover) plus the ones in the<= br> > P-MAARs list."

Thanks, this helps a lot!

>
> >=C2=A0 =C2=A0 When there are multiple previous MAARs, e.g., k MAAR= s, a single PBU
> >=C2=A0 =C2=A0 received by the CMD triggers k outgoing packets from= a single
> >=C2=A0 =C2=A0 incoming packet.=C2=A0 This may lead to packet burst= s originated from the
> >=C2=A0 =C2=A0 CMD, albeit to different targets.=C2=A0 Pacing mecha= nisms MAY be
> >=C2=A0 =C2=A0 introduced to avoid bursts on the outgoing link.
> >
> > I'll defer to my TSV colleagues, but a "SHOULD" fee= ls more comfortable
> > than "MAY" to me, here.
> >
>
> [CB] Actually, based on other comments we have decided to go for "= ;MUST".

Indeed.=C2=A0 (It looks like I forgot to change this comment when I added a= note
to my discuss point after I read Mirja's position.)

>
> > Section 3.3
> >
> >=C2=A0 =C2=A0 The handover latency experienced in the approach sho= wn before can be
> >=C2=A0 =C2=A0 reduced if the P-MAARs are allowed to signal directl= y their
> >=C2=A0 =C2=A0 information to the new S-MAAR.=C2=A0 This procedure = reflects what was
> >=C2=A0 =C2=A0 described in Section 3.2 up to the moment the P-MAAR= receives the PBU
> >=C2=A0 =C2=A0 with the P-MAAR option.=C2=A0 At that point a P-MAAR= is aware of the new
> >
> > nit(?): I think this is the S-MAAR option, not the P-MAAR option?=
> >
>
> [CB] Right! Thanks.
>
>
> >
> >=C2=A0 =C2=A0 S-MAAR including the prefix it is anchoring.=C2=A0 T= his latter PBA does
> >=C2=A0 =C2=A0 not need to include new options, as the prefix is em= bedded in the HNP
> >=C2=A0 =C2=A0 option and the P-MAAR's address is taken from th= e message's source
> >=C2=A0 =C2=A0 address.=C2=A0 The CMD is relieved from forwarding t= he PBA to the S-MAAR,
> >
> > (side note: this assumes there's no NAT or tunneling or simil= ar between
> > MAARs, which seems like a plausible assumption, at least for now.= )
> >
>
> [CB] Yes, that's right.
>
>
> >
> > Section 3.4
> >
> >=C2=A0 =C2=A0 side.=C2=A0 When P-MAARs complete the update, they s= end a PBA to the CMD
> >=C2=A0 =C2=A0 to indicate that the operation is concluded and the = information is
> >=C2=A0 =C2=A0 updated in all network nodes.=C2=A0 This procedure i= s obtained from the
> >
> > Is there anything useful to say about behavior on timeout at the = CMD
> > (failing to reive a PBA from one or more P-MAARs)?
> >
> > [CB] A new Section 3.6 "Retransmissions and Rate Limiting&qu= ot; has been added
> (to address also other received comments). I hope this addresses this<= br> > comment.

It doesn't directly give guidance about the CMD's behavior as a rec= ipient,
but it does give some more context for the expected operation of the
system, which should be enough.

>
> > Section 3.5
> >
> >=C2=A0 =C2=A0 The de-registration mechanism devised for PMIPv6 can= not be used as is
> >=C2=A0 =C2=A0 in this solution.=C2=A0 The reason for this is that = each MAAR handles an
> >
> > nit: s/as is/as-is/
> >
>
> [CB] Fixed, thanks.
>
>
> >
> >=C2=A0 =C2=A0 Indeed, when a previous MAAR initiates a de-registra= tion procedure,
> >=C2=A0 =C2=A0 because the MN is no longer present on the MAAR'= s access link, it
> >=C2=A0 =C2=A0 removes the routing state for that (those) prefix(es= ), that would be
> >=C2=A0 =C2=A0 deleted by the CMD as well, hence defeating any pref= ix continuity
> >=C2=A0 =C2=A0 attempt.=C2=A0 The simplest approach to overcome thi= s limitation is to
> >
> > nit(?): s/when/if/.=C2=A0 At least, this makes more sense to me i= f I do that
> > ... maybe I'm just confused.
> >
>
> [CB] OK, fixed.
>
>
> >
> >=C2=A0 =C2=A0 serving MAAR to de-register the whole MN session.=C2= =A0 This can be
> >=C2=A0 =C2=A0 achieved by first removing any layer-2 detachment ev= ent, so that de-
> >=C2=A0 =C2=A0 registration is triggered only when the session life= time expires,
> >
> > I see that RFC 5213 has some mechanisms for lifetime management, = but
> > didn't get to look closely enough to understand how clear the= necessary
> > lifetime management will be in the DMM case when there are multip= le
> > prefixes registered to a given MN at different MAARs.=C2=A0 (Also= , 5213
> > doesn't seem to use the "session lifetime" phrase v= erbatim.)
> >
>
> [CB] I've replaced "session lifetime" with "binding= lifetime" to make it
> more consistent with the terminology used in RFC 5213. Note that "= ;mobility
> session" is used in RFC 5213.

Thanks!

>
> >
> > Section 3.6
> >
> >=C2=A0 =C2=A0 requiring special support from the mobile node's= IP stack.=C2=A0 This
> >=C2=A0 =C2=A0 document defines the Distributed Logical Interface (= DLIF), which is a
> >=C2=A0 =C2=A0 software construct that allows to easily hide the ch= ange of
> >=C2=A0 =C2=A0 associated anchors from the mobile node.
> >
> > A software construct in the MAAR, right?
> >
>
> [CB] Yes, I've added "in the MAAR" to the text.
>
>
> >
> >
> > How common is "HMAC" as an abbreviation for "hardw= are MAC address"?
> > It's also an abbreviation for Hash-based Message Authenticati= on Code,
> > which confuses my poor security-focused brain, though I acknowled= ge that
> > this does not necessarily extend to most of the target audience f= or this
> > document...
> >
>
> [CB] It is not common. To avoid potential confusions I've removed = HMAC and
> just used MAC, which I think it is sufficient in the scope of this doc= ument
> (as we use LMAC for the logical one).
>
>
> >=C2=A0 =C2=A0 and MN3, while MAAR2 is serving MN1.=C2=A0 MN1, MN2 = and MN3 have two
> >=C2=A0 =C2=A0 P-MAARs: MAAR1 and MAAR2.=C2=A0 Note that a serving = MAAR always plays the
> >
> > Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)? > >
>
> [CB] You are right. Here there was a mistake, as P-MAAR was being mixe= d
> with anchoring MAAR. I've removed that sentence to keep it clearer= .
>
>
> >=C2=A0 =C2=A0 role of anchoring MAAR for the attached (served) MNs= .=C2=A0 Each MAAR has
> >=C2=A0 =C2=A0 one single physical wireless interface.
> >
> > Have we defined "anchoring MAAR" yet?
> >
>
> [CB] We have added a definition to the terminology section.
>
>
> > Also, I assume that the "single physical interface" is = just "as depicted
> > in this example" and not a protocol requirement :)
> >
>
> [CB] Yes, right.
>
>
> >
> >=C2=A0 =C2=A0 As introduced before, each MN always "sees"= ; multiple logical routers
> >=C2=A0 =C2=A0 -- one per P-MAAR -- independently of its currently = serving MAAR.
> >
> > [same P-MAAR vs. S-MAAR split as above]
> >
>
> [CB] Right, fixed by replacing P-MAAR with anchoring MAAR.
>
>
>
> >
> >=C2=A0 =C2=A0 by the serving MAAR (MAAR2) configuring an additiona= l distributed
> >=C2=A0 =C2=A0 logical interface: mn1mar1, which behaves exactly as= the logical
> >=C2=A0 =C2=A0 interface configured by MAAR1 when MN1 was attached = to it.=C2=A0 This
> >
> > nit(?): "exactly" is asking for pedants to try and poke= holes in the
> > claimed perfection.
> >
>
> [CB] Right, I removed "exactly".
>
>
> >
> >=C2=A0 =C2=A0 deprecated).=C2=A0 The goal is to deprecate the pref= ixes delegated by
> >=C2=A0 =C2=A0 these MAARs (which will be no longer serving the MN)= .=C2=A0 Note that on-
> >
> > nit(?): s/which will be no longer/so that they will no longer be/= , IIUC
> >
>
> [CB] Fixed.
>
>
> >
> > Section 4.1
> >
> > The intdir reviewer's comments regarding the flag bits seem a= propos (I
> > presume they were allocated by other extensions to 5213, but we s= hould
> > say something about it).
> >
>
> [CB] OK, I'll address this in my response to the intdir review.
It looks like the plan is to reference the IANA registry for the flags?
That sounds good, though I assume it's still only in the editor's c= opy.

>
> >
> >
> >=C2=A0 =C2=A0 A new flag (D) is included in the Proxy Binding Upda= te to indicate
> >=C2=A0 =C2=A0 that the Proxy Binding Update is coming from a Mobil= ity Anchor and
> >
> > "D" is for "DMM", I trust?=C2=A0 It could be = worth mentioning.
>
>
> [CB] Yes, done.
>
>
> >
>
>
> > Is the D bit set for the PBUs sent from CMD to P-MAAR as well? > >
>
> [CB] Yes, I've fixed that.
>
>
> > (I see that the PBA description uses a slightly different formula= tion to
> > cover the 'D' bit; is there a reason to diverge?)
> >
>
> [CB] No reason. I've updated the text to use the same formulation.=
>
>
> >
> >=C2=A0 =C2=A0 Mobility Options
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Variable-length field of such length th= at the complete Mobility
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Header is an integer multiple of 8 octe= ts long.=C2=A0 This field
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0contains zero or more TLV-encoded mobil= ity options.=C2=A0 The encoding
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and format of defined options are descr= ibed in Section 6.2 of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6275].=C2=A0 The MAAR MUST ignore a= nd skip any options that it does
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0not understand.
> >
> > MAARs that *receive* PBUs must be P-MAARs, right?
> >
>
> [CB] Yes, but also a CMD. Therefore I've replaced "MAAR"= with "receiving
> node".
>
>
> > Section 4.2
> >
> >=C2=A0 =C2=A0 MAAR (D)
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0The D is set to indicate that the sende= r of the message supports
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0operating as a Mobility Anchor and Acce= ss Router.=C2=A0 When a MAG that
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0does not support the extensions describ= ed in this document
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0receives a message with the D-Flag set,= it MUST ignore the message
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and an error MUST be returned.
> >
> > Is the CMD considered a MAAR for this purpose?
> >
>
> [CB] I've replaced "operating as a Mobility Anchor and Access= Router" with
> "operating as a MAAR or a CMD".
>
>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0contains zero or more TLV-encoded mobil= ity options.=C2=A0 The encoding
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and format of defined options are descr= ibed in Section 6.2 of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC6275].=C2=A0 The MAAR MUST ignore a= nd skip any options that it does
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0not understand.
> >
> > What about the CMD?
> >
>
> [CB] Same.. Therefore I've replaced "MAAR" with "re= ceiving node".
>
>
> >
> > Section 4.3, 4.4
> >
> >=C2=A0 =C2=A0 Prefix Length
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A08-bit unsigned integer indicating the p= refix length of the IPv6
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix contained in the option.
> >
> >=C2=A0 =C2=A0 Anchored Prefix
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0A sixteen-byte field containing the mob= ile node's IPv6 Anchored
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Prefix.=C2=A0 Only the first Prefix Len= gth bytes are valid for the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Anchored Prefix.=C2=A0 The rest of the = bytes MUST be ignored.
> >
> > Is the prefix length bits or bytes?
> >
>
> [CB] Bits. Fixed (also mentioned by another review).
>
>
> >
> > Section 4.4
> >
> > Is this also used to convey "local" prefixes in the PBA= from CMD to
> > S-MAAR?=C2=A0 (If not, how does the S-MAAR know to advertise them= from its
> > DLIF?)
> >
>
> [CB] Yes, this is right. I've rewritten the text to reflect it. >
> >
> > Section 4.5
> >
> > What's the alignment requirement?
> > (There's no need to put in a Reserved octet to keep things wo= rd
> > aligned?)
> >
>
> [CB] You are right. And this is embarrassing, as the internal code we = use
> is actually using the format with the extra reserved byte that was not=
> reflected in the document.
>
>
> >=C2=A0 =C2=A0 Prefix Length
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A08-bit unsigned integer indicating the p= refix length of the IPv6
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix contained in the option.
> >=C2=A0 =C2=A0 [...]
> >=C2=A0 =C2=A0 Home Network Prefix
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0A sixteen-byte field containing the mob= ile node's IPv6 Home
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Network Prefix.=C2=A0 Only the first Pr= efix Length bytes are valid for
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the mobile node's IPv6 Home Network= Prefix.=C2=A0 The rest of the bytes
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be ignored.
> >
> > [is the prefix length bits or bytes?]
> >
>
> [CB] Bits. Fixed.
>
>
> >
> > Section 4.6
> >
> > Is there an alignment requirement for this option?
> >
>
> [CB] Yes, added.
>
>
> >
> >=C2=A0 =C2=A0 This new option is defined for use with the Proxy Bi= nding Update and
> >=C2=A0 =C2=A0 Proxy Binding Acknowledgement messages exchanged bet= ween the CMD and
> >
> > When is this option used in a PBA?
> >
>
> [CB] Right, it is only used in a PBU. Fixed.
>
>
> >
> > Section 4.7
> >
> >=C2=A0 =C2=A0 A new DLIF Link-local Address option is defined for = use with the
> >=C2=A0 =C2=A0 Proxy Binding Update and Proxy Binding Acknowledgmen= t messages
> >=C2=A0 =C2=A0 exchanged between MAARs.=C2=A0 This option is used f= or exchanging the
> >
> > MAARs but not CMDs?
> > When is this used in the PBU?
> >
>
> [CB] Also CMDs. And only in PBA. Fixed.
>
>
> >
> > Section 4.8
> >
> >=C2=A0 =C2=A0 A new DLIF Link-layer Address option is defined for = use with the
> >=C2=A0 =C2=A0 Proxy Binding Update and Proxy Binding Acknowledgmen= t messages
> >=C2=A0 =C2=A0 exchanged between MAARs.=C2=A0 This option is used f= or exchanging the
> >
> > MAARs but not CMDs?
> > When is this used in the PBU?
> >
>
> [CB] Same as before.
>
>
> >
> > Section 6
> >
> > Unfortunately it seems that RFC 5213 does not include any privacy=
> > considerations discussion.=C2=A0 While the privacy properties of = this
> > protocol bear similarities to those of RFC 5213, it seems that th= ere are
> > also some significant differences, so I do think it is important = to
> > produce some documentation of privacy considerations for this doc= ument.
> > The main factor would, of cousre, be tracking which entities obta= in
> > updates/information about the location of the MN, what those enti= ties
> > are expected to do with that data, and how trusted they are to be= proper
> > custodians of it.=C2=A0 Other factors may exist as well, includin= g the
> > potential for side-channel information leakage, e.g., due to traf= fic
> > analysis.=C2=A0 There might also be a reverse situation where exp= osing the
> > link-layer address(es) of a P-MAAR have privacy considerations, t= hough I
> > don't have anything particular in mind at the moment.
> >
>
> [CB] OK, I see your point. I've tried to add something in version = -06. Let
> me know if you think it is sufficient (I tried to keep it short and si= mple,
> while still addressing your point).

I think it covers the key points.=C2=A0 Since all the parties are highly tr= usted
anyway, we don't need to go into great detail.

>
> >
> >=C2=A0 =C2=A0 security concerns of Proxy Mobile IPv6 [RFC5213].=C2= =A0 It is recommended
> >=C2=A0 =C2=A0 that the signaling messages, Proxy Binding Update an= d Proxy Binding
> >=C2=A0 =C2=A0 Acknowledgment, exchanged between the MAARs are prot= ected using IPsec
> >=C2=A0 =C2=A0 using the established security association between t= hem.=C2=A0 This
> >
> > This is essentially unchanged from 5213, just with different name= s for
> > the endpoints, right, and so the existing guidance/experiences ap= ply?
> >
>
> [CB] Yes, it should apply. We haven't identified anything differen= t.
>
>
> >
> > I think we should also say something about all MAARs and the CMD = being
> > trusted parties.=C2=A0 We should also say something about the aut= horization
> > model (I assume it's just "all trusted parties are trust= ed to perform
> > all operations relevant to their role", but that's still= useful to say).
> >
>
> [CB] OK, I've added a sentence on that.
>
>
> >
> >=C2=A0 =C2=A0 When the CMD acts as a PBU/PBA relay, the CMD may ac= t as a relay of a
> >=C2=A0 =C2=A0 single PBU to multiple previous MAARs.=C2=A0 In situ= ations of many fast
> >=C2=A0 =C2=A0 handovers (e.g., with vehicular networks), there may= exist multiple
> >=C2=A0 =C2=A0 previous (e.g., k) MAARs exist.=C2=A0 In this situat= ion, the CMD creates k
> >
> > nit: remove the redundant "exist"
> >
>
> [CB] Done.
>
>
> >
> >=C2=A0 =C2=A0 When the CMD acts as MAAR locator, mobility signalin= g (PBAs) is
> >=C2=A0 =C2=A0 exchanged between P-MAARs and current S-MAAR.=C2=A0 = This requires security
> >=C2=A0 =C2=A0 associations to exist between the involved MAARs (in= addition to the
> >=C2=A0 =C2=A0 ones needed with the CMD).
> >
> > Is this relevant because of scaling/resource-consumption concerns= or
> > keying/trust ones?
> >
>
> [CB] This is relevant because RFC 5213 uses a model in which signallin= g is
> exchanged only between LMA (the anchor) and MAGs (the access routers),=
> while in this document there are some operation modes that also involv= e
> signalling between MAARs (the access routers). This was just to highli= ght
> this point (it is related to the point you made before about the trust=
> model).

Okay, thanks for the clarification.

>
> >
> > Appendix A.5
> >
> >=C2=A0 =C2=A0 not implement existing mobility protocols.=C2=A0 Fur= thermore, a DMM
> >=C2=A0 =C2=A0 solution SHOULD work across different networks, poss= ibly operated as
> >=C2=A0 =C2=A0 separate administrative domains, when the needed mob= ility management
> >
> > Hmm, separate administrative domains makes the risk of NAT relati= vely
> > higher (per previous comment about NAT).
> >
> >=C2=A0 =C2=A0 intervention.=C2=A0 The partially distributed DMM so= lution can be deployed
> >=C2=A0 =C2=A0 across different domains with trust agreements if th= e CMDs of the
> >=C2=A0 =C2=A0 operators are enabled to transfer context from one n= ode to another.
> >
> > It would probably be worth expounding a bit more about this scena= rio and
> > the necessary trust/authorization relationships, in the security<= br> > > considerations.
> >
> > [CB] As per other comment from IESG evaluation I've removed t= he two
> appendixes.
>
> Huge thanks for your very good points!

And thanks for all the updates!
I will go update my ballot position now.

-Ben
--00000000000047c21605a14db499-- From nobody Mon Mar 23 15:10:37 2020 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8513A0920; Mon, 23 Mar 2020 15:10:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.122.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rfc-editor@rfc-editor.org, suresh@kaloom.com, max.ldp@alibaba-inc.com, draft-ietf-dmm-pmipv6-dlif@ietf.org, Dapeng Liu , dmm-chairs@ietf.org, dmm@ietf.org, The IESG MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <158500140571.2337.14797623183342448430@ietfa.amsl.com> Date: Mon, 23 Mar 2020 15:10:05 -0700 Archived-At: Subject: [DMM] Document Action: 'Proxy Mobile IPv6 extensions for Distributed Mobility Management' to Experimental RFC (draft-ietf-dmm-pmipv6-dlif-06.txt) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 22:10:29 -0000 The IESG has approved the following document: - 'Proxy Mobile IPv6 extensions for Distributed Mobility Management' (draft-ietf-dmm-pmipv6-dlif-06.txt) as Experimental RFC This document is the product of the Distributed Mobility Management Working Group. The IESG contact persons are Éric Vyncke and Suresh Krishnan. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ Technical Summary This document describes a new mechanism for realizing distributed mobility management system based on Proxy Mobile IPv6 protocol. Working Group Summary This document has been in development, first as an individual submission in the DMM WG and later as a working group document. The document has gone through around 5 revisions. Document Quality The document is well-written and technically correct in our opinion. The document had some amount of reviews and inputs by the working group and also by some of the mobility experts in the WG. Furthermore, some of the authors have very good understanding of the Proxy Mobile IPv6 protocol and therefore we believe the quality of the document is good. Personnel Dapeng(Max) Liu is the document shepherd. Suresh Krishnan is the responsible AD. From nobody Tue Mar 24 00:59:09 2020 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AFD3A08A9 for ; Tue, 24 Mar 2020 00:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iCJshofT-t0 for ; Tue, 24 Mar 2020 00:59:05 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id EA4FF3A08DC for ; Tue, 24 Mar 2020 00:59:00 -0700 (PDT) Received: from CNNIC-THINK (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5gMC4vXleVdceAA--.37209S2; Tue, 24 Mar 2020 15:58:48 +0800 (CST) Date: Tue, 24 Mar 2020 15:58:47 +0800 From: "Z.W. Yan" To: dmm Cc: "Jong-Hyouk Lee" , ggg , htao X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Mime-Version: 1.0 Message-ID: <202003241558474826189@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart603645021323_=----" X-CM-TRANSID: AQAAf0B5gMC4vXleVdceAA--.37209S2 X-Coremail-Antispam: 1UD129KBjvJXoW7try5AF13Xryktr45AFW7twb_yoW8CF4Upa 9a9ay5G3s7Z397Grs7Zr1DuayUArWIgrZrAFnrtr1jywsrG3Wkt3WSyF4YvFWUAr13Kryv qr42vryrAw1FgrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPlb7Iv0xC_Ar1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzxvEb7x7McIj6xIIjxv20xvE14v26r1j6r 18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vI r41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07MxkIecxEwVAFwVW8Cw CF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r10 6r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64 vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIx AIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZF pf9x0zEMKZJUUUUU= X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Subject: [DMM] Fw: New Version Notification for draft-yan-dmm-man-06.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2020 07:59:08 -0000 This is a multi-part message in MIME format. ------=_001_NextPart603645021323_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQpCYXNlZCBvbiB0aGUgY29tbWVudHMgYW5kIGRpc2N1c3Npb25zIGR1cmluZyB0 aGUgbGFzdCBJRVRGIEYyRiBtZWV0aW5nLCB3ZSByZXZpc2VkIHRoZSBkcmFmdCBvZiBNb2JpbGl0 eSBDYXBhYmlsaXR5IE5lZ290aWF0aW9uIGFuZCBQcm90b2NvbCBTZWxlY3Rpb24uDQpUaGUgY3Vy cmVudCB2ZXJzaW9uIG1haW5seSBhaW1zIHRvIHByZXNlbnQgdGhpcyBwcm9ibGVtIGFuZCBzb21l IGJhc2ljIHByaW5jaXBsZXMgdG8gbmVnb3RpYXRlIGFuZCBzZWxlY3QgdGhlIG1vYmlsaXR5IG1h bmFnZW1lbnQgcHJvdG9jb2wuDQpBbmQgd2UgbGVhdmUgdGhlIHNvbHV0aW9uIHRvIHRoZSBpbXBs ZW1lbnRhdGlvbiwgdGhlbiB0aGF0IGlzIG5vdCBjb3ZlcmVkIGJ5IHRoaXMgZHJhZnQuDQpUaGFu ayB5b3UgZm9yIHlvdXIgZnVydGhlciBjb21tZW50cy4NCkJSLA0KDQoNCg0KDQpaLlcuIFlhbg0K IA0KRnJvbTogaW50ZXJuZXQtZHJhZnRzDQpEYXRlOiAyMDIwLTAzLTI0IDA4OjIxDQpUbzogR3Vh bmdnYW5nIEdlbmc7IEpvbmctSHlvdWsgTGVlOyBaaGl3ZWkgWWFuOyBUYW8gSHVhbmcNClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteWFuLWRtbS1tYW4tMDYudHh0 DQogDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteWFuLWRtbS1tYW4tMDYudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFpoaXdlaSBZYW4gYW5kIHBvc3RlZCB0byB0 aGUNCklFVEYgcmVwb3NpdG9yeS4NCiANCk5hbWU6IGRyYWZ0LXlhbi1kbW0tbWFuDQpSZXZpc2lv bjogMDYNClRpdGxlOiBNb2JpbGl0eSBDYXBhYmlsaXR5IE5lZ290aWF0aW9uIGFuZCBQcm90b2Nv bCBTZWxlY3Rpb24NCkRvY3VtZW50IGRhdGU6IDIwMjAtMDMtMjMNCkdyb3VwOiBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NClBhZ2VzOiAxMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15YW4tZG1tLW1hbi0wNi50eHQNClN0YXR1czogICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15YW4tZG1tLW1hbi8N Ckh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWFuLWRt bS1tYW4tMDYNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LXlhbi1kbW0tbWFuDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXlhbi1kbW0tbWFuLTA2DQogDQpBYnN0cmFjdDoNCiAg IEJhc2VkIG9uIGRpZmZlcmVudCByZXF1aXJlbWVudHMsIG11bHRpcGxlIG1vYmlsaXR5IG1hbmFn ZW1lbnQNCiAgIHByb3RvY29scyBoYXZlIGJlZW4gZGV2ZWxvcGVkLiAgRGlmZmVyZW50IHByb3Rv Y29scyBoYXZlIGRpZmZlcmVudA0KICAgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgb24gdGhlIG5l dHdvcmsgZWxlbWVudCBvciB0aGUgaG9zdCBhbmQgdGhlbiBhDQogICBzY2hlbWUgc2hvdWxkIGJl IHVzZWQgaW4gb3JkZXIgdG8gc3VwcG9ydCB0aGUgbmVnb3RpYXRpb24gYW5kDQogICBzZWxlY3Rp b24gb2YgYWRvcHRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IHByb3RvY29sIHdoZW4gYSBob3N0DQog ICBhY2Nlc3NlcyB0byBhIG5ldyBuZXR3b3JrLiAgSW4gdGhpcyBkcmFmdCwgdGhpcyBpc3N1ZSBp cyBhbmFseXplZC4NCiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiANCiANClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQogDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KIA0KIA0K IA0K ------=_001_NextPart603645021323_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
Dear All,
Based on the comments and discu= ssions during the last IETF F2F meeting, we revised the draft of Mobility Capability Negotiation and Protocol Selection.
=
The current version mainly aims to present this problem and= some basic principles to negotiate and select the mobility management pro= tocol.
And we leave the solution to the impleme= ntation, then that is not covered by this draft.
Thank yo= u for your further comments.
BR,

=0A
=0A
=0A
Z.W. Yan
=  
Date:&n= bsp;2020-03-24 08:21
Subject: New = Version Notification for draft-yan-dmm-man-06.txt
 
=0A
A new version of I-D, draft-yan-dmm-man-06.txt=0A
has been successfully submitted by Zhiwei Yan and posted to the=0A
IETF repository.
=0A
 
=0A
Name: draft= -yan-dmm-man
=0A
Revision: 06
=0A
Title: Mobility Capab= ility Negotiation and Protocol Selection
=0A
Document date: 2020-= 03-23
=0A
Group: Individual Submission
=0A
Pages: 12=0A
URL:         &nbs= p;  https://www.ietf.org/internet-drafts/draft-yan-dmm-man-06.txt=0A
Status:         https://= datatracker.ietf.org/doc/draft-yan-dmm-man/
=0A
Htmlized: &n= bsp;     https://tools.ietf.org/html/draft-yan-dmm-man= -06
=0A
Htmlized:       https://dat= atracker.ietf.org/doc/html/draft-yan-dmm-man
=0A
Diff:  = ;         https://www.ietf.org/rfc= diff?url2=3Ddraft-yan-dmm-man-06
=0A
 
=0A
Abstract= :
=0A
   Based on different requirements, multiple mobi= lity management
=0A
   protocols have been developed.&n= bsp; Different protocols have different
=0A
   function= al requirements on the network element or the host and then a
=0A   scheme should be used in order to support the negotiation an= d
=0A
   selection of adopted mobility management proto= col when a host
=0A
   accesses to a new network. = In this draft, this issue is analyzed.
=0A
 
=0A
&= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;      
=0A
 
=0A 
=0A
Please note that it may take a couple of minutes fro= m the time of submission
=0A
until the htmlized version and diff = are available at tools.ietf.org.
=0A
 
=0A
The IETF= Secretariat
=0A
 
=0A
 
=0A
 =0A
=0A ------=_001_NextPart603645021323_=------