From nobody Fri Nov 1 05:05:14 2019 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 585AC120091; Fri, 1 Nov 2019 05:05:14 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <157260991431.31784.5524181743925705047@ietfa.amsl.com> Date: Fri, 01 Nov 2019 05:05:14 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-distributed-mobility-anchoring-14.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: Fri, 01 Nov 2019 12:05:14 -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-14.txt Pages : 19 Date : 2019-11-01 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-distributed-mobility-anchoring-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-distributed-mobility-anchoring-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 1 05:06:25 2019 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 5371D120118 for ; Fri, 1 Nov 2019 05:06:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 yAeiaFVjzWGe for ; Fri, 1 Nov 2019 05:06:08 -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 F3F53120853 for ; Fri, 1 Nov 2019 05:06:07 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id y7so7353228edo.12 for ; Fri, 01 Nov 2019 05:06:07 -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=otQ2qta23d5CE2J5ryVSg7VFYG92+EYt+USCS+/NA8I=; b=cpNHU0BP+HGEA0Y1LNfuZdjb0WwqWCptgrk23avvNTsw2aWq6mYmsU4HDdQXek0RNG cDww3zbGVIZIKxofE63weMp0EFwzq9CmXIt5jnxX/q8dCuIDzIqD8jnE5T10xk15xA2n hTBoeaRW5T504rRtuvKA/hm0e3TxDeV10tyn/0Rvxjw0ct97NwLk7FQzFioHt3tw1Mfn OHczmBeeIgSFQ9bOQOI8i0vlNsGfpXdyjZTbLv2o90+Bjvq2ym43XDKfTXq81wwRDBAP BYYFgj1hQiL5ty99VYrt0mG+0Si5tJ2d5ltecKpSG9oxnJKtA6WCJGfvEG/Xty+rZG1H bgzg== 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=otQ2qta23d5CE2J5ryVSg7VFYG92+EYt+USCS+/NA8I=; b=cBeruHw29bKrsPnNJcmcIBUhpQIWnW8ViQZUoyncGYbnIcxEKB5qxGtnGveqeZWg23 18VUaqyVDFO8H5YwNxrW27IRyxBTznf2fwr0S9Q0kuJ0R54Pghib+9V0rm9KRiZZ2Gu7 eZxx0bAFXXDHpX69ovTtpNkt68U4kUGb3LkprLSVfRn1vVbvGEgARCxt7u6MV/ihLPlp MeYn4t4Yh9UtaiPQtbNrEfQHINqxK1v83iZyDMiYi5DE+c7v58ZKn1CYyyxjTtBOeiHF Hk4+c4MKGSyGyevjlI8hcoSTW1gBppHdj4zDxAfOhy3gPfiLNRkyiTGZv73SlMWVMLfe kMFQ== X-Gm-Message-State: APjAAAXIZ2yOX5b4VtGXYpGscKHw5zG+p8f217iml2f7impFQbL3ri7l WasHYKUKhOAtLPzl1enWPKhNR84oYDkav2SMMRJi/Q== X-Google-Smtp-Source: APXvYqxkRLMpQuBtOOTQYHg6T5NpbGP5D5lUxldQuLofiB1b87hPfnNA6audNVw75cakpSVEf4Qs+t+XgAMxaqyn9fQ= X-Received: by 2002:a17:906:c9d9:: with SMTP id hk25mr9461852ejb.74.1572609966195; Fri, 01 Nov 2019 05:06:06 -0700 (PDT) MIME-Version: 1.0 References: <157103982375.24746.491736148532050112@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Fri, 1 Nov 2019 13:05:49 +0100 Message-ID: To: Yoshifumi Nishida Cc: tsv-art@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, ietf@ietf.org, dmm Content-Type: multipart/alternative; boundary="00000000000067f7a2059647ca59" Archived-At: Subject: Re: [DMM] Tsvart 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: Fri, 01 Nov 2019 12:06:12 -0000 --00000000000067f7a2059647ca59 Content-Type: text/plain; charset="UTF-8" Dear Yoshi, We've just posted a new revision (-14) addressing all your comments. Thanks! Carlos On Thu, Oct 24, 2019 at 9:38 AM Yoshifumi Nishida wrote: > Hi Carlos, > Thanks for the response. I put my comments in lines. > > On Fri, Oct 18, 2019 at 4:20 AM CARLOS JESUS BERNARDOS CANO < > cjbc@it.uc3m.es> wrote: > >> Dear Yoshifumi, >> >> Thanks a lot for the review. Please check inline below for some comments >> from my side. >> >> On Mon, Oct 14, 2019 at 9:57 AM Yoshifumi Nishida via Datatracker < >> noreply@ietf.org> wrote: >> >>> Reviewer: Yoshifumi Nishida >>> Review result: Almost Ready >>> >>> This document has been reviewed as part of the transport area review >>> team's >>> ongoing effort to review key IETF documents. These comments were written >>> primarily for the transport area directors, but are copied to the >>> document's >>> authors and WG to allow them to address any issues raised and also to >>> the IETF >>> discussion list for information. >>> >>> When done at the time of IETF Last Call, the authors should consider this >>> review as part of the last-call comments they receive. Please always CC >>> tsv-art@ietf.org if you reply to or forward this review. >>> >>> Summary: This document is almost ready for publication as an >>> informational RFC, >>> but it will be better to clarify the following points. >>> >>> 1: The examples shown in the draft look behave conveniently. >>> For examples, in the figure 3 case, the flow is somehow terminated >>> before >>> the MN moves and is re-initiated after the movement has finished. >>> However, I >>> believe there should be the cases where applications don't aware of >>> network >>> changes and transmit data while migrating, which may cause packet >>> drops, >>> delays and timeouts, etc. I think this draft should clarify the >>> treatments >>> of these cases. Is it out of scope of the draft? Or, do some >>> components >>> generate ICMP messages to give some hints to the applications, or >>> provide >>> buffering features to mitigate the side effects? >>> >> >> [Carlos] I guess you mean Figure 4, right? In that figure, we try to >> explain what would happen if there is no actual mobility support, meaning >> that a communication flow does not need such mobility support. This might >> happen because the flow stops before the movement (as shown in the figure) >> or also because the application can deal with the mobility itself (no >> mobility at the IP layer). We don't explicitly mention that second case >> because it is not in the scope of the draft (IP mobility). We can better >> clarify the scope in the text. >> > > Sorry for confusion. Yes, the data flow is explained in Figure 4. > What I wanted to mention was how the flow can stop it without mobility > support. If there's no mobility support, the app should not be able to know > when network change will happen. So, I am thinking that in some cases, the > flow may not able to stop before the movement. > I am guessing this case would be a major case than the case described in > the draft. > Or, is there any available approach here? > >> >> >>> >>> 2: Page 8: >>> "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." >>> >>> -> It seems to me that the draft implicitly suggests the use of >>> draft-ietf-dmm-ondemand-mobility here. >>> If so, I think it would be better to state more explicitly. Or, >>> do we >>> have other options? >>> >> >> [Carlos] We can definitely add an explicit reference to >> draft-ietf-dmm-ondemand-mobility, but I'd mention it as an example. I don't >> have another option in mind, but we can leave it open. >> > > Yes, referring as an example is fine. I just thought if this approach can > be used, then it might be better to explain it explicitly. > >> >> >>> 3: Page 10: >>> "the initial anchor remains the anchor and forwards traffic" >>> >>> -> could be "anchor remains and the anchor.."? >>> >> >> [Carlos] Maybe "mobility anchor remains playing that role and forwards >> traffic"? >> > > Works for me. Thanks! > -- > Yoshi > -- Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g --00000000000067f7a2059647ca59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Yoshi,

We've just posted a new= revision (-14) addressing all your comments.

Than= ks!

Carlos

On Thu, Oct 24, 2019 at 9:38 AM Yo= shifumi Nishida <nsd.ietf@gmail.co= m> wrote:
Hi Carlos,=C2=A0
Thanks for the response. I put my comments in lines.

On Fri, Oct 18= , 2019 at 4:20 AM CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote:
Dear=C2=A0Yoshifumi,

Thanks a lot for the review. Plea= se check inline below for some comments from my side.

On Mon, Oct 14, = 2019 at 9:57 AM Yoshifumi Nishida via Datatracker <noreply@ietf.org> wrote:
<= 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">Reviewer: Yoshifumi Nishid= a
Review result: Almost Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org = if you reply to or forward this review.

Summary: This document is almost ready for publication as an informational = RFC,
but it will be better to clarify the following points.

1: The examples shown in the draft look behave conveniently.
=C2=A0 =C2=A0For examples, in the figure 3 case, the flow is somehow termin= ated before
=C2=A0 =C2=A0the MN moves and is re-initiated after the movement has finish= ed. However, I
=C2=A0 =C2=A0believe there should be the cases where applications don't= aware of network
=C2=A0 =C2=A0changes and transmit data while migrating, which may cause pac= ket drops,
=C2=A0 =C2=A0delays and timeouts, etc. I think this draft should clarify th= e treatments
=C2=A0 =C2=A0of these cases. Is it out of scope of the draft? Or, do some c= omponents
=C2=A0 =C2=A0generate ICMP messages to give some hints to the applications,= or provide
=C2=A0 =C2=A0buffering features to mitigate the side effects?

[Carlos] I guess you mean Figure 4, right? In that f= igure, we try to explain what would happen if there is no actual mobility s= upport, meaning that a communication flow does not need such mobility suppo= rt. This might happen because the flow stops before the movement (as shown = in the figure) or also because the application can deal with the mobility i= tself (no mobility at the IP layer). We don't explicitly mention that s= econd case because it is not in the scope of the draft (IP mobility). We ca= n better clarify the scope in the text.
=
Sorry for confusion. Yes, t= he data flow is explained in Figure 4.=C2=A0
What I wanted to mention was how the flow can stop it w= ithout mobility support. If there's no mobility support, the app should= not be able to know when network change will happen. So, I am thinking tha= t in some cases, the flow may not able to stop before the movement.=C2=A0
I am guessing this case wo= uld be a major case than the case described in the draft.
= Or, is there any available approach here?<= /font>
=C2=A0

2: Page 8:
=C2=A0 =C2=A0"A MN will need to choose which IP prefix/address to use = for each flow
=C2=A0 =C2=A0 according to whether it needs IP mobility support or not.&quo= t;

=C2=A0 =C2=A0 =C2=A0-> It seems to me that the draft implicitly suggests= the use of
=C2=A0 =C2=A0 =C2=A0draft-ietf-dmm-ondemand-mobility here.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If so, I think it would be better to state more= explicitly. Or, do we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 have other options?

[Carlos] We can definitely add an explicit reference to draft-ietf= -dmm-ondemand-mobility, but I'd mention it as an example. I don't h= ave another option in mind, but we can leave it open.

Yes, referring as an example is fine. I just t= hought if this approach can be used, then it might be better to explain it = explicitly. =C2=A0
<= div dir=3D"ltr">


3: Page 10:
=C2=A0 =C2=A0 "the initial anchor remains the anchor and forwards traf= fic"

=C2=A0 =C2=A0 =C2=A0-> could be "anchor remains and the anchor..&qu= ot;?

[Carlos] Maybe "mobility anch= or remains playing that role and forwards traffic"?
<= /blockquote>

Works for me. Thanks!
--
Yoshi=C2=A0


--
--00000000000067f7a2059647ca59-- From nobody Fri Nov 1 05:13:40 2019 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 A6B0512002E for ; Fri, 1 Nov 2019 05:13: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q4Ue9RH72v0s for ; Fri, 1 Nov 2019 05:13:38 -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 D856A12088A for ; Fri, 1 Nov 2019 05:06:52 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id b72so7398782edf.1 for ; Fri, 01 Nov 2019 05:06:52 -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=rkqrna1NRQzfybbehKYGNKR/ie9lLXXCu31++a01xuc=; b=nPeLau0GgxYK/XllG3csHguXH7Pd1O2MygDySl4P0r9vYJ3ANXtU8+hyydSb8la97z WM6dTdz5LmQxF5QYTbQi4RMTm1LkQhBtK+fvgB7D6BXsWq85dTtDWIPckC0fxpGGWxhs rIBLelhQiWXQllMczeMX3mPpJZtRwlbouPSidMKBOZyowwGazmHeM/RHfHjVBKORLO/g EhqG38iNb6ogurpolUzwpIxPjgR642rsZtYqeFTfYV0A6dUCZL2ma/d8t/Q15IoN5yV+ b7zj2Y1qZN16bOZHrhcEf2arSA9ypvNdZflrrAbKB1zqNd/AM3mS7icHXqdEEk7ToqjY WutA== 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=rkqrna1NRQzfybbehKYGNKR/ie9lLXXCu31++a01xuc=; b=nY+HS4Jlj6k0c8W5T4BkEdSwiCszHcsdyD/lGdDwJLmMefluwfI/V2LB+MX6Vq1LG/ W6zNvTEBZK3rFrs0MXlnYsaUOahY/ZUAatWSC5Zm+1eRwSOHXc8UOpiWtjoQ7gVURqoy JaNhkouKeBVi8C2Fsr9KtsEAhQU6m5UJgrFkgyk3qw4xIxOdyCNbM2ypUcRP3IpINwdu CZpkVrjR+4VCC+g7yHZ7XRtbf70/G6yMONsfJwPOJQArP0PH/1+8MimrJ7vx9U9i5Yek rsYCFpCzcC0Oq5FMjCNiGb9VKaUloZNSPQeaIPGU4T9meuIrkSbOa8vvsr/zNAPso8vU Gp/g== X-Gm-Message-State: APjAAAVTyTggGMByT42cEDGREm9yUBgicwgN1A9bo+TE/cr6kWB021KU FExfKbKZ0LR99T8o2XeNGxEs86v6kg+OBJSfPjGzPg== X-Google-Smtp-Source: APXvYqw/+GqscUBUqrdkILmvsg6AmJHIEGXiHIVQgbTlJsPMm4TQ9wEWx8B1lufM2QcKE9tZApJYO4LAcV2liLSB204= X-Received: by 2002:a50:fd03:: with SMTP id i3mr12315823eds.70.1572610011254; Fri, 01 Nov 2019 05:06:51 -0700 (PDT) MIME-Version: 1.0 References: <157100555733.20750.5488529297693995498@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Fri, 1 Nov 2019 13:06:35 +0100 Message-ID: To: Joseph Salowey Cc: secdir@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, The IESG , dmm Content-Type: multipart/alternative; boundary="000000000000176dcc059647cd56" Archived-At: Subject: Re: [DMM] Secdir 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: Fri, 01 Nov 2019 12:13:40 -0000 --000000000000176dcc059647cd56 Content-Type: text/plain; charset="UTF-8" Dear Joseph, We've just posted a new revision (-14) addressing all your comments. Thanks! Carlos On Fri, Oct 18, 2019 at 1:12 PM CARLOS JESUS BERNARDOS CANO wrote: > Dear Joseph, > > Thanks a lot for the review. We will improve the security consideration > section by including also some of the considerations mentioned in draft- > ietf-dmm-deployment-models-04, and also by better scoping current text. > We believe we don't need much more in terms of text, as the document is > informational, and the actual security mechanisms for a distributed > anchoring solution would depend on the specifics of that solution. We can > also better reflect that rational in the text. > > Thanks, > > Carlos > > On Mon, Oct 14, 2019 at 12:25 AM Joseph Salowey via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Joseph Salowey >> Review result: Has Issues >> >> I have reviewed this document as part of the security directorate's >> 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 just like any other last call comments. >> >> The summary of the review is the document has issues with the security >> considerations section. >> >> The security consideration section is extremely light. It mainly >> contains text >> from RFC 7333. It seems that there should be more discussion of security >> as it >> relates to the different configurations and different cases. Do each of >> these >> cases have the same security properties and require the same types of >> security >> controls? >> >> Are the IPSEC recommendations mentioned in the security considerations of >> draft-ietf-dmm-deployment-models-04 applicable for all the cases? Should >> these be pointed out in the security considerations section? >> >> >> > > -- > 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 --000000000000176dcc059647cd56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Joseph,

We've just posted a ne= w revision (-14) addressing all your comments.

Tha= nks!

Carlos

On Fri, Oct 18, 2019 at 1:12 PM C= ARLOS JESUS BERNARDOS CANO <cjbc@it.u= c3m.es> wrote:
Dear Joseph,

Thanks a lot for the= review. We will improve the security consideration section by including al= so some of the considerations mentioned in=C2=A0draft-ie= tf-dmm-deployment-models-04, and also by better scoping= current text. We believe we don't need much more in terms of text, as = the document is informational, and the actual security mechanisms for a dis= tributed anchoring solution would depend on the specifics of that solution.= We can also better reflect that rational in the text.

=
Thanks,

Carlos

On Mon, Oct 14, 2019 at 1= 2:25 AM Joseph Salowey via Datatracker <noreply@ietf.org> wrote:
Reviewer: Joseph Salowey
Review result: Has Issues

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

The summary of the review is the document has issues with the security
considerations section.

The security consideration section is extremely light.=C2=A0 It mainly cont= ains text
from RFC 7333.=C2=A0 It seems that there should be more discussion of secur= ity as it
relates to the different configurations and different cases.=C2=A0 =C2=A0Do= each of these
cases have the same security properties and require the same types of secur= ity
controls?

Are the IPSEC recommendations mentioned in the security considerations of draft-ietf-dmm-deployment-models-04 applicable for all the cases?=C2=A0 =C2= =A0Should
these be pointed out in the security considerations section?




--


--
--000000000000176dcc059647cd56-- From nobody Fri Nov 1 10:39:42 2019 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 69373120A31 for ; Fri, 1 Nov 2019 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 jguvA1d0rFB2 for ; Fri, 1 Nov 2019 10:39:38 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 B2A4812099E for ; Fri, 1 Nov 2019 10:39:37 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id z12so7785081lfj.9 for ; Fri, 01 Nov 2019 10:39:37 -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=QRnY0AfWUgqOF2BDYyFlDxnKlNhpdjSdwPjrDifLbCE=; b=H6hqiJ0uIgjn3v5tXk3qDq6Wlpm94omWSNNWQcg67j6bH0Ks1ZzX3UtfOKAqWxIzUw XgotV8wVge2ege6RkUJjt5CrZG2vjjXpjDBY+jsL0rlJmHqUUt9OnlZDNdJzVt5WRgJV fXQ89GYneaT1fF5jrOmu51VJimpbqZ+swwxcHfO5sMJjtNwKtWNEziQw7SNvpmtfp9gT kOPqd4znSfCHeWBwhJRxB5iYofxT6riKoNVNkAmZ0mXrIHgV58duwTSDieg3QB3f1/de vPIp4I1fevQT3QVPv9tqeItr2ahCObSZDsgADPSJ5xytKtgZC/GcRSZbfgMZro7y2flw zgVg== 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=QRnY0AfWUgqOF2BDYyFlDxnKlNhpdjSdwPjrDifLbCE=; b=dIuSms+b4/OW+h8LvlGHDsv6yiU/Pk8nvMHcyo1a5gd2PuiPHjj7FaG7yg/xyA71ZH dlMHu4EXRI6VSFtqbI2gupq9ceLxdPilESy/XGj4ByL0eDR40S+gLxCyNOFSaJxa088f U6Q+gHEGKFazgb1jWAlbiImbu9GBP0vJGN1/EdQzlgx04zNHtHHscY6T+C+Z7YB9W15O 4mAVjZXb4TDZ8IYnCs4kmvgXCnFsg1J33ukjZhmRFwJNq+oS7yzb8DfXo2ibqjWTbzuB kyxg61FtuEnjtdb2nzBg5Hi4kenlRxw9b3vOREqCAozqeCZK0xQCTs/V/awN/qJ4Mh+e eb8w== X-Gm-Message-State: APjAAAU1RWdGobP4ocskdbc1OGPXMb93pVfujRNeEOI0fX9mRuygXdTm D9G6Q1tcByaarxET5bhS8UBS2u78K57YAICCB0k= X-Google-Smtp-Source: APXvYqwsWZ088viWgU3nibAIyB6eMqDJ9ffl7ibkCCPf7/833XNvxxNvdHYT9yYGRSMSNTjxOp/rTFSGkZn85DRQMGg= X-Received: by 2002:a19:520b:: with SMTP id m11mr7929032lfb.77.1572629975843; Fri, 01 Nov 2019 10:39:35 -0700 (PDT) MIME-Version: 1.0 References: <49BD327C-5377-4166-BC7C-9F5FBA7FD4E3@gmail.com> <602C6C0B-B325-440D-BFA1-609B9A7F6EF1@gmail.com> In-Reply-To: <602C6C0B-B325-440D-BFA1-609B9A7F6EF1@gmail.com> From: Miya Kohno Date: Sat, 2 Nov 2019 02:39:24 +0900 Message-ID: To: Satoru Matsushima Cc: dmm , "Pablo Camarillo (pcamaril)" , zali@cisco.com, fclad@cisco.com Content-Type: multipart/alternative; boundary="00000000000012c8bf05964c73ab" Archived-At: Subject: Re: [DMM] IETF106 - 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: Fri, 01 Nov 2019 17:39:41 -0000 --00000000000012c8bf05964c73ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear DMM chairs, I would like to request a slot to discuss about the following draft. --------------- The title of the presentation: Architecture Discussion on SRv6 Mobile User plane Presenter name: Miya Kohno Time you need: 15min Draft reference: https://www.ietf.org/id/draft-kohno-dmm-srv6mob-arch-00.tx= t --------------- Thanks! Miya On Wed, Oct 23, 2019 at 11:49 AM Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > One correction for a typo: > > > Reminder: > > The draft cut-off date: 4th November UTC 23:59 (2 weeks before the > meeting). > > > Regards, > --satoru > > > > 2019/10/22 12:07=E3=80=81Satoru Matsushima =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: > > > > Folks, > > > > The DMM chairs are planning the dmm meeting in Singapore at IETF106: > > > > 18th November, Monday Afternoon Session II (15:50-17:50) > > > > If you have a draft or any topics you would like to discuss, please sen= d > your request for agenda time to the dmm chairs. Please include the > information in the request as following: > > > > The title of the presentation: > > Presenter name: > > Time you need: > > Draft reference: > > > > Please have agenda items to us by 2019-11-04 (November 4th). > > > > Reminder: > > The draft cut-off date: 14th November UTC 23:59 (2 weeks before the > meeting). > > > > Dapeng & Sri & Satoru > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --00000000000012c8bf05964c73ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear DMM chairs,

=
I would like to request a slot to discuss about the following dr= aft.

---------------
The title = of the presentation: Architecture Discussion on SRv6 Mobile User plane
Presenter name: Miya Kohno
Time you need: 15min
Draft reference: https://www.ietf.org/id/draft-kohno-dmm-srv= 6mob-arch-00.txt
---------------

Tha= nks!
Miya

On Wed, Oct 23, 2019 at 11:49 AM Satoru Matsu= shima <= satoru.matsushima@gmail.com> wrote:
One correction for a typo:

> Reminder:
> The draft cut-off date: 4th November UTC 23:59 (2 weeks before the mee= ting).


Regards,
--satoru


> 2019/10/22 12:07=E3=80=81Satoru Matsushima <satoru.matsushima@gmail.com&g= t;=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB:
>
> Folks,
>
> The DMM chairs are planning the dmm meeting in Singapore at IETF106: >
> 18th November, Monday Afternoon Session II (15:50-17:50)
>
> If you have a draft or any topics you would like to discuss, please se= nd your request for agenda time to the dmm chairs. Please include the infor= mation in the request as following:
>
> The title of the presentation:
> Presenter name:
> Time you need:
> Draft reference:
>
> Please have agenda items to us by 2019-11-04 (November 4th).
>
> Reminder:
> The draft cut-off date: 14th November UTC 23:59 (2 weeks before the me= eting).
>
> Dapeng & Sri & Satoru

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
--00000000000012c8bf05964c73ab-- From nobody Sat Nov 2 04:26:56 2019 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 4373C121628; Sat, 2 Nov 2019 04:26:54 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <157269401423.6060.6149451065948206503@ietfa.amsl.com> Date: Sat, 02 Nov 2019 04:26:54 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-pmipv6-dlif-05.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, 02 Nov 2019 11:26:54 -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-05.txt Pages : 33 Date : 2019-11-02 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-pmipv6-dlif-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-pmipv6-dlif-05 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 Nov 2 04:45:29 2019 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 85F0F1200C3 for ; Sat, 2 Nov 2019 04:45:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 l2vCXnxMWPzV for ; Sat, 2 Nov 2019 04:45:08 -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 3AD201200F5 for ; Sat, 2 Nov 2019 04:45:08 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id b18so9439850edr.11 for ; Sat, 02 Nov 2019 04:45:08 -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=lcIwduxkTQslzIf+ZfXZvLzqz/C7rW4lYRSVZUgSnPQ=; b=cm1TsDb4k5BUjLaXRlEGUIH2ii76qmODEC0EN/yxA1ACQySaWvYDBpMdioFdoxqCsk cyltaAHChLovM9n7c+w36JPyhpybf6lRckOkbhBrlvpHCTQ+toLPEQYPcp7KciZG2vLa u2IpqAaH6sYy9JBZjSL1Tle/WMGDvWZv6UnFmBmcIjq7hgxKRMbb91OXBEb2FMemsR7D U2NDpX0uvMlaLqnD8wgFP6IwKECin3d1tH5DoCVtWQmcVbN3pU2EdKC1v2mfsDrquI4q Ph9Em/H7C0IgginGoNI179e/GHeBZYqfAdyD07nWpkJWsFwKfaidP2GnMDWcf4gNDyga nB+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=lcIwduxkTQslzIf+ZfXZvLzqz/C7rW4lYRSVZUgSnPQ=; b=neRGX/1BAZcoOCM6LGQO1QqTLPGB2BgWKrQxl7QKpW/P6M8XcH18fniTg+vLVNKhdi x3TTj04gzrtWT9ifdvq0GEXDfJbF98sRpf+snA/wYZT13Rb66hoBaA6j9uR9Zrj1N0Wf aZ6D/gTD4E3OBKQNVB3fFE2VmrB8d9z0i1FjSGNWqDJThOAfz2V/LWyToFBw7eDDaHai AgmV5pD3ErbtDZaiN8kPLntUrDiXSE/ks72uY1pLRuZrQEr+EX0RB/QWKrzWZTLSuh2P qCzMl9VvM2hijqoXbY5LXUdiHTd7a01g5EXk3fPDF7iofnyFpe5Ogj51ZlOsPJD8ZtbW e97g== X-Gm-Message-State: APjAAAV3bqVAgMsEosLSfHtQ3MZa5xXFJZo90pm8I8k05pGGmkTG96MT FFeMU7J8L4tuCfn/BiIyjgk7gvyAiIojcr1ZJoZ9dA== X-Google-Smtp-Source: APXvYqw0J7Od/w+H+Ce2gZ5UR1VN+xIiQU03mm9mSccdmHatBRBfgV837O56SBCINxX/R+t0l42HXgK/iGyfgSJC0K8= X-Received: by 2002:a17:906:2615:: with SMTP id h21mr9781282ejc.212.1572695106249; Sat, 02 Nov 2019 04:45:06 -0700 (PDT) MIME-Version: 1.0 References: <157108446243.24779.12043209679040887677@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Sat, 2 Nov 2019 12:44:50 +0100 Message-ID: To: Ines Robles Cc: General Area Review Team , draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm Content-Type: multipart/alternative; boundary="0000000000002611f305965b9d81" Archived-At: Subject: Re: [DMM] 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: Sat, 02 Nov 2019 11:45:13 -0000 --0000000000002611f305965b9d81 Content-Type: text/plain; charset="UTF-8" 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 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 >> >> . >> >> 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 --0000000000002611f305965b9d81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ines,

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

Thanks,

Carlos

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

Thanks for the review. We'll che= ck 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.=C2=A0 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&g= t;.

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<= br> (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 indicat= ing
the registry which the option type belong, etc. [rfc8126]

Thank you for this document,

Ines.




--


--
--0000000000002611f305965b9d81-- From nobody Sat Nov 2 04:45:35 2019 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 49CB3120EA9 for ; Sat, 2 Nov 2019 04:45:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 eUdFcT-VteWO for ; Sat, 2 Nov 2019 04:45:18 -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 10B7B1213E2 for ; Sat, 2 Nov 2019 04:45:18 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id p59so9441723edp.7 for ; Sat, 02 Nov 2019 04:45:17 -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=x2BYLZxIxSAdt8ypoIQIORGGOqYh56gnCIuumwf7wWQ=; b=nAV7SZSZaSaY0VhNCfKKiX576UJLCpjr4GQ9tNwhj9/MQ67e/QlXz6rLSA7xlph/UT 3VazXn3X6drNshoFhh6l6XYkNj1ApGKcR8jkJu0kSJl9vGYobK16Sl96NYbNVSUNGNNN aADqe8ubLHwhhMMWmPiSOy7UyYUA93cGwDR6J4cSdV0TkfKYY3p5EmQ7btwPbdTpyPyB Ju1661iNirywP/e26zxX8mUig5TxRb7x0XH2K1HZlOyx9LOgnSTjxArEkwcVFsg9c779 qz4tAC2g2fiBxdrHLI5gi1PQJzKo6xMyEF1FlMiCWadhzrRmIXSmq55mF/lmsBx+LwB/ Lz5A== 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=x2BYLZxIxSAdt8ypoIQIORGGOqYh56gnCIuumwf7wWQ=; b=mqOVBLk0ZjhA/hCID8/nv/hovS/5/2BviJDzsrBA0VDf+tZ73vofwWQ45A7meFbnLk DWd5PSQ1JWUwCRlxJ7uBLl7pLbKImUBEeIQoT0pBTBDPEtBRZebKET42tr0X29NSVNiB zL6vHrVkRHqtw1aT3HrYZbew9VMVXt/ycD5Ix610FroC2/MB45Fu7O0PzMmE7UZJN5ga 4cUf5T9TuOSckUQMe6QIiOfkk5arkuWnFAZ1lOZSUGOUxQZdmIHsRHi6MMPO5ZFR0Rnz S2cds3oNMRC372qW9jC/Xdzj5hUM7FqiqO1HqkH57Ew9A4XNk4IyvpUMXJ3IfcUXGyge hZkA== X-Gm-Message-State: APjAAAX1gN6qK+HuGJbYkHD5uVSP8B5Awc1NrJDvEmhpJF1GOaCxICzJ 1Wd3QZAJWCqgDNqmR/kw1di4mr7ENpQSeMJA3hSdsQ== X-Google-Smtp-Source: APXvYqyMg9u+FQN8yjW5bbJ3saZU6ASCWr7o2kNaxodf+eTNakKybBufK71tbhOc+FSoSoSgXhM7756TWX9eRG1A0XI= X-Received: by 2002:a17:906:448e:: with SMTP id y14mr14770700ejo.136.1572695116290; Sat, 02 Nov 2019 04:45:16 -0700 (PDT) MIME-Version: 1.0 References: <157108615425.24656.12786623966649135975@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Sat, 2 Nov 2019 12:45:00 +0100 Message-ID: To: Joerg Ott Cc: tsv-art@ietf.org, draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm Content-Type: multipart/alternative; boundary="000000000000bf3eb305965b9d43" Archived-At: Subject: Re: [DMM] Tsvart 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: Sat, 02 Nov 2019 11:45:27 -0000 --000000000000bf3eb305965b9d43 Content-Type: text/plain; charset="UTF-8" Hi Joerg, We've just posted a new revision addressing your comments. Thanks, Carlos On Fri, Oct 18, 2019 at 1:24 PM CARLOS JESUS BERNARDOS CANO wrote: > Thanks a lot Joerg for your very comprehensive review. > > We will carefully look at your comments and provide responses (with > proposals of text changes) in the next few days. I prefer to take some time > to properly address all your points. > > Thanks! > > Carlos > > On Mon, Oct 14, 2019 at 10:49 PM Joerg Ott via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Joerg Ott >> Review result: Ready with Issues >> >> Hi, >> >> this document has been reviewed as part of the transport area review >> team's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the >> document's >> authors and WG to allow them to address any issues raised and also to the >> IETF >> discussion list for information. >> >> When done at the time of IETF Last Call, the authors should consider this >> review as part of the last-call comments they receive. Please always CC >> tsv-art@ietf.org if you reply to or forward this review. >> >> The draft defines extensions to Proxy Mobile IPv6 to support a more >> distributed >> variant of mobility management. In essence, as a mobile node moves from >> one >> point of attachment (Mobility Anchor and Access Router, MAAR) to the next, >> its routing prefix with the previous MAAR(s) remain(s) and ongoing >> transport >> layer connections remain active and routed indirectly via the previous >> MAAR, >> while new ones will use the present MAAR. The interactions of MAARs are >> managed via a Central Mobility Database (CMD). >> >> The draft is well written and good to follow, describing the protocols and >> extensions clearly. I just have two transport-specific concern and two >> general >> operational issues that require further clarification in the draft. >> >> The transport issues: >> >> T1. Section 3.2. When the CMD acts as a relay for Proxy Binding Updates >> (PBUs) >> and Proxy Binding Acts (PBAs), the CMD may act as a relay of a single PBU >> to >> multiple previous MAARs. If multiple previous MAARs exist, say k, (and >> there >> may be numerous in case of many fast handovers, e.g., with vehicular >> networks), >> the CMD creates k outgoing packets from a single incoming packet. This >> bears >> a certain amplification risk (which may also need to be addressed in the >> security >> considerations section) but it also may lead to packet bursts originated >> from the >> CMD, albeit to different targets. Other protocols start introducing >> pacing to avoid >> bursts on the outgoing link, even if the packets do take different paths >> in the end. >> This may be worthwhile considering. >> >> T2. Also in section 3.2, when relaying PBAs, the CMD serves as a >> transport or >> application endpoint and should have a way to deal with missing responses >> (after all, this is a connectionless protocol on top of an unreliable >> Internet). >> A timeout is only mentioned for aggregation, but even there there the >> timeout >> is not specified, nor is a reference to, e.g., RFC 5213 or so to infer a >> timeout >> used elsewhere. >> >> General issues: >> >> G1. Section 3.2 (again) specifies that responses are aggregated on p.10. >> How >> does response aggregation work? How is error handling done? >> >> Moreover, also on p.10, further below the draft states that if a timer >> expires, >> the requests already received are forwarded. The missing ones come later. >> This seems to contradict aggregation because the originator (the currently >> server MAAR) does not expect more than a single response if it sent out a >> single update. This may thus require updated processing in the MAAR. >> >> G2. Sect. 3.3 suggests that PBAs could be sent straight from the previous >> MAAR >> to the current MAAR. How does this work if security associations are >> supposed >> to be applied? It would seem that, when following the security >> considerations, >> such cases are not covered. At least, this would warrant further >> explanation as >> in this case we suddenly have three involved security associations, which >> would >> also need to be established. >> >> G3. Sect 3.5 discusses deregistration and suggests that this can only be >> done by >> timeout; I understand the rationale but can any risks arise on continued >> resource >> consumption (DoS attacks)? >> >> G4. Sect. 6.: As alluded to above, the security considerations may need >> expanding. >> >> Nits: >> p.12: "information are" -> "information is" >> p.12: "influence on" -> "influence" >> >> > > -- > 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 --000000000000bf3eb305965b9d43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joerg,

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

Thanks,

Carlos

On Fri, Oct 18, 2019 at 1:24 PM CARLOS JESUS = BERNARDOS CANO <cjbc@it.uc3m.es&g= t; wrote:
Thanks a lot Joerg for your very comprehensive review.

<= /div>
We will carefully look at your comments and provide responses (wi= th proposals of text changes) in the next few days. I prefer to take some t= ime to properly address all your points.

Thanks!

Carlos

On Mon, Oct 14, 2019 at 10:49 PM Joerg = Ott via Datatracker <noreply@ietf.org> wrote:
Reviewer: Joerg Ott
Review result: Ready with Issues

Hi,

this document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org = if you reply to or forward this review.

The draft defines extensions to Proxy Mobile IPv6 to support a more distrib= uted
variant of mobility management. In essence, as a mobile node moves from one=
point of attachment (Mobility Anchor and Access Router, MAAR) to the next,<= br> its routing prefix with the previous MAAR(s) remain(s) and ongoing transpor= t
layer connections remain active and routed indirectly via the previous MAAR= ,
while new ones will use the present MAAR. The interactions of MAARs are
managed via a Central Mobility Database (CMD).

The draft is well written and good to follow, describing the protocols and<= br> extensions clearly. I just have two transport-specific concern and two gene= ral
operational issues that require further clarification in the draft.

The transport issues:

T1. Section 3.2. When the CMD acts as a relay for Proxy Binding Updates (PB= Us)
and Proxy Binding Acts (PBAs), the CMD may act as a relay of a single PBU t= o
multiple previous MAARs. If multiple previous MAARs exist, say k, (and ther= e
may be numerous in case of many fast handovers, e.g., with vehicular networ= ks),
the CMD creates k outgoing packets from a single incoming packet. This bear= s
a certain amplification risk (which may also need to be addressed in the se= curity
considerations section) but it also may lead to packet bursts originated fr= om the
CMD, albeit to different targets. Other protocols start introducing pacing = to avoid
bursts on the outgoing link, even if the packets do take different paths in= the end.
This may be worthwhile considering.

T2. Also in section 3.2, when relaying PBAs, the CMD serves as a transport = or
application endpoint and should have a way to deal with missing responses (after all, this is a connectionless protocol on top of an unreliable Inter= net).
A timeout is only mentioned for aggregation, but even there there the timeo= ut
is not specified, nor is a reference to, e.g., RFC 5213 or so to infer a ti= meout
used elsewhere.

General issues:

G1. Section 3.2 (again) specifies that responses are aggregated on p.10. Ho= w
does response aggregation work? How is error handling done?

Moreover, also on p.10, further below the draft states that if a timer expi= res,
the requests already received are forwarded. The missing ones come later. This seems to contradict aggregation because the originator (the currently<= br> server MAAR) does not expect more than a single response if it sent out a single update. This may thus require updated processing in the MAAR.

G2. Sect. 3.3 suggests that PBAs could be sent straight from the previous M= AAR
to the current MAAR. How does this work if security associations are suppos= ed
to be applied? It would seem that, when following the security consideratio= ns,
such cases are not covered. At least, this would warrant further explanatio= n as
in this case we suddenly have three involved security associations, which w= ould
also need to be established.

G3. Sect 3.5 discusses deregistration and suggests that this can only be do= ne by
timeout; I understand the rationale but can any risks arise on continued re= source
consumption (DoS attacks)?

G4. Sect. 6.: As alluded to above, the security considerations may need exp= anding.

Nits:
p.12: "information are" -> "information is"
p.12: "influence on" -> "influence"



--


--
--000000000000bf3eb305965b9d43-- From nobody Sun Nov 3 05:48:47 2019 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 6D8411200EC; Sun, 3 Nov 2019 05:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3cPaPN1xKdCa; Sun, 3 Nov 2019 05:48:42 -0800 (PST) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.in.tum.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DF3120089; Sun, 3 Nov 2019 05:48:41 -0800 (PST) Received: by mail.in.tum.de (Postfix, from userid 107) id 4C7C81C0403; Sun, 3 Nov 2019 14:48:39 +0100 (CET) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 1F0841C03FD; Sun, 3 Nov 2019 14:48:35 +0100 (CET) (Extended-Queue-bit tech_dnhcj@fff.in.tum.de) To: CARLOS JESUS BERNARDOS CANO , Joerg Ott Cc: draft-ietf-dmm-pmipv6-dlif.all@ietf.org, tsv-art@ietf.org, ietf@ietf.org, dmm References: <157108615425.24656.12786623966649135975@ietfa.amsl.com> From: Joerg Ott Message-ID: <33569fa4-6bfb-782c-d6a5-2f25b7a4fced@in.tum.de> Date: Sun, 3 Nov 2019 14:48:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] [Tsv-art] Tsvart 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: Sun, 03 Nov 2019 13:48:46 -0000 Hi Carlos, thanks much, will review shortly, but this will take about a week and a bit. Best, Jörg On 02.11.19 12:45, CARLOS JESUS BERNARDOS CANO wrote: > Hi Joerg, > > We've just posted a new revision addressing your comments. > > Thanks, > > Carlos > > On Fri, Oct 18, 2019 at 1:24 PM CARLOS JESUS BERNARDOS CANO > > wrote: > > Thanks a lot Joerg for your very comprehensive review. > > We will carefully look at your comments and provide responses (with > proposals of text changes) in the next few days. I prefer to take > some time to properly address all your points. > > Thanks! > > Carlos > > On Mon, Oct 14, 2019 at 10:49 PM Joerg Ott via Datatracker > > wrote: > > Reviewer: Joerg Ott > Review result: Ready with Issues > > Hi, > > this document has been reviewed as part of the transport area > review team's > ongoing effort to review key IETF documents. These comments were > written > primarily for the transport area directors, but are copied to > the document's > authors and WG to allow them to address any issues raised and > also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should > consider this > review as part of the last-call comments they receive. Please > always CC > tsv-art@ietf.org if you reply to or > forward this review. > > The draft defines extensions to Proxy Mobile IPv6 to support a > more distributed > variant of mobility management. In essence, as a mobile node > moves from one > point of attachment (Mobility Anchor and Access Router, MAAR) to > the next, > its routing prefix with the previous MAAR(s) remain(s) and > ongoing transport > layer connections remain active and routed indirectly via the > previous MAAR, > while new ones will use the present MAAR. The interactions of > MAARs are > managed via a Central Mobility Database (CMD). > > The draft is well written and good to follow, describing the > protocols and > extensions clearly. I just have two transport-specific concern > and two general > operational issues that require further clarification in the draft. > > The transport issues: > > T1. Section 3.2. When the CMD acts as a relay for Proxy Binding > Updates (PBUs) > and Proxy Binding Acts (PBAs), the CMD may act as a relay of a > single PBU to > multiple previous MAARs. If multiple previous MAARs exist, say > k, (and there > may be numerous in case of many fast handovers, e.g., with > vehicular networks), > the CMD creates k outgoing packets from a single incoming > packet. This bears > a certain amplification risk (which may also need to be > addressed in the security > considerations section) but it also may lead to packet bursts > originated from the > CMD, albeit to different targets. Other protocols start > introducing pacing to avoid > bursts on the outgoing link, even if the packets do take > different paths in the end. > This may be worthwhile considering. > > T2. Also in section 3.2, when relaying PBAs, the CMD serves as a > transport or > application endpoint and should have a way to deal with missing > responses > (after all, this is a connectionless protocol on top of an > unreliable Internet). > A timeout is only mentioned for aggregation, but even there > there the timeout > is not specified, nor is a reference to, e.g., RFC 5213 or so to > infer a timeout > used elsewhere. > > General issues: > > G1. Section 3.2 (again) specifies that responses are aggregated > on p.10. How > does response aggregation work? How is error handling done? > > Moreover, also on p.10, further below the draft states that if a > timer expires, > the requests already received are forwarded. The missing ones > come later. > This seems to contradict aggregation because the originator (the > currently > server MAAR) does not expect more than a single response if it > sent out a > single update. This may thus require updated processing in the MAAR. > > G2. Sect. 3.3 suggests that PBAs could be sent straight from the > previous MAAR > to the current MAAR. How does this work if security associations > are supposed > to be applied? It would seem that, when following the security > considerations, > such cases are not covered. At least, this would warrant further > explanation as > in this case we suddenly have three involved security > associations, which would > also need to be established. > > G3. Sect 3.5 discusses deregistration and suggests that this can > only be done by > timeout; I understand the rationale but can any risks arise on > continued resource > consumption (DoS attacks)? > > G4. Sect. 6.: As alluded to above, the security considerations > may need expanding. > > Nits: > p.12: "information are" -> "information is" > p.12: "influence on" -> "influence" > > > > -- > 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 > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > From nobody Sun Nov 3 18:56:28 2019 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 D34BA12002E for ; Sun, 3 Nov 2019 18:56:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 w7RqgMYBU9SI for ; Sun, 3 Nov 2019 18:56:23 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id E44E812001E for ; Sun, 3 Nov 2019 18:56:22 -0800 (PST) Received: from CNNIC-THINK (unknown [218.241.111.47]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0Dp8c1Nk79dQdKwBA--.29487S2; Mon, 04 Nov 2019 10:56:13 +0800 (CST) Date: Mon, 4 Nov 2019 10:56:10 +0800 From: "Z.W. Yan" To: "Satoru Matsushima" , dmm Cc: "Jong-Hyouk Lee" , "H Anthony Chan" , gengguanggang References: <49BD327C-5377-4166-BC7C-9F5FBA7FD4E3@gmail.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.156[cn] Mime-Version: 1.0 Message-ID: <201911041056098735678@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart111405140308_=----" X-CM-TRANSID: AQAAf0Dp8c1Nk79dQdKwBA--.29487S2 X-Coremail-Antispam: 1UD129KBjvdXoW7XFykAF47XF1rXry8JF4rAFb_yoWDAFc_CF Z8KF1jyayUCr4UXr47GF17JrnxXayvgw17Xw1DJr4xta4xZa1xurZ5urWfZr4xWr4DJr98 J3sxuFWfXry3WjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbTAYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAIxVCF xsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzxvEb7x7McIj6xIIjxv20xvE14v26r1j6r 18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vI r41lFcxC0VAYjxAxZF0Ew4CEw7xC0wCY02Avz4vE14v_Gr1l42xK82IYc2Ij64vIr41l4I 8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AK xVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIx AIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0D MIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4 xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU7CD7DUUUU X-CM-SenderInfo: x1dqqupqqluhdfq/ Archived-At: Subject: Re: [DMM] IETF106 - 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: Mon, 04 Nov 2019 02:56:26 -0000 This is a multi-part message in MIME format. ------=_001_NextPart111405140308_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIERNTSBjaGFpcnMsDQpJIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhIHNsb3QgdG8gZGlz Y3VzcyB0aGUgZm9sbG93aW5nIGRyYWZ0LiANCg0KLS0tLS0tLS0tLS0tLS0tDQpUaGUgdGl0bGUg b2YgdGhlIHByZXNlbnRhdGlvbjogTW9iaWxpdHkgQ2FwYWJpbGl0eSBOZWdvdGlhdGlvbiBhbmQg UHJvdG9jb2wgU2VsZWN0aW9uDQpQcmVzZW50ZXIgbmFtZTogWmhpd2VpIFlhbg0KVGltZSB5b3Ug bmVlZDogMTVtaW4NCkRyYWZ0IHJlZmVyZW5jZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXlhbi1kbW0tbWFuLTA1DQotLS0tLS0tLS0tLS0tLS0NCg0KVGhhbmtzIQ0KWi5XLiBZ YW4NCiANCkZyb206IFNhdG9ydSBNYXRzdXNoaW1hDQpEYXRlOiAyMDE5LTEwLTIyIDExOjA3DQpU bzogZG1tDQpTdWJqZWN0OiBbRE1NXSBJRVRGMTA2IC0gQ2FsbCBmb3IgQWdlbmRhIEl0ZW1zDQpG b2xrcywNCg0KVGhlIERNTSBjaGFpcnMgYXJlIHBsYW5uaW5nIHRoZSBkbW0gbWVldGluZyBpbiBT aW5nYXBvcmUgYXQgSUVURjEwNjoNCg0KMTh0aCBOb3ZlbWJlciwgTW9uZGF5IEFmdGVybm9vbiBT ZXNzaW9uIElJICgxNTo1MC0xNzo1MCkNCg0KSWYgeW91IGhhdmUgYSBkcmFmdCBvciBhbnkgdG9w aWNzIHlvdSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MsIHBsZWFzZSBzZW5kIHlvdXIgcmVxdWVzdCBm b3IgYWdlbmRhIHRpbWUgdG8gdGhlIGRtbSBjaGFpcnMuIFBsZWFzZSBpbmNsdWRlIHRoZSBpbmZv cm1hdGlvbiBpbiB0aGUgcmVxdWVzdCBhcyBmb2xsb3dpbmc6DQoNClRoZSB0aXRsZSBvZiB0aGUg cHJlc2VudGF0aW9uOg0KUHJlc2VudGVyIG5hbWU6DQpUaW1lIHlvdSBuZWVkOg0KRHJhZnQgcmVm ZXJlbmNlOiANCg0KUGxlYXNlIGhhdmUgYWdlbmRhIGl0ZW1zIHRvIHVzIGJ5IDIwMTktMTEtMDQg KE5vdmVtYmVyIDR0aCkuDQoNClJlbWluZGVyOg0KVGhlIGRyYWZ0IGN1dC1vZmYgZGF0ZTogMTR0 aCBOb3ZlbWJlciBVVEMgMjM6NTkgKDIgd2Vla3MgYmVmb3JlIHRoZSBtZWV0aW5nKS4NCg0KRGFw ZW5nICYgU3JpICYgU2F0b3J1DQo= ------=_001_NextPart111405140308_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A
= Hello, DMM chairs,
I would like to r= equest a slot to discuss the following draft. 

---------------
The title of the presentation: Mobility Capability Negotia= tion and Protocol Selection
Presenter name: Zhiwei Yan
Time you need= : 15min
Draft reference: https://tools.ietf.org/html/draft-yan-dmm-man-05
---------------

Thanks!
Z.W. Yan
 
=
Date: 2019-10-22&nb= sp;11:07
To: dmm=
Subject: [DMM] IETF106 - Call for Agenda Items
Folks,=

The DMM chairs are planning the dmm meeting in Singapore at IE= TF106:

18th Novemb= er, Monday Afternoon Session II (15:50-17:50)

If yo= u have a draft or any topics you would like to discuss, please send your r= equest for agenda time to the dmm chairs. Please include the information i= n the request as following:

The title of the presentation:
P= resenter name:
Time you need:
Draft reference: 

Please have agen= da items to us by 2019-11-04 (<= a href=3D"x-apple-data-detectors://1" dir=3D"ltr" x-apple-data-detectors= =3D"true" x-apple-data-detectors-type=3D"calendar-event" x-apple-data-dete= ctors-result=3D"1" style=3D"color: currentcolor; text-decoration-color: rg= ba(127, 127, 127, 0..380392);">November 4th).
Reminder:
The draft cut-off date: 14th Nov= ember UTC 23:59 (2 weeks b= efore the meeting).

D= apeng & Sri & Satoru
=0A ------=_001_NextPart111405140308_=------ From nobody Sun Nov 3 19:54:26 2019 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 D1FCE120878 for ; Sun, 3 Nov 2019 19:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=salowey-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 hiPYJg_TrLcT for ; Sun, 3 Nov 2019 19:54:21 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 31EB3120848 for ; Sun, 3 Nov 2019 19:54:21 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id h2so8627473qto.1 for ; Sun, 03 Nov 2019 19:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pq7nWTH53QfNHeZqya4ydbm0u7cyU4EiK4Uy7pcEDFI=; b=T9Fv4d1FGIlKKuR+BghkmoZt8UJUfoQXyllzJelxchZPcIQjALsmqaR67eD1b1MkEF u5bF6Rtj8w8+rffA2BJTjNudNHPp2iNa850X1qIm8ZiYjWUM++cm4YleO2lqXrDcmyzj 7c5bKO6YMHlA3dhXUc7Oaox43PjY5p/iuJq7ht/ww8Vel87kyPHGHRrADIYa1jfbNWrw iKKO0LJV8CsaZsO8j+mlyAdo6bkHfo4LUROZYdVuji88AmbOWeH9GxO04mLnBn+zycJQ qMguPvgF/7bUHLujqEGxOAHNZxPyuai77znwclMY5mr6/Yer1DjteF/XAs4lMxSZjssK RhPw== 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=Pq7nWTH53QfNHeZqya4ydbm0u7cyU4EiK4Uy7pcEDFI=; b=qUJ859RWCym74AvGZKuIYX2aZi5aOz9DbWRONN/s/Jj+QHLnCWOlJo17kFrluP7rCK IK/F1kTWtSYN+Ld2qw/ZXnCXabwl7FLVxXoDPAjlA34uGSzcMMrb+fRRa9DU9RWqexY+ N9FL3+/rWvIhlm0076W+YzFFwcvJZkgCD4vCc69/pd7GWVOLZO9GFBdnGx3T4jHqvhxs Bqjc5MXPiqFDa9GZ9woo/fLS9oOaQAWBh55aQMZg1T1Wkc2mG4b3KFDfgcUbKPR5NW1M GZA3lMmj0NK4CLshwr+ubVZ24ci1wgkirdWVeNnlPgBgNCZx8SsH8x0dKDSd+HIUrsZK RFJw== X-Gm-Message-State: APjAAAWoq9raCLYPPRnzjKukQjVkgsmmRk5qPvKACizjGKRFsV9E52Pg e5SqbdpVmmTB1UeovDgiLtwkUfsWLqAQwIROsgSPFNWW X-Google-Smtp-Source: APXvYqxWLhOfHUc1tl46FY/aD+dr76XdhOvuPqmx77yMuXSkNM2gU3A0ZMM6JTavE43wfWrRPdxvOUgOaOB4aS5BnYQ= X-Received: by 2002:a0c:9838:: with SMTP id c53mr20760057qvd.250.1572839659936; Sun, 03 Nov 2019 19:54:19 -0800 (PST) MIME-Version: 1.0 References: <157100555733.20750.5488529297693995498@ietfa.amsl.com> In-Reply-To: From: Joseph Salowey Date: Sun, 3 Nov 2019 19:54:09 -0800 Message-ID: To: CARLOS JESUS BERNARDOS CANO Cc: secdir , draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, The IESG , dmm Content-Type: multipart/alternative; boundary="00000000000038335805967d4542" Archived-At: Subject: Re: [DMM] Secdir 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: Mon, 04 Nov 2019 03:54:24 -0000 --00000000000038335805967d4542 Content-Type: text/plain; charset="UTF-8" Hi Carlos, THanks for addressing my comments. I don't have any further issues with the document. Cheers, Joe On Fri, Nov 1, 2019 at 5:06 AM CARLOS JESUS BERNARDOS CANO wrote: > Dear Joseph, > > We've just posted a new revision (-14) addressing all your comments. > > Thanks! > > Carlos > > On Fri, Oct 18, 2019 at 1:12 PM CARLOS JESUS BERNARDOS CANO < > cjbc@it.uc3m.es> wrote: > >> Dear Joseph, >> >> Thanks a lot for the review. We will improve the security consideration >> section by including also some of the considerations mentioned in draft- >> ietf-dmm-deployment-models-04, and also by better scoping current text. >> We believe we don't need much more in terms of text, as the document is >> informational, and the actual security mechanisms for a distributed >> anchoring solution would depend on the specifics of that solution. We can >> also better reflect that rational in the text. >> >> Thanks, >> >> Carlos >> >> On Mon, Oct 14, 2019 at 12:25 AM Joseph Salowey via Datatracker < >> noreply@ietf.org> wrote: >> >>> Reviewer: Joseph Salowey >>> Review result: Has Issues >>> >>> I have reviewed this document as part of the security directorate's >>> 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 just like any other last call comments. >>> >>> The summary of the review is the document has issues with the security >>> considerations section. >>> >>> The security consideration section is extremely light. It mainly >>> contains text >>> from RFC 7333. It seems that there should be more discussion of >>> security as it >>> relates to the different configurations and different cases. Do each >>> of these >>> cases have the same security properties and require the same types of >>> security >>> controls? >>> >>> Are the IPSEC recommendations mentioned in the security considerations of >>> draft-ietf-dmm-deployment-models-04 applicable for all the cases? >>> Should >>> these be pointed out in the security considerations section? >>> >>> >>> >> >> -- >> 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 > > --00000000000038335805967d4542 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,

THanks for addressing my com= ments.=C2=A0 I don't have any further issues with the document.=C2=A0= =C2=A0

Cheers,

Joe
<= /div>
O= n Fri, Nov 1, 2019 at 5:06 AM CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote:
Dear Joseph,

=
We've just posted a new revision (-14) addressing all your c= omments.

Thanks!

Carlos

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

Thanks a lot for the review. We will imp= rove the security consideration section by including also some of the consi= derations mentioned in=C2=A0draft-ietf-dmm<= /span>-deployment-models-04, and also by better scoping current text. We be= lieve we don't need much more in terms of text, as the document is info= rmational, and the actual security mechanisms for a distributed anchoring s= olution would depend on the specifics of that solution. We can also better = reflect that rational in the text.

Thanks,

Carlos

On Mon, Oct 14, 2019 at 12:25 AM Joseph Salow= ey via Datatracker <noreply@ietf.org> wrote:
Reviewer: Joseph Salowey
Review result: Has Issues

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

The summary of the review is the document has issues with the security
considerations section.

The security consideration section is extremely light.=C2=A0 It mainly cont= ains text
from RFC 7333.=C2=A0 It seems that there should be more discussion of secur= ity as it
relates to the different configurations and different cases.=C2=A0 =C2=A0Do= each of these
cases have the same security properties and require the same types of secur= ity
controls?

Are the IPSEC recommendations mentioned in the security considerations of draft-ietf-dmm-deployment-models-04 applicable for all the cases?=C2=A0 =C2= =A0Should
these be pointed out in the security considerations section?




--


--
--00000000000038335805967d4542-- From nobody Sun Nov 3 22:08:38 2019 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 510C61200F1; Sun, 3 Nov 2019 22:08:36 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <157284771625.13257.12467689189984909955@ietfa.amsl.com> Date: Sun, 03 Nov 2019 22:08:36 -0800 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-5g-uplane-analysis-03.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, 04 Nov 2019 06:08:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management WG of the IETF. Title : User Plane Protocol and Architectural Analysis on 3GPP 5G System Authors : Shunsuke Homma Takuya Miyasaka Satoru Matsushima Daniel Voyer Filename : draft-ietf-dmm-5g-uplane-analysis-03.txt Pages : 39 Date : 2019-11-03 Abstract: This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-5g-uplane-analysis-03 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-5g-uplane-analysis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-5g-uplane-analysis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 13:35:59 2019 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 B329912013B; Mon, 4 Nov 2019 13:35:50 -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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dmm@ietf.org Message-ID: <157290335065.13956.14719452150089257695@ietfa.amsl.com> Date: Mon, 04 Nov 2019 13:35:50 -0800 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-07.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, 04 Nov 2019 21:35:57 -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 : Segment Routing IPv6 for Mobile User Plane Authors : Satoru Matsushima Clarence Filsfils Miya Kohno Pablo Camarillo Daniel Voyer Charles E. Perkins Filename : draft-ietf-dmm-srv6-mobile-uplane-07.txt Pages : 29 Date : 2019-11-04 Abstract: This document shows the applicability of SRv6 (Segment Routing IPv6) to the user-plane of mobile networks. The network programming nature of SRv6 accomplish mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user-plane, providing flexibility, end-to-end network slicing and SLA control for various applications. This document describes the SRv6 mobile user plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-07 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-srv6-mobile-uplane-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 13:46:01 2019 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 9296C120953 for ; Mon, 4 Nov 2019 13:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uISmxLeu3Pmg for ; Mon, 4 Nov 2019 13:45:45 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 457991208CF for ; Mon, 4 Nov 2019 13:45:45 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id o9so3718689uat.8 for ; Mon, 04 Nov 2019 13:45:45 -0800 (PST) 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=k4m9rD5O620VPDDzsOxSrNoOYqDHXljovu/EIn/N5f4=; b=cVnX30T3oovhzP+XSM5oLfbv3gzRVZD9T3CnDSbIFWHLPxsZd92rFD6bz/AO4l2QKq xlnSGum/Ejz/bBIceyToq3FJxFBtZyzz0NmMF5uKaaVynTRq7cOuDQtZdINZhyPT5/Y2 kmi4syB5ssByVCjKxOYYYtUAYX1zq3U/IFkwhNkHFQesQmYAvkUHCMucpN7JR9/CZoq2 TkB1lrx8eE9pC0cs8+TZTlxe2p/BF8wRBRTggCZA8OsxPL+O2mTWJ0To5ifdCI7CBh+p WmVZx762EN924jbawAkZymcaWbpJa75ts1us5qcLGEf+IsZlDKGciRX6m54TOMQy593o TYkw== 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=k4m9rD5O620VPDDzsOxSrNoOYqDHXljovu/EIn/N5f4=; b=pTFa/Fr36JtKW77Hcr574FLd5AY79/JOt9Du8T95eebRgxBuL1WQRB16//okoXybrk VpdQcnI1QRZzczWtue6AJvt3iZBk6scrdytVsZsJziyRAweOPNNihecWZAPDTQqgfctr 9muaHwljVlX4MFmPwA+aDXNlqP4YNkcx11ibFEwkfD2djPkIm5wQJR2hNJwnhbef9yh5 AT3eF3wlm8ujXKMaV+nnCclFXF1yHz8yAsSmmoYGFTEbIc5DZfvFgpPcfsi4bg9/R+4r U+QiLg/c7bZurwpf02UsX1jW1dsTSSZ4HMAKqYeoGdNJOK+92dLAYYlOfOgsot57ni7x luBw== X-Gm-Message-State: APjAAAWXQmdm9pW8Zf1a7q7tPeHcIyIK4owTwdAN715kkf18Xmxwu7M6 AfDDTuyXtpyEqrOJ3KYUXwnhEYOq2LC1U8jeSDI= X-Google-Smtp-Source: APXvYqz9OKaQ7n2DxK+V3n5niVVmlHIZ70+DBvGChEfD8H8CJYvOP9ONIiU8Fo/b878mteHLB/v1+4Q7Gk3zh7SUGd0= X-Received: by 2002:ab0:189a:: with SMTP id t26mr13094266uag.87.1572903944369; Mon, 04 Nov 2019 13:45:44 -0800 (PST) MIME-Version: 1.0 References: <49BD327C-5377-4166-BC7C-9F5FBA7FD4E3@gmail.com> In-Reply-To: <49BD327C-5377-4166-BC7C-9F5FBA7FD4E3@gmail.com> From: Uma Chunduri Date: Mon, 4 Nov 2019 13:45:32 -0800 Message-ID: To: Satoru Matsushima Cc: dmm , richard.li@futurewei.com, sridharb@altiostar.com, john.kaippallimalil@futurewei.com, Jeff Tantsura , luismiguel.contrerasmurillo@telefonica.com, praveen.muley@nokia.com Content-Type: multipart/alternative; boundary="000000000000deba8905968c3cfe" Archived-At: Subject: Re: [DMM] IETF106 - 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: Mon, 04 Nov 2019 21:45:55 -0000 --000000000000deba8905968c3cfe Content-Type: text/plain; charset="UTF-8" Dear Satoru & Sri Based on the inputs from DMM group and offline discussions with other folks at IETF105 we published the 05 version https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/?include_text=1 It would be great if you can put at least 10 minutes for the above in the agenda. Either John or I would present the same. Cheers! -- Uma C. (on behalf of all co-authors) On Mon, Oct 21, 2019 at 8:07 PM Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Folks, > > The DMM chairs are planning the dmm meeting in Singapore at IETF106: > > 18th November, Monday Afternoon Session II (15:50-17:50) > > If you have a draft or any topics you would like to discuss, please send > your request for agenda time to the dmm chairs. Please include the > information in the request as following: > > The title of the presentation: > Presenter name: > Time you need: > Draft reference: > > Please have agenda items to us by 2019-11-04 (November 4th). > > Reminder: > The draft cut-off date: 14th November UTC 23:59 (2 weeks before the > meeting). > > Dapeng & Sri & Satoru > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --000000000000deba8905968c3cfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Satoru & Sri

= Based on the inputs from=C2=A0 DMM group=C2=A0and offline discussions with = other folks at IETF105=C2=A0 we published=C2=A0the 05 version

=

It would be great if you can put at l= east 10 minutes for the above in the agenda. Either John or I would present= the same.

Cheers!

--
Uma C.
(on behalf of all co-authors)=C2=A0

<= /div>
=C2=A0

On Mon, Oct 21, 2019 at 8:07 PM Satoru Matsushima= <satoru.matsushima@gmail= .com> wrote:
Folks,=

The DM= M chairs are planning the dmm meeting in Singapore at IETF106:
=

18th November, Monday Afternoon= Session II (15:50-17:50)

If y= ou have a draft or any topics you would like to discuss, please send your r= equest for agenda time to the dmm chairs. Please include the information in= the request as following:

The title of the presentation:
Presenter name:
Time y= ou need:
Draft reference:=C2=A0
Please have agenda items to us by=C2=A02019-11-04= =C2=A0(November 4th).

Reminder:
The draft cut-off date: 14t= h November=C2=A0UTC=C2=A023:59=C2=A0(2 weeks before the m= eeting).

Dapeng & Sri & Satoru
_______________________________________________ dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
--000000000000deba8905968c3cfe-- From nobody Mon Nov 4 17:20:57 2019 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 DE19612002E for ; Mon, 4 Nov 2019 17:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 u13lXlCLyyNp for ; Mon, 4 Nov 2019 17:20:53 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 CFA2C12000F for ; Mon, 4 Nov 2019 17:20:53 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id q16so8543697pll.11 for ; Mon, 04 Nov 2019 17:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:subject:cc:to:message-id; bh=KOeRH4JyTlrVjZhrKdKMonJLnuLb6Y+wvp0LaUCbS60=; b=QVmRFpNnVauMK4fjkV5wrafUERE+v6lk5JwDqs4cLf4EKhMnNmHT/2iLGESSOi1li6 xlx1Dn2J7O73c3dP95kLUZCQR8KeAEZaEsnYF24Ck7Vw/yZFCIoDo0yjnvAnsYnIBI7B u/kfi7ymqB6czdEK2i5/lEwuhzomtqUOKNUZeZNR+NPqbj4vB/iOosqdN9r08YxRqprQ u9OshVadL3epwPLcPFFSIEbRgW2/qbiQ/9e96SIiwQT+LwT1KEBbFAd0wDqOL6b5F1uk pLy4rj8fq2MUc7xREpwmO7zNSYW+3Hx+UB/NhEtSU2594RLqg88yrhqbsOFfimz2Kymp 402g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:subject:cc:to:message-id; bh=KOeRH4JyTlrVjZhrKdKMonJLnuLb6Y+wvp0LaUCbS60=; b=PQSVLENYB811VRv5TLbKo7lrrU/veCWXh6cT4LHkae3lJq2tk6EOFiZQSca8TORVHz coS12lpQJ5ppK7nvt6Je+oDV79eoTzHrw943MSM6XvqBRWMod46w+xlfHlbq4PVdws3n GEWg/3afLUu7bphqE3g2nR8nsjtaBke3zgD5mNxtEeBCpGMMmVfqfJa70QsGNU8SKMDq 5Kur3sjRNNvf+SL+/iZkMpVD1PiLk6b4C4xAli8R9fyvFBwxYR8OqezEeiDwAA/1MNRF 1SEkokKbEPxSy+OoIgr6h3liNuvFckzNKWqvN1iRMlK6bQHOUVv7Cjgq06mp37FmZ948 4ogw== X-Gm-Message-State: APjAAAW5WMACHu5WnwZoR00TGhALVFzszAvXKBADx+4ZmZo9cNGRtK49 mJt8PZYzJ7PRcrdzppBQu+mH+TS/ X-Google-Smtp-Source: APXvYqy/Ft8H9eLy9UqCBK6tvVzcs+xnQQ+X5+y4Fk89sVEfGbe+cNtACiHGNarr3rj0r+msWJJPoA== X-Received: by 2002:a17:902:7289:: with SMTP id d9mr30897408pll.121.1572916852866; Mon, 04 Nov 2019 17:20:52 -0800 (PST) Received: from [10.7.100.137] (adsl-70-234-233-187.dsl.rcsntx.sbcglobal.net. [70.234.233.187]) by smtp.gmail.com with ESMTPSA id m123sm17398787pfb.133.2019.11.04.17.20.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 17:20:52 -0800 (PST) From: Tetsuya Murakami Content-Type: multipart/alternative; boundary="Apple-Mail=_669AC778-2395-4184-9CFC-475F6081CD5B" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Mon, 4 Nov 2019 17:20:51 -0800 Cc: "satoru.matsushima@gmail.com Satoru" , Kentaro Ebisawa , Camarillo Pablo , ravishek@cisco.com To: dmm Message-Id: <118A8588-05D9-40F8-9F9E-A876E3683669@gmail.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: [DMM] New draft of draft-murakami-dmm-user-plane-message-encoding-00 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, 05 Nov 2019 01:20:56 -0000 --Apple-Mail=_669AC778-2395-4184-9CFC-475F6081CD5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi WG, We have posted the following new draft, = draft-murakami-dmm-user-plane-message-encoding, which defines User = Plane message encoding into SRH. We appreciate your review comments and = suggestions. Thanks, Tetsuya A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : User Plane Message Encoding Authors : Tetsuya Murakami Satoru Matsushima Kentaro Ebisawa Pablo Camarillo Garvia Ravi Shekhar Filename : = draft-murakami-dmm-user-plane-message-encoding-00.txt Pages : 8 Date : 2019-11-04 Abstract: This document defines the encoding of User Plane messages into Segment Routing Header (SRH). The SRH carries the User Plane messages over SRv6 Network. The IETF datatracker status page for this draft is: = https://datatracker.ietf.org/doc/draft-murakami-dmm-user-plane-message-enc= oding/ = There are also htmlized versions available at: = https://tools.ietf.org/html/draft-murakami-dmm-user-plane-message-encoding= -00 = = https://datatracker.ietf.org/doc/html/draft-murakami-dmm-user-plane-messag= e-encoding-00 = Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org = . Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ = _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce = Internet-Draft directories: http://www.ietf.org/shadow.html = or ftp://ftp.ietf.org/ietf/1shadow-sites.txt = = --Apple-Mail=_669AC778-2395-4184-9CFC-475F6081CD5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = WG,

We have posted = the following new draft, draft-murakami-dmm-user-plane-message-encoding,  which = defines User Plane message encoding into SRH. We appreciate your review comments and = suggestions.

Thanks,
Tetsuya


A New Internet-Draft is = available from the on-line Internet-Drafts directories.


       Title =           : User Plane = Message Encoding
       Authors =         : Tetsuya = Murakami
          &nb= sp;            = ;  Satoru Matsushima
          &nb= sp;            = ;  Kentaro Ebisawa
          &nb= sp;            = ;  Pablo Camarillo Garvia
          &nb= sp;            = ;  Ravi Shekhar
Filename        : = draft-murakami-dmm-user-plane-message-encoding-00.txt
Pages =           : = 8
Date =            : = 2019-11-04

Abstract:
  This = document defines the encoding of User Plane messages into
  Segment Routing Header (SRH).  The SRH = carries the User Plane
  messages over SRv6 = Network.


The IETF datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-murakami-dmm-user-plane-= message-encoding/

There are also htmlized versions = available at:
https://tools.ietf.org/html/draft-murakami-dmm-user-plane-messa= ge-encoding-00
https://datatracker.ietf.org/doc/html/draft-murakami-dmm-user-p= lane-message-encoding-00


Please note that it may take a = couple of minutes from the time of submission
until the htmlized version and diff are available = at tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
= --Apple-Mail=_669AC778-2395-4184-9CFC-475F6081CD5B-- From nobody Thu Nov 7 19:58:49 2019 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 9F16B1201DB for ; Thu, 7 Nov 2019 19:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=jQ3iurI4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ulIiEND5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyUWccXOpo3x for ; Thu, 7 Nov 2019 19:58:45 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B24512006E for ; Thu, 7 Nov 2019 19:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6219; q=dns/txt; s=iport; t=1573185525; x=1574395125; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=s7CsEmXfK1FoB/5mmLB2SKtahfJseUjea+br3zxY+QQ=; b=jQ3iurI4TMtkK2pKGcsH1HyZypydbMcvLsC/8uqNgggILLqkfWfRVhAH yw0WwEqiPuvORxCGjmLhxQVHNV4EGNyQ/cby5ozxpv/geWN+6z3qYt/HL FZTpNQ9xeEjblxGL09JK+cYQwRh+pBUW7b7wrSrZm5ce95aGLoXW6MVE7 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AjWuZAxPDkSp7liYBzN0l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjgI+PsYyUkEexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5BwAj58Rd/49dJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWwFAQELAYEbL1AFbFggBAsqCoRwgnUDiwIcMoIQiVaJRoRigS6?= =?us-ascii?q?BJANUCQEBAQwBASMKAgEBhEAChA4kNgcOAgMLAQEEAQEBAgEFBG2FNwyFUQE?= =?us-ascii?q?BAQEDEgsjAQE4DwIBCBEDAQIoByERFAkIAgQTIoMBgXlNAy4BAgynKwKBOIh?= =?us-ascii?q?ggieCfgEBBYE4BAxBQIJEDQuCFwMGgTYBjBMYgUA/hCM+gQSBF0cCAgEBgX0?= =?us-ascii?q?NhUGVSSSXXUEKgiSHF4oZhBEbgjyHYY11gWKEP5I7ghKPJwIEAgQFAg4BAQW?= =?us-ascii?q?BWQwmgVhwFRqDDVARFJA2GINbhRSFP3SBKI4/AYEOAQE?= X-IronPort-AV: E=Sophos;i="5.68,280,1569283200"; d="scan'208,217";a="573252742" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Nov 2019 03:58:44 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id xA83wiDx006069 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Nov 2019 03:58:44 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 21:58:43 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Nov 2019 21:58:43 -0600 Received: from NAM05-CO1-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; Thu, 7 Nov 2019 21:58:43 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cvmp3Z7Pq0rV3DABXmExZFS3ogC6B9KLSmRGUuOaX58W1FjFX0I+Guc8cfDsJUE9rny9ZWbmXZ8sOME2CgbK2ztz1g4zLJBwYU+NlOFXl47YcoLUc7GSiuwglON+y/gNx+z5rtjO1VwWsF/D2NIVhVOP9AIk6czJm3Qsf67fZxOVhw+NLlEBCVpL0mCnyBnhHhYBMluy47sqPh7TGjJg86g5kvW0C6XnChzR3q633RH0UflGdLAAG4c84DhvN45oH5STobXSv97lJLaeLu7ceo4uumeaEq3DQsFbPleJx0rGrc0RKUKs20vNai/g5gDAXZOCJcc5cQEEUxX8Wd310g== 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=s7CsEmXfK1FoB/5mmLB2SKtahfJseUjea+br3zxY+QQ=; b=XN1t214MpFO5l8Nbbz7nUTcY8y2p5q8yhjulBpFru5ioVafj5yVCQUm9lSa8kPoMIzPIoFLCGza2hjYCbu5A+wiX25d2dhPlw+nboIc/khsDtV++/gntwmFFcNiHfJkugzH4zIVWF6r7EUj9sOKo6GgaXSBsmeF5b1jl0cC0UqJTWLd55YKZ+QCMQpCCHP8dRGUnEPjwuJkK2QluZrDPRmmqfhTKQDrHs2YJdvlBiW33gYsWgsdGisA0j8IbcS3O+03i5PizPSd5PkIdsMYCF/CcZkah3dmZVEyAXKmouaYzaouD+8l/25kJbNdYsuLH9GdUjsHyrskaeBRgNSwBHA== 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=s7CsEmXfK1FoB/5mmLB2SKtahfJseUjea+br3zxY+QQ=; b=ulIiEND553V8nXBAkti3b64TrWlVnvTKQKsg+K1S4wa2KLt68okuUL1XWOZSCUNtUmoqgvq8HUMNdlFGcU0GmLGybfsjKtlQYfil+9CDQdWRDS8N8O8iuJs8AmMKMHV3C+pGwhiumLdTnKHdvTfr8djKkbpDGtfqk8fP4VSu/jM= Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB3621.namprd11.prod.outlook.com (20.178.238.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Fri, 8 Nov 2019 03:58:41 +0000 Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e5b0:1702:87b:b1e]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e5b0:1702:87b:b1e%5]) with mapi id 15.20.2430.020; Fri, 8 Nov 2019 03:58:41 +0000 From: "Sri Gundavelli (sgundave)" To: dmm Thread-Topic: [DMM] IETF106 - Call for Agenda Items Thread-Index: AQHVleBr2ddtJ8HFHkm/401NnraRKg== Date: Fri, 8 Nov 2019 03:58:40 +0000 Message-ID: References: <49BD327C-5377-4166-BC7C-9F5FBA7FD4E3@gmail.com> In-Reply-To: <49BD327C-5377-4166-BC7C-9F5FBA7FD4E3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgundave@cisco.com; x-originating-ip: [128.107.241.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 34f42e67-913e-4833-7332-08d763fff132 x-ms-traffictypediagnostic: BYAPR11MB3621: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0215D7173F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(366004)(376002)(396003)(39860400002)(199004)(189003)(446003)(11346002)(256004)(6916009)(36756003)(2616005)(66556008)(6486002)(229853002)(66946007)(25786009)(66476007)(14454004)(71190400001)(6436002)(64756008)(186003)(99286004)(54896002)(606006)(8676002)(478600001)(86362001)(966005)(71200400001)(66446008)(2906002)(26005)(6306002)(8936002)(14444005)(7736002)(6116002)(3846002)(102836004)(53546011)(6506007)(6246003)(76176011)(5660300002)(476003)(81156014)(81166006)(316002)(58126008)(66066001)(236005)(6512007)(76116006)(4744005)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3621; 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: dIXFsGHwoiS04+LjtCDV9eYwFLSSsBxK0+xoggP9Nuuq1nSM1hXMoI1bw7bol1rYhWmb5fJD9uLtH7hngKuav0BQJ//QPG/BBI0lCLeVU5dIcIsLLPE7kzN6CJ2DT9YyOPr9qWuhwyV55Xeci1nF8VSmrut0dSp/cZlIf3IBXBPxbYwkP/Dwpi3MjwDRaNB29fCtCf7p62Up3i70EH7GT7qPAiuzKg/CwDmqLM52RGodIQYozyEY14kAKJPyXGye20qPm7JLiuTbbkhJst69nKZA1HP2W/nKw/J6+yXIgTpk7rd+iqpPpFhfRdlY2ZkcBoL4LNLKfEWOb9llFDYYGRV2ARMPzTWzqAaAiklB6xlSab2CD3MjqywcheQfJlYryMFF2D41jnWtXjnvO9JAlRt0JOX9CnIcipvCw9RBjonQF3UNxuafiPWfLnvF9sU1J91C1HV/J7HWsK0deHPcvTuUkkKHuUFffPZSI84UDyc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_D9EA27933246E8sgundaveciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 34f42e67-913e-4833-7332-08d763fff132 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2019 03:58:40.9021 (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: 4yw1l1CcRsAgb+HITLFcf4jbxuLb6xdOz/2pkqChCoim7qmwxSCrbUBM3QMS83xGYkLbLNrjOrNvLSI+yUZyhw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3621 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [DMM] IETF106 - 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: Fri, 08 Nov 2019 03:58:48 -0000 --_000_D9EA27933246E8sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda is now posted. Please review. https://datatracker.ietf.org/doc/agenda-106-dmm/ Presenters: Please send your slides by Sunday, 17th Nov, 6PM SGT. Satoru & Sri From: dmm > on behalf of = Satoru Matsushima > Date: Monday, October 21, 2019 at 8:07 PM To: dmm > Subject: [DMM] IETF106 - Call for Agenda Items Folks, The DMM chairs are planning the dmm meeting in Singapore at IETF106: 18th November, Monday Afternoon Session II (15:50-17:50) If you have a draft or any topics you would like to discuss, please send yo= ur request for agenda time to the dmm chairs. Please include the informatio= n in the request as following: The title of the presentation: Presenter name: Time you need: Draft reference: Please have agenda items to us by 2019-11-04 (N= ovember 4th). Reminder: The draft cut-off date: 14th November UTC 23:59= (2 weeks before the meeting). Dapeng & Sri & Satoru --_000_D9EA27933246E8sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <80233B0B10A4A64180E31813CB3251AB@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Agenda is now posted. Please review.


Presenters: Please send your slides by Sunday, 17th Nov, 6PM SGT.
 

Satoru & Sri


From: dmm <dmm-bounces@ietf.org> on behalf of Satoru Matsush= ima <satoru.matsushima@gm= ail.com>
Date: Monday, October 21, 2019 at 8= :07 PM
To: dmm <dmm@ietf.org>
Subject: [DMM] IETF106 - Call for A= genda Items

Folks,

The DMM ch= airs are planning the dmm meeting in Singapore at IETF106:

18th November, Monday Afternoon Session II (15:50-17:50)
If you have a draft or any = topics you would like to discuss, please send your request for agenda time = to the dmm chairs. Please include the information in the request as followi= ng:

The title = of the presentation:
Presenter = name:
Time you n= eed:
Draft refe= rence: 

Please have agenda items to= us by 2019-11-04 (November 4th).

Reminder:
The draft = cut-off date: 14th November UTC 23:59 (2 weeks before the meeting).

Dapeng & Sri & Sato= ru
--_000_D9EA27933246E8sgundaveciscocom_-- From nobody Sun Nov 17 14:51:48 2019 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 9111A12008F; Sun, 17 Nov 2019 14:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xKPA-iUU4qHM; Sun, 17 Nov 2019 14:51:42 -0800 (PST) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.in.tum.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE4112008C; Sun, 17 Nov 2019 14:51:42 -0800 (PST) Received: by mail.in.tum.de (Postfix, from userid 107) id 912CD1C0403; Sun, 17 Nov 2019 23:51:39 +0100 (CET) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id A750F1C03F4; Sun, 17 Nov 2019 23:51:35 +0100 (CET) (Extended-Queue-bit tech_ovdez@fff.in.tum.de) To: CARLOS JESUS BERNARDOS CANO , Joerg Ott Cc: draft-ietf-dmm-pmipv6-dlif.all@ietf.org, tsv-art@ietf.org, ietf@ietf.org, dmm References: <157108615425.24656.12786623966649135975@ietfa.amsl.com> From: Joerg Ott Message-ID: <18fe369b-5dab-f6df-a5eb-25fae589e2c0@in.tum.de> Date: Mon, 18 Nov 2019 06:51:32 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DMM] [Tsv-art] Tsvart 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: Sun, 17 Nov 2019 22:51:46 -0000 Hi Carlos, thanks for the update. I checked and, well, I was hoping for more than just a few statements in the text reflecting my comments below. Actually, I was wondering if some of the protocol mechanisms would need updating to make sure that everything works. Given that the target of the document is experimental, missing bits may not be such a big deal, it is for experimentation after all. Still, for example, pacing could be spec'ed more precisely. And I am not sure how much you guys thought about security associations altogether (I am not a security person and I don't play one on TV either). The secdir review provided other comments. Are all those taken care of now? Best, Jörg On 02.11.19 12:45, CARLOS JESUS BERNARDOS CANO wrote: > Hi Joerg, > > We've just posted a new revision addressing your comments. > > Thanks, > > Carlos > > On Fri, Oct 18, 2019 at 1:24 PM CARLOS JESUS BERNARDOS CANO > > wrote: > > Thanks a lot Joerg for your very comprehensive review. > > We will carefully look at your comments and provide responses (with > proposals of text changes) in the next few days. I prefer to take > some time to properly address all your points. > > Thanks! > > Carlos > > On Mon, Oct 14, 2019 at 10:49 PM Joerg Ott via Datatracker > > wrote: > > Reviewer: Joerg Ott > Review result: Ready with Issues > > Hi, > > this document has been reviewed as part of the transport area > review team's > ongoing effort to review key IETF documents. These comments were > written > primarily for the transport area directors, but are copied to > the document's > authors and WG to allow them to address any issues raised and > also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should > consider this > review as part of the last-call comments they receive. Please > always CC > tsv-art@ietf.org if you reply to or > forward this review. > > The draft defines extensions to Proxy Mobile IPv6 to support a > more distributed > variant of mobility management. In essence, as a mobile node > moves from one > point of attachment (Mobility Anchor and Access Router, MAAR) to > the next, > its routing prefix with the previous MAAR(s) remain(s) and > ongoing transport > layer connections remain active and routed indirectly via the > previous MAAR, > while new ones will use the present MAAR. The interactions of > MAARs are > managed via a Central Mobility Database (CMD). > > The draft is well written and good to follow, describing the > protocols and > extensions clearly. I just have two transport-specific concern > and two general > operational issues that require further clarification in the draft. > > The transport issues: > > T1. Section 3.2. When the CMD acts as a relay for Proxy Binding > Updates (PBUs) > and Proxy Binding Acts (PBAs), the CMD may act as a relay of a > single PBU to > multiple previous MAARs. If multiple previous MAARs exist, say > k, (and there > may be numerous in case of many fast handovers, e.g., with > vehicular networks), > the CMD creates k outgoing packets from a single incoming > packet. This bears > a certain amplification risk (which may also need to be > addressed in the security > considerations section) but it also may lead to packet bursts > originated from the > CMD, albeit to different targets. Other protocols start > introducing pacing to avoid > bursts on the outgoing link, even if the packets do take > different paths in the end. > This may be worthwhile considering. > > T2. Also in section 3.2, when relaying PBAs, the CMD serves as a > transport or > application endpoint and should have a way to deal with missing > responses > (after all, this is a connectionless protocol on top of an > unreliable Internet). > A timeout is only mentioned for aggregation, but even there > there the timeout > is not specified, nor is a reference to, e.g., RFC 5213 or so to > infer a timeout > used elsewhere. > > General issues: > > G1. Section 3.2 (again) specifies that responses are aggregated > on p.10. How > does response aggregation work? How is error handling done? > > Moreover, also on p.10, further below the draft states that if a > timer expires, > the requests already received are forwarded. The missing ones > come later. > This seems to contradict aggregation because the originator (the > currently > server MAAR) does not expect more than a single response if it > sent out a > single update. This may thus require updated processing in the MAAR. > > G2. Sect. 3.3 suggests that PBAs could be sent straight from the > previous MAAR > to the current MAAR. How does this work if security associations > are supposed > to be applied? It would seem that, when following the security > considerations, > such cases are not covered. At least, this would warrant further > explanation as > in this case we suddenly have three involved security > associations, which would > also need to be established. > > G3. Sect 3.5 discusses deregistration and suggests that this can > only be done by > timeout; I understand the rationale but can any risks arise on > continued resource > consumption (DoS attacks)? > > G4. Sect. 6.: As alluded to above, the security considerations > may need expanding. > > Nits: > p.12: "information are" -> "information is" > p.12: "influence on" -> "influence" > > > > -- > 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 > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art > From nobody Mon Nov 18 00:35:25 2019 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 1887D12087D for ; Mon, 18 Nov 2019 00:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=WSrYndyL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OQ4MmW8Z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5Nw9EP5xd-M for ; Mon, 18 Nov 2019 00:35:21 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240D61200CE for ; Mon, 18 Nov 2019 00:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3720; q=dns/txt; s=iport; t=1574066120; x=1575275720; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WiefHZooV8lT9Qn/W9qJCfkGkqXyJ3o+xyqaLpj4v+c=; b=WSrYndyLGPulgY9l5n0iDlUE40wrVE4Rgxd6oJ9daVSYiduE7Xkx7KNm 17GcoslnUDN9j7UaWuf+12nRK4sWKir3YG2l7GQ+P75ripR3nA3hkiy51 ujRb0S/GTSEQw3QivD+VUOikybna3wDDPYw7ujPms1RAm6Chke924ac80 s=; IronPort-PHdr: =?us-ascii?q?9a23=3Au0rubBI2EfrAhKaZitmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFb0MfjmZjI3NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AAAcV9Jd/4ENJK1iAxwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYFrBgEBCwGBSiQsBYFEIAQLKoQqg0YDinFOgWslmACBLhSBEAN?= =?us-ascii?q?UCQEBAQwBAS0CAQGEQAIXggwkNQgOAgMLAQEEAQEBAgEFBG2FNwELhVEBAQE?= =?us-ascii?q?BAxIREQwBATgLBAIBCBEDAQIDAiYCAgIwFQYBAQUDAgQTIoMAgkcDLgECoyg?= =?us-ascii?q?CgTiIYHWBMoJ+AQEFgkmCNxiCFwmBDigBhXuGGRiBQD+BOAwTgkw+hA1PCia?= =?us-ascii?q?CSTKCLI1IgkueGgqCKpVPFAeCPodojgeBZIRZiW+aCAIEAgQFAg4BAQWBVAE?= =?us-ascii?q?2gVhwFRohKgGCQVARFJEag3OKU3SBKI04AQE?= X-IronPort-AV: E=Sophos;i="5.68,319,1569283200"; d="scan'208";a="440909344" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Nov 2019 08:35:19 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xAI8ZJ9S012634 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 18 Nov 2019 08:35:19 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 02:35:18 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 02:35:18 -0600 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Nov 2019 02:35:18 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VkGky6OKbEt71OTB9q8MblhTJLhfTkWYyTLpp2wSfWdlWnIWw9BQUw3MXvzx7k5A/Ytyl1yeA8W/dJqFIKwgTwMOREgwa7RTNBux3Iz+rHRJZRjS99pbFzSxSDqdA6vNKpz0037W/QeuuL9DC8oX9pLQOlpgBHT5YeUZQX9i0Bnn4btB1e4N4kjO1QpPho6UVS0NYcs2q0GffRBU4hk21vgxU7McSFHLlJrb4QHBb2jq37+KSdwQ/6JOBkgWe3N+dnEmxRQgEAKGLBWjazvLo4F2Lsp9wW2ZZPBclr9IhT2l+C1yy0GnXVMdc7u9ypHtr97fZsgZg/HZ0pfunL1kkg== 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=WiefHZooV8lT9Qn/W9qJCfkGkqXyJ3o+xyqaLpj4v+c=; b=TOOJhyACEmbnKJVCn+TpBmIu2BxXjFId5IaEy5YohY4HU7udRd5JB4LrrJGcPO6QJhvU677qRPmHeuT+fpFq/WilQo3med9OLITEcx6vYEKsOiJd2l4rJ1n20Kv5plU9Kj5gNyn9Ab7ceT0JhlUjvlnp/CylgesXuBgKj50gsaV4a4Pt4Hxl4J852hdxSRL02klGlQY8BNUr7VouA0xiPz39BbBmOa21qVAxmZqUKcWQNfTKNO9gf+hXnVBjjoedHc8xhdkV739VHgplVx+dC5X1O0OpX6+kFgWEKFs+ARLv1e8VaJUWNJyoDpdDtDpDAyMiv9K06s0MtlOgNA4A0w== 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=WiefHZooV8lT9Qn/W9qJCfkGkqXyJ3o+xyqaLpj4v+c=; b=OQ4MmW8ZPyrzLFZ8+o3wpH5Fnono9SMnUjzk/7xXwYdfkNHWv3ZoziRQ4O4n6OG0/s6MAj4XNstJjVuJPDT/N+3lCNAYZmLtaveUExvz2Ae5dYNP5ZZUYgc0ukZEvJ7zlhl6MntMGshsOY0IFicTazsRUiW7kHkLWKHGXMLq0Tg= Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB2679.namprd11.prod.outlook.com (52.135.227.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Mon, 18 Nov 2019 08:35:17 +0000 Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e5b0:1702:87b:b1e]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e5b0:1702:87b:b1e%5]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 08:35:17 +0000 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: IPR Statement RE: draft-ietf-dmm-srv6-mobile-uplane-07 Thread-Index: AQHVlmeG0NcroN1OqE+FNbmtIfDsY6eRKG0A//763AA= Date: Mon, 18 Nov 2019 08:35:17 +0000 Message-ID: References: <20191108190535.544366002F@sjc-wwpl-cpol1.cisco.com> <0D57B6CC-2891-4448-BCF0-9E04BF741091@cisco.com> In-Reply-To: <0D57B6CC-2891-4448-BCF0-9E04BF741091@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.f.191014 authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgundave@cisco.com; x-originating-ip: [2001:420:c0d4:1001::d9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f5b77b6-af8c-4f20-8f37-08d76c023d8b x-ms-traffictypediagnostic: BYAPR11MB2679: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(39860400002)(366004)(396003)(13464003)(189003)(199004)(186003)(58126008)(256004)(33656002)(6916009)(5640700003)(6486002)(6436002)(6512007)(66446008)(229853002)(66556008)(66476007)(2501003)(2616005)(36756003)(476003)(46003)(71200400001)(71190400001)(25786009)(76176011)(6506007)(53546011)(102836004)(11346002)(446003)(99286004)(14454004)(81156014)(1730700003)(8676002)(486006)(2351001)(81166006)(8936002)(316002)(478600001)(305945005)(2473003)(6116002)(7736002)(86362001)(5660300002)(66946007)(2906002)(76116006)(91956017)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2679; H:BYAPR11MB3558.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: muG6zGBNnLTNWsibyplp0bBcE6Od+HtzzgLg9g6dnSRVCcxjcKYU9MkZqo1tfDONZMSHjnj3hk26V2FHLDZWx/t9WmjvUPhyeOax4QuO1qfOhkeVdymhcagA4fyhXQfq92Jv3qQcN6u41odKtt24gK2heaJ4CEZvg+ai0MUySYjwLMLHOafvg8w0QyW6HWRUDjLFhuNO+XosI9sYfz+LxPHP7/tBgAOyPry9d/2K42xcZWkX9jYFbhqn8BAX60ku6xPpQgqwJemRbCp7JoidrjtWycbsP7DMPR/d6ZyuEcjv04ZxOTh7yJJA4Pi2QuskKD/M+TRO7gmk/X5UA8WK5c4sIP1znWlYXEdfjUoMExppU5jRpjxv2NDd2VHFkWBF2KVtoSVTk2BpV1PgvIzpj2h5Nxz27AfHQB9hHoeEot41peScGKHGvAl7f/gD/UYV x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8B10A3CB59AC2A4C9A6E8C252C88F184@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6f5b77b6-af8c-4f20-8f37-08d76c023d8b X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 08:35:17.3705 (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: JFz5PuIdo7zzty6BzdFqDwzMeEs71RNcdcOQaFyO8GaApJr8J57eeXWzTsXnFeWLajMjN77RDa2/81Tk+PmaOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2679 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: [DMM] FW: IPR Statement RE: draft-ietf-dmm-srv6-mobile-uplane-07 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, 18 Nov 2019 08:35:23 -0000 QXV0aG9ycy9XRzogUGxlYXNlIHJldmlldyB0aGlzIElQUiBkaXNjbG9zdXJlLCBhbmQgcHJvdmlk ZSB5b3VyIGZlZWRiYWNrIG9uIHRoZSBtYWlsZXIuDQoNClNyaQ0KDQrvu79PbiAxMS8xOC8xOSwg MTI6MTAgQU0sICJQYWJsbyBDYW1hcmlsbG8gKHBjYW1hcmlsKSIgPHBjYW1hcmlsQGNpc2NvLmNv bT4gd3JvdGU6DQoNCiAgICBEZWFyIGNoYWlycywNCiAgICANCiAgICBUaGVyZSBoYXMgYmVlbiBh biBJUFIgZGlzY2xvc3VyZSBmb3IgdGhpcyBkcmFmdC4gVGhpcyBJUFIgaGFzIG5vdCBiZWVuIHJl ZmxlY3RlZCBpbiB0aGUgZHJhZnQgdHJhY2tlci4NCiAgICBQbGVhc2UgbGV0IG1lIGtub3cgd2hl dGhlciB0aGVyZSBpcyBhbnkgYWN0aW9uIG5lZWRlZCBmcm9tIG15IHNpZGUuDQogICAgDQogICAg VGhhbmtzLA0KICAgIFBhYmxvLg0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQogICAgRnJvbTogInJhbGJyaWdoQGNpc2NvLmNvbSIgPHJhbGJyaWdoQGNpc2NvLmNvbT4NCiAg ICBEYXRlOiBTYXR1cmRheSwgOSBOb3ZlbWJlciAyMDE5IGF0IDAzOjA1DQogICAgVG86ICJpZXRm LWlwckBpZXRmLm9yZyIgPGlldGYtaXByQGlldGYub3JnPg0KICAgIENjOiAiY2YobWFpbGVyIGxp c3QpIiA8Y2ZAY2lzY28uY29tPiwgIk1peWEgS29obm8gKG1rb2hubykiIDxta29obm9AY2lzY28u Y29tPiwgIlBhYmxvIENhbWFyaWxsbyAocGNhbWFyaWwpIiA8cGNhbWFyaWxAY2lzY28uY29tPg0K ICAgIFN1YmplY3Q6IElQUiBTdGF0ZW1lbnQgUkU6IGRyYWZ0LWlldGYtZG1tLXNydjYtbW9iaWxl LXVwbGFuZS0wNw0KICAgIA0KICAgICAgICBDaXNjbyBpcyB0aGUgb3duZXIgb2YgVVMgUHVibGlz aGVkIFBhdGVudCBBcHBsaWNhdGlvbiAyMDE5MDI4ODg3MyBlbnRpdGxlZCAiUGFja2V0IENvbW11 bmljYXRpb25zIFByb3ZpZGluZyBQYWNrZXQgRm9yd2FyZGluZyBFZmZpY2llbmNpZXMgaW4gYSBO ZXR3b3JrIGluY2x1ZGluZyBVc2luZyBhIFNlZ21lbnQgUm91dGluZyBhbmQgVHVubmVsIEV4Y2hh bmdlIiB3aGljaCB3YXMgZmlsZWQgb24gTWFyY2ggMTksIDIwMTgsIHJlbGF0aW5nIHRvIHRoZSBz dWJqZWN0IG1hdHRlciBvZiAiU2VnbWVudCBSb3V0aW5nIElQdjYgZm9yIE1vYmlsZSBVc2VyIFBs YW5lIiA8ZHJhZnQtaWV0Zi1kbW0tc3J2Ni1tb2JpbGUtdXBsYW5lLTA3Pi4gDQogICAgICAgICAN CiAgICAgICAgSWYgdGVjaG5vbG9neSBpbiB0aGlzIGRvY3VtZW50IGlzIGluY2x1ZGVkIGluIGEg c3RhbmRhcmQgYWRvcHRlZCBieSBJRVRGIGFuZCBhbnkgY2xhaW1zIG9mIGFueSBDaXNjbyBwYXRl bnRzIGFyZSBuZWNlc3NhcnkgZm9yIHByYWN0aWNpbmcgdGhlIHN0YW5kYXJkLCBhbnkgcGFydHkg d2lsbCBoYXZlIHRoZSByaWdodCB0byB1c2UgYW55IHN1Y2ggcGF0ZW50IGNsYWltcyB1bmRlciBy ZWFzb25hYmxlLCBub24tZGlzY3JpbWluYXRvcnkgdGVybXMsIHdpdGggcmVjaXByb2NpdHksIHRv IGltcGxlbWVudCBhbmQgZnVsbHkgY29tcGx5IHdpdGggdGhlIHN0YW5kYXJkLg0KICAgICAgICAg DQogICAgICAgIFRoZSByZWFzb25hYmxlIG5vbi1kaXNjcmltaW5hdG9yeSB0ZXJtcyBhcmU6DQog ICAgICAgICANCiAgICAgICAgSWYgdGhpcyBzdGFuZGFyZCBpcyBhZG9wdGVkLCBDaXNjbyB3aWxs IG5vdCBhc3NlcnQgYW55IHBhdGVudHMgb3duZWQgb3IgY29udHJvbGxlZCBieSBDaXNjbyBhZ2Fp bnN0IGFueSBwYXJ0eSBmb3IgbWFraW5nLCB1c2luZywgc2VsbGluZywgaW1wb3J0aW5nIG9yIG9m ZmVyaW5nIGZvciBzYWxlIGEgcHJvZHVjdCB0aGF0IGltcGxlbWVudHMgdGhlIHN0YW5kYXJkLCBw cm92aWRlZCwgaG93ZXZlciB0aGF0IENpc2NvIHJldGFpbnMgdGhlIHJpZ2h0IHRvIGFzc2VydCBp dHMgcGF0ZW50cyAoaW5jbHVkaW5nIHRoZSByaWdodCB0byBjbGFpbSBwYXN0IHJveWFsdGllcykg YWdhaW5zdCBhbnkgcGFydHkgdGhhdCBhc3NlcnRzIGEgcGF0ZW50IGl0IG93bnMgb3IgY29udHJv bHMgKGVpdGhlciBkaXJlY3RseSBvciBpbmRpcmVjdGx5KSBhZ2FpbnN0IENpc2NvIG9yIGFueSBv ZiBDaXNjbydzIGFmZmlsaWF0ZXMgb3Igc3VjY2Vzc29ycyBpbiB0aXRsZSBvciBhZ2FpbnN0IGFu eSBwcm9kdWN0cyBvZiBDaXNjbyBvciBhbnkgcHJvZHVjdHMgb2YgYW55IG9mIENpc2NvJ3MgYWZm aWxpYXRlcyBlaXRoZXIgYWxvbmUgb3IgaW4gY29tYmluYXRpb24gd2l0aCBvdGhlciBwcm9kdWN0 czsgYW5kIENpc2NvIHJldGFpbnMgdGhlIHJpZ2h0IHRvIGFzc2VydCBpdHMgcGF0ZW50cyBhZ2Fp bnN0IGFueSBwcm9kdWN0IG9yIHBvcnRpb24gdGhlcmVvZiB0aGF0IGlzIG5vdCBuZWNlc3Nhcnkg Zm9yIGNvbXBsaWFuY2Ugd2l0aCB0aGUgc3RhbmRhcmQuDQogICAgICAgICANCiAgICAgICAgUm95 YWx0eS1iZWFyaW5nIGxpY2Vuc2VzIHdpbGwgYmUgYXZhaWxhYmxlIHRvIGFueW9uZSB3aG8gcHJl ZmVycyB0aGF0IG9wdGlvbi4NCiAgICAgICAgDQogICAgICAgIEZvciBpbmZvcm1hdGlvbiBjb250 YWN0Og0KICAgICAgICAgDQogICAgICAgIERhbiBMYW5nDQogICAgICAgIFZpY2UgUHJlc2lkZW50 IGFuZCBEZXB1dHkgR2VuZXJhbCBDb3Vuc2VsIA0KICAgICAgICBDaXNjbyBTeXN0ZW1zLCBJbmMu DQogICAgICAgICsxIDQwOC01MjYtNjY3Mg0KICAgICAgICBzdGFuZGFyZHMtaXByQGNpc2NvLmNv bQ0KICAgICAgICANCiAgICAgICAgDQogICAgDQogICAgDQoNCg== From nobody Tue Nov 19 18:13:49 2019 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 015E41200E5 for ; Tue, 19 Nov 2019 18:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 wbgMlnXFUVvf for ; Tue, 19 Nov 2019 18:13:41 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750047.outbound.protection.outlook.com [40.107.75.47]) (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 421DF12002F for ; Tue, 19 Nov 2019 18:13:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=URSwLiVI2CM9olzOnW7rN8kDwFDvuAwO8UcXNBi9l/0KCCqx/UlFSW5+j55fVj4tDnlFOaR62/XVqiS1duSbtbpJ6euEbd6qTSWu6OaP6HUlVcxSEWDomoyHR0YXOtFGOrzm57BfOaaRVh/lQFN2x50EDVhN4fbcdS/jOeZH2M7Xn9WgCylyH8a7tjJAyy9FMbx0F23xwB8Dv1TSBBTrZKfX3zyw5CevI7Lh3q+0Ze2D/padtu43aApU3LJV0pNkKqsGUas//VbYNN34m2b08DlTk6RCDWDAT87lWjpyjAS6uGXc2WazKctc/aQ8b1ETNKFR+v65idszPYVBEGqIWQ== 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=HyAnxPB3ZzY3H9N9bAkAi7MWyCesjB3IEmn0OHTqZUg=; b=fR2SNdzGjaITT4ZvntmAy8tbyu7uBUloF4G83hJ/+nQy6GxA/teZXXYJMAVWlAFNRa3Hbro+WnxbUUn1xzn/KhYHyJz9PkC5U388I6YNQDca0sWNgMlabi4Fh2jhDGCmpY1tWu3YBesj4VpxAff+M74swhXt2phycve/ku9RvwlFCUXzRfQ89ptdOMjsVxKAZUm9jM3nsCcEgth9ArkQQ0l/mh7X55BNJHGxr0hWFUFkqxOOajNvrsbAQmKoPs7cZnE8gOY4Ik2NKuvMLQYZ6S5+CEQLMFsNkxO8Udz8ANO7auj8DXkD2QC2NOGlCxk/DfmH/dW4XgKizCAceHf85Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HyAnxPB3ZzY3H9N9bAkAi7MWyCesjB3IEmn0OHTqZUg=; b=W76zH0H+fBaYiORXaJ/L0OREoi8RSvjrKM3ovA8mcTt4jGvLZvLu6ELWjSJtBFYtsG0cuTXgzN4U8pITbzCLO2iFl3kv30g70srWELi9tPd5hKIDqCqo4w4HgMHCSYQbNlFUY4sKuFDfrh+Px//EBgReakJU7Chz1DrYUk18Qxs= Received: from BYAPR15MB3078.namprd15.prod.outlook.com (20.178.239.16) by BYAPR15MB3398.namprd15.prod.outlook.com (20.179.59.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.30; Wed, 20 Nov 2019 02:13:36 +0000 Received: from BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::71e8:8974:a702:9622]) by BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::71e8:8974:a702:9622%3]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 02:13:36 +0000 From: David Allan I To: "dmm@ietf.org" Thread-Topic: Minutes for DMM at IETF 106 Thread-Index: AdWfRtbNPWe4lz1fTZ+KBPqF7PKb9A== Date: Wed, 20 Nov 2019 02:13:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.i.allan@ericsson.com; x-originating-ip: [2001:67c:370:128:b5ae:f579:2ddf:ba7f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23566691-3d3f-46e6-a462-08d76d5f4016 x-ms-traffictypediagnostic: BYAPR15MB3398: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(366004)(39860400002)(136003)(43544003)(199004)(189003)(5660300002)(66556008)(64756008)(25786009)(2906002)(76116006)(256004)(9326002)(66446008)(478600001)(66476007)(7736002)(6506007)(186003)(7696005)(74316002)(6916009)(14454004)(5024004)(14444005)(102836004)(52536014)(99286004)(8676002)(486006)(476003)(1730700003)(81156014)(81166006)(8936002)(71190400001)(71200400001)(46003)(33656002)(2501003)(66946007)(86362001)(54896002)(9686003)(316002)(6436002)(790700001)(6116002)(55016002)(6306002)(2351001)(4326008)(5640700003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB3398; H:BYAPR15MB3078.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ll1tcuO+AJ1ywy0MN8jVd8Vp4o+24bBUyG/6N+X4iYv3F8hq1qdNGoIVSigveM1a3wriO7DoVqgkjQMVYvFDUmv1re0RUBXqeUF3Jcu7Qu0DQNsSG5N9MpeHYivoChAHACKH0DesJHuVYoeEHwQAUPa6lsVJeJuGeGFkXZP5yG2Q0vKFM+MCd1uGZekXBBxNXmOvt4u5s3uVIKEQWxRohbdIMYjKZ4nkV8B/J7YlKuJT7WSG0Q/C1PD91Ymua7nG5usAt2vvr58uER68X/DJ8GqgR7eCH86W5Lu6EQowg8Xl8wcCWWCrnHBRrr72z1I7w2Wgvu/G7jAGOqpi8Q74qbVWEYSb8+v3QVIT35q1igVof9+frnhVTpYjhtwsX7znYy2HpbAO+HaaWsdtWfLoXsEQxcbgc63boq6dI/LODLfJyYftE9KZG4kg2CZHT5bd x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR15MB30780A2F2875D12751D5F605D04F0BYAPR15MB3078namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23566691-3d3f-46e6-a462-08d76d5f4016 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 02:13:35.8542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FOKywntc85j94O2wsmjNqq+hrtGfFjKJpXAmYh44y+mW4nyEsLwWxGnartyjLnMLdHAzjuoPtQQBXXrwZQzyQwylxBT5B1mArdRRcGgj0Jw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3398 Archived-At: Subject: [DMM] Minutes for DMM at IETF 106 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, 20 Nov 2019 02:13:48 -0000 --_000_BYAPR15MB30780A2F2875D12751D5F605D04F0BYAPR15MB3078namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi The following are the notes I captured on the Etherpad. Comments I was not= able to capture are indicated with . Apologies in advance for any inco= rrect attributions.... Cheers D DMM Monday 11/18/2019 Scribe #1: Dave Allan, Ericsson Shunsuke: CT groups looking to complete work for release 16 in March. Can w= e go to last call. Suresh: Requires WG review. We can also send a liaison. Cannot see a way = to complete this by March. Sri: Status of different items. FPC work ground to a halt, need a way forward. Distributed Mobility Anchoring, shepherd notes need to be redone. True for= proxy MIP as well. Suresh: On-demand mobility management has an RFC number assigned. It's don= e. SRv6 for Mobile User plane /Pablo - summary of updates, removed insertion. Added drop-in, double ended GTP in= terworking. removed support for unstructured PDU session type. Changes to h= andling of ethernet means new allocations would be required. Carlos: willing to review. User plane message encoding-00: Tetsuya Murakami Goal is to carry GTP-U message information. Proposes carrying information = in the unused tag field in the SRv6 header (?) . Proposed bit field defini= tions for end-marker etc. Add a TLV to carry 3GPP information. Penultimate Segment Popping must NOT be used. Proposed for WG adoption. Uma: Purpose is to remove GTP completely and replace with SRv6. Is there = any use case to send from the UE itself? Tetsuya: Sri: Does not extend to the UE. Suresh: Spectrum is expensive. Do not want GTP on the air. Dave: Stuff covered is either carried over PDCP or only of significance to = the gNodeB. Do not need GTP to UE. Sri: Need more feedback from WG and the AD. Keep doing the work and we'll = see about adoption. Transport Network Aware Mobility for 5G, Uma, John K. Current version narrows down choices for MTNC-ID in meta data. Looking for mapping from PDU session layer to transport network paths. Sri: Overlay to underlay mapping is not a new problem. Right. Uma: What has been deployed used non-standardized ways of mapping. We're lo= oking to streamline this. John: Wanted to converge on one solution. Added option for encoding contex= t ID in th outer header--> source UDP port. Sri: Where do you get this transport network context? John: It is not IETF work to come up with this mapping. Believe they have a= lso selected ACTN, but details still being resolved in SA5. TNF is a logic= al function, interfaces are IETF. 3GPP slice aspects NSSAI is related to wh= at a user is supplied. May be 1000 customers and 3 slices. Impacts N2 and = N4. Sri: Today you do mapping at a session level. What are the advantages of at= a slice level? John: DSCP is not immutable. QFI is too deep for packet inspection. Dave: Source port normally used for ECMP. Is this turned off? John: in the text. Only certain ranges used (?) Satoryu: You are proposing using the source port for mapping. What WG woul= d define this. Uma: This is a local mapping. Not a WG problem and is backwards compatibl= e. Suresh: If rewriting UDP ports, are you redoing the checksums? Uma: Done at the UPF where the UDP header originates. Xuesong: VLAN should not be excluded. Can user other encaps to respect the= information John: We can include that Marco: UDP is a bi-directional thing. Does the value need to be symmetric. John: We are considering unidirectional flows. Assume some symmetry. If usi= ng a range on the upstream, range does not need to correspond. QFI itself = insufficient. Tasuya: John: Range of the UDP port handled by the IP part. Tasuya: So do not use existing PFCP John: What about WG adoption? Sri: Can ask the group. Xuesong: Map in the RAN to the backhaul, this is isolated work. Sri: How to take this up. Xuesong: In the same WG. Not sure these are tied together and could be di= fferent drafts. John: What part? Xuesong: The solution space. Carlos: Also willing to review. Sri: Need more discussion, good feedback. Architecture Discussion on SRv6 mobile User plane, Miya Kohno How to map mobility data plane. Suggests SRv6 is the right choice for 5G. Suggests an additional user plane ID is required for slice mapping. PE red= undancy is an additional requirement. Goal is to have the UPF be part of the TN and not a CE. 3GPP entities do not care about IP routing?? Sidecar proxy can take care = of communication state exchange. BSID can be used for topology hiding. URLLC with duplication and elimination requires modification of GTP-U. Proposed for discussion. John: Good points on URLLC. How does SRv6 allow paths to be disjoint? Miya: Could provide TI-LFA and other tools. SR aware entities can directly = control the mechanisms. John: With a chain of N3/N9, how does SRv6 help? Suresh: What is this a separate document? Miya: SRv6 mobile user plane document simply describes the protocol. I want= ed to discuss more the architectural implications. Suresh: Text is useful, how it proceeds to be discussed. It is pretty depen= dent on other stuff. This comes up in IESG as supporting documents. If it = is to be separate and progress need to think about the write up. Sri: Good points. Uma: Good questions are asked. Can collapse GTPU and SRv6. We are envisio= ning a future of IPv6 only transport. When we started it ws NS1U. This is = a bigger discussion. Marco: Service mesh, what does this have to do with slicing. It is an imple= mentation matter. Miya: Conventional box thinking needs to be evaluated. Marco: What about proxies... . Miya: IF there could be a proxy that could do all routing and forwarding s= tuff and it sits in the host. We could provide routing in host. Rajeev: Liked the side car analogy, so the proxy was adjacent to the applic= ation itself. Marco: Sidecars function at a DHCP level. Rajeev: There is also the notion of application routing. Lines are blurring= and have been for some time. Suresh: If in a sidecar, the app does not need to know about it. Sri: Good work, needs more discussion. Uma: This and the last presentation are very much connected. Mobility capability negotiation and protocol selection Zhiwei Two categories, network and host based solutions. Suggests a negotiating discipline. Possible solutions for negotiation. ICMPv6 gets a new option. Suresh: Everything you say has been tried before. 2007-2008, it never worke= d. If the network can do it, it will do it. CMIP vs PMIP. The problem is n= ot technical. There is no deployment scenario where this will be useful. T= here is a past history of failure. Think about where and how you would use= this. Sri: May want to work with a few people, get some feedback, and decide whet= her to pursue. Rajeev: For an endpoint attached to cellular, going to a site GW, where is = this message going? Could be a side gateway. SO this notion of something i= n the RS an RA to allow mobility to work, needs to be compatible with outsi= de of the cellular world. It would have a low footprint. Suresh: The other ones were RS RA based. Uma: Why did it fail, security or what? Suresh: Not anchored in architectures anywhere. For good or bad, architect= ures done elsewhere. Stuff need to be anchored or it goes nowhere. Deploym= ent support. Everything Rajeev said was looked at. YANG for Protocol for Forwarding Policy Configuration (FPC)/ Satoru FPC did not touch any over the wire protocol. Decided to define a YANG mode= l to provide an API. After the update by Charlie, there has not been further work, so the draft = has expired. Continuing to pursue this dependent on group/industry interest. Comments? Marco: co-author. This stuff is pretty stable. Since we have two pretty mat= ure parts, need to review. But we should progress them. Need reasonable rev= iews to proceed. It would be a pity not to proceed. Sri: Move this to the mailing list. Need to go through the process and get= some reviews. Suresh agrees. Session Closed --_000_BYAPR15MB30780A2F2875D12751D5F605D04F0BYAPR15MB3078namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

The following are the notes I captured on the Eth= erpad.  Comments I was not able to capture are indicated with <?>= ;.  Apologies in advance for any incorrect attributions….

Cheers

D

 

DMM Monday 11/18/2019

Scribe #1: Dave Allan, Ericsson

 

Shunsuke: CT groups looking to complete work for = release 16 in March. Can we go to last call. 

Suresh:  Requires WG review. We can also sen= d a liaison.  Cannot see a way to complete this by March.  <= o:p>

 

Sri: Status of different items.

FPC work ground to a halt, need a way forward.&nb= sp;

Distributed Mobility Anchoring, shepherd notes ne= ed to be redone.  True for proxy MIP as well. 

Suresh: On-demand mobility management has an RFC = number assigned.  It's done.

 

SRv6 for Mobile User plane /Pablo

- summary of updates, removed insertion. Added dr= op-in, double ended GTP interworking. removed support for unstructured PDU = session type. Changes to handling of ethernet means new allocations would b= e required. 

 

Carlos: willing to review.

&nbs= p;

User plane message encoding-00:  Tetsuya = Murakami

 

Goal is to carry GTP-U message information. = Proposes carrying information in the unused tag field in the SRv6 header (= ?) .  Proposed bit field definitions for end-marker etc.

 

Add a TLV to carry 3GPP information. 

Penultimate Segment Popping must NOT be used.&nbs= p;

 

Proposed for WG adoption.

 

Uma: Purpose is to remove GTP completely and repl= ace with SRv6.   Is there any use case to send from the UE itself= ?

Tetsuya:  <not captured>

Sri:  Does not extend to the UE.<= /p>

Suresh: Spectrum is expensive. Do not want GTP on= the air.

Dave: Stuff covered is either carried over PDCP o= r only of significance to the gNodeB. Do not need GTP to UE.

 

Sri: Need more feedback from WG and the AD. = Keep doing the work and we'll see about adoption.

 

Transport Network Aware Mobility for 5G, Uma, = John K.

 

Current version narrows down choices for MTNC-ID = in meta data. 

 

Looking for mapping from PDU session layer to tra= nsport network paths.  

Sri: Overlay to underlay mapping is not a new pro= blem. Right.  

Uma: What has been deployed used non-standardized= ways of mapping. We're looking to streamline this.

 

John:  Wanted to converge on one solution. A= dded option for encoding context ID in th outer header--> source UDP por= t.

Sri: Where do you get this transport network cont= ext?

John: It is not IETF work to come up with this ma= pping. Believe they have also selected ACTN, but details still being resolv= ed in SA5.  TNF is a logical function, interfaces are IETF. 3GPP slice= aspects NSSAI is related to what a user is supplied. May be 1000 customers and 3 slices.  Impacts N2 and N4.&= nbsp;

Sri: Today you do mapping at a session level. Wha= t are the advantages of at a slice level?

John: DSCP is not immutable. QFI is too deep for = packet inspection. 

Dave: Source port normally used for ECMP. Is this= turned off?

John: in the text. Only certain ranges used (?)

Satoryu:  You are proposing using the source= port for mapping. What WG would define this.  

Uma:  This is a local mapping.  Not a W= G problem and is backwards compatible.

Suresh: If rewriting UDP ports, are you redoing t= he checksums?  

Uma: Done at the UPF where the UDP header origina= tes. 

Xuesong: VLAN should not be excluded.  Can u= ser other encaps to respect the information

John:  We can include that

Marco: UDP is a bi-directional thing.  Does = the value need to be symmetric. 

John: We are considering unidirectional flows. As= sume some symmetry. If using a range on the upstream, range does not need t= o correspond.  QFI itself insufficient.

Tasuya:  <?>

John: Range of the UDP port handled by the IP par= t. 

Tasuya: So do not use existing PFCP <?>

John: What about WG adoption?

Sri: Can ask the group.

Xuesong: Map in the RAN to the backhaul, this is = isolated work.

Sri:  How to take this up.

Xuesong:  In the same WG.  Not sure the= se are tied together and could be different drafts. 

John:  What part?

Xuesong: The solution space.

Carlos: Also willing to review.

Sri:  Need more discussion, good feedback.

 

Architecture Discussion on SRv6 mobile User pl= ane, Miya Kohno

 

How to map mobility data plane.  Suggests SR= v6 is the right choice for 5G.

Suggests an additional user plane ID is required = for slice mapping.  PE redundancy is an additional requirement.

Goal is to have the UPF be part of the TN and not= a CE.

 

3GPP entities do not care about IP routing?? = ;  Sidecar proxy can take care of communication state exchange.  = BSID can be used for topology hiding.

URLLC with duplication and elimination requires m= odification of GTP-U.

Proposed for discussion.

 

John: Good points on URLLC. How does SRv6 allow p= aths to be disjoint? 

Miya: Could provide TI-LFA and other tools. SR aw= are entities can directly control the mechanisms.

John: With a chain of N3/N9, how does SRv6 help?&= nbsp; <go offline>

Suresh: What is this a separate document? &n= bsp;

Miya: SRv6 mobile user plane document simply desc= ribes the protocol. I wanted to discuss more the architectural implications= .

Suresh: Text is useful, how it proceeds to be dis= cussed. It is pretty dependent on other stuff. This comes up in IESG as sup= porting documents.  If it is to be separate and progress need to think= about the write up.

Sri: Good points.

Uma: Good questions are asked.  Can collapse= GTPU and SRv6.  We are envisioning a future of IPv6 only transport. W= hen we started it ws NS1U.  This is a bigger discussion.

Marco: Service mesh, what does this have to do wi= th slicing. It is an implementation matter.

Miya: Conventional box thinking needs to be evalu= ated.

Marco: What about proxies... <?>.

Miya:  IF there could be a proxy that could = do all routing and forwarding stuff and it sits in the host. We could provi= de routing in host.

Rajeev: Liked the side car analogy, so the proxy = was adjacent to the application itself.  

Marco:  Sidecars function at a DHCP level.&n= bsp;

Rajeev: There is also the notion of application r= outing. Lines are blurring and have been for some time.

Suresh:  If in a sidecar, the app does not n= eed to know about it. 

Sri: Good work, needs more discussion.  = ;

Uma: This and the last presentation are very much= connected.

 

Mobility capability negotiation and protocol s= election  Zhiwei

 

Two categories, network and host based solutions.=   

 

Suggests a negotiating discipline.

 

Possible solutions for negotiation.  

ICMPv6 gets a new option. 

 

Suresh: Everything you say has been tried before.= 2007-2008, it never worked. If the network can do it, it will do it. = CMIP vs PMIP. The problem is not technical. There is no deployment scenari= o where this will be useful.  There is a past history of failure.  Think about where and how you would use t= his.

 

Sri: May want to work with a few people, get some= feedback, and decide whether to pursue.

Rajeev: For an endpoint attached to cellular, goi= ng to a site GW, where is this message going? Could be a side gateway. = ; SO this notion of something in the RS an RA to allow mobility to work, ne= eds to be compatible with outside of the cellular world.  It would have a low footprint.   

Suresh: The other ones were RS RA based. 

Uma:  Why did it fail, security or what?

Suresh: Not anchored in architectures anywhere.&n= bsp; For good or bad, architectures done elsewhere.  Stuff need to be = anchored or it goes nowhere. Deployment support. Everything Rajeev said was= looked at. 

 

YANG for Protocol for Forwarding Policy Config= uration (FPC)/ Satoru

 

FPC did not touch any over the wire protocol. Dec= ided to define a YANG model to provide an API.

 

After the update by Charlie, there has not been f= urther work, so the draft has expired. 

 

Continuing to pursue this dependent on group/indu= stry interest.  Comments?

 

Marco: co-author. This stuff is pretty stable. Si= nce we have two pretty mature parts, need to review. But we should progress= them. Need reasonable reviews to proceed. It would be a pity not to procee= d.

 

Sri: Move this to the mailing list.  Need to= go through the process and get some reviews. Suresh agrees.  

 

Session Closed

 

 

 

--_000_BYAPR15MB30780A2F2875D12751D5F605D04F0BYAPR15MB3078namp_-- From nobody Tue Nov 19 18:16:45 2019 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 E6DD212012C for ; Tue, 19 Nov 2019 18:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=GsDeTyZE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tSa1/WkB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv_H7h74dqZO for ; Tue, 19 Nov 2019 18:16:40 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8949A1200E5 for ; Tue, 19 Nov 2019 18:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35319; q=dns/txt; s=iport; t=1574216200; x=1575425800; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=twLFBomotsfehfYYde8vJ8nI/Foilup8mkLHYDyprLQ=; b=GsDeTyZEd30bp91ZAeZUi6gbBSIPq7IIZ0J5Ld9RAfhBCqqQd0ZkA51e 7mF+J4L/3vqadVFrn8nDQMQT9zifNE+mVaShglwjmZ6xvk03duC2xq1lM Jv14QGxk9hxm1LYkr8aGxPv6/e1+y3YeWw+c7lh8EfGEQH9oZcxkAb84R A=; IronPort-PHdr: =?us-ascii?q?9a23=3AcbqAWhHA0zEUZdnnKcddz51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeXlcio2FdpPfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiAwArodRd/5hdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgW0EAQELAYEbL1AFgUQgBAsqCoQgg0YDinNOghCYAIFCgRADVAk?= =?us-ascii?q?BAQEMAQEtAgEBhEACF4IOJDcGDgIDDQEBBAEBAQIBBQRthTcBC4VRAQIBAxI?= =?us-ascii?q?RBAYTAQElBwwPAgEZAQIBAiEHAwICAjAUAwQCCAEBBBMbB4MAgXpNAy4BAqZ?= =?us-ascii?q?SAoE4iGB1fzOCfgEBBYJJgj4YghcJgTYBjBQYgUA/gRABJx+CHi4+gQSDBSQ?= =?us-ascii?q?4BhCCWjKCLI0WBgkKKII8hUeCP4cHjw0KgiuVTxuCPodojgeBZI5IgUGYRwI?= =?us-ascii?q?EAgQFAg4BAQWBaCMqgS5wFTsqAYJBUBEUkRoMDAuDUIpTdAGBJ40CATBeAQE?= X-IronPort-AV: E=Sophos;i="5.69,220,1571702400"; d="scan'208,217";a="579930467" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Nov 2019 02:16:38 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id xAK2GcHL032657 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Nov 2019 02:16:38 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 20:16:38 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 20:16:37 -0600 Received: from NAM02-CY1-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; Tue, 19 Nov 2019 21:16:36 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oGvpruY8lleaenYLEDRoNqpe5P5qET+lbuUd+5Hfck5R7Deh3vYR+4UmDs6pPsdczmII7uiRQkwVSxs+4lXNQMrUGpDCTNQkODFgIuT/iBDUdpGtiZ1xtb06p2fwYFm2yqsExK0fA+AKoUiT4Xxi6acFxdIiYh3X5MbSeIRCbY1L6cO2Zwi21H1vyvdIUSWh3oQCApE0DEmJF+tenqBO/r/ENkL6cS2ADKTCwYFKU5igIXUKT885t/i+esjMuawzycMQBkMgO71uWadWsPmLUUB4bNBVGzJIM5kIs5CsPrTlWgSi0rc+k5cVo8/Uo740aCKpqyAP7RZGcBTXFkEeKA== 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=twLFBomotsfehfYYde8vJ8nI/Foilup8mkLHYDyprLQ=; b=OtAABMPtkzvPsIrVcBpNxNkaftrgTqrqh9+v+fpJFFY+ZUJK2bXdmYOphgOmz1Vgpg5yVkMKbTTiKKysAog+HkG0iiRFbHU03/WLP//Z2ZGYzH0NSVCphmS6S13rE+vZWhHz/zTl1Ni7oiibqE1Gso9uw26auZxRwBrBdmPxViGE6kLOlLvg/y4fcD/AQKMT7tb531HTPQKzY0yT2znSF/+k01XzKca2BicEFXocbZLMkIsOVu9IyK2CFcDvr9zL6sNnPzb7L96yO4YD+isJdsZeo5Bl6qKl1U5WA3eg6WUYxSy1KJKwpgSchzw/9d9enxVqgkZOif5Nkjti6XO8Ww== 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=twLFBomotsfehfYYde8vJ8nI/Foilup8mkLHYDyprLQ=; b=tSa1/WkBmuKuD20VKUXwp8Zim1+rqCR3stGE0mG4gggnLPWn+o0o2mpWLKPdXLWn9OVX7IA7tMOzXacD7Xhk2hnYhp2+VHzxmcH9JCCygBNlRJCazB0s3BmX/cR+og9ilr5YrB5nggJPstHl4jViBoiaOhqmED7sUi2IZBbX6W0= Received: from BYAPR11MB3558.namprd11.prod.outlook.com (20.178.206.75) by BYAPR11MB3671.namprd11.prod.outlook.com (20.178.206.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Wed, 20 Nov 2019 02:16:35 +0000 Received: from BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e5b0:1702:87b:b1e]) by BYAPR11MB3558.namprd11.prod.outlook.com ([fe80::e5b0:1702:87b:b1e%5]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 02:16:34 +0000 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: Minutes for DMM at IETF 106 Thread-Index: AdWfRtbNPWe4lz1fTZ+KBPqF7PKb9AAAbFAO Date: Wed, 20 Nov 2019 02:16:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sgundave@cisco.com; x-originating-ip: [174.194.140.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 72c5b894-7454-4101-73eb-08d76d5faaba x-ms-traffictypediagnostic: BYAPR11MB3671: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(43544003)(199004)(189003)(6486002)(25786009)(6436002)(1730700003)(8676002)(81156014)(99286004)(2501003)(76176011)(5660300002)(6506007)(790700001)(76116006)(66066001)(6116002)(66556008)(33656002)(14454004)(3846002)(66946007)(316002)(66446008)(26005)(66476007)(8936002)(53546011)(102836004)(186003)(86362001)(7736002)(229853002)(2351001)(64756008)(81166006)(2616005)(11346002)(486006)(71190400001)(6512007)(476003)(5024004)(256004)(14444005)(236005)(36756003)(54896002)(2906002)(2473003)(5640700003)(71200400001)(478600001)(6916009)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3671; 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: fOmAD0ugrAfem67TXWLjnNoDZpnLhIzuvp+1Qq8F43iOxcp5ChHljIYlIZuW+fXNpC2zYv1CiOtnaGtyo3j2dZ3x4nGTkgEPuwkN52wXavTTtiiFBIcaBytckLVflGtgqXYKWw9AmvGxqewtcJORW7V487W0gryChh+sDTlIl6seQXyMeFQkzdcFWjf10jFzinHfsxHapiYKVfqH2LDjzCIxnJJsZDafK2m63vQm3iFe78Ent/WBjLGVTjxcoMzivh8g9ph0e1bzc7Q/2N4BQousneCsw4StTPIdUStp37xklwx9WmPJEwNxBk/ErBzxlnrudwWzT0G4+rwQveadwag/9ahuKz3eeJCwbb0SyupiVuyl+QY6LjjPB8ArNvaheSc+yFWX2S/F6txgbU7QPs8qfKL67WnwKyzFm/cKhRnrxa5vuNNK1KtWC79qcMUM Content-Type: multipart/alternative; boundary="_000_F1A749CA9D1E4BD79CFB5F6E2F667036ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 72c5b894-7454-4101-73eb-08d76d5faaba X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2019 02:16:34.8082 (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: uwTEwCiDcr9s2DAUmLqXqEPTySS0Nlx3t8ywyHsm2VdJEDrmh7WzwwZNF1h8Ie82dmmHbT6q4DC8Jhcliu2/aA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3671 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: [DMM] Fwd: Minutes for DMM at IETF 106 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, 20 Nov 2019 02:16:44 -0000 --_000_F1A749CA9D1E4BD79CFB5F6E2F667036ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IERhdmlkLiBWZXJ5IG11Y2ggYXBwcmVjaWF0ZWQuDQoNCldHOiBQbGVhc2UgcmV2 aWV3IGFuZCBwcm92aWRlIGFueSBlZGl0cy4NCg0KU3JpDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1l c3NhZ2U6DQoNCkZyb206IERhdmlkIEFsbGFuIEkgPGRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29t PG1haWx0bzpkYXZpZC5pLmFsbGFuQGVyaWNzc29uLmNvbT4+DQpEYXRlOiBOb3ZlbWJlciAyMCwg MjAxOSBhdCAxMDoxMzozNSBBTSBHTVQrOA0KVG86ICJkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBp ZXRmLm9yZz4iIDxkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4+DQpDYzogIlNyaSBH dW5kYXZlbGxpIChzZ3VuZGF2ZSkiIDxzZ3VuZGF2ZUBjaXNjby5jb208bWFpbHRvOnNndW5kYXZl QGNpc2NvLmNvbT4+DQpTdWJqZWN0OiBNaW51dGVzIGZvciBETU0gYXQgSUVURiAxMDYNCg0KDQpI aQ0KDQoNCg0KVGhlIGZvbGxvd2luZyBhcmUgdGhlIG5vdGVzIEkgY2FwdHVyZWQgb24gdGhlIEV0 aGVycGFkLiAgQ29tbWVudHMgSSB3YXMgbm90IGFibGUgdG8gY2FwdHVyZSBhcmUgaW5kaWNhdGVk IHdpdGggPD8+LiAgQXBvbG9naWVzIGluIGFkdmFuY2UgZm9yIGFueSBpbmNvcnJlY3QgYXR0cmli dXRpb25z4oCmLg0KDQpDaGVlcnMNCg0KRA0KDQoNCg0KRE1NIE1vbmRheSAxMS8xOC8yMDE5DQoN ClNjcmliZSAjMTogRGF2ZSBBbGxhbiwgRXJpY3Nzb24NCg0KDQoNClNodW5zdWtlOiBDVCBncm91 cHMgbG9va2luZyB0byBjb21wbGV0ZSB3b3JrIGZvciByZWxlYXNlIDE2IGluIE1hcmNoLiBDYW4g d2UgZ28gdG8gbGFzdCBjYWxsLg0KDQpTdXJlc2g6ICBSZXF1aXJlcyBXRyByZXZpZXcuIFdlIGNh biBhbHNvIHNlbmQgYSBsaWFpc29uLiAgQ2Fubm90IHNlZSBhIHdheSB0byBjb21wbGV0ZSB0aGlz IGJ5IE1hcmNoLg0KDQoNCg0KU3JpOiBTdGF0dXMgb2YgZGlmZmVyZW50IGl0ZW1zLg0KDQpGUEMg d29yayBncm91bmQgdG8gYSBoYWx0LCBuZWVkIGEgd2F5IGZvcndhcmQuDQoNCkRpc3RyaWJ1dGVk IE1vYmlsaXR5IEFuY2hvcmluZywgc2hlcGhlcmQgbm90ZXMgbmVlZCB0byBiZSByZWRvbmUuICBU cnVlIGZvciBwcm94eSBNSVAgYXMgd2VsbC4NCg0KU3VyZXNoOiBPbi1kZW1hbmQgbW9iaWxpdHkg bWFuYWdlbWVudCBoYXMgYW4gUkZDIG51bWJlciBhc3NpZ25lZC4gIEl0J3MgZG9uZS4NCg0KDQoN ClNSdjYgZm9yIE1vYmlsZSBVc2VyIHBsYW5lIC9QYWJsbw0KDQotIHN1bW1hcnkgb2YgdXBkYXRl cywgcmVtb3ZlZCBpbnNlcnRpb24uIEFkZGVkIGRyb3AtaW4sIGRvdWJsZSBlbmRlZCBHVFAgaW50 ZXJ3b3JraW5nLiByZW1vdmVkIHN1cHBvcnQgZm9yIHVuc3RydWN0dXJlZCBQRFUgc2Vzc2lvbiB0 eXBlLiBDaGFuZ2VzIHRvIGhhbmRsaW5nIG9mIGV0aGVybmV0IG1lYW5zIG5ldyBhbGxvY2F0aW9u cyB3b3VsZCBiZSByZXF1aXJlZC4NCg0KDQoNCkNhcmxvczogd2lsbGluZyB0byByZXZpZXcuDQoN Cg0KDQpVc2VyIHBsYW5lIG1lc3NhZ2UgZW5jb2RpbmctMDA6ICBUZXRzdXlhIE11cmFrYW1pDQoN Cg0KDQpHb2FsIGlzIHRvIGNhcnJ5IEdUUC1VIG1lc3NhZ2UgaW5mb3JtYXRpb24uICBQcm9wb3Nl cyBjYXJyeWluZyBpbmZvcm1hdGlvbiBpbiB0aGUgdW51c2VkIHRhZyBmaWVsZCBpbiB0aGUgU1J2 NiBoZWFkZXIgKD8pIC4gIFByb3Bvc2VkIGJpdCBmaWVsZCBkZWZpbml0aW9ucyBmb3IgZW5kLW1h cmtlciBldGMuDQoNCg0KDQpBZGQgYSBUTFYgdG8gY2FycnkgM0dQUCBpbmZvcm1hdGlvbi4NCg0K UGVudWx0aW1hdGUgU2VnbWVudCBQb3BwaW5nIG11c3QgTk9UIGJlIHVzZWQuDQoNCg0KDQpQcm9w b3NlZCBmb3IgV0cgYWRvcHRpb24uDQoNCg0KDQpVbWE6IFB1cnBvc2UgaXMgdG8gcmVtb3ZlIEdU UCBjb21wbGV0ZWx5IGFuZCByZXBsYWNlIHdpdGggU1J2Ni4gICBJcyB0aGVyZSBhbnkgdXNlIGNh c2UgdG8gc2VuZCBmcm9tIHRoZSBVRSBpdHNlbGY/DQoNClRldHN1eWE6ICA8bm90IGNhcHR1cmVk Pg0KDQpTcmk6ICBEb2VzIG5vdCBleHRlbmQgdG8gdGhlIFVFLg0KDQpTdXJlc2g6IFNwZWN0cnVt IGlzIGV4cGVuc2l2ZS4gRG8gbm90IHdhbnQgR1RQIG9uIHRoZSBhaXIuDQoNCkRhdmU6IFN0dWZm IGNvdmVyZWQgaXMgZWl0aGVyIGNhcnJpZWQgb3ZlciBQRENQIG9yIG9ubHkgb2Ygc2lnbmlmaWNh bmNlIHRvIHRoZSBnTm9kZUIuIERvIG5vdCBuZWVkIEdUUCB0byBVRS4NCg0KDQoNClNyaTogTmVl ZCBtb3JlIGZlZWRiYWNrIGZyb20gV0cgYW5kIHRoZSBBRC4gIEtlZXAgZG9pbmcgdGhlIHdvcmsg YW5kIHdlJ2xsIHNlZSBhYm91dCBhZG9wdGlvbi4NCg0KDQoNClRyYW5zcG9ydCBOZXR3b3JrIEF3 YXJlIE1vYmlsaXR5IGZvciA1RywgVW1hLCBKb2huIEsuDQoNCg0KDQpDdXJyZW50IHZlcnNpb24g bmFycm93cyBkb3duIGNob2ljZXMgZm9yIE1UTkMtSUQgaW4gbWV0YSBkYXRhLg0KDQoNCg0KTG9v a2luZyBmb3IgbWFwcGluZyBmcm9tIFBEVSBzZXNzaW9uIGxheWVyIHRvIHRyYW5zcG9ydCBuZXR3 b3JrIHBhdGhzLg0KDQpTcmk6IE92ZXJsYXkgdG8gdW5kZXJsYXkgbWFwcGluZyBpcyBub3QgYSBu ZXcgcHJvYmxlbS4gUmlnaHQuDQoNClVtYTogV2hhdCBoYXMgYmVlbiBkZXBsb3llZCB1c2VkIG5v bi1zdGFuZGFyZGl6ZWQgd2F5cyBvZiBtYXBwaW5nLiBXZSdyZSBsb29raW5nIHRvIHN0cmVhbWxp bmUgdGhpcy4NCg0KDQoNCkpvaG46ICBXYW50ZWQgdG8gY29udmVyZ2Ugb24gb25lIHNvbHV0aW9u LiBBZGRlZCBvcHRpb24gZm9yIGVuY29kaW5nIGNvbnRleHQgSUQgaW4gdGggb3V0ZXIgaGVhZGVy LS0+IHNvdXJjZSBVRFAgcG9ydC4NCg0KU3JpOiBXaGVyZSBkbyB5b3UgZ2V0IHRoaXMgdHJhbnNw b3J0IG5ldHdvcmsgY29udGV4dD8NCg0KSm9objogSXQgaXMgbm90IElFVEYgd29yayB0byBjb21l IHVwIHdpdGggdGhpcyBtYXBwaW5nLiBCZWxpZXZlIHRoZXkgaGF2ZSBhbHNvIHNlbGVjdGVkIEFD VE4sIGJ1dCBkZXRhaWxzIHN0aWxsIGJlaW5nIHJlc29sdmVkIGluIFNBNS4gIFRORiBpcyBhIGxv Z2ljYWwgZnVuY3Rpb24sIGludGVyZmFjZXMgYXJlIElFVEYuIDNHUFAgc2xpY2UgYXNwZWN0cyBO U1NBSSBpcyByZWxhdGVkIHRvIHdoYXQgYSB1c2VyIGlzIHN1cHBsaWVkLiBNYXkgYmUgMTAwMCBj dXN0b21lcnMgYW5kIDMgc2xpY2VzLiAgSW1wYWN0cyBOMiBhbmQgTjQuDQoNClNyaTogVG9kYXkg eW91IGRvIG1hcHBpbmcgYXQgYSBzZXNzaW9uIGxldmVsLiBXaGF0IGFyZSB0aGUgYWR2YW50YWdl cyBvZiBhdCBhIHNsaWNlIGxldmVsPw0KDQpKb2huOiBEU0NQIGlzIG5vdCBpbW11dGFibGUuIFFG SSBpcyB0b28gZGVlcCBmb3IgcGFja2V0IGluc3BlY3Rpb24uDQoNCkRhdmU6IFNvdXJjZSBwb3J0 IG5vcm1hbGx5IHVzZWQgZm9yIEVDTVAuIElzIHRoaXMgdHVybmVkIG9mZj8NCg0KSm9objogaW4g dGhlIHRleHQuIE9ubHkgY2VydGFpbiByYW5nZXMgdXNlZCAoPykNCg0KU2F0b3J5dTogIFlvdSBh cmUgcHJvcG9zaW5nIHVzaW5nIHRoZSBzb3VyY2UgcG9ydCBmb3IgbWFwcGluZy4gV2hhdCBXRyB3 b3VsZCBkZWZpbmUgdGhpcy4NCg0KVW1hOiAgVGhpcyBpcyBhIGxvY2FsIG1hcHBpbmcuICBOb3Qg YSBXRyBwcm9ibGVtIGFuZCBpcyBiYWNrd2FyZHMgY29tcGF0aWJsZS4NCg0KU3VyZXNoOiBJZiBy ZXdyaXRpbmcgVURQIHBvcnRzLCBhcmUgeW91IHJlZG9pbmcgdGhlIGNoZWNrc3Vtcz8NCg0KVW1h OiBEb25lIGF0IHRoZSBVUEYgd2hlcmUgdGhlIFVEUCBoZWFkZXIgb3JpZ2luYXRlcy4NCg0KWHVl c29uZzogVkxBTiBzaG91bGQgbm90IGJlIGV4Y2x1ZGVkLiAgQ2FuIHVzZXIgb3RoZXIgZW5jYXBz IHRvIHJlc3BlY3QgdGhlIGluZm9ybWF0aW9uDQoNCkpvaG46ICBXZSBjYW4gaW5jbHVkZSB0aGF0 DQoNCk1hcmNvOiBVRFAgaXMgYSBiaS1kaXJlY3Rpb25hbCB0aGluZy4gIERvZXMgdGhlIHZhbHVl IG5lZWQgdG8gYmUgc3ltbWV0cmljLg0KDQpKb2huOiBXZSBhcmUgY29uc2lkZXJpbmcgdW5pZGly ZWN0aW9uYWwgZmxvd3MuIEFzc3VtZSBzb21lIHN5bW1ldHJ5LiBJZiB1c2luZyBhIHJhbmdlIG9u IHRoZSB1cHN0cmVhbSwgcmFuZ2UgZG9lcyBub3QgbmVlZCB0byBjb3JyZXNwb25kLiAgUUZJIGl0 c2VsZiBpbnN1ZmZpY2llbnQuDQoNClRhc3V5YTogIDw/Pg0KDQpKb2huOiBSYW5nZSBvZiB0aGUg VURQIHBvcnQgaGFuZGxlZCBieSB0aGUgSVAgcGFydC4NCg0KVGFzdXlhOiBTbyBkbyBub3QgdXNl IGV4aXN0aW5nIFBGQ1AgPD8+DQoNCkpvaG46IFdoYXQgYWJvdXQgV0cgYWRvcHRpb24/DQoNClNy aTogQ2FuIGFzayB0aGUgZ3JvdXAuDQoNClh1ZXNvbmc6IE1hcCBpbiB0aGUgUkFOIHRvIHRoZSBi YWNraGF1bCwgdGhpcyBpcyBpc29sYXRlZCB3b3JrLg0KDQpTcmk6ICBIb3cgdG8gdGFrZSB0aGlz IHVwLg0KDQpYdWVzb25nOiAgSW4gdGhlIHNhbWUgV0cuICBOb3Qgc3VyZSB0aGVzZSBhcmUgdGll ZCB0b2dldGhlciBhbmQgY291bGQgYmUgZGlmZmVyZW50IGRyYWZ0cy4NCg0KSm9objogIFdoYXQg cGFydD8NCg0KWHVlc29uZzogVGhlIHNvbHV0aW9uIHNwYWNlLg0KDQpDYXJsb3M6IEFsc28gd2ls bGluZyB0byByZXZpZXcuDQoNClNyaTogIE5lZWQgbW9yZSBkaXNjdXNzaW9uLCBnb29kIGZlZWRi YWNrLg0KDQoNCg0KQXJjaGl0ZWN0dXJlIERpc2N1c3Npb24gb24gU1J2NiBtb2JpbGUgVXNlciBw bGFuZSwgTWl5YSBLb2hubw0KDQoNCg0KSG93IHRvIG1hcCBtb2JpbGl0eSBkYXRhIHBsYW5lLiAg U3VnZ2VzdHMgU1J2NiBpcyB0aGUgcmlnaHQgY2hvaWNlIGZvciA1Ry4NCg0KU3VnZ2VzdHMgYW4g YWRkaXRpb25hbCB1c2VyIHBsYW5lIElEIGlzIHJlcXVpcmVkIGZvciBzbGljZSBtYXBwaW5nLiAg UEUgcmVkdW5kYW5jeSBpcyBhbiBhZGRpdGlvbmFsIHJlcXVpcmVtZW50Lg0KDQpHb2FsIGlzIHRv IGhhdmUgdGhlIFVQRiBiZSBwYXJ0IG9mIHRoZSBUTiBhbmQgbm90IGEgQ0UuDQoNCg0KDQozR1BQ IGVudGl0aWVzIGRvIG5vdCBjYXJlIGFib3V0IElQIHJvdXRpbmc/PyAgIFNpZGVjYXIgcHJveHkg Y2FuIHRha2UgY2FyZSBvZiBjb21tdW5pY2F0aW9uIHN0YXRlIGV4Y2hhbmdlLiAgQlNJRCBjYW4g YmUgdXNlZCBmb3IgdG9wb2xvZ3kgaGlkaW5nLg0KDQpVUkxMQyB3aXRoIGR1cGxpY2F0aW9uIGFu ZCBlbGltaW5hdGlvbiByZXF1aXJlcyBtb2RpZmljYXRpb24gb2YgR1RQLVUuDQoNClByb3Bvc2Vk IGZvciBkaXNjdXNzaW9uLg0KDQoNCg0KSm9objogR29vZCBwb2ludHMgb24gVVJMTEMuIEhvdyBk b2VzIFNSdjYgYWxsb3cgcGF0aHMgdG8gYmUgZGlzam9pbnQ/DQoNCk1peWE6IENvdWxkIHByb3Zp ZGUgVEktTEZBIGFuZCBvdGhlciB0b29scy4gU1IgYXdhcmUgZW50aXRpZXMgY2FuIGRpcmVjdGx5 IGNvbnRyb2wgdGhlIG1lY2hhbmlzbXMuDQoNCkpvaG46IFdpdGggYSBjaGFpbiBvZiBOMy9OOSwg aG93IGRvZXMgU1J2NiBoZWxwPyAgPGdvIG9mZmxpbmU+DQoNClN1cmVzaDogV2hhdCBpcyB0aGlz IGEgc2VwYXJhdGUgZG9jdW1lbnQ/DQoNCk1peWE6IFNSdjYgbW9iaWxlIHVzZXIgcGxhbmUgZG9j dW1lbnQgc2ltcGx5IGRlc2NyaWJlcyB0aGUgcHJvdG9jb2wuIEkgd2FudGVkIHRvIGRpc2N1c3Mg bW9yZSB0aGUgYXJjaGl0ZWN0dXJhbCBpbXBsaWNhdGlvbnMuDQoNClN1cmVzaDogVGV4dCBpcyB1 c2VmdWwsIGhvdyBpdCBwcm9jZWVkcyB0byBiZSBkaXNjdXNzZWQuIEl0IGlzIHByZXR0eSBkZXBl bmRlbnQgb24gb3RoZXIgc3R1ZmYuIFRoaXMgY29tZXMgdXAgaW4gSUVTRyBhcyBzdXBwb3J0aW5n IGRvY3VtZW50cy4gIElmIGl0IGlzIHRvIGJlIHNlcGFyYXRlIGFuZCBwcm9ncmVzcyBuZWVkIHRv IHRoaW5rIGFib3V0IHRoZSB3cml0ZSB1cC4NCg0KU3JpOiBHb29kIHBvaW50cy4NCg0KVW1hOiBH b29kIHF1ZXN0aW9ucyBhcmUgYXNrZWQuICBDYW4gY29sbGFwc2UgR1RQVSBhbmQgU1J2Ni4gIFdl IGFyZSBlbnZpc2lvbmluZyBhIGZ1dHVyZSBvZiBJUHY2IG9ubHkgdHJhbnNwb3J0LiBXaGVuIHdl IHN0YXJ0ZWQgaXQgd3MgTlMxVS4gIFRoaXMgaXMgYSBiaWdnZXIgZGlzY3Vzc2lvbi4NCg0KTWFy Y286IFNlcnZpY2UgbWVzaCwgd2hhdCBkb2VzIHRoaXMgaGF2ZSB0byBkbyB3aXRoIHNsaWNpbmcu IEl0IGlzIGFuIGltcGxlbWVudGF0aW9uIG1hdHRlci4NCg0KTWl5YTogQ29udmVudGlvbmFsIGJv eCB0aGlua2luZyBuZWVkcyB0byBiZSBldmFsdWF0ZWQuDQoNCk1hcmNvOiBXaGF0IGFib3V0IHBy b3hpZXMuLi4gPD8+Lg0KDQpNaXlhOiAgSUYgdGhlcmUgY291bGQgYmUgYSBwcm94eSB0aGF0IGNv dWxkIGRvIGFsbCByb3V0aW5nIGFuZCBmb3J3YXJkaW5nIHN0dWZmIGFuZCBpdCBzaXRzIGluIHRo ZSBob3N0LiBXZSBjb3VsZCBwcm92aWRlIHJvdXRpbmcgaW4gaG9zdC4NCg0KUmFqZWV2OiBMaWtl ZCB0aGUgc2lkZSBjYXIgYW5hbG9neSwgc28gdGhlIHByb3h5IHdhcyBhZGphY2VudCB0byB0aGUg YXBwbGljYXRpb24gaXRzZWxmLg0KDQpNYXJjbzogIFNpZGVjYXJzIGZ1bmN0aW9uIGF0IGEgREhD UCBsZXZlbC4NCg0KUmFqZWV2OiBUaGVyZSBpcyBhbHNvIHRoZSBub3Rpb24gb2YgYXBwbGljYXRp b24gcm91dGluZy4gTGluZXMgYXJlIGJsdXJyaW5nIGFuZCBoYXZlIGJlZW4gZm9yIHNvbWUgdGlt ZS4NCg0KU3VyZXNoOiAgSWYgaW4gYSBzaWRlY2FyLCB0aGUgYXBwIGRvZXMgbm90IG5lZWQgdG8g a25vdyBhYm91dCBpdC4NCg0KU3JpOiBHb29kIHdvcmssIG5lZWRzIG1vcmUgZGlzY3Vzc2lvbi4N Cg0KVW1hOiBUaGlzIGFuZCB0aGUgbGFzdCBwcmVzZW50YXRpb24gYXJlIHZlcnkgbXVjaCBjb25u ZWN0ZWQuDQoNCg0KDQpNb2JpbGl0eSBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIGFuZCBwcm90b2Nv bCBzZWxlY3Rpb24gIFpoaXdlaQ0KDQoNCg0KVHdvIGNhdGVnb3JpZXMsIG5ldHdvcmsgYW5kIGhv c3QgYmFzZWQgc29sdXRpb25zLg0KDQoNCg0KU3VnZ2VzdHMgYSBuZWdvdGlhdGluZyBkaXNjaXBs aW5lLg0KDQoNCg0KUG9zc2libGUgc29sdXRpb25zIGZvciBuZWdvdGlhdGlvbi4NCg0KSUNNUHY2 IGdldHMgYSBuZXcgb3B0aW9uLg0KDQoNCg0KU3VyZXNoOiBFdmVyeXRoaW5nIHlvdSBzYXkgaGFz IGJlZW4gdHJpZWQgYmVmb3JlLiAyMDA3LTIwMDgsIGl0IG5ldmVyIHdvcmtlZC4gSWYgdGhlIG5l dHdvcmsgY2FuIGRvIGl0LCBpdCB3aWxsIGRvIGl0LiAgQ01JUCB2cyBQTUlQLiBUaGUgcHJvYmxl bSBpcyBub3QgdGVjaG5pY2FsLiBUaGVyZSBpcyBubyBkZXBsb3ltZW50IHNjZW5hcmlvIHdoZXJl IHRoaXMgd2lsbCBiZSB1c2VmdWwuICBUaGVyZSBpcyBhIHBhc3QgaGlzdG9yeSBvZiBmYWlsdXJl LiAgVGhpbmsgYWJvdXQgd2hlcmUgYW5kIGhvdyB5b3Ugd291bGQgdXNlIHRoaXMuDQoNCg0KDQpT cmk6IE1heSB3YW50IHRvIHdvcmsgd2l0aCBhIGZldyBwZW9wbGUsIGdldCBzb21lIGZlZWRiYWNr LCBhbmQgZGVjaWRlIHdoZXRoZXIgdG8gcHVyc3VlLg0KDQpSYWplZXY6IEZvciBhbiBlbmRwb2lu dCBhdHRhY2hlZCB0byBjZWxsdWxhciwgZ29pbmcgdG8gYSBzaXRlIEdXLCB3aGVyZSBpcyB0aGlz IG1lc3NhZ2UgZ29pbmc/IENvdWxkIGJlIGEgc2lkZSBnYXRld2F5LiAgU08gdGhpcyBub3Rpb24g b2Ygc29tZXRoaW5nIGluIHRoZSBSUyBhbiBSQSB0byBhbGxvdyBtb2JpbGl0eSB0byB3b3JrLCBu ZWVkcyB0byBiZSBjb21wYXRpYmxlIHdpdGggb3V0c2lkZSBvZiB0aGUgY2VsbHVsYXIgd29ybGQu ICBJdCB3b3VsZCBoYXZlIGEgbG93IGZvb3RwcmludC4NCg0KU3VyZXNoOiBUaGUgb3RoZXIgb25l cyB3ZXJlIFJTIFJBIGJhc2VkLg0KDQpVbWE6ICBXaHkgZGlkIGl0IGZhaWwsIHNlY3VyaXR5IG9y IHdoYXQ/DQoNClN1cmVzaDogTm90IGFuY2hvcmVkIGluIGFyY2hpdGVjdHVyZXMgYW55d2hlcmUu ICBGb3IgZ29vZCBvciBiYWQsIGFyY2hpdGVjdHVyZXMgZG9uZSBlbHNld2hlcmUuICBTdHVmZiBu ZWVkIHRvIGJlIGFuY2hvcmVkIG9yIGl0IGdvZXMgbm93aGVyZS4gRGVwbG95bWVudCBzdXBwb3J0 LiBFdmVyeXRoaW5nIFJhamVldiBzYWlkIHdhcyBsb29rZWQgYXQuDQoNCg0KDQpZQU5HIGZvciBQ cm90b2NvbCBmb3IgRm9yd2FyZGluZyBQb2xpY3kgQ29uZmlndXJhdGlvbiAoRlBDKS8gU2F0b3J1 DQoNCg0KDQpGUEMgZGlkIG5vdCB0b3VjaCBhbnkgb3ZlciB0aGUgd2lyZSBwcm90b2NvbC4gRGVj aWRlZCB0byBkZWZpbmUgYSBZQU5HIG1vZGVsIHRvIHByb3ZpZGUgYW4gQVBJLg0KDQoNCg0KQWZ0 ZXIgdGhlIHVwZGF0ZSBieSBDaGFybGllLCB0aGVyZSBoYXMgbm90IGJlZW4gZnVydGhlciB3b3Jr LCBzbyB0aGUgZHJhZnQgaGFzIGV4cGlyZWQuDQoNCg0KDQpDb250aW51aW5nIHRvIHB1cnN1ZSB0 aGlzIGRlcGVuZGVudCBvbiBncm91cC9pbmR1c3RyeSBpbnRlcmVzdC4gIENvbW1lbnRzPw0KDQoN Cg0KTWFyY286IGNvLWF1dGhvci4gVGhpcyBzdHVmZiBpcyBwcmV0dHkgc3RhYmxlLiBTaW5jZSB3 ZSBoYXZlIHR3byBwcmV0dHkgbWF0dXJlIHBhcnRzLCBuZWVkIHRvIHJldmlldy4gQnV0IHdlIHNo b3VsZCBwcm9ncmVzcyB0aGVtLiBOZWVkIHJlYXNvbmFibGUgcmV2aWV3cyB0byBwcm9jZWVkLiBJ dCB3b3VsZCBiZSBhIHBpdHkgbm90IHRvIHByb2NlZWQuDQoNCg0KDQpTcmk6IE1vdmUgdGhpcyB0 byB0aGUgbWFpbGluZyBsaXN0LiAgTmVlZCB0byBnbyB0aHJvdWdoIHRoZSBwcm9jZXNzIGFuZCBn ZXQgc29tZSByZXZpZXdzLiBTdXJlc2ggYWdyZWVzLg0KDQoNCg0KU2Vzc2lvbiBDbG9zZWQNCg0K DQoNCg0KDQoNCg== --_000_F1A749CA9D1E4BD79CFB5F6E2F667036ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpU aGFuayB5b3UgRGF2aWQuIFZlcnkgbXVjaCBhcHByZWNpYXRlZC4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PldHOiBQbGVhc2UgcmV2aWV3IGFuZCBwcm92aWRlIGFueSBlZGl0cy48L2Rpdj4NCjxk aXY+PGJyPg0KPGRpdj5Tcmk8L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdj48YnI+DQpCZWdpbiBmb3J3 YXJkZWQgbWVzc2FnZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGRpdj48Yj5Gcm9tOjwvYj4gRGF2aWQgQWxsYW4gSSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRh dmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tIj5kYXZpZC5pLmFsbGFuQGVyaWNzc29uLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+RGF0ZTo8L2I+IE5vdmVtYmVyIDIwLCAyMDE5IGF0IDEwOjEzOjM1IEFNIEdN VCYjNDM7ODxicj4NCjxiPlRvOjwvYj4gJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9y ZyI+ZG1tQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9y ZyI+ZG1tQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ICZxdW90O1NyaSBHdW5kYXZl bGxpIChzZ3VuZGF2ZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZ3VuZGF2ZUBjaXNjby5j b20iPnNndW5kYXZlQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IDxiPk1p bnV0ZXMgZm9yIERNTSBhdCBJRVRGIDEwNjwvYj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxtZXRhIG5hbWU9IkdlbmVy YXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQs IGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uYXV0aG9yLWEtbGV0ejgyejd6ODd6eGo5NzZleG5hcQ0KCXttc28t c3R5bGUtbmFtZTphdXRob3ItYS1sZXR6ODJ6N3o4N3p4ajk3NmV4bmFxO30NCnNwYW4uUGxhaW5U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SGk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGZvbGxvd2luZyBhcmUgdGhlIG5vdGVz IEkgY2FwdHVyZWQgb24gdGhlIEV0aGVycGFkLiZuYnNwOyBDb21tZW50cyBJIHdhcyBub3QgYWJs ZSB0byBjYXB0dXJlIGFyZSBpbmRpY2F0ZWQgd2l0aCAmbHQ7PyZndDsuJm5ic3A7IEFwb2xvZ2ll cyBpbiBhZHZhbmNlIGZvciBhbnkgaW5jb3JyZWN0IGF0dHJpYnV0aW9uc+KApi48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNoZWVyczxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+RDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ETU0g TW9uZGF5IDExLzE4LzIwMTkgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5TY3JpYmUgIzE6IERhdmUgQWxsYW4sIEVyaWNzc29uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlNodW5zdWtlOiBDVCBncm91cHMgbG9va2luZyB0byBjb21wbGV0ZSB3b3JrIGZvciBy ZWxlYXNlIDE2IGluIE1hcmNoLiBDYW4gd2UgZ28gdG8gbGFzdCBjYWxsLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3VyZXNoOiZuYnNwOyBSZXF1aXJlcyBX RyByZXZpZXcuIFdlIGNhbiBhbHNvIHNlbmQgYSBsaWFpc29uLiZuYnNwOyBDYW5ub3Qgc2VlIGEg d2F5IHRvIGNvbXBsZXRlIHRoaXMgYnkgTWFyY2guJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlNyaTogU3RhdHVzIG9mIGRpZmZlcmVudCBpdGVtcy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkZQQyB3b3JrIGdyb3VuZCB0byBhIGhhbHQs IG5lZWQgYSB3YXkgZm9yd2FyZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkRpc3RyaWJ1dGVkIE1vYmlsaXR5IEFuY2hvcmluZywgc2hlcGhlcmQgbm90ZXMg bmVlZCB0byBiZSByZWRvbmUuJm5ic3A7IFRydWUgZm9yIHByb3h5IE1JUCBhcyB3ZWxsLiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3VyZXNoOiBPbi1kZW1h bmQgbW9iaWxpdHkgbWFuYWdlbWVudCBoYXMgYW4gUkZDIG51bWJlciBhc3NpZ25lZC4mbmJzcDsg SXQncyBkb25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48dT5TUnY2IGZvciBNb2Jp bGUgVXNlciBwbGFuZSAvUGFibG88bzpwPjwvbzpwPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4tIHN1bW1hcnkgb2YgdXBkYXRlcywgcmVtb3ZlZCBpbnNlcnRpb24uIEFkZGVkIGRy b3AtaW4sIGRvdWJsZSBlbmRlZCBHVFAgaW50ZXJ3b3JraW5nLiByZW1vdmVkIHN1cHBvcnQgZm9y IHVuc3RydWN0dXJlZCBQRFUgc2Vzc2lvbiB0eXBlLiBDaGFuZ2VzIHRvIGhhbmRsaW5nIG9mIGV0 aGVybmV0IG1lYW5zIG5ldyBhbGxvY2F0aW9ucyB3b3VsZCBiZSByZXF1aXJlZC4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q2FybG9zOiB3aWxsaW5nIHRvIHJldmlldy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjx1PjxvOnA+PHNwYW4gc3R5bGU9 InRleHQtZGVjb3JhdGlvbjpub25lIj4mbmJzcDs8L3NwYW4+PC9vOnA+PC91PjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjx1PlVzZXIgcGxhbmUgbWVzc2FnZSBlbmNvZGluZy0wMDombmJz cDsgVGV0c3V5YSBNdXJha2FtaTxvOnA+PC9vOnA+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+R29h bCBpcyB0byBjYXJyeSBHVFAtVSBtZXNzYWdlIGluZm9ybWF0aW9uLiZuYnNwOyBQcm9wb3NlcyBj YXJyeWluZyBpbmZvcm1hdGlvbiBpbiB0aGUgdW51c2VkIHRhZyBmaWVsZCBpbiB0aGUgU1J2NiBo ZWFkZXIgKD8pIC4mbmJzcDsgUHJvcG9zZWQgYml0IGZpZWxkIGRlZmluaXRpb25zIGZvciBlbmQt bWFya2VyIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWRkIGEgVExWIHRvIGNh cnJ5IDNHUFAgaW5mb3JtYXRpb24uJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5QZW51bHRpbWF0ZSBTZWdtZW50IFBvcHBpbmcgbXVzdCBOT1QgYmUgdXNlZC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UHJvcG9zZWQgZm9yIFdHIGFkb3B0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5VbWE6IFB1cnBvc2UgaXMgdG8gcmVt b3ZlIEdUUCBjb21wbGV0ZWx5IGFuZCByZXBsYWNlIHdpdGggU1J2Ni4mbmJzcDsmbmJzcDsgSXMg dGhlcmUgYW55IHVzZSBjYXNlIHRvIHNlbmQgZnJvbSB0aGUgVUUgaXRzZWxmPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGV0c3V5YTombmJzcDsgJmx0O25vdCBjYXB0 dXJlZCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNyaTombmJz cDsgRG9lcyBub3QgZXh0ZW5kIHRvIHRoZSBVRS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlN1cmVzaDogU3BlY3RydW0gaXMgZXhwZW5zaXZlLiBEbyBub3Qgd2FudCBH VFAgb24gdGhlIGFpci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRh dmU6IFN0dWZmIGNvdmVyZWQgaXMgZWl0aGVyIGNhcnJpZWQgb3ZlciBQRENQIG9yIG9ubHkgb2Yg c2lnbmlmaWNhbmNlIHRvIHRoZSBnTm9kZUIuIERvIG5vdCBuZWVkIEdUUCB0byBVRS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3JpOiBOZWVkIG1vcmUgZmVlZGJhY2sgZnJvbSBXRyBh bmQgdGhlIEFELiZuYnNwOyBLZWVwIGRvaW5nIHRoZSB3b3JrIGFuZCB3ZSdsbCBzZWUgYWJvdXQg YWRvcHRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjx1PlRyYW5zcG9ydCBOZXR3 b3JrIEF3YXJlIE1vYmlsaXR5IGZvciA1RywgVW1hLCBKb2huIEsuPG86cD48L286cD48L3U+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5DdXJyZW50IHZlcnNpb24gbmFycm93cyBkb3duIGNob2ljZXMgZm9y IE1UTkMtSUQgaW4gbWV0YSBkYXRhLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5Mb29raW5nIGZvciBtYXBwaW5nIGZyb20gUERVIHNlc3Npb24gbGF5ZXIgdG8gdHJhbnNwb3J0 IG5ldHdvcmsgcGF0aHMuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Tcmk6IE92ZXJsYXkgdG8gdW5kZXJsYXkgbWFwcGluZyBpcyBub3QgYSBuZXcg cHJvYmxlbS4gUmlnaHQuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5VbWE6IFdoYXQgaGFzIGJlZW4gZGVwbG95ZWQgdXNlZCBub24tc3RhbmRhcmRp emVkIHdheXMgb2YgbWFwcGluZy4gV2UncmUgbG9va2luZyB0byBzdHJlYW1saW5lIHRoaXMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkpvaG46Jm5ic3A7IFdhbnRlZCB0byBjb252ZXJn ZSBvbiBvbmUgc29sdXRpb24uIEFkZGVkIG9wdGlvbiBmb3IgZW5jb2RpbmcgY29udGV4dCBJRCBp biB0aCBvdXRlciBoZWFkZXItLSZndDsgc291cmNlIFVEUCBwb3J0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3JpOiBXaGVyZSBkbyB5b3UgZ2V0IHRoaXMgdHJhbnNw b3J0IG5ldHdvcmsgY29udGV4dD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkpvaG46IEl0IGlzIG5vdCBJRVRGIHdvcmsgdG8gY29tZSB1cCB3aXRoIHRoaXMgbWFwcGlu Zy4gQmVsaWV2ZSB0aGV5IGhhdmUgYWxzbyBzZWxlY3RlZCBBQ1ROLCBidXQgZGV0YWlscyBzdGls bCBiZWluZyByZXNvbHZlZCBpbiBTQTUuJm5ic3A7IFRORiBpcyBhIGxvZ2ljYWwgZnVuY3Rpb24s IGludGVyZmFjZXMgYXJlIElFVEYuIDNHUFAgc2xpY2UgYXNwZWN0cyBOU1NBSSBpcyByZWxhdGVk IHRvIHdoYXQgYSB1c2VyDQogaXMgc3VwcGxpZWQuIE1heSBiZSAxMDAwIGN1c3RvbWVycyBhbmQg MyBzbGljZXMuJm5ic3A7IEltcGFjdHMgTjIgYW5kIE40LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3JpOiBUb2RheSB5b3UgZG8gbWFwcGluZyBhdCBhIHNl c3Npb24gbGV2ZWwuIFdoYXQgYXJlIHRoZSBhZHZhbnRhZ2VzIG9mIGF0IGEgc2xpY2UgbGV2ZWw/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Kb2huOiBEU0NQIGlzIG5v dCBpbW11dGFibGUuIFFGSSBpcyB0b28gZGVlcCBmb3IgcGFja2V0IGluc3BlY3Rpb24uJm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EYXZlOiBTb3VyY2UgcG9y dCBub3JtYWxseSB1c2VkIGZvciBFQ01QLiBJcyB0aGlzIHR1cm5lZCBvZmY/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Kb2huOiBpbiB0aGUgdGV4dC4gT25seSBjZXJ0 YWluIHJhbmdlcyB1c2VkICg/KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+U2F0b3J5dTombmJzcDsgWW91IGFyZSBwcm9wb3NpbmcgdXNpbmcgdGhlIHNvdXJjZSBwb3J0 IGZvciBtYXBwaW5nLiBXaGF0IFdHIHdvdWxkIGRlZmluZSB0aGlzLiZuYnNwOyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VW1hOiZuYnNwOyBUaGlzIGlzIGEg bG9jYWwgbWFwcGluZy4mbmJzcDsgTm90IGEgV0cgcHJvYmxlbSBhbmQgaXMgYmFja3dhcmRzIGNv bXBhdGlibGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdXJlc2g6 IElmIHJld3JpdGluZyBVRFAgcG9ydHMsIGFyZSB5b3UgcmVkb2luZyB0aGUgY2hlY2tzdW1zPyZu YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VW1hOiBE b25lIGF0IHRoZSBVUEYgd2hlcmUgdGhlIFVEUCBoZWFkZXIgb3JpZ2luYXRlcy4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlh1ZXNvbmc6IFZMQU4gc2hvdWxk IG5vdCBiZSBleGNsdWRlZC4mbmJzcDsgQ2FuIHVzZXIgb3RoZXIgZW5jYXBzIHRvIHJlc3BlY3Qg dGhlIGluZm9ybWF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5K b2huOiZuYnNwOyBXZSBjYW4gaW5jbHVkZSB0aGF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5NYXJjbzogVURQIGlzIGEgYmktZGlyZWN0aW9uYWwgdGhpbmcuJm5ic3A7 IERvZXMgdGhlIHZhbHVlIG5lZWQgdG8gYmUgc3ltbWV0cmljLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Sm9objogV2UgYXJlIGNvbnNpZGVyaW5nIHVuaWRp cmVjdGlvbmFsIGZsb3dzLiBBc3N1bWUgc29tZSBzeW1tZXRyeS4gSWYgdXNpbmcgYSByYW5nZSBv biB0aGUgdXBzdHJlYW0sIHJhbmdlIGRvZXMgbm90IG5lZWQgdG8gY29ycmVzcG9uZC4mbmJzcDsg UUZJIGl0c2VsZiBpbnN1ZmZpY2llbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5UYXN1eWE6Jm5ic3A7ICZsdDs/Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Sm9objogUmFuZ2Ugb2YgdGhlIFVEUCBwb3J0IGhhbmRsZWQgYnkgdGhl IElQIHBhcnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5U YXN1eWE6IFNvIGRvIG5vdCB1c2UgZXhpc3RpbmcgUEZDUCAmbHQ7PyZndDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkpvaG46IFdoYXQgYWJvdXQgV0cgYWRvcHRpb24/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Tcmk6IENhbiBhc2sgdGhl IGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WHVlc29uZzog TWFwIGluIHRoZSBSQU4gdG8gdGhlIGJhY2toYXVsLCB0aGlzIGlzIGlzb2xhdGVkIHdvcmsuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Tcmk6Jm5ic3A7IEhvdyB0byB0 YWtlIHRoaXMgdXAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5YdWVz b25nOiZuYnNwOyBJbiB0aGUgc2FtZSBXRy4mbmJzcDsgTm90IHN1cmUgdGhlc2UgYXJlIHRpZWQg dG9nZXRoZXIgYW5kIGNvdWxkIGJlIGRpZmZlcmVudCBkcmFmdHMuJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Kb2huOiZuYnNwOyBXaGF0IHBhcnQ/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5YdWVzb25nOiBUaGUgc29sdXRpb24g c3BhY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DYXJsb3M6IEFs c28gd2lsbGluZyB0byByZXZpZXcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5Tcmk6Jm5ic3A7IE5lZWQgbW9yZSBkaXNjdXNzaW9uLCBnb29kIGZlZWRiYWNrLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48dT5BcmNoaXRlY3R1cmUgRGlzY3Vzc2lvbiBvbiBT UnY2IG1vYmlsZSBVc2VyIHBsYW5lLCBNaXlhIEtvaG5vPG86cD48L286cD48L3U+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5Ib3cgdG8gbWFwIG1vYmlsaXR5IGRhdGEgcGxhbmUuJm5ic3A7IFN1Z2dlc3Rz IFNSdjYgaXMgdGhlIHJpZ2h0IGNob2ljZSBmb3IgNUcuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5TdWdnZXN0cyBhbiBhZGRpdGlvbmFsIHVzZXIgcGxhbmUgSUQgaXMg cmVxdWlyZWQgZm9yIHNsaWNlIG1hcHBpbmcuJm5ic3A7IFBFIHJlZHVuZGFuY3kgaXMgYW4gYWRk aXRpb25hbCByZXF1aXJlbWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkdvYWwgaXMgdG8gaGF2ZSB0aGUgVVBGIGJlIHBhcnQgb2YgdGhlIFROIGFuZCBub3QgYSBD RS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+M0dQUCBlbnRpdGllcyBkbyBub3QgY2Fy ZSBhYm91dCBJUCByb3V0aW5nPz8mbmJzcDsmbmJzcDsgU2lkZWNhciBwcm94eSBjYW4gdGFrZSBj YXJlIG9mIGNvbW11bmljYXRpb24gc3RhdGUgZXhjaGFuZ2UuJm5ic3A7IEJTSUQgY2FuIGJlIHVz ZWQgZm9yIHRvcG9sb2d5IGhpZGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlVSTExDIHdpdGggZHVwbGljYXRpb24gYW5kIGVsaW1pbmF0aW9uIHJlcXVpcmVzIG1v ZGlmaWNhdGlvbiBvZiBHVFAtVS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlByb3Bvc2VkIGZvciBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5Kb2huOiBHb29kIHBvaW50cyBvbiBVUkxMQy4gSG93IGRvZXMgU1J2NiBhbGxvdyBwYXRocyB0 byBiZSBkaXNqb2ludD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPk1peWE6IENvdWxkIHByb3ZpZGUgVEktTEZBIGFuZCBvdGhlciB0b29scy4gU1IgYXdhcmUg ZW50aXRpZXMgY2FuIGRpcmVjdGx5IGNvbnRyb2wgdGhlIG1lY2hhbmlzbXMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Kb2huOiBXaXRoIGEgY2hhaW4gb2YgTjMvTjks IGhvdyBkb2VzIFNSdjYgaGVscD8mbmJzcDsgJmx0O2dvIG9mZmxpbmUmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdXJlc2g6IFdoYXQgaXMgdGhpcyBhIHNlcGFy YXRlIGRvY3VtZW50PyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+TWl5YTogU1J2NiBtb2JpbGUgdXNlciBwbGFuZSBkb2N1bWVudCBzaW1wbHkgZGVz Y3JpYmVzIHRoZSBwcm90b2NvbC4gSSB3YW50ZWQgdG8gZGlzY3VzcyBtb3JlIHRoZSBhcmNoaXRl Y3R1cmFsIGltcGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlN1cmVzaDogVGV4dCBpcyB1c2VmdWwsIGhvdyBpdCBwcm9jZWVkcyB0byBiZSBkaXNjdXNz ZWQuIEl0IGlzIHByZXR0eSBkZXBlbmRlbnQgb24gb3RoZXIgc3R1ZmYuIFRoaXMgY29tZXMgdXAg aW4gSUVTRyBhcyBzdXBwb3J0aW5nIGRvY3VtZW50cy4mbmJzcDsgSWYgaXQgaXMgdG8gYmUgc2Vw YXJhdGUgYW5kIHByb2dyZXNzIG5lZWQgdG8gdGhpbmsgYWJvdXQgdGhlIHdyaXRlIHVwLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3JpOiBHb29kIHBvaW50cy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlVtYTogR29vZCBxdWVzdGlvbnMg YXJlIGFza2VkLiZuYnNwOyBDYW4gY29sbGFwc2UgR1RQVSBhbmQgU1J2Ni4mbmJzcDsgV2UgYXJl IGVudmlzaW9uaW5nIGEgZnV0dXJlIG9mIElQdjYgb25seSB0cmFuc3BvcnQuIFdoZW4gd2Ugc3Rh cnRlZCBpdCB3cyBOUzFVLiZuYnNwOyBUaGlzIGlzIGEgYmlnZ2VyIGRpc2N1c3Npb24uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NYXJjbzogU2VydmljZSBtZXNoLCB3 aGF0IGRvZXMgdGhpcyBoYXZlIHRvIGRvIHdpdGggc2xpY2luZy4gSXQgaXMgYW4gaW1wbGVtZW50 YXRpb24gbWF0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TWl5 YTogQ29udmVudGlvbmFsIGJveCB0aGlua2luZyBuZWVkcyB0byBiZSBldmFsdWF0ZWQuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NYXJjbzogV2hhdCBhYm91dCBwcm94 aWVzLi4uICZsdDs/Jmd0Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pk1peWE6Jm5ic3A7IElGIHRoZXJlIGNvdWxkIGJlIGEgcHJveHkgdGhhdCBjb3VsZCBkbyBhbGwg cm91dGluZyBhbmQgZm9yd2FyZGluZyBzdHVmZiBhbmQgaXQgc2l0cyBpbiB0aGUgaG9zdC4gV2Ug Y291bGQgcHJvdmlkZSByb3V0aW5nIGluIGhvc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5SYWplZXY6IExpa2VkIHRoZSBzaWRlIGNhciBhbmFsb2d5LCBzbyB0aGUg cHJveHkgd2FzIGFkamFjZW50IHRvIHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYuJm5ic3A7Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5NYXJjbzombmJzcDsgU2lk ZWNhcnMgZnVuY3Rpb24gYXQgYSBESENQIGxldmVsLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+UmFqZWV2OiBUaGVyZSBpcyBhbHNvIHRoZSBub3Rpb24gb2Yg YXBwbGljYXRpb24gcm91dGluZy4gTGluZXMgYXJlIGJsdXJyaW5nIGFuZCBoYXZlIGJlZW4gZm9y IHNvbWUgdGltZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlN1cmVz aDombmJzcDsgSWYgaW4gYSBzaWRlY2FyLCB0aGUgYXBwIGRvZXMgbm90IG5lZWQgdG8ga25vdyBh Ym91dCBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNy aTogR29vZCB3b3JrLCBuZWVkcyBtb3JlIGRpc2N1c3Npb24uJm5ic3A7Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5VbWE6IFRoaXMgYW5kIHRoZSBsYXN0IHBy ZXNlbnRhdGlvbiBhcmUgdmVyeSBtdWNoIGNvbm5lY3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHU+TW9iaWxpdHkgY2FwYWJpbGl0eSBuZWdvdGlhdGlvbiBhbmQgcHJvdG9jb2wg c2VsZWN0aW9uJm5ic3A7IFpoaXdlaTxvOnA+PC9vOnA+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VHdvIGNhdGVnb3JpZXMsIG5ldHdvcmsgYW5kIGhvc3QgYmFzZWQgc29sdXRpb25zLiZuYnNwOyZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdWdnZXN0cyBhIG5lZ290aWF0aW5n IGRpc2NpcGxpbmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBvc3NpYmxlIHNvbHV0 aW9ucyBmb3IgbmVnb3RpYXRpb24uJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5JQ01QdjYgZ2V0cyBhIG5ldyBvcHRpb24uJm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlN1cmVzaDogRXZlcnl0aGluZyB5b3Ugc2F5IGhhcyBiZWVu IHRyaWVkIGJlZm9yZS4gMjAwNy0yMDA4LCBpdCBuZXZlciB3b3JrZWQuIElmIHRoZSBuZXR3b3Jr IGNhbiBkbyBpdCwgaXQgd2lsbCBkbyBpdC4mbmJzcDsgQ01JUCB2cyBQTUlQLiBUaGUgcHJvYmxl bSBpcyBub3QgdGVjaG5pY2FsLiBUaGVyZSBpcyBubyBkZXBsb3ltZW50IHNjZW5hcmlvIHdoZXJl IHRoaXMgd2lsbCBiZSB1c2VmdWwuJm5ic3A7IFRoZXJlIGlzDQogYSBwYXN0IGhpc3Rvcnkgb2Yg ZmFpbHVyZS4mbmJzcDsgVGhpbmsgYWJvdXQgd2hlcmUgYW5kIGhvdyB5b3Ugd291bGQgdXNlIHRo aXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNyaTogTWF5IHdhbnQgdG8gd29yayB3 aXRoIGEgZmV3IHBlb3BsZSwgZ2V0IHNvbWUgZmVlZGJhY2ssIGFuZCBkZWNpZGUgd2hldGhlciB0 byBwdXJzdWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SYWplZXY6 IEZvciBhbiBlbmRwb2ludCBhdHRhY2hlZCB0byBjZWxsdWxhciwgZ29pbmcgdG8gYSBzaXRlIEdX LCB3aGVyZSBpcyB0aGlzIG1lc3NhZ2UgZ29pbmc/IENvdWxkIGJlIGEgc2lkZSBnYXRld2F5LiZu YnNwOyBTTyB0aGlzIG5vdGlvbiBvZiBzb21ldGhpbmcgaW4gdGhlIFJTIGFuIFJBIHRvIGFsbG93 IG1vYmlsaXR5IHRvIHdvcmssIG5lZWRzIHRvIGJlIGNvbXBhdGlibGUgd2l0aCBvdXRzaWRlIG9m IHRoZQ0KIGNlbGx1bGFyIHdvcmxkLiZuYnNwOyBJdCB3b3VsZCBoYXZlIGEgbG93IGZvb3Rwcmlu dC4mbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlN1cmVzaDogVGhlIG90aGVyIG9uZXMgd2VyZSBSUyBSQSBiYXNlZC4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlVtYTombmJzcDsgV2h5IGRpZCBpdCBm YWlsLCBzZWN1cml0eSBvciB3aGF0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+U3VyZXNoOiBOb3QgYW5jaG9yZWQgaW4gYXJjaGl0ZWN0dXJlcyBhbnl3aGVyZS4mbmJz cDsgRm9yIGdvb2Qgb3IgYmFkLCBhcmNoaXRlY3R1cmVzIGRvbmUgZWxzZXdoZXJlLiZuYnNwOyBT dHVmZiBuZWVkIHRvIGJlIGFuY2hvcmVkIG9yIGl0IGdvZXMgbm93aGVyZS4gRGVwbG95bWVudCBz dXBwb3J0LiBFdmVyeXRoaW5nIFJhamVldiBzYWlkIHdhcyBsb29rZWQgYXQuJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjx1PllBTkcgZm9yIFByb3RvY29sIGZvciBGb3J3YXJk aW5nIFBvbGljeSBDb25maWd1cmF0aW9uIChGUEMpLyBTYXRvcnU8bzpwPjwvbzpwPjwvdT48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkZQQyBkaWQgbm90IHRvdWNoIGFueSBvdmVyIHRoZSB3aXJlIHByb3Rv Y29sLiBEZWNpZGVkIHRvIGRlZmluZSBhIFlBTkcgbW9kZWwgdG8gcHJvdmlkZSBhbiBBUEkuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFmdGVyIHRoZSB1cGRhdGUgYnkgQ2hhcmxpZSwg dGhlcmUgaGFzIG5vdCBiZWVuIGZ1cnRoZXIgd29yaywgc28gdGhlIGRyYWZ0IGhhcyBleHBpcmVk LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Db250aW51aW5nIHRvIHB1cnN1 ZSB0aGlzIGRlcGVuZGVudCBvbiBncm91cC9pbmR1c3RyeSBpbnRlcmVzdC4mbmJzcDsgQ29tbWVu dHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk1hcmNvOiBjby1hdXRob3IuIFRoaXMg c3R1ZmYgaXMgcHJldHR5IHN0YWJsZS4gU2luY2Ugd2UgaGF2ZSB0d28gcHJldHR5IG1hdHVyZSBw YXJ0cywgbmVlZCB0byByZXZpZXcuIEJ1dCB3ZSBzaG91bGQgcHJvZ3Jlc3MgdGhlbS4gTmVlZCBy ZWFzb25hYmxlIHJldmlld3MgdG8gcHJvY2VlZC4gSXQgd291bGQgYmUgYSBwaXR5IG5vdCB0byBw cm9jZWVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Tcmk6IE1vdmUgdGhpcyB0byB0 aGUgbWFpbGluZyBsaXN0LiZuYnNwOyBOZWVkIHRvIGdvIHRocm91Z2ggdGhlIHByb2Nlc3MgYW5k IGdldCBzb21lIHJldmlld3MuIFN1cmVzaCBhZ3JlZXMuJm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlNlc3Npb24gQ2xvc2VkPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F1A749CA9D1E4BD79CFB5F6E2F667036ciscocom_--