* Presenters: Please send your slides by Sunday, July 16th, 9PM CEST.<= /div>

- Dapping & Sri

=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1= =AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA= =A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA-

** DMM Working Group Agenda =A8C IETF99 **

Date: Wed, July 19th, 2017

Time: 9:30 AM to 12:00 PM, CEST

Location: Prague, Czech Republic

Room: Berlin/Brussels

@09:30 AM

Title: Administrivia & Intro, WG organization & milestones

Time: 15 minutes

Description: Agenda, Note-taker negotiation and WG Progress Update

Presenters: Chairs

@09:45 AM

Title: Protocol for Forwarding Policy Configuration (FPC) in DMM

Time: 25 minutes

Presenter: Marco Liebsch

Description: Document = Status and Changes

Draft: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-07

@10:10 AM

Title: MN Identifier Types for RFC 4283 MN Id Option

Time: 15 minutes

Presenter: Charlie Perkins (and Suresh Krishnan on IESG feedback)=

Description: IESG DISCUSS Status

Draft: https://www.ietf.org/id/draft-ietf-dmm-4283mnids-04.txt<= /a>

@10:25 AM

Title: Distributed Mobility Anchoring

Time: 20 minutes

Presenter: H Anthony Chan

Description: Update on the changes related to last call comments

Draft: https://tools.ietf.org/html/draft-ietf-dmm-d= istributed-mobility-anchoring-06

@10:45 AM

Title: On Demand Mobility Management Socket Extensions

Time: 15 minutes

Pres= enter: Danny Moses

Description: Update on changes to the draft since IETF 98

Draf= t: https://www.ietf.org/id/draft-ietf-dmm-ondemand-mobility-11.txt

@11:00 AM

Title: DMM Deployment Models and Arc= hitectural Considerations

Time: 5 minutes

Presenter: TBD

Description: Update on the draft sta= tus

Draft: https://www.ietf.org/id/draft-ietf-dmm-deployment-models= -01.txt

@11:05 AM

Title: SRv6 for Mobile User-Plane<= /div>

Time: 15 minutes

Presenter: Satoru Matsushima

Description: Applicability of SRv6= (Segment Routing IPv6) to user-plane of mobile networks

Draft: https:/= /tools.ietf.org/html/draft-matsushima-spring-dmm-srv6-mobile-uplane-00&= nbsp;

@11:20AM

Title: Network-based and Client-based DMM solutions using= Mobile IP me= chanisms

Time: 15 minutes

Presenter: Carlos Jes=A8=B2s Bernardos Cano

Description: Use of MIP protocol in DMM a= rchitecture

Draft (s):

ht= tps://www.ietf.org/id/draft-bernardos-dmm-cmip-07.txt

ht= tps://www.ietf.org/id/draft-bernardos-dmm-pmip-08.txt

https://www.ietf.org/id/draft-bernardos-dmm-distributed-anch= oring-09.txt

@11:35 AM

Title: Router Advertisement Prefix Option Extension for On-Demand= Mobility

Time: 10 minutes

Presenter: Wu-chiX Feng

Description: Extensions to ND for indicating Mobility Service Type

Draf= t: https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-00.txt =

@11: 45 AM

Title: Virtual CPE Deployment Considerations

Time: 10 minutes

Presenter: TBD

Description: Virtual CPE Architecture and DMM Interfaces

Draft: https://tools.ietf.org/html/draft-pularikkal-virtual-cpe-02<= /a>

11:55AM Adjourn

=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1= =AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA= =A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA=A1=AA-

--_000_D582DC4A2831A5sgundaveciscocom_-- From nobody Mon Jul 10 12:26:17 2017 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 D60B113188A for ; Mon, 10 Jul 2017 12:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2miXKjzQwK7O for ; Mon, 10 Jul 2017 12:26:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E29131866 for ; Mon, 10 Jul 2017 12:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26652; q=dns/txt; s=iport; t=1499714773; x=1500924373; h=from:to:cc:subject:date:message-id:mime-version; bh=GZ9vERJsgExYpBrDTlWdqCWYKjU9ptWqgPLLDw/cA6s=; b=cL0sTT4HUlXJtYomvHYzGQBLr8w5DG+Pml/tIuGzH8LotMjlS/UJrMjz BEy8siCqCjOA/zYzghH5LC/NOd9AUsFnIihlfTq2Y4ZAGBpGDeFllqCer WnOJXockDmY4ZRbze3UFLFcRfQNSk7jGynBoV0YimBB4YnzfrqlGJuY5F g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAQAp1GNZ/4oNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9rZIEUB4NpY4k2kWuWBIIRLoVuHIMPPxgBAgEBAQEBAQFrHQuFGAE?= =?us-ascii?q?DAyNWEgEGAhEBAgECIQcDAgQwFAMGCgQOBRuJMGQQjWedY4Imiz0BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARkFgyiDTIFhgySFCoJzgmEFnx4Ch0aMQoIMhUuKS4k4jAc?= =?us-ascii?q?BHziBCnUVH4dAdgGHWIENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,342,1496102400"; d="scan'208,217";a="266428835" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jul 2017 19:26:12 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6AJQCRb018537 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Jul 2017 19:26:12 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Jul 2017 14:26:11 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Mon, 10 Jul 2017 14:26:11 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" CC: =?utf-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= Thread-Topic: DMM Working Group Agenda - IETF99 (Rev-2) Thread-Index: AQHS+bJjQTB8jErM3Ee3WYazXfFm7A== Date: Mon, 10 Jul 2017 19:26:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.188.59] Content-Type: multipart/alternative; boundary="_000_D5892257283B87sgundaveciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [DMM] DMM Working Group Agenda - IETF99 (Rev-2) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 19:26:16 -0000 --_000_D5892257283B87sgundaveciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSB0aGUgYmVsb3cgcGFnZSBmb3IgdGhlIHVwZGF0ZWQgYWdlbmRhOg0KDQpodHRw czovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85OS9hZ2VuZGEvYWdlbmRhLTk5LWRtbS0wMA0K DQoNCg0KDQpGcm9tOiBTcmkgR3VuZGF2ZWxsaSA8c2d1bmRhdmVAY2lzY28uY29tPG1haWx0bzpz Z3VuZGF2ZUBjaXNjby5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdWx5IDUsIDIwMTcgYXQgMTE6 MDEgUE0NClRvOiAiZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+IiA8ZG1tQGlldGYu b3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+Pg0KQ2M6ICLliJjlpKfpuY8o6bmP5oiQKSIgPG1heC5s ZHBAYWxpYmFiYS1pbmMuY29tPG1haWx0bzptYXgubGRwQGFsaWJhYmEtaW5jLmNvbT4+DQpTdWJq ZWN0OiBETU0gV29ya2luZyBHcm91cCBBZ2VuZGEgLSBJRVRGOTkNCg0KQXR0YWNoZWQgaXMgdGhl IGFnZW5kYSBmb3IgdGhlIERNTSBtZWV0aW5nIGF0IElFVEY5OS4NCg0KKiBQcmVzZW50ZXJzOiBQ bGVhc2Ugc2VuZCB5b3VyIHNsaWRlcyBieSBTdW5kYXksIEp1bHkgMTZ0aCwgOVBNIENFU1QuDQoN Ci0gRGFwcGluZyAmIFNyaQ0KDQrigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTigJTi gJQtDQoqKiBETU0gV29ya2luZyBHcm91cCBBZ2VuZGEg4oCTIElFVEY5OSAqKg0KDQpEYXRlOiAg V2VkLCBKdWx5IDE5dGgsIDIwMTcNClRpbWU6ICA5OjMwIEFNIHRvIDEyOjAwIFBNLCBDRVNUDQpM b2NhdGlvbjogICBQcmFndWUsIEN6ZWNoIFJlcHVibGljDQpSb29tOiBCZXJsaW4vQnJ1c3NlbHMN Cg0KDQpAMDk6MzAgIEFNDQpUaXRsZTogQWRtaW5pc3RyaXZpYSAmIEludHJvLCBXRyBvcmdhbml6 YXRpb24gJiBtaWxlc3RvbmVzDQpUaW1lOiAxNSBtaW51dGVzDQpEZXNjcmlwdGlvbjogQWdlbmRh LCBOb3RlLXRha2VyIG5lZ290aWF0aW9uIGFuZCBXRyBQcm9ncmVzcyBVcGRhdGUNClByZXNlbnRl cnM6IENoYWlycw0KDQoNCkAwOTo0NSBBTQ0KVGl0bGU6IFByb3RvY29sIGZvciBGb3J3YXJkaW5n IFBvbGljeSBDb25maWd1cmF0aW9uIChGUEMpIGluIERNTQ0KVGltZTogMjUgbWludXRlcw0KUHJl c2VudGVyOiBNYXJjbyBMaWVic2NoDQpEZXNjcmlwdGlvbjogIERvY3VtZW50IFN0YXR1cyBhbmQg Q2hhbmdlcw0KRHJhZnQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRt bS1mcGMtY3BkcC0wNw0KDQoNCkAxMDoxMCBBTQ0KVGl0bGU6IE1OIElkZW50aWZpZXIgVHlwZXMg Zm9yIFJGQyA0MjgzIE1OIElkIE9wdGlvbg0KVGltZTogMTUgbWludXRlcw0KUHJlc2VudGVyOiBD aGFybGllIFBlcmtpbnMgKGFuZCBTdXJlc2ggS3Jpc2huYW4gb24gSUVTRyBmZWVkYmFjaykNCkRl c2NyaXB0aW9uOiBJRVNHIERJU0NVU1MgU3RhdHVzDQpEcmFmdDogIGh0dHBzOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LWlldGYtZG1tLTQyODNtbmlkcy0wNC50eHQ8aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtaWV0Zi1kbW0tZGVwbG95bWVudC1tb2RlbHMtMDEudHh0Pg0KDQoNCkAxMDoy NSBBTQ0KVGl0bGU6IERpc3RyaWJ1dGVkIE1vYmlsaXR5IEFuY2hvcmluZw0KVGltZTogIDIwIG1p bnV0ZXMNClByZXNlbnRlcjogSCBBbnRob255IENoYW4NCkRlc2NyaXB0aW9uOiBVcGRhdGUgb24g dGhlIGNoYW5nZXMgcmVsYXRlZCB0byBsYXN0IGNhbGwgY29tbWVudHMNCkRyYWZ0OiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbW0tZGlzdHJpYnV0ZWQtbW9iaWxpdHkt YW5jaG9yaW5nLTA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG1tLWRp c3RyaWJ1dGVkLW1vYmlsaXR5LWFuY2hvcmluZy0wMz42DQoNCg0KQDEwOjQ1IEFNDQpUaXRsZTog T24gRGVtYW5kIE1vYmlsaXR5IE1hbmFnZW1lbnQgU29ja2V0IEV4dGVuc2lvbnMNClRpbWU6IDE1 IG1pbnV0ZXMNClByZXNlbnRlcjogRGFubnkgTW9zZXMNCkRlc2NyaXB0aW9uOiBVcGRhdGUgb24g Y2hhbmdlcyB0byB0aGUgZHJhZnQgc2luY2UgSUVURiA5OA0KRHJhZnQ6IGh0dHBzOi8vd3d3Lmll dGYub3JnL2lkL2RyYWZ0LWlldGYtZG1tLW9uZGVtYW5kLW1vYmlsaXR5LTExLnR4dA0KDQoNCkAx MTowMCBBTQ0KVGl0bGU6IERNTSBEZXBsb3ltZW50IE1vZGVscyBhbmQgQXJjaGl0ZWN0dXJhbCBD b25zaWRlcmF0aW9ucw0KVGltZTogNSBtaW51dGVzDQpQcmVzZW50ZXI6IFRCRA0KRGVzY3JpcHRp b246IFVwZGF0ZSBvbiB0aGUgZHJhZnQgc3RhdHVzDQpEcmFmdDogIGh0dHBzOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LWlldGYtZG1tLWRlcGxveW1lbnQtbW9kZWxzLTAxLnR4dA0KDQoNCkAxMTow NSBBTQ0KVGl0bGU6IFNSdjYgZm9yIE1vYmlsZSBVc2VyLVBsYW5lDQpUaW1lOiAxNSBtaW51dGVz DQpQcmVzZW50ZXI6IFNhdG9ydSBNYXRzdXNoaW1hDQpEZXNjcmlwdGlvbjogQXBwbGljYWJpbGl0 eSBvZiBTUnY2IChTZWdtZW50IFJvdXRpbmcgSVB2NikgdG8gdXNlci1wbGFuZSBvZiBtb2JpbGUg bmV0d29ya3MNCkRyYWZ0OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0c3Vz aGltYS1zcHJpbmctZG1tLXNydjYtbW9iaWxlLXVwbGFuZS0wMA0KDQoNCkAxMToyMEFNDQpUaXRs ZTogIE5ldHdvcmstYmFzZWQgYW5kIENsaWVudC1iYXNlZCBETU0gc29sdXRpb25zIHVzaW5nIE1v YmlsZSBJUCBtZWNoYW5pc21zDQpUaW1lOiAxNSBtaW51dGVzDQpQcmVzZW50ZXI6ICBDYXJsb3Mg SmVzw7pzIEJlcm5hcmRvcyBDYW5vDQpEZXNjcmlwdGlvbjogVXNlIG9mIE1JUCBwcm90b2NvbCBp biBETU0gYXJjaGl0ZWN0dXJlDQpEcmFmdCAocyk6DQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC1iZXJuYXJkb3MtZG1tLWNtaXAtMDcudHh0DQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC1iZXJuYXJkb3MtZG1tLXBtaXAtMDgudHh0DQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC1iZXJuYXJkb3MtZG1tLWRpc3RyaWJ1dGVkLWFuY2hvcmluZy0wOS50eHQNCg0KDQpAMTE6 MzUgQU0NClRpdGxlOiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBQcmVmaXggT3B0aW9uIEV4dGVuc2lv biBmb3IgT24tRGVtYW5kIE1vYmlsaXR5DQpUaW1lOiAxMCBtaW51dGVzDQpQcmVzZW50ZXI6IFd1 LWNoaVggRmVuZw0KRGVzY3JpcHRpb246IEV4dGVuc2lvbnMgdG8gTkQgZm9yIGluZGljYXRpbmcg TW9iaWxpdHkgU2VydmljZSBUeXBlDQpEcmFmdDogIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWZlbmctZG1tLXJhLXByZWZpeHR5cGUtMDAudHh0DQoNCg0KQDExOiA0NSBBTQ0KVGl0bGU6 IFZpcnR1YWwgQ1BFIERlcGxveW1lbnQgQ29uc2lkZXJhdGlvbnMNClRpbWU6IDEwIG1pbnV0ZXMN ClByZXNlbnRlcjogVEJEDQpEZXNjcmlwdGlvbjogVmlydHVhbCBDUEUgQXJjaGl0ZWN0dXJlIGFu ZCBETU0gSW50ZXJmYWNlcw0KRHJhZnQ6ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtcHVsYXJpa2thbC12aXJ0dWFsLWNwZS0wMg0KDQoNCg0KMTE6NTVBTSAgICAgICBBZGpvdXJu DQoNCuKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlC0NCg0KDQo= --_000_D5892257283B87sgundaveciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1EC907EDEED515459D1461FB02246D7D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5QbGVhc2Ugc2Vl IHRoZSBiZWxvdyBwYWdlIGZvciB0aGUgdXBkYXRlZCBhZ2VuZGE6PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 OS9hZ2VuZGEvYWdlbmRhLTk5LWRtbS0wMCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvOTkvYWdlbmRhL2FnZW5kYS05OS1kbW0tMDA8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNr OyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQ QURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGlu OyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJv bTogPC9zcGFuPlNyaSBHdW5kYXZlbGxpICZsdDs8YSBocmVmPSJtYWlsdG86c2d1bmRhdmVAY2lz Y28uY29tIj5zZ3VuZGF2ZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBKdWx5IDUsIDIwMTcgYXQgMTE6 MDEgUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVv dDs8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90O+WImOWkp+m5 jyjpuY/miJApJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWF4LmxkcEBhbGliYWJhLWluYy5j b20iPm1heC5sZHBAYWxpYmFiYS1pbmMuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPkRNTSBXb3JraW5nIEdyb3VwIEFnZW5kYSAt IElFVEY5OTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5B dHRhY2hlZCBpcyB0aGUgYWdlbmRhIGZvciB0aGUgRE1NIG1lZXRpbmcgYXQgSUVURjk5LiZuYnNw OzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+KiBQcmVzZW50ZXJzOiBQbGVhc2Ugc2Vu ZCB5b3VyIHNsaWRlcyBieSBTdW5kYXksIEp1bHkgMTZ0aCwgOVBNIENFU1QuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIERhcHBpbmcgJmFtcDsgU3JpPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9Indv cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNp emU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU4oCU 4oCU4oCU4oCULTwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KKiogRE1NIFdv cmtpbmcgR3JvdXAgQWdlbmRhIOKAkyBJRVRGOTkgKio8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpEYXRlOiAmbmJzcDtXZWQsIEp1 bHkgMTl0aCwgMjAxNzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQg ZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5UaW1lOiAmbmJzcDs5OjMwIEFNIHRvIDEyOjAwIFBN LCBDRVNUPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQg ZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5Mb2NhdGlvbjogJm5ic3A7IDwvZm9udD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7IGZvbnQtc2l6ZTogbWVkaXVtOyI+ UHJhZ3VlLCBDemVjaCBSZXB1YmxpYzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NClJvb206IEJlcmxpbi9CcnVzc2VsczwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+DQpAMDk6MzAgJm5ic3A7QU08L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij4NClRpdGxlOiBBZG1pbmlzdHJpdmlhICZhbXA7IEludHJvLCBXRyBv cmdhbml6YXRpb24gJmFtcDsgbWlsZXN0b25lczwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KVGltZTogMTUgbWludXRlczwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KRGVzY3JpcHRpb246IEFnZW5kYSwgTm90ZS10YWtlciBuZWdvdGlhdGlvbiBhbmQgV0cg UHJvZ3Jlc3MgVXBkYXRlPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpQcmVz ZW50ZXJzOiBDaGFpcnM8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpAMDk6NDUgQU0gJm5ic3A7ICZuYnNwOyAmbmJzcDs8 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NClRpdGxlOiBQcm90b2NvbCBmb3Ig Rm9yd2FyZGluZyBQb2xpY3kgQ29uZmlndXJhdGlvbiAoRlBDKSBpbiBETU08L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtp dC1zdGFuZGFyZDsiPlRpbWU6IDI1IG1pbnV0ZXM8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+DQpQcmVzZW50ZXI6IE1hcmNvIExpZWJzY2gmbmJzcDs8L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogLXdl YmtpdC1zdGFuZGFyZDsiPkRlc2NyaXB0aW9uOiAmbmJzcDtEb2N1bWVudCBTdGF0dXMgYW5kIENo YW5nZXM8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpEcmFmdDom bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbW0t ZnBjLWNwZHAtMDciPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRtbS1m cGMtY3BkcC0wNzwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpAMTA6MTAgQU08L2Rpdj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJk OyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij5UaXRsZTombmJzcDs8L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj5NTiBJZGVudGlmaWVyIFR5cGVzIGZvciBSRkMgNDI4MyBNTiBJZCBPcHRp b248L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+VGlt ZTogMTUgbWludXRlczwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN0YW5kYXJkOyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5QcmVzZW50ZXI6 IENoYXJsaWUgUGVya2lucyAoYW5kIFN1cmVzaCZuYnNwO0tyaXNobmFuIG9uIElFU0cgZmVlZGJh Y2spPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPkRl c2NyaXB0aW9uOiBJRVNHIERJU0NVU1MgU3RhdHVzPC9mb250PjwvZGl2Pg0KPGRpdj5EcmFmdDog Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kbW0tZGVw bG95bWVudC1tb2RlbHMtMDEudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LWRtbS00MjgzbW5pZHMtMDQudHh0PC9hPiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpAMTA6MjUgQU0gJm5ic3A7ICZuYnNwOyAmbmJzcDs8 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXY+VGl0bGU6IERpc3RyaWJ1 dGVkIE1vYmlsaXR5IEFuY2hvcmluZzwvZGl2Pg0KPGRpdj5UaW1lOiAmbmJzcDsyMCBtaW51dGVz ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDs8L2Rpdj4NCjxkaXY+UHJl c2VudGVyOiBIIEFudGhvbnkgQ2hhbiZuYnNwOzwvZGl2Pg0KPGRpdj5EZXNjcmlwdGlvbjogVXBk YXRlIG9uIHRoZSBjaGFuZ2VzIHJlbGF0ZWQgdG8gbGFzdCBjYWxsIGNvbW1lbnRzPC9kaXY+DQo8 ZGl2PkRyYWZ0OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWRtbS1kaXN0cmlidXRlZC1tb2JpbGl0eS1hbmNob3JpbmctMDMiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRtbS1kaXN0cmlidXRlZC1tb2JpbGl0eS1hbmNo b3JpbmctMDwvYT42PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5 bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpAMTA6NDUg QU08L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXY+VGl0bGU6IE9uIERl bWFuZCBNb2JpbGl0eSBNYW5hZ2VtZW50IFNvY2tldCBFeHRlbnNpb25zPC9kaXY+DQo8ZGl2PlRp bWU6IDE1IG1pbnV0ZXM8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPjwvc3Bhbj5QcmVzZW50ZXI6IERhbm55IE1vc2VzPC9k aXY+DQo8ZGl2PkRlc2NyaXB0aW9uOiBVcGRhdGUgb24gY2hhbmdlcyB0byB0aGUgZHJhZnQgc2lu Y2UgSUVURiA5ODwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxl PSJ3aGl0ZS1zcGFjZTogcHJlOyI+PC9zcGFuPkRyYWZ0OiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZG1tLW9uZGVtYW5kLW1vYmlsaXR5LTExLnR4dCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kbW0tb25kZW1hbmQtbW9iaWxpdHkt MTEudHh0PC9hPiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KQDExOjAwIEFNPC9kaXY+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1z ZXJpZiI+VGl0bGU6IERNTSBEZXBsb3ltZW50IE1vZGVscyBhbmQgQXJjaGl0ZWN0dXJhbCBDb25z aWRlcmF0aW9uczwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNl cmlmIj5UaW1lOiA1IG1pbnV0ZXM8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+UHJlc2VudGVyOiBUQkQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNhbGlicmksc2Fucy1zZXJpZiI+RGVzY3JpcHRpb246IFVwZGF0ZSBvbiB0aGUgZHJhZnQg c3RhdHVzPC9mb250PjwvZGl2Pg0KPGRpdj5EcmFmdDogJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1kbW0tZGVwbG95bWVudC1tb2RlbHMtMDEudHh0Ij5o dHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWRtbS1kZXBsb3ltZW50LW1vZGVscy0w MS50eHQ8L2E+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpAMTE6MDUgQU08L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij4NCjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+VGl0bGU6 IFNSdjYgZm9yIE1vYmlsZSBVc2VyLVBsYW5lPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5UaW1lOiAxNSBt aW51dGVzPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQg ZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5QcmVzZW50ZXI6Jm5ic3A7PC9mb250Pjxmb250IGZh Y2U9IkNhbGlicmksc2Fucy1zZXJpZiI+U2F0b3J1IE1hdHN1c2hpbWE8L2ZvbnQ+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiPkRlc2NyaXB0aW9uOiBBPC9mb250PnBwbGljYWJpbGl0eSBvZiBTUnY2IChTZWdtZW50IFJv dXRpbmcgSVB2NikgdG8gdXNlci1wbGFuZSBvZiBtb2JpbGUgbmV0d29ya3M8L2Rpdj4NCjxkaXYg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+ RHJhZnQ6Jm5ic3A7PC9mb250PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1tYXRzdXNoaW1hLXNwcmluZy1kbW0tc3J2Ni1tb2JpbGUtdXBsYW5lLTAwIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0c3VzaGltYS1zcHJpbmctZG1tLXNydjYtbW9i aWxlLXVwbGFuZS0wMDwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpAMTE6MjBBTTwvZGl2Pg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+VGl0bGU6ICZuYnNwOzwvZm9udD48Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiPk5ldHdvcmstYmFzZWQgYW5kIENsaWVudC1iYXNlZCBETU0g c29sdXRpb25zIHVzaW5nIE1vYmlsZSBJUCZuYnNwOzwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5tZWNoYW5pc21zPC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij5UaW1lOiAxNSBtaW51dGVzPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIiBzdHlsZT0iY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPlByZXNlbnRlcjogJm5ic3A7PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJp ZiI+Q2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubzwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij4NCjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+RGVzY3Jp cHRpb246IFVzZSBvZiBNSVAgcHJvdG9jb2wgaW4gRE1NIGFyY2hpdGVjdHVyZTwvZm9udD48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+RHJhZnQgKHMpOjwvZGl2 Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1iZXJuYXJkb3Mt ZG1tLWNtaXAtMDcudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1iZXJuYXJkb3Mt ZG1tLWNtaXAtMDcudHh0PC9hPjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1iZXJuYXJkb3MtZG1tLXBtaXAtMDgudHh0Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC1iZXJuYXJkb3MtZG1tLXBtaXAtMDgudHh0PC9hPjwvZGl2Pg0KPGRpdj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1iZXJuYXJkb3MtZG1tLWRpc3Ry aWJ1dGVkLWFuY2hvcmluZy0wOS50eHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJl cm5hcmRvcy1kbW0tZGlzdHJpYnV0ZWQtYW5jaG9yaW5nLTA5LnR4dDwvYT4mbmJzcDs8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K QDExOjM1IEFNPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2PjxzcGFu IGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij48L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxkaXY+VGl0bGU6 Jm5ic3A7Um91dGVyIEFkdmVydGlzZW1lbnQgUHJlZml4IE9wdGlvbiBFeHRlbnNpb24gZm9yIE9u LURlbWFuZCBNb2JpbGl0eTwvZGl2Pg0KPGRpdj5UaW1lOiAxMCBtaW51dGVzPC9kaXY+DQo8ZGl2 PlByZXNlbnRlcjogV3UtY2hpWCBGZW5nJm5ic3A7PC9kaXY+DQo8ZGl2PkRlc2NyaXB0aW9uOiBF eHRlbnNpb25zIHRvIE5EIGZvciBpbmRpY2F0aW5nIE1vYmlsaXR5IFNlcnZpY2UgVHlwZTwvZGl2 Pg0KPGRpdj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTog cHJlOyI+PC9zcGFuPkRyYWZ0OiAmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1mZW5nLWRtbS1yYS1wcmVmaXh0eXBlLTAwLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtZmVuZy1kbW0tcmEtcHJlZml4dHlwZS0wMC50eHQ8L2E+Jm5ic3A7PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QDExOiA0NSBBTTwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQpUaXRsZTogVmlydHVh bCBDUEUgRGVwbG95bWVudCBDb25zaWRlcmF0aW9uczwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTRweDsiPg0KVGltZTogMTAgbWludXRlczwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KUHJlc2VudGVyOiBUQkQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxkaXY+RGVzY3JpcHRpb246IFZpcnR1YWwgQ1BFIEFyY2hpdGVjdHVyZSBhbmQgRE1NIElu dGVyZmFjZXM8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KRHJh ZnQ6Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXB1bGFyaWtrYWwtdmlydHVhbC1jcGUtMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1wdWxhcmlra2FsLXZpcnR1YWwtY3BlLTAyPC9hPiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KMTE6NTVBTSAmbmJzcDsgJm5i c3A7ICZuYnNwOyBBZGpvdXJuPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCuKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlC08L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_D5892257283B87sgundaveciscocom_-- From nobody Thu Jul 20 00:44:39 2017 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 34BC01317A1 for ; Thu, 20 Jul 2017 00:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySjR33sWi-Gs for ; Thu, 20 Jul 2017 00:44:36 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659DE13169C for ; Thu, 20 Jul 2017 00:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10156; q=dns/txt; s=iport; t=1500536676; x=1501746276; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=YKlgmfgxKMlHzCKoxYZsCh8nbzOwSyewcDwHOwziyoI=; b=gJPXDhHUQkoPgqFJHGbfajB5gj5i+h61ptwfmhCb507ejeYcJSflPdIL 2oFQhuc2ODaFSQ7OUqmpHBOi2ZgTyB2wsq5P1UFMw7rGB+7bqf2GIaVru BuQh4Bvyq1/395cN6aUPCRwmCw7xD5HM/stq3iEX6+19IFh6cRTspbL6N U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQAMXnBZ/5RdJa1cHAEBBAEBCgEBg?= =?us-ascii?q?1pkgRQHjgSna4IRLoUZg28/GAECAQEBAQEBAWsdC4YKAx0BGgJkFxAEExuKFBC?= =?us-ascii?q?zFYsfAQEBBwEBAQEBAR0FgyiBYYFsgWGHalyFPAWfPgKHSYxPggyJSIZgiUiMF?= =?us-ascii?q?QEfOIEKdRUfKoUTHIFndgGHOYEygQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.40,382,1496102400"; d="scan'208";a="458261254" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2017 07:44:35 +0000 Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v6K7iZTe030609 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Jul 2017 07:44:35 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Jul 2017 02:44:34 -0500 Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Thu, 20 Jul 2017 02:44:34 -0500 From: "Sri Gundavelli (sgundave)" To: "dmm@ietf.org" Thread-Topic: Meeting Minutes - DMM@IETF99 Thread-Index: AQHTASwHzjPJ8cOPP0m80emRHneerQ== Date: Thu, 20 Jul 2017 07:44:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.87.58] Content-Type: text/plain; charset="Windows-1252" Content-ID: <945E0A1BC0841149B16A963271816314@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [DMM] Meeting Minutes - DMM@IETF99 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 07:44:38 -0000 Thanks to Lyle Bertz for capturing this notes. On 7/20/17, 12:22 AM, "Bertz, Lyle T [CTO]" wrote: >Copied over from Etherpad for your reference. > >** DMM Working Group Agenda ** > > >Date: Wed, July 19th, 2017 >Time: 9:30 AM to 12:00 PM, CEST >Location: IETF99 - Prague, Czech Republic >Meeting Chairs: Dapeng Liu (Alibaba) & Sri Gundavelli (Cisco) > > >9:30 AM: >Title: Administrivia & Intro, WG organization & milestones >Time: 15 minutes >Description: Agenda, Note-taker negotiation and WG Progress Update >Presenters: Chairs > > >9:45 AM: >Title: Protocol for Forwarding Policy Configuration (FPC) in DMM >Time: 25 minutes >Presenter: Lyle Bertz >Description: Document Status and Changes >Draft: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-07 > >- have been working weekly since Chicago >- focus on topology and policy >- implementation from Verizon (demo'd at MWC) >- ONOS and OpenDayLight. >- this is an information model (abstract) >- enhanced type model - DPN type >- topology is only for DPN selection >Suresh (AD): how soon before deadline? >Lyle: Aiming for end of Sept. >Sri: when are reviewers assigned? >Suresh: when you tell me its ready from YANG perspective. These specs are >obscure for those outside the area. Let's avoid last-minute surprise. >Lyle: understaood. >Dapeng: volunteers within this WG? (no one volunteered) >Suresh: without review, this document doesn't leave WG. Wants to see >non-author read. >Lyle: invite anyone to pop into the weekly calls. >SSuresh: we need people within the group to review. Wants to see more >discussion on list. >Lyle: we have write-up internally, will see if impact on mobility. >Determines how much before > > > > >10:10 AM: >Title: MN Identifier Types for RFC 4283 MN Id Option >Time: 15 minutes >Presenter: Charlie Perkins (and Suresh Krishnan on IESG feedback) >Description: IESG DISCUSS Status >Draft: https://www.ietf.org/id/draft-ietf-dmm-4283mnids-04.txt >- Lots of discussion around types and issues on mailing lists wrt the >draft >- Security issue > - Believe we have possible resolutions for issues that were raised > - Presented many parts of the mailing list discussion in the >presentation > - RFID Types explained further > - Noted adding more types for LPWAN >- Reviewed commentary from mailing list > - Privacy concerns > - MNIDs by their nature are privacy issues > - recommend encrypting all MNIDs > - Why so many MNIDs? > - people ask for them > - this proposal is a registry > - MUST encrypt (proper security measures) can help with the > - Low energy on mailing list on what is needed > - push registry to drive the expert review > - ensure IANA considerations in the registry are strong > - confirmed - only really for newer MNID types > - plan is to change IANA policy, get approval, designate the >experts and move on >- Next steps > - straw proposal > - keep id types and make further considerations and re-submit for >last call >- No hard delivery date for the next steps > > >10:25 AM: >Title: Distributed Mobility Anchoring >Time: 15 minutes >Presenter: H Anthony Chan >Description: Update on the changes related to last call comments >Draft:=20 >https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring- >06 >- 4 reviews resulting in 3 version updates; 1 review pending >- Reviewed each change > - In 06 > - deleted slicing from the document > - deleted security management > - Removed description of the forwarding table >- Noted the draft does not propose a solution but describes the mobility >anchor and parameters used in communication/signaling >- Described in detail the many different examples by which DMA can be >achieved >- Clarified scope of document and organized it so that you don=B9t have to >read everything >- Chair wants to ensure that all 4 prior reviewers approve the changes in >the latest spec version > > >10:40 AM: >Title: On Demand Mobility Management Socket Extensions >Time: 15 minutes >Presenter: Danny Moses >Description: Update on changes to the draft since IETF 98 >Draft: https://www.ietf.org/id/draft-ietf-dmm-ondemand-mobility-11.txt >- reviewed l(blocking issue) >- noted request from chairs to address socket blocking (setsockopt) >raised in IETF 98 by Erik Kline > - 3 alternatives proposed and put on list > - Noted that there was no mailing list response > - Dave Dolson made a comment (off list) but did not select one of the >3 options nor discussed it on the mailing list > - Selected 2nd alternative > - Chair asked if issue originator was satisfied by the solution? > - What is the guarantee of the SetSc return? session has been >successfully allocated and assigned to the client > - v6 Only noted several times > - Requests for accepting 2nd alternative > - As long as the function is documented that it blocks > - For POSIX, a non-blocking version or call back version is >async probably should be provided > - AD - Do we need another abstract function? > - EK - depends on OS > - In general, bind is hard to use cause the AF must be known > - More than 1 V6 address in the return? no > - SetSc uses return address > - Another approach raised - set preferences then do something >else > - Michael - the text is not clear that the APIs are abstract; >needs to make clearer > - does not mind but concerned by issues raised in other IETF >99 meetings > - Suresh - although we don=B9t do language bindings; goal is t= o >stay abstract > - Lyle - Suggested to change any reference of =8Ccode=B9 to >pseudo code to make it more apparent it is not a language binding. This >seems to address the concern > - Suresh - this work and privacy access are orthogonal; not sure >how the flags are considered or merging (RFC 5014 and this work) > - Need to check between specs and make some new considerations >- Support of future on demand types > - add new continuity type similar to 3GPP SSC mode 3 > - time limited session continuity > - valid and preferred lifetime > - Suresh - already signaled in the framework > - What is the graceful replacement use case (will ask on mailing list) > >10:55 AM: >Title: DMM Deployment Models and Architectural Considerations >Time: 5 minutes >Presenter: Seil Jeon >Description: Update on the draft status >Draft: https://www.ietf.org/id/draft-ietf-dmm-deployment-models-01.txt >- quick update >- Chair suggest to authors to fined reviewers (offline) for the document > > >11:00 AM: >Title: SRv6 for Mobile User-PlaneTime: 15 minutes >Presenter: Satoru Matsushima >Description: Applicability of SRv6 (Segment Routing IPv6) to user-plane >of mobile networks >Draft:=20 >https://tools.ietf.org/html/draft-matsushima-spring-dmm-srv6-mobile-uplane >-00 >- Context; a new proposal >- Showed current example of mobile network and tunneling solution >- Showed SRv6 impact >- Gave Srv6 in a nutshell review >- Showed examples of how this solution supports >- related to FPC yang as a possible way to implement the solution >Questions >- Xingpeng- Does this work use the prefix types for on demand mobility? > - Don=B9t think this is binding to the MN address assignment. >- Marco - May add more items to the paths that are not representative of >roles > - How is QoS handled? It is mentioned in the draft >- Dapeng - Why this vs. any other solution? Gets rid of tunnels >- Sri - Very good work item but not in the charter. Keep progressing and >will discuss with AD. >- Author hopes to update > > >11:15AM: >Title: Network-based and Client-based DMM solutions using Mobile IP >mechanisms >Time: 15 minutes >Presenter: Carlos Jes=FAs Bernardos Cano >Description: Use of MIP protocol in DMM architecture >Draft (s): >https://www.ietf.org/id/draft-bernardos-dmm-cmip-07.txt >https://www.ietf.org/id/draft-bernardos-dmm-pmip-08.txt >https://www.ietf.org/id/draft-bernardos-dmm-distributed-anchoring-09.txt >- reviewed the various documents >- noted prior demos @ IETF >- noted open source code availablity >- ask WG if this work should continiue and will follow this up on the >maling list > > >11:30 AM: >Title: Anchor-less Mobility Management >Time: 10 minutes >Presenter: Xinpeng(Jackie) Wei >Description: >Draft: https://tools.ietf.org/id/draft-wei-dmm-anchorless-mm-01.txt >- reviewed proposal >- described MEC use case (smart relocation) and changes for DMM >- has the author looked at LISP? Yes > >11:40AM: >Title: Router Advertisement Prefix Option Extension for On-Demand Mobility >Time: 10 minutes >Presenter: Wu-chiX Feng >Description: Extensions to ND for indicating Mobility Service Type >Draft: https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-00.txt >- reviewed >- suggested it was brought to 6man (was done) >- no conflict with X bit but there is another proposal to burn anohter >bit which eats 2 of the 3 R-bits >- Suresh noted an extension mechanims for the exhaust or control through >a registry >- Alex - Who makes the demand? > > - Authors: We don't want to change the semantics of RS with this >proposal. Network will provide alternatives for the 'who'? > >- If there is an argument to modify RS we could try but authors were >discouraged. >- PBD option may be good for this. - This should be discussed in 6MAN Working group, suggested by Suresh and others. > >11:50 AM: >Title: FORCES for FPC >Time: 5 minutes >Presenter: Jamal Salim >Description: Proposal for using FORCES on FPC as a south bound protocol >Draft: TBD >- Lyle - As an author we are interested in finishing the information model >- as an implementor interested in the protocol > > > >11:55 AM: Adjourn >________________________________________ From nobody Fri Jul 21 08:13:53 2017 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 8E1CB131761; Fri, 21 Jul 2017 08:13:51 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150065003154.11227.8171952980864593456@ietfa.amsl.com> Date: Fri, 21 Jul 2017 08:13:51 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-4283mnids-05.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 15:13:52 -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 : MN Identifier Types for RFC 4283 Mobile Node Identifier Option Authors : Charles E. Perkins Vijay Devarapalli Filename : draft-ietf-dmm-4283mnids-05.txt Pages : 13 Date : 2017-07-21 Abstract: Additional Identifier Type Numbers are defined for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-05 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-4283mnids-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-4283mnids-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 Tue Jul 25 14:36:24 2017 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 75B961252BA; Tue, 25 Jul 2017 14:36:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: ietf@ietf.org, dmm@ietf.org, draft-ietf-dmm-mag-multihoming.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150101858235.26256.6969152365134554054@ietfa.amsl.com> Date: Tue, 25 Jul 2017 14:36:22 -0700 Archived-At: Subject: [DMM] Genart telechat review of draft-ietf-dmm-mag-multihoming-04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 21:36:22 -0000 Reviewer: Robert Sparks 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-dmm-mag-multihoming-04 Reviewer: Robert Sparks Review Date: 2017-07-25 IETF LC End Date: 2017-06-16 IESG Telechat date: 2017-08-03 Summary: Ready with nits that should be addressed before publication as Proposed Standard Thanks for addressing most of the points in my review of -03. There are still a couple of things that I think need attention: * In the second bullet of section 3.2 there is a sentence that does not make sense. Look at "or at When operating" in this sentence: "Packet distribution can be done either at the transport level, e.g. using MPTCP or at When operating at the IP packet level, different packets distribution algorithms are possible." * I still find the definitions of Interface Label and Binding Identifier confusing. I suspect they _both_ need to be carefully rewritten to make sure they are definitions of the terms, and not descriptions of the interactions of the two fields. Why is the Interface Label definition talking so much about binding? As currently written, that last sentence of the Binding Identifier definition says the document says the mobile access gateway assigns a single unique binding identifier for each of its interfaces. From nobody Wed Jul 26 08:14:12 2017 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 0B03C132049; Wed, 26 Jul 2017 08:13:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150108203604.23028.13812219104720689196@ietfa.amsl.com> Date: Wed, 26 Jul 2017 08:13:56 -0700 Archived-At: Subject: [DMM] IPR Disclosure InterDigital Patent Holdings, Inc.'s Statement about IPR related to draft-ietf-dmm-distributed-mobility-anchoring X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 15:13:56 -0000 Dear Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil Jeon, Alexandre Petrescu, Fred Templin: An IPR disclosure that pertains to your Internet-Draft entitled "Distributed Mobility Anchoring" (draft-ietf-dmm-distributed-mobility-anchoring) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3030/). The title of the IPR disclosure is "InterDigital Patent Holdings, Inc.'s Statement about IPR related to draft-ietf-dmm-distributed-mobility-anchoring" Thank you IETF Secretariat From nobody Sun Jul 30 05:02:06 2017 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 D3A8312EA95; Sun, 30 Jul 2017 05:01: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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150141611481.17689.2753520886981134101@ietfa.amsl.com> Date: Sun, 30 Jul 2017 05:01:54 -0700 Archived-At: Subject: [DMM] I-D Action: draft-ietf-dmm-ondemand-mobility-12.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 12:01:55 -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 : On Demand Mobility Management Authors : Alper Yegin Danny Moses Kisuk Kweon Jinsung Lee Jungshin Park Seil Jeon Filename : draft-ietf-dmm-ondemand-mobility-12.txt Pages : 16 Date : 2017-07-30 Abstract: Applications differ with respect to whether they need IP session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies. This document describes a solution for taking the application needs into account by selectively providing IP session continuity and IP address reachability on a per- socket basis. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-12 https://datatracker.ietf.org/doc/html/draft-ietf-dmm-ondemand-mobility-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-ondemand-mobility-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 30 05:06:56 2017 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 1D92413188F for ; Sun, 30 Jul 2017 05:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 rskdEl0lhNjW for ; Sun, 30 Jul 2017 05:06:53 -0700 (PDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 71E8812EA95 for ; Sun, 30 Jul 2017 05:06:53 -0700 (PDT) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2017 05:06:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,436,1496127600"; d="scan'208,217";a="131191826" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga005.jf.intel.com with ESMTP; 30 Jul 2017 05:06:52 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 30 Jul 2017 05:06:51 -0700 Received: from hasmsx108.ger.corp.intel.com (10.184.198.18) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 30 Jul 2017 05:06:51 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.208]) by hasmsx108.ger.corp.intel.com ([169.254.9.171]) with mapi id 14.03.0319.002; Sun, 30 Jul 2017 15:06:48 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: New version of the OnDemand draft: draft-ietf-dmm-ondemand-mobility-12 Thread-Index: AdMJLAb+/QOI98fkTR2FJofLBMAZ4A== Date: Sun, 30 Jul 2017 12:06:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.124.184.193] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134F2CB8CHASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] New version of the OnDemand draft: draft-ietf-dmm-ondemand-mobility-12 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 12:06:55 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134F2CB8CHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In IETF99 (Prague) the following comments/questions were raised regarding t= he OnDemand draft: 1. Need to clarify in the text that the setsc() API is blocking 2. It is not clear from the text that the APIs are abstract 3. How does this work merge with RFC5014? 4. Request for a description of a use-case for 'Graceful-Replacement' To address these, we have posted a new version of the draft (v12) that incl= udes the following modifications: Clarified the text describing setsc(): The following text was added at the end of section 6.1 - New APIs: "setsc() may block the invoking thread if it triggers the TCP/IP stack to r= equest a new IP prefix from the network to construct the desired source IP= address. If an IP prefix with the desired session continuity features alre= ady exists (was previously allocated to the mobile host) and the stack is n= ot required to request a new one as a result of setting the IPV6_REQUIRE_SR= C_ON_NET flag (defined below), setsc() may return immediately with the cons= tructed IP address and will not block the thread. " Clarifying that the code in the draft is abstract We changed the word 'code' to 'pseudo-code' where code samples are provided= in the text In section 3.4 the original text: "(See code example in Section 4 below)" w= as replaced with: "(See pseudo-code example in Section 4 below)" In section 4 the original text: "The following example shows the code for c= reating..." was replaced with: "The following example shows the pseudo-code= for creating..." Merging this work with RFC5014: Added a new section - 5.4 Coexistence with rfc5014 - that describes the coe= xistence with source address selection defined in RFC5014: "RFC5014 defines new flags that may be used with setsockopt() to influence = source IP selection for a socket. The list of flags include: source home ad= dress, care-of address, temporary address, public address CGA (Cryptographi= cally Created Address) and non-CGA. When applications require session conti= nuity service and use setsc() and bind(), they should not set the flags spe= cified in RFC5014. However, if an application sets a specific option using setsockopt() with o= ne of the flags specified in RFC5014 and also selects a source IP address u= sing setsc() and bind() the IP address that was generated by setsc() and bo= und using bind() will be the one used by traffic generated using that socke= t and the options set by setsockopt() will be ignored. If bind() was not invoked after setsc() by the application, the IP address = generated by setsc() will not be used and traffic generated by the socket w= ill use a source IP address that complies with the options selected by sets= ockopt()." In my next email to the list, I will provide a description of the OnDemand = session continuity services including 'Graceful-Replacement' to elaborate o= n the differences between them and use-cases for their need. Thanks for the useful comments. Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134F2CB8CHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

In IETF99 (Prague) the following comments/questions = were raised regarding the OnDemand draft:

1. Need to clarify in the tex= t that the setsc() API is blocking

2. It is not clear from the t= ext that the APIs are abstract

3. How does this work merge w= ith RFC5014?

4. Request for a description = of a use-case for ‘Graceful-Replacement’

To address these, we have posted a new version of th= e draft (v12) that includes the following modifications:

Clarified the text describing setsc():

The following text was added at the end of section 6= .1 – New APIs:

“setsc() may block the invoking thread if it t= riggers the TCP/IP stack to request a new IP prefix from the network = to construct the desired source IP address. If an IP prefix with the desire= d session continuity features already exists (was previously allocated to the mobile host) and the stack is not require= d to request a new one as a result of setting the IPV6_REQUIRE_SRC_ON_NET f= lag (defined below), setsc() may return immediately with the constructed IP= address and will not block the thread. “

Clarifying that the code in the draft is abstract

We changed the word ‘code’ to ‘pse= udo-code’ where code samples are provided in the text

In section 3.4 the original text: “(See code e= xample in Section 4 below)” was replaced with: “(See pseudo-cod= e example in Section 4 below)”

In section 4 the original text: “The following= example shows the code for creating…” was replaced with: ̶= 0;The following example shows the pseudo-code for creating…”

Merging this work with RFC5014:

Added a new section – 5.4 Coexistence with rfc= 5014 – that describes the coexistence with source address selection d= efined in RFC5014:

“RFC5014 defines new flags that may be used wi= th setsockopt() to influence source IP selection for a socket. The list of = flags include: source home address, care-of address, temporary address, pub= lic address CGA (Cryptographically Created Address) and non-CGA. When applications require session continuity service= and use setsc() and bind(), they should not set the flags specified in RFC= 5014.

However, if an application sets a specific option us= ing setsockopt() with one of the flags specified in RFC5014 and also select= s a source IP address using setsc() and bind() the IP address that was gene= rated by setsc() and bound using bind() will be the one used by traffic generated using that socket and the option= s set by setsockopt() will be ignored.

If bind() was not invoked after setsc() by the appli= cation, the IP address generated by setsc() will not be used and traffic ge= nerated by the socket will use a source IP address that complies with the o= ptions selected by setsockopt().”

In my next email to the list, I will provide a descr= iption of the OnDemand session continuity services including ‘Gracefu= l-Replacement’ to elaborate on the differences between them and use-c= ases for their need.

Thanks for the useful comments.

Danny

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC28134F2CB8CHASMSX106gercor_-- From nobody Sun Jul 30 05:09:37 2017 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 2582B13188F for ; Sun, 30 Jul 2017 05:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 HBYGA8suQmwf for ; Sun, 30 Jul 2017 05:09:33 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 059C312EA95 for ; Sun, 30 Jul 2017 05:09:32 -0700 (PDT) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2017 05:09:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,436,1496127600"; d="scan'208,217";a="131192240" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga005.jf.intel.com with ESMTP; 30 Jul 2017 05:09:31 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 30 Jul 2017 05:09:30 -0700 Received: from hasmsx112.ger.corp.intel.com (10.184.198.40) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 30 Jul 2017 05:09:30 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.10.208]) by HASMSX112.ger.corp.intel.com ([169.254.11.95]) with mapi id 14.03.0319.002; Sun, 30 Jul 2017 15:09:28 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: More info on the different OnDemand Session Continuity services Thread-Index: AdMJLJtMY8bwUSb9Q16fOGua0S08FQ== Date: Sun, 30 Jul 2017 12:09:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.124.184.193] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC28134F2CBA3HASMSX106gercor_" MIME-Version: 1.0 Archived-At: Subject: [DMM] More info on the different OnDemand Session Continuity services X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 12:09:35 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC28134F2CBA3HASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In IETF99 (Prague) we introduced the "Graceful-Replacement" session continu= ity service in addition to the services specified in previous versions as a= result of 3GPP specifying SSC (Service and Session Continuity) mode 3. This led to some questions at IETF 99 regarding this new service and the ne= ed for the other services. I am sending this note (as promised in the DMM session), to refresh everyon= e's memory and to provide use-cases for each service type. Session Continuity Services are associated with source IP prefixes assigned= to mobile nodes by the network. The TCP/IP stack in the mobile node create= s IP addresses using those prefixes and assigns them upon request to specif= ic IP sockets. Applications on the mobile nodes request and receive source = IP addresses with a specific Session Continuity service. The draft specifies the following session continuity services (or "type of = source IP addresses" as they are referred to) in section 3.1: - Fixed IP Address A Fixed IP address is an address with a guarantee to be valid for a very lo= ng time, regardless of whether it is being used in any packet to/from the m= obile host, or whether or not the mobile host is connected to the network, or whether it moves from one point-of-attachment = to another (with a different IP prefix) while it is connected. - Session-lasting IP Address A session-lasting IP address is an address with a guarantee to be valid thr= oughout the IP session(s) for which it was requested. It is guaranteed to b= e valid even after the mobile host had moved from one point-of-attachment to another (with a different IP prefix). - Non-persistent IP Address This type of IP address does not provide IP session continuity nor IP addre= ss reachability. The IP address is created from an IP prefix that is obtain= ed from the serving IP gateway and is not maintained across gateway changes= . In other words, the IP prefix may be released and replaced by a new one w= hen the IP gateway changes due to the movement of the mobile host forcing t= he creation of a new source IP address with the updated allocated IP prefix. - Graceful Replacement IP Address In some cases, the network cannot guarantee the validity of the provided IP= prefix throughout the duration of the IP session, but can provide a limite= d graceful period of time in which both the original IP prefix and a new one are valid. This enables the application some flexib= ility in the transition from the existing source IP address to the new one. This gracefulness is still better than the non-persistence type of address = for applications that can handle a change in their source IP address but re= quire that extra flexibility. Some use-cases: Servers require Fixed IP addresses for reachability: A server that is connected to a mobile network requires that it be reachabl= e by its clients. One of the common ways of achieving reachability is by ad= vertising its source IP address via DNS. For this purpose it is very useful= to have an IP address that never changes (even when the server is disconne= cted from the network for maintenance). A change of source IP address will = require a DNS update to re-enable clients to reach it. This is a time-consu= ming process that is not desirable in many cases. Real-time application require session-lasting addresses for contiguous conn= ection: A real-time application that requires constant connection to peers through = the network requires the connection to be session-lasting. A change of the = source IP address will cause the destination address of packets sent back t= o become obsolete and, as a result, will not reach their destination. Altho= ugh this error could be detected by higher-layer protocols, the time to det= ect the loss and overcome it might be too large for some applications. A se= ssion-lasting source IP address guarantees that this event never occurs. Common viewers use non-persistent addresses: There are various non-real time applications that people use like: web brow= sing (for non-streaming activities) and email clients. These applications d= o not require any special service from the network and can recover from a s= ocket error caused by a change of the source IP address with minimal effect= on their user's experience. Non-persistent source IP addresses will do. Us= ing such addresses is beneficial for these applications and networks. Appli= cations do not suffer from their traffic having to be encapsulated, decapsu= lated and routed through non-optimal routes and through congested mobility = anchors, and networks can save their precious resources and still provide g= ood connectivity. Video viewers use Graceful-replacement addresses: The Graceful-replacement service is a compromise between session-lasting se= rvice and non-persistent service. They are the best fit for applications li= ke video applications that can handle a short disconnect from their server = if they accumulate enough content in local buffers. Although, in many cases= , the session-lasting service is the most appropriate service for such appl= ications, they can still work fairly well with graceful-replacement service= , since they can still control the exact time of switching to the new IP ad= dress. In some cases, Graceful-replacement service is even better than session-las= ting service for video viewers. When the content streamed to the viewer com= es from a cached (or replicate server) source in the local access network a= nd the host of the viewer handoffs to a point-of-attachment in a different = access network, it is preferable for the viewer to disconnect from the old = (and remote by now) cache and reconnect to a new local cache. This process = may take some time as the new cache needs to be located. While finding the = new cache, the user can still enjoy the movie that is continued to be strea= med from the old cache. The graceful time, enables the viewer to be prepare= d to switch to the new source without affecting the user's experience. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC28134F2CBA3HASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

In IETF99 (Prague) we introduced the “Graceful= -Replacement” session continuity service in addition to the services = specified in previous versions as a result of 3GPP specifying SSC (Service = and Session Continuity) mode 3.

This led to some questions at IETF 99 regarding this= new service and the need for the other services.

I am sending this note (as promised in the DMM sessi= on), to refresh everyone’s memory and to provide use-cases for each s= ervice type.

Session Continuity Services are associated with sour= ce IP prefixes assigned to mobile nodes by the network. The TCP/IP stack in= the mobile node creates IP addresses using those prefixes and assigns them= upon request to specific IP sockets. Applications on the mobile nodes request and receive source IP addresses w= ith a specific Session Continuity service.

The draft specifies the following session continuity= services (or “type of source IP addresses” as they are referre= d to) in section 3.1:

- Fixed IP Address
A Fixed IP address is an address with a guarantee to be valid for a very lo= ng time, regardless of whether it is being used in any packet to/from the m= obile host, or whether or not the mobile host is
connected to the network, or whether it moves from one point-of-attachment = to another (with a different IP prefix) while it is connected.

- Session-lasting IP Address
A session-lasting IP address is an address with a guarantee to be valid thr= oughout the IP session(s) for which it was requested. It is guaranteed to b= e valid even after the mobile host had moved from one
point-of-attachment to another (with a different IP prefix).

- Non-persistent IP Address

This type of IP address does not provide IP session = continuity nor IP address reachability. The IP address is created from an I= P prefix that is obtained from the serving IP gateway and is not maintained= across gateway changes. In other words, the IP prefix may be released and replaced by a new one when the IP= gateway changes due to the movement of the mobile host forcing the creatio= n of a new source
IP address with the updated allocated IP prefix.

- Graceful Replacement IP Address
In some cases, the network cannot guarantee the validity of the provided IP= prefix throughout the duration of the IP session, but can provide a limite= d graceful period of time in which both the original
IP prefix and a new one are valid. This enables the application some flexib= ility in the transition from the existing source IP address to the new one.=

This gracefulness is still better than the non-persi= stence type of address for applications that can handle a change in their s= ource IP address but require that extra flexibility.

Some use-cases:

Servers require Fixed IP addresses for reachability:=

A server that is connected to a mobile network requi= res that it be reachable by its clients. One of the common ways of achievin= g reachability is by advertising its source IP address via DNS. For this pu= rpose it is very useful to have an IP address that never changes (even when the server is disconnected from t= he network for maintenance). A change of source IP address will require a D= NS update to re-enable clients to reach it. This is a time-consuming proces= s that is not desirable in many cases.

Real-time application require session-lasting addres= ses for contiguous connection:

A real-time application that requires constant conne= ction to peers through the network requires the connection to be session-la= sting. A change of the source IP address will cause the destination address= of packets sent back to become obsolete and, as a result, will not reach their destination. Although this error co= uld be detected by higher-layer protocols, the time to detect the loss and = overcome it might be too large for some applications. A session-lasting sou= rce IP address guarantees that this event never occurs.

Common viewers use non-persistent addresses:

There are various non-real time applications that pe= ople use like: web browsing (for non-streaming activities) and email client= s. These applications do not require any special service from the network a= nd can recover from a socket error caused by a change of the source IP address with minimal effect on their u= ser’s experience. Non-persistent source IP addresses will do. Using s= uch addresses is beneficial for these applications and networks. Applicatio= ns do not suffer from their traffic having to be encapsulated, decapsulated and routed through non-optimal routes and= through congested mobility anchors, and networks can save their precious r= esources and still provide good connectivity.

Video viewers use Graceful-replacement addresses:

The Graceful-replacement service is a compromise bet= ween session-lasting service and non-persistent service. They are the best = fit for applications like video applications that can handle a short discon= nect from their server if they accumulate enough content in local buffers. Although, in many cases, the session-last= ing service is the most appropriate service for such applications, they can= still work fairly well with graceful-replacement service, since they can s= till control the exact time of switching to the new IP address.

In some cases, Graceful-replacement service is even = better than session-lasting service for video viewers. When the content str= eamed to the viewer comes from a cached (or replicate server) source in the= local access network and the host of the viewer handoffs to a point-of-attachment in a different access netw= ork, it is preferable for the viewer to disconnect from the old (and remote= by now) cache and reconnect to a new local cache. This process may take so= me time as the new cache needs to be located. While finding the new cache, the user can still enjoy the movi= e that is continued to be streamed from the old cache. The graceful time, e= nables the viewer to be prepared to switch to the new source without affect= ing the user’s experience.

---------------------------------------------------------------------
A member of the Intel Corporation group of companies