From nobody Mon Jan 1 18:21:51 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEABC126C89; Mon, 1 Jan 2018 18:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.586 X-Spam-Level: * X-Spam-Status: No, score=1.586 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 Qk3Cz56a8Je1; Mon, 1 Jan 2018 18:21:47 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254096.outbound.protection.outlook.com [40.92.254.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739D3124234; Mon, 1 Jan 2018 18:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7t3yuHNsckUd5bpssXE1G65i3s8n8ChG1DsYrgKz7RE=; b=clMzO47h0IxeS7Y7PWNdXpspBkd3S8xLOn6ObuomkY9IGIe3rjx/xztQO7bolJtNpFBv+xfKG2d0elHqZfqMA8TUmvF9t+xPz5RD4sL/ISxxiKvyM/J9EQD9XI2hZyW4eS7pTVpSCKEnDedOHSrX8GPj8KwPf3E8az8eCB1u5tYf4HGcCXZ9dV55CsKHWJEpATT8GJXOGbF43b9ShlRFM4w7PwhoPuKQSX1jmszicNRSUK7dGzuJzqYG3gRddos6flCyX1k118EmPJF+mhNEN/6OmXDO+rlSAWQSnFHmxPTn77n2LbF8HfQFB0YHqFWlC2KLd4GIeuiL1ZKmdXhTWw== Received: from SG2APC01FT017.eop-APC01.prod.protection.outlook.com (10.152.250.55) by SG2APC01HT177.eop-APC01.prod.protection.outlook.com (10.152.251.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6; Tue, 2 Jan 2018 02:21:42 +0000 Received: from HK2PR0601MB1492.apcprd06.prod.outlook.com (10.152.250.54) by SG2APC01FT017.mail.protection.outlook.com (10.152.250.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.282.5 via Frontend Transport; Tue, 2 Jan 2018 02:21:42 +0000 Received: from HK2PR0601MB1492.apcprd06.prod.outlook.com ([fe80::4d94:b2d3:4556:8710]) by HK2PR0601MB1492.apcprd06.prod.outlook.com ([fe80::4d94:b2d3:4556:8710%14]) with mapi id 15.20.0366.007; Tue, 2 Jan 2018 02:21:42 +0000 From: li zhenqiang To: opsawg-chairs , opsawg Thread-Topic: WGLC request for draft-ietf-opsawg-ipfix-bgp-community-04.txt Thread-Index: AQHTg3BtcqeMjE2pCU6OuTqtbbN3Bg== Date: Tue, 2 Jan 2018 02:21:42 +0000 Message-ID: References: , , , Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:4F6EE9E2865E4BCCCDB95CE65CFD370CFC166881C4CD75B51FD164E08CDCBA5B; UpperCasedChecksum:849C342968273DE80237A8BD9D18B1126EEDA087002F7568B19EB3EA2F82BC0D; SizeAsReceived:7355; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [BCkC23v2Sj8nA5gb0hIttMuxOC/KXyqtygqc2/tnEms=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SG2APC01HT177; 6:c3ek/aMQ7AAmCQlMNwwlqZNEcpxaQxLWD26nIzCRw/KH+YUCemHxjmMy7Xr0Dn4A7Qi4d+OQIfAkBI3IifQdn429NSwws/pkmZeHtb7Q7KJSVv/fVj+52imnxeVwjCov77w0PqKStsWA140pzrNnDqiFaER7X/7BLQnlxdUC9yZNnzh7MLCfERwhVm6m67R2xSb/lPLw8prG9CW97oNuA60siP1l5dHSiG3TDOSc0KOv1AP1mMBGOpExzXgQXlMTrAU8QlcrdGuIkJm4hCKzEbqmeqVxPtAgplPD6kNYKGP2b1vVpTalVURzPFXhh3eUQ3twjjM9A3gpp5dXks5r3LsOOTSqoktK7zQyhfItL8w=; 5:ZXAlpJr8+PzxByU471Ksl77eg3Me7iIlcpOyDMPX0ZpPdQmVd+4FKCa6mTGq5rSW2llM83am3kcvfvSz294CpDUGB4wBS+zvbtf32DHIpkuv7Nc1qMFTOWxIp9IgCI1fjw2jhOT4CM19t5EtVUM6O+IY17CNwOihI3hSodHqF0o=; 24:YoIh42VXSUxFuaVzzDyRwsRDRrWI1+b3RoEahLX+n7JzQIYF4wLXk+n4ebMrQY6Sn0RRaygb8v3JiqG7wsOKEzxn58miQiWAcvWMUj2K7FQ=; 7:inu4/rRMQ5s7JEyMu+J01wHaDv6aaEBfhl2S7oF/jHB5wgifxFRgaQS4nJ3bHeeaxHbF2XstqekCNfV1FeJ8jMsleFbb5qk4z8vo2Grdo3FG2+bA3wWl2/a0McW1JraBUztXjcGqEv41BWuguBUN+gnwFxvJxYKoesYSqgMTBM/EaFRLxRMZFV9+HcfVwxORafK4kETEizKsP0ltOwNTgk5zsMawAEkTup3f5dhfwAoCdiWgNjvOAjXnTuxlAI2f x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:SG2APC01HT177; x-ms-traffictypediagnostic: SG2APC01HT177: x-ms-office365-filtering-correlation-id: c6b23c91-6af1-413a-7cb9-08d551878f06 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SG2APC01HT177; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SG2APC01HT177; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT177; H:HK2PR0601MB1492.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB149253011681B569FD5FC44AFC190HK2PR0601MB1492_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: c6b23c91-6af1-413a-7cb9-08d551878f06 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 02:21:42.6983 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT177 Archived-At: Subject: [OPSAWG] WGLC request for draft-ietf-opsawg-ipfix-bgp-community-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 02:21:50 -0000 --_000_HK2PR0601MB149253011681B569FD5FC44AFC190HK2PR0601MB1492_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gV0cgQ2hhaXJzIGFuZCBhbGwsDQoNCkFzIGRpc2N1c3NlZCBpbiB0aGUgbWFpbCBsaXN0 IGFuZCBTaW5nYXBvcmUgbWVldGluZywgSSB1cGRhdGVkIHRoZSBkcmFmdCByZXNvbHZpbmcgYWxs IHRoZSBjb21tZW50cy4gQWxtb3N0IG9uZSBtb250aCBwYXN0LCB3ZSByZWNlaXZlZCBubyBtb3Jl IGNvbW1lbnRzLiBTbyBJIHJlcXVlc3QgdGhlIFdHIHRvIGRvIHRoZSBsYXN0IGNhbGwuIFRoYW5r cyB5b3UgdmVyeSBtdWNoLg0KDQpCZXN0IFJlZ2FyZHMsDQpaaGVucWlhbmcgTGkNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpsaV96aGVucWlhbmdAaG90bWFpbC5jb20NCg0KRnJv bTogbGkgemhlbnFpYW5nPG1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20+DQpEYXRlOiAy MDE3LTEyLTA2IDE0OjUxDQpUbzogWmhvdXRpYW5yYW48bWFpbHRvOnpob3V0aWFucmFuQGh1YXdl aS5jb20+OyBvcHNhd2ctY2hhaXJzPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPjsgb3Bz YXdnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09QU0FXR10gV0dMQyBy ZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAzLnR4dA0K SGVsbG8gV0cgQ2hhaXJzIGFuZCBhbGwsDQoNCkkgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9u IHdpdGggYSBuZXcgc2VjdGlvbiAzIGNhbGxlZCBCR1AgQ29tbXVuaXR5IGJhc2VkIFRyYWZmaWMg Q29sbGVjdGlvbiwgd2hpY2ggaXMgYSBkZXRhaWxlZCB1c2UgY2FzZSB0byBzaG93IG9uZSBvZiB0 aGUgYXBwbGljYXRpb24gc2NlbmFyaW9zIGZvciB0aGUgaW50cm9kdWNlZCBJRXMuIEZvciB0aGUg ZW5jb2RpbmcgZXhhbXBsZSB3aGVuIHRoZSBJRXMgYXJlIHVzZWQgaW4gdGhlIElQRklYIHByb3Rv Y29sLCBwbGVhc2UgcmVmZXIgQXBwZW5kaXggQS4gVGhlIHNlY3Rpb24gMyBpbiB0aGUgbGF0ZXN0 IHZlcnNpb24gaXMgdXNlZCB0byBhZGRyZXNzIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24gMSBhbmQg My4NCg0KRm9yIHF1ZXN0aW9uIDIsIHdlIGRvbid0IHRoaW5rIGRlZmluaW5nIGEgY29tbW9uIGNv bnRhaW5lciBmb3IgYWxsIHRoZSBjb21tdW5pdGllcyAoc3RhbmRhcmQsIGV4dGVuZGVkLCBsYXJn ZSkgaGF2ZSBzaWduaWZpY2FudCBhZHZhbnRhZ2VzLiBBcyBzaG93biBpbiBBcHBlbmRpeCBBLCB3 ZSBoYXZlIHRvIHVzZSBkaWZmZXJlbnQgSUUgaW4gdGhlIHRlbXBsZXRlIHJlY29yZCB0byB0ZWxs IHRoZSBleHBvcnRlciB3aGljaCBraW5kIG9mIEJHUCBjb21tdW5pdHkgd2UgYXJlIGludGVyZXN0 ZWQgaW4sIGZvciBleGFtcGxlIHRoZSBsYXJnZSBjb21tdW5pdHkgY29ycmVzcG9uZGluZyB0byB0 aGUgc291cmNlIElQIG9mIGEgc3BlY2lmaWMgZmxvdyBhbmQgdGhlIHN0YW5kYXJkIGNvbW11bml0 eSBjb3JyZXNwb25kaW5nIHRvIHRoZSBkZXN0aW5hdGlvbiBJUCBvZiBhIHNwZWNpZmljIGZsb3cu ICBXaGF0IHdlIG1heSB1c2UgYSBjb21tb24gY29udGFpbmVyIGlzIHRoZSBlbGVtZW50IG9mIHRo ZSBiYXNpYyBsaXN0IGluIHRoZSBkYXRhIHNldC4gSW4gdGhpcyB3YXksIHRoZSBjb250YWluZXIg aGF2ZSB0byBiZSBiaWcgZW5vdWdoIHRvIGFjY29ybWFkYXRlIGF0IGxlYXN0IHRoZSBsYXJnZSBj b21tdW5pdHksIHdoaWNoIGlzIDEyIG9jdGV0cy4gV2hlbiB0aGlzIGNvbnRhaW5lciBpcyB1c2Vk IHRvIGV4cG9ydCB0aGUgc3RhbmRhcmQgb3IgZXh0ZW5kZWQgY29tbXVuaXR5LCB3ZSBoYXZlIHRv IHBhZCB0aGUgb3ZlcnNpemVkIGJ5dGVzLiBUaGlzIGtpbmQgb2YgZW5jb2RpbmcgaXMgZmVhc2li bGUgYnV0IGEgbGl0dGxlIGJpdCBpbmVmZmljaWVudC4gQXQgdGhlIHNhbWUgdGltZSwgY29uc2lk ZXJpbmcgdGhhdCB0aGUgc2F2aW5ncyBvbiBJRXMgYXJlIG5vdCBvYnZpb3VzLCB3ZSBkb24ndCBh Y2NlcHQgdGhpcyBzY2hlbWUuDQoNCllvdSBjYW4gYWNjZXNzIHRoZSBuZXcgdmVyc2lvbiBieSB0 aGUgZm9sbG93aW5nIGxpbmsuDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3Ig dGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA0DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkt MDQNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzYXdnLWlwZml4 LWJncC1jb21tdW5pdHktMDQNCg0KQW55IG90aGVyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBh cmUgd2VsY29tZWQuIFRoYW5rIHlvdSB2ZXJ5IG11Y2guDQoNCkJlc3QgUmVnYXJkcywNCnpoZW5x aWFuZyBMaQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxpX3poZW5xaWFuZ0Bo b3RtYWlsLmNvbQ0KDQpGcm9tOiBsaSB6aGVucWlhbmc8bWFpbHRvOmxpX3poZW5xaWFuZ0Bob3Rt YWlsLmNvbT4NCkRhdGU6IDIwMTctMTAtMzAgMTc6MDMNClRvOiBaaG91dGlhbnJhbjxtYWlsdG86 emhvdXRpYW5yYW5AaHVhd2VpLmNvbT47IG9wc2F3ZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsg b3BzYXdnLWNoYWlyczxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbT1BTQVdHXSBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1j b21tdW5pdHktMDMudHh0DQpIZWxsbyBUaWFucmFuIGFuZCB0aGUgY28tY2hhaXJzLA0KDQpUaGFu ayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldyBhbmQgc3VnZ2VzdGlvbnMuIEkgd2lsbCBh ZGRyZXNzIGFsbCB5b3VyIGNvbW1lbnRzIGluIHRoZSBuZXh0IHZlc2lvbi4gQnV0IEkgYW0gYWZy YWlkIEkgY2FuIG5vdCBjYXRjaCB0aGUgc3VibWl0dGlvbiBkZWFkbGluZSBmb3IgdGhlIGNvbWlu ZyBtZWV0aW5nLiBTbywgdGhlIHVwZGF0ZWQgdmVyc2lvbiB3aWxsIGJlIHVwbG9hZGVkIGFmdGVy IHRoZSBTaW5nYXBvcmUgbWVldGluZy4NCg0KQmVzdCBSZWdhcmRzLA0KWmhlbnFpYW5nIExpDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29t DQoNCkZyb206IFRpYW5yYW4gWmhvdTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4NCkRh dGU6IDIwMTctMTAtMzAgMTY6MTkNClRvOiBsaSB6aGVucWlhbmc8bWFpbHRvOmxpX3poZW5xaWFu Z0Bob3RtYWlsLmNvbT47IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsg b3BzYXdnLWNoYWlyczxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkt MDMudHh0DQpIaSBaaGVucWlhbmcgYW5kIHRoZSBjb2F1dGhvcnMsDQoNCkJhc2VkIG9uIHlvdXIg bGF0ZXN0IHBvc3QsIHRoZSBjby1jaGFpcnMgd291bGQgbGlrZSB0byBzdWdnZXN0IHRoZSBmb2xs b3dpbmcgaW1wcm92ZW1lbnRzIGJlZm9yZSBpc3N1aW5nIHRoZSBMQy4NCg0KMS4gSXTigJlzIHN0 aWxsIG5vdCBjbGVhciB3aHkgdGhlIHByb3Bvc2VkIElFcyBhcmUgbmVjZXNzYXJ5IGFuZCB1c2Vm dWwsIGFsdGhvdWdoIHlvdSBoYXZlIHNvbWUgc2ltcGxlIHdvcmRzIGluIHRoZSBpbnRyb2R1Y3Rp b24uIEl04oCZcyBiZXR0ZXIgdG8gYWRkIGEgc2VwYXJhdGUgdXNlIGNhc2Ugc2VjdGlvbiB0byBl eHBhbmQgdGhlIHR3byByZWZlcmVuY2VzIFtDb21tdW5pdHktVEVdIGFuZCBbUkZDNDM4NF0sIGFu ZCB0byBhZGRyZXNzIHlvdXIgb3BlcmF0aW9uIGV4cGVyaWVuY2Ugb24gdXNpbmcgdGhlbS4NClRo aXMgd2lsbCBhbHNvIGhlbHAgdG8gbW90aXZhdGUgdGhlIGF1ZGllbmNlIHRvIHVuZGVyc3RhbmQg YW5kIHVzZSB0aGlzIElFIGV4dGVuc2lvbi4NCg0KMi4gR2l2ZW4gdGhhdCBib3RoIHN0YW5kYXJk IGFuZCBsYXJnZSBjb21tdW5pdGllcyB3aWxsIHN0YXkgaW4gZGVwbG95bWVudCBhbmQgdGhleSBi b3RoIGFjY29tcGxpc2ggZXF1aXZhbGVudCBmdW5jdGlvbiwgYW5kIGxhcmdlIGNhbiBjYXJyeSBh bGwgdGhlIHZhbHVlIHNwYWNlcyBvZiBzdGFuZGFyZCBvbmVzLCBvbmUgb3B0aW9uIGlzIHRvIGRl ZmluZSBhIGNvbnRhaW5lciBmb3IgbGFyZ2Ugd2l0aCBhIHByZWRlZmluZWQgZmllbGQgZm9yIG1h cHBpbmcgaW4gYSBzdGFuZGFyZCBjb21tdW5pdHkgdmFsdWUuIFRoaXMgaXMgYSB0ZWNobmlxdWUg aXNzdWUgdGhhdCBuZWVkIHRvIGJlIGRpc2N1c3NlZC4gSWYgeW91IGluc2lzdCB5b3VyIHdheSwg cGxlYXNlIGFkZCBzb21lIHRleHRzIGluIHRoZSBkcmFmdCB0byBjbGFyaWZ5IHdoeSB0d28gd2Vy ZSBjaG9zZW4uICBQZXJoYXBzIHlvdSBoYXZlIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgdGhhdCBl eHBsYWlucyB3aHkgdGhlIG11bHRpcGxlIGNvbnRhaW5lcnMgaGVscC4NCg0KMy4gWW91IGhhdmUg YWRkZWQgYW4gb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhcyB3YXMgcmVxdWVz dGVkIGluIFByYWd1ZS4gIFBlcmhhcHMgYSBiaXQgbW9yZSB0ZXh0IG9uIHRoZSAid2h5IiBjb25j ZXJuaW5nIHRoZSBhcHByb2FjaCBpcyBhbHNvIHJlcXVpcmVkIHRvIGhlbHAgaW5mb3JtIHRob3Nl IHdobyBtaWdodCBkZXBsb3kgdGhpcy4NCg0KVGhhbmtzLA0KSWduYXMsIEpvZSwgVGlhbnJhbg0K DQoNCkZyb206IGxpIHpoZW5xaWFuZyBbbWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbV0N ClNlbnQ6IEZyaWRheSwgT2N0b2JlciAyMCwgMjAxNyAzOjU3IFBNDQpUbzogb3BzYXdnQGlldGYu b3JnOyBvcHNhd2ctY2hhaXJzDQpTdWJqZWN0OiBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYt b3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDMudHh0DQoNCkRlYXIgV0cgQ2hhaXJzIGFuZCBh bGwsDQoNCkkgdXBkYXRlZCB0aGUgZm9sbG93aW5nIGRyYWZ0IGFjY29yZGluZyB0byB0aGUgY29t bWVudHMgcmVjZWl2ZWQgZnJvbSB0aGUgbGlzdCBhbmQgdGhlIFByYWhhIG1lZXRpbmcuIFRoZSBw dXJwb3NlIHRvIGludHJvZHVjZSBuZXcgSUVzIGluIElQRklYIGlzIGV4cGxhaW5lZCBtb3JlIGNs ZWFybHkgaW4gdGhlIGludHJvZHVjYXRpb24gcGFydCBhbmQgZW1waGVzaXplZCBpbiB0aGUgYWJz dHJhY3QgcGFydC4gV2UgY2hhbmdlZCBvbmUgc2VjdGlvbiB0aXRsZSBmcm9tICBNZXNzYWdlIExl bmd0aCBDb25zaWRlcmF0aW9ucyB0byAgT3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnMsIGFuZCBl eHBsYWluZWQsIGF0IHByZXNlbnQgZm9yIHRoZSBmaWVsZCBuZXR3b3JrLCBvbmUgSVBGSVggbWVz c2FnZSBoYXMgZW5vdWdoIHNwYWNlIHRvIGZpdCBhbGwgdGhlIGNvbW11bml0eSBpbmZvcm1hdGlv biByZWxhdGVkIHRvIGEgc3BlY2lmaWMgdHJhZmZpYyBmbG93IC4NCg0KU2luY2Ugbm8gbW9yZSB0 ZWNobmljYWwgaXNzdWVzIHJlbWFpbiB0byBiZSBzb2x2ZWQsIGFzIHJlcXVlc3RlZCBpbiB0aGUg UHJhaGEgbWVldGluZywgd2UgdGhpbmsgdGhpcyBkb2MgaXMgcmVhZHkgdG8gZG8gV0dMQy4gVGhh bmsgeW91IHZlcnkgbXVjaC4NCg0KDQpOYW1lOiBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3At Y29tbXVuaXR5DQpSZXZpc2lvbjogMDMNClRpdGxlOiBFeHBvcnQgQkdQIGNvbW11bml0eSBpbmZv cm1hdGlvbiBpbiBJUCBGbG93IEluZm9ybWF0aW9uIEV4cG9ydCAoSVBGSVgpDQpEb2N1bWVudCBk YXRlOiAyMDE3LTEwLTE3DQpHcm91cDogb3BzYXdnDQpQYWdlczogMTcNClVSTDogaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1j b21tdW5pdHktMDMudHh0DQpTdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkvDQpIdG1saXplZDogaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5p dHktMDMNCkh0bWxpemVkOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDMNCkRpZmY6IGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVu aXR5LTAzDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCB1cGRhdGVzIFJGQzcwMTIgSVBGSVgg aW5mb3JtYXRpb24gbW9kZWwgYnkgaW50cm9kdWNpbmcNCiAgIHNldmVyYWwgaW5mb3JtYXRpb24g ZWxlbWVudHMgdG8gZW5hYmxlIElQRklYIHRvIGV4cG9ydCB0aGUgQkdQDQogICBjb21tdW5pdHkg aW5mb3JtYXRpb24sIGluY2x1ZGluZyBCR1Agc3RhbmRhcmQgY29tbXVuaXR5IGRlZmluZWQgaW4N CiAgIFJGQzE5OTcsIEJHUCBleHRlbmRlZCBjb21tdW5pdHkgZGVmaW5lZCBpbiBSRkM0MzYwLCBh bmQgQkdQIGxhcmdlDQogICBjb21tdW5pdHkgZGVmaW5lZCBpbiBSRkM4MDkyLiAgTmV0d29yayB0 cmFmZmljIGZsb3cgaW5mb3JtYXRpb24gY2FuDQogICB0aGVuIGJlIGFjY3VtdWxhdGVkIGFuZCBh bmFseXNlZCBhdCB0aGUgZ3JhbnVsYXJpdHkgc3BlY2lmaWVkIGJ5IHRoZQ0KICAgQkdQIGNvbW11 bml0aWVzLCB3aGljaCBpcyBzdWl0YWJsZSBmb3IgYW5kIG5lZWRlZCBieSBzb21lIHRyYWZmaWMN CiAgIG9wdGltaXphdGlvbiBhcHBsaWNhdGlvbnMgbG9jYXRlZCBpbiBJUEZJWCBjb2xsZWN0b3Is IFNETiBjb250cm9sbGVyDQogICBvciBQQ0UgKFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCkuDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpsaV96aGVucWlhbmdAaG90bWFpbC5j b208bWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbT4NCg== --_000_HK2PR0601MB149253011681B569FD5FC44AFC190HK2PR0601MB1492_ Content-Type: text/html; charset="utf-8" Content-ID: <32D18E24E3CD574B948B460EBF667F32@apcprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLWxlZnQ6IDAuNWVtOyB9cCB7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyB9ZGl2LkZveERpdjIwMTgwMTAyMDk0NzI4NTU1MjkzIHsgfWJvZHkgeyBmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kTsgY29sb3I6IHJnYigwLCAwLCAwKTsgbGlu ZS1oZWlnaHQ6IDEuNTsgfTwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCjxkaXY+PHNwYW4+PC9z cGFuPkhlbGxvIFdHIENoYWlycyBhbmQgYWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+QXMgZGlzY3Vzc2VkIGluIHRoZSBtYWlsIGxpc3QgYW5kIFNpbmdhcG9yZSBtZWV0aW5nLCBJ IHVwZGF0ZWQgdGhlIGRyYWZ0IHJlc29sdmluZyBhbGwgdGhlIGNvbW1lbnRzLiBBbG1vc3Qgb25l IG1vbnRoIHBhc3QsIHdlIHJlY2VpdmVkIG5vIG1vcmUgY29tbWVudHMuIFNvIEkgcmVxdWVzdCB0 aGUgV0cgdG8gZG8gdGhlIGxhc3QgY2FsbC4gVGhhbmtzIHlvdSB2ZXJ5IG11Y2guPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2PlpoZW5xaWFu ZyBMaTwvZGl2Pg0KPGhyIHN0eWxlPSJ3aWR0aDogMjEwcHg7IGhlaWdodDogMXB4OyIgY29sb3I9 IiNiNWM0ZGYiIHNpemU9IjEiIGFsaWduPSJsZWZ0Ij4NCjxkaXY+PHNwYW4+DQo8ZGl2IHN0eWxl PSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQiPg0K PGRpdj5saV96aGVucWlhbmdAaG90bWFpbC5jb208L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1Ub3A6IDBweDsgbWFyZ2luLUJvdHRvbTogMHB4 OyBtYXJnaW4tTGVmdDogMC41ZW0iPg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxkaXYgc3R5bGU9IlBBRERJTkctUklHSFQ6IDhweDsgUEFERElORy1MRUZU OiA4cHg7IEZPTlQtU0laRTogMTJweDtGT05ULUZBTUlMWTp0YWhvbWE7Q09MT1I6IzAwMDAwMDsg QkFDS0dST1VORDogI2VmZWZlZjsgUEFERElORy1CT1RUT006IDhweDsgUEFERElORy1UT1A6IDhw eCI+DQo8ZGl2PjxiPkZyb206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpsaV96aGVucWlhbmdA aG90bWFpbC5jb20iPmxpIHpoZW5xaWFuZzwvYT48L2Rpdj4NCjxkaXY+PGI+RGF0ZTo8L2I+Jm5i c3A7MjAxNy0xMi0wNiZuYnNwOzE0OjUxPC9kaXY+DQo8ZGl2PjxiPlRvOjwvYj4mbmJzcDs8YSBo cmVmPSJtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbSI+WmhvdXRpYW5yYW48L2E+OyA8YSBo cmVmPSJtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZyI+DQpvcHNhd2ctY2hhaXJzPC9hPjsg PGEgaHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3BzYXdnPC9hPjwvZGl2Pg0KPGRpdj48 Yj5TdWJqZWN0OjwvYj4mbmJzcDtSZTogW09QU0FXR10gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1p ZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAzLnR4dDwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJGb3hEaXYyMDE4MDEwMjA5NDcyODU1NTI5MyI+DQo8ZGl2 PjxzcGFuPjwvc3Bhbj5IZWxsbyBXRyBDaGFpcnMgYW5kIGFsbCw8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkkgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uIHdpdGggYSBuZXcgc2Vj dGlvbiAzIGNhbGxlZCZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgw LCAwLCAwLCAwKTsiPkJHUCZuYnNwO0NvbW11bml0eSZuYnNwO2Jhc2VkJm5ic3A7VHJhZmZpYyZu YnNwO0NvbGxlY3Rpb24sIHdoaWNoIGlzIGEgZGV0YWlsZWQgdXNlIGNhc2UgdG8gc2hvdyBvbmUg b2YgdGhlDQogYXBwbGljYXRpb24gc2NlbmFyaW9zIGZvciB0aGUgaW50cm9kdWNlZCBJRXMuIEZv ciB0aGUgZW5jb2RpbmcgZXhhbXBsZSB3aGVuIHRoZSBJRXMgYXJlIHVzZWQgaW4gdGhlIElQRklY IHByb3RvY29sLCBwbGVhc2UgcmVmZXIgQXBwZW5kaXggQS4gVGhlIHNlY3Rpb24gMyBpbiB0aGUg bGF0ZXN0IHZlcnNpb24gaXMgdXNlZCB0byBhZGRyZXNzIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24g MSBhbmQgMy48L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xv cjogcmdiYSgwLCAwLCAwLCAwKTsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTAuNXB0OyBsaW5lLWhlaWdodDog MS41OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDAsIDAsIDAsIDApOyI+Rm9yIHF1ZXN0aW9uIDIs IHdlIGRvbid0IHRoaW5rIGRlZmluaW5nIGEgY29tbW9uIGNvbnRhaW5lciBmb3IgYWxsIHRoZSBj b21tdW5pdGllcyAoc3RhbmRhcmQsIGV4dGVuZGVkLCBsYXJnZSkgaGF2ZSBzaWduaWZpY2FudCBh ZHZhbnRhZ2VzLiBBcyBzaG93bg0KIGluIEFwcGVuZGl4IEEsIHdlIGhhdmUgdG8gdXNlIGRpZmZl cmVudCBJRSBpbiB0aGUgdGVtcGxldGUgcmVjb3JkIHRvIHRlbGwgdGhlIGV4cG9ydGVyIHdoaWNo IGtpbmQgb2YgQkdQIGNvbW11bml0eSB3ZSBhcmUgaW50ZXJlc3RlZCBpbiwgZm9yIGV4YW1wbGUg dGhlIGxhcmdlIGNvbW11bml0eSBjb3JyZXNwb25kaW5nIHRvIHRoZSBzb3VyY2UgSVAgb2YgYSBz cGVjaWZpYyBmbG93IGFuZCB0aGUgc3RhbmRhcmQgY29tbXVuaXR5IGNvcnJlc3BvbmRpbmcNCiB0 byB0aGUgZGVzdGluYXRpb24gSVAgb2YgYSBzcGVjaWZpYyBmbG93LiAmbmJzcDtXaGF0IHdlIG1h eSB1c2UgYSBjb21tb24gY29udGFpbmVyIGlzIHRoZSBlbGVtZW50IG9mIHRoZSBiYXNpYyBsaXN0 IGluIHRoZSBkYXRhIHNldC4gSW4gdGhpcyB3YXksIHRoZSBjb250YWluZXIgaGF2ZSB0byBiZSBi aWcgZW5vdWdoIHRvIGFjY29ybWFkYXRlIGF0IGxlYXN0IHRoZSBsYXJnZSBjb21tdW5pdHksIHdo aWNoIGlzIDEyIG9jdGV0cy4gV2hlbiB0aGlzIGNvbnRhaW5lcg0KIGlzIHVzZWQgdG8gZXhwb3J0 IHRoZSBzdGFuZGFyZCBvciBleHRlbmRlZCBjb21tdW5pdHksIHdlIGhhdmUgdG8gcGFkIHRoZSBv dmVyc2l6ZWQgYnl0ZXMuIFRoaXMga2luZCBvZiBlbmNvZGluZyBpcyBmZWFzaWJsZSBidXQgYSBs aXR0bGUgYml0IGluZWZmaWNpZW50LiBBdCB0aGUgc2FtZSB0aW1lLCBjPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwLjVwdDsgbGluZS1oZWlnaHQ6IDEuNTsgYmFja2dyb3VuZC1jb2xv cjogd2luZG93OyI+b25zaWRlcmluZw0KIHRoYXQgdGhlIHNhdmluZ3Mgb24gSUVzIGFyZSBub3Qg b2J2aW91cywgdzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGxpbmUtaGVp Z2h0OiAxLjU7IGJhY2tncm91bmQtY29sb3I6IHdpbmRvdzsiPmUgZG9uJ3QgYWNjZXB0IHRoaXMg c2NoZW1lLjwvc3Bhbj48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllvdSBjYW4gYWNj ZXNzIHRoZSBuZXcgdmVyc2lvbiBieSB0aGUgZm9sbG93aW5nIGxpbmsuPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kSwgVGFob21hOyBsaW5lLWhlaWdo dDogbm9ybWFsOyI+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJh ZnQgaXM6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog5b6u6L2v6ZuF6buRLCBUYWhv bWE7IGxpbmUtaGVpZ2h0OiBub3JtYWw7Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LyIgc3R5bGU9 InRleHQtZGVjb3JhdGlvbjogbm9uZSAhaW1wb3J0YW50OyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS88L2E+PC9k aXY+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5EsIFRhaG9tYTsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kSwg VGFob21hOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0OjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOW+rui9 r+mbhem7kSwgVGFob21hOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkt MDQiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmUgIWltcG9ydGFudDsiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA0 PC9hPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kSwgVGFob21h OyBsaW5lLWhlaWdodDogbm9ybWFsOyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA0IiBz dHlsZT0idGV4dC1kZWNvcmF0aW9uOiBub25lICFpbXBvcnRhbnQ7Ij5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5p dHktMDQ8L2E+PC9kaXY+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5EsIFRh aG9tYTsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IOW+ rui9r+mbhem7kSwgVGFob21hOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+QSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0OjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IOW+rui9r+mbhem7kSwgVGFob21hOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzYXdn LWlwZml4LWJncC1jb21tdW5pdHktMDQiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmUgIWlt cG9ydGFudDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9w c2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA0PC9hPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTog5b6u6L2v6ZuF6buRLCBUYWhvbWE7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 Ij48YnI+DQo8L2Rpdj4NCjxkaXY+QW55IG90aGVyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBh cmUgd2VsY29tZWQuIFRoYW5rIHlvdSB2ZXJ5IG11Y2guPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2PnpoZW5xaWFuZyBMaTwvZGl2Pg0KPGhy IHN0eWxlPSJ3aWR0aDogMjEwcHg7IGhlaWdodDogMXB4OyIgY29sb3I9IiNiNWM0ZGYiIHNpemU9 IjEiIGFsaWduPSJsZWZ0Ij4NCjxkaXY+PHNwYW4+DQo8ZGl2IHN0eWxlPSJNQVJHSU46IDEwcHg7 IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQiPg0KPGRpdj5saV96aGVucWlh bmdAaG90bWFpbC5jb208L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi1Ub3A6IDBweDsgbWFyZ2luLUJvdHRvbTogMHB4OyBtYXJnaW4tTGVmdDog MC41ZW0iPg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxk aXYgc3R5bGU9IlBBRERJTkctUklHSFQ6IDhweDsgUEFERElORy1MRUZUOiA4cHg7IEZPTlQtU0la RTogMTJweDtGT05ULUZBTUlMWTp0YWhvbWE7Q09MT1I6IzAwMDAwMDsgQkFDS0dST1VORDogI2Vm ZWZlZjsgUEFERElORy1CT1RUT006IDhweDsgUEFERElORy1UT1A6IDhweCI+DQo8ZGl2PjxiPkZy b206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20iPmxp IHpoZW5xaWFuZzwvYT48L2Rpdj4NCjxkaXY+PGI+RGF0ZTo8L2I+Jm5ic3A7MjAxNy0xMC0zMCZu YnNwOzE3OjAzPC9kaXY+DQo8ZGl2PjxiPlRvOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86emhv dXRpYW5yYW5AaHVhd2VpLmNvbSI+WmhvdXRpYW5yYW48L2E+OyA8YSBocmVmPSJtYWlsdG86b3Bz YXdnQGlldGYub3JnIj4NCm9wc2F3ZzwvYT47IDxhIGhyZWY9Im1haWx0bzpvcHNhd2ctY2hhaXJz QGlldGYub3JnIj5vcHNhd2ctY2hhaXJzPC9hPjwvZGl2Pg0KPGRpdj48Yj5TdWJqZWN0OjwvYj4m bmJzcDtSZTogW09QU0FXR10gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZp eC1iZ3AtY29tbXVuaXR5LTAzLnR4dDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IGNsYXNzPSJGb3hEaXYyMDE3MTIwNjE0MTY0MDE5NTA4OSI+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiID48L286c2hh cGVkZWZhdWx0cz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+Cjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi ID48L286aWRtYXA+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXY+PHNw YW4+PC9zcGFuPkhlbGxvIFRpYW5yYW4gYW5kIHRoZSBjby1jaGFpcnMsPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldyBhbmQg c3VnZ2VzdGlvbnMuIEkgd2lsbCBhZGRyZXNzIGFsbCB5b3VyIGNvbW1lbnRzIGluIHRoZSBuZXh0 IHZlc2lvbi4gQnV0IEkgYW0gYWZyYWlkIEkgY2FuIG5vdCBjYXRjaCB0aGUgc3VibWl0dGlvbiBk ZWFkbGluZSBmb3IgdGhlIGNvbWluZyBtZWV0aW5nLiBTbywgdGhlIHVwZGF0ZWQgdmVyc2lvbiB3 aWxsIGJlIHVwbG9hZGVkIGFmdGVyIHRoZSBTaW5nYXBvcmUgbWVldGluZy48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkJlc3QgUmVnYXJkcyw8L2Rpdj4NCjxkaXY+WmhlbnFpYW5nIExp PC9kaXY+DQo8aHIgc3R5bGU9IndpZHRoOiAyMTBweDsgaGVpZ2h0OiAxcHg7IiBjb2xvcj0iI2I1 YzRkZiIgc2l6ZT0iMSIgYWxpZ249ImxlZnQiPg0KPGRpdj48c3Bhbj4NCjxkaXYgc3R5bGU9Ik1B UkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IHZlcmRhbmE7IEZPTlQtU0laRTogMTBwdCI+DQo8ZGl2 PmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbTwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1h cmdpbi1sZWZ0OiAwLjVlbTsiPg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxkaXYgc3R5bGU9IlBBRERJTkctUklHSFQ6IDhweDsgUEFERElORy1MRUZUOiA4 cHg7IEZPTlQtU0laRTogMTJweDtGT05ULUZBTUlMWTp0YWhvbWE7Q09MT1I6IzAwMDAwMDsgQkFD S0dST1VORDogI2VmZWZlZjsgUEFERElORy1CT1RUT006IDhweDsgUEFERElORy1UT1A6IDhweCI+ DQo8ZGl2PjxiPkZyb206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzp6aG91dGlhbnJhbkBodWF3 ZWkuY29tIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+ VGlhbnJhbiBaaG91PC9hPjwvZGl2Pg0KPGRpdj48Yj5EYXRlOjwvYj4mbmJzcDsyMDE3LTEwLTMw Jm5ic3A7MTY6MTk8L2Rpdj4NCjxkaXY+PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzps aV96aGVucWlhbmdAaG90bWFpbC5jb20iIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0 aW9uOiB1bmRlcmxpbmU7Ij5saSB6aGVucWlhbmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm9wc2F3 Z0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsiPg0Kb3BzYXdnQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm9wc2F3Zy1jaGFpcnNA aWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 Ij4NCm9wc2F3Zy1jaGFpcnM8L2E+PC9kaXY+DQo8ZGl2PjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JF OiBXR0xDIHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkt MDMudHh0PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IkZveERpdjIw MTcxMDMwMTYzNTM4NzU4MDYzIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgPjwvbzpzaGFwZWRlZmF1bHRzPgo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPgo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgPjwvbzppZG1hcD4KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x IiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBaaGVucWlhbmcgYW5k IHRoZSBjb2F1dGhvcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog U2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MHB4IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmFzZWQgb24geW91ciBsYXRlc3QgcG9zdCwg dGhlIGNvLWNoYWlycyB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBpbXByb3Zl bWVudHMgYmVmb3JlIGlzc3VpbmcgdGhlIExDLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1 bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjEuIEl04oCZcyBzdGls bCBub3QgY2xlYXIgd2h5IHRoZSBwcm9wb3NlZCBJRXMgYXJlIG5lY2Vzc2FyeSBhbmQgdXNlZnVs LCBhbHRob3VnaCB5b3UgaGF2ZSBzb21lIHNpbXBsZSB3b3JkcyBpbiB0aGUgaW50cm9kdWN0aW9u LiBJdOKAmXMgYmV0dGVyIHRvIGFkZCBhIHNlcGFyYXRlIHVzZSBjYXNlIHNlY3Rpb24NCiB0byBl eHBhbmQgdGhlIHR3byByZWZlcmVuY2VzIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+W0NvbW11bml0eS1URV0gYW5kIFtSRkM0Mzg0XSwgYW5kIHRvIGFkZHJlc3Mg eW91ciBvcGVyYXRpb24gZXhwZXJpZW5jZSBvbiB1c2luZyB0aGVtLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoaXMgd2lsbCBhbHNvIGhlbHAgdG8gbW90aXZhdGUgdGhlIGF1ZGll bmNlIHRvIHVuZGVyc3RhbmQgYW5kIHVzZSB0aGlzIElFIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4yLiBHaXZlbiB0aGF0IGJvdGggc3RhbmRhcmQgYW5kIGxhcmdlIGNvbW11bml0aWVzIHdpbGwg c3RheSBpbiBkZXBsb3ltZW50IGFuZCB0aGV5IGJvdGggYWNjb21wbGlzaCBlcXVpdmFsZW50IGZ1 bmN0aW9uLCBhbmQgbGFyZ2UgY2FuIGNhcnJ5IGFsbCB0aGUgdmFsdWUgc3BhY2VzIG9mIHN0YW5k YXJkDQogb25lcywgb25lIG9wdGlvbiBpcyB0byBkZWZpbmUgYSBjb250YWluZXIgZm9yIGxhcmdl IHdpdGggYSBwcmVkZWZpbmVkIGZpZWxkIGZvciBtYXBwaW5nIGluIGEgc3RhbmRhcmQgY29tbXVu aXR5IHZhbHVlLiBUaGlzIGlzIGEgdGVjaG5pcXVlIGlzc3VlIHRoYXQgbmVlZCB0byBiZSBkaXNj dXNzZWQuIElmIHlvdSBpbnNpc3QgeW91ciB3YXksIHBsZWFzZSBhZGQgc29tZSB0ZXh0cyBpbiB0 aGUgZHJhZnQgdG8gY2xhcmlmeSB3aHkgdHdvIHdlcmUgY2hvc2VuLiZuYnNwOw0KIFBlcmhhcHMg eW91IGhhdmUgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB0aGF0IGV4cGxhaW5zIHdoeSB0aGUgbXVs dGlwbGUgY29udGFpbmVycyBoZWxwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjMuIFlvdSBoYXZlIGFkZGVkIGFu IG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gYXMgd2FzIHJlcXVlc3RlZCBpbiBQ cmFndWUuJm5ic3A7IFBlcmhhcHMgYSBiaXQgbW9yZSB0ZXh0IG9uIHRoZSAmcXVvdDt3aHkmcXVv dDsgY29uY2VybmluZyB0aGUgYXBwcm9hY2ggaXMgYWxzbyByZXF1aXJlZCB0byBoZWxwIGluZm9y bQ0KIHRob3NlIHdobyBtaWdodCBkZXBsb3kgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBT aW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MHB4IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWduYXMsIEpvZSwgVGlhbnJhbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAw Y207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog U2ltU3VuOyI+DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBs aSB6aGVucWlhbmcgW21haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDIwLCAyMDE3IDM6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+ IG9wc2F3Z0BpZXRmLm9yZzsgb3BzYXdnLWNoYWlyczxicj4NCjxiPlN1YmplY3Q6PC9iPiBXR0xD IHJlcXVlc3QgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDMudHh0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGVhciBXRyBDaGFpcnMg YW5kIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgdXBkYXRlZCB0aGUgZm9s bG93aW5nIGRyYWZ0IGFjY29yZGluZyB0byB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJvbSB0aGUg bGlzdCBhbmQgdGhlIFByYWhhIG1lZXRpbmcuIFRoZSBwdXJwb3NlIHRvIGludHJvZHVjZSBuZXcg SUVzIGluIElQRklYIGlzIGV4cGxhaW5lZCBtb3JlIGNsZWFybHkNCiBpbiB0aGUgaW50cm9kdWNh dGlvbiBwYXJ0IGFuZCBlbXBoZXNpemVkIGluIHRoZSBhYnN0cmFjdCBwYXJ0LiBXZSBjaGFuZ2Vk IG9uZSBzZWN0aW9uIHRpdGxlIGZyb20gJm5ic3A7TWVzc2FnZSZuYnNwO0xlbmd0aCZuYnNwO0Nv bnNpZGVyYXRpb25zPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwO3RvICZuYnNw Ozwvc3Bhbj5PcGVyYXRpb25hbCZuYnNwO0NvbnNpZGVyYXRpb25zLCBhbmQgZXhwbGFpbmVkLCBh dCBwcmVzZW50IGZvciB0aGUgZmllbGQgbmV0d29yaywgb25lIElQRklYDQogbWVzc2FnZSBoYXMg ZW5vdWdoIHNwYWNlIHRvIGZpdCBhbGwgdGhlIGNvbW11bml0eSBpbmZvcm1hdGlvbiByZWxhdGVk IHRvIGEgc3BlY2lmaWMgdHJhZmZpYyBmbG93IC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlNpbmNlIG5vIG1vcmUgdGVjaG5pY2FsIGlzc3VlcyByZW1haW4gdG8gYmUgc29sdmVkLCBh cyByZXF1ZXN0ZWQgaW4gdGhlIFByYWhhIG1lZXRpbmcsIHdlIHRoaW5rIHRoaXMgZG9jIGlzIHJl YWR5IHRvIGRvIFdHTEMuIFRoYW5rIHlvdSB2ZXJ5IG11Y2guPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4 IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNp bVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5hbWU6IGRyYWZ0LWlldGYtb3Bz YXdnLWlwZml4LWJncC1jb21tdW5pdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmV2aXNpb246IDAzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlRpdGxlOiBFeHBvcnQgQkdQIGNvbW11bml0eSBpbmZvcm1hdGlvbiBpbiBJUCBGbG93IElu Zm9ybWF0aW9uIEV4cG9ydCAoSVBGSVgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRvY3VtZW50IGRhdGU6IDIwMTct MTAtMTc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+R3JvdXA6IG9wc2F3ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QYWdlczogMTc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1T dW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+VVJMOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAzLnR4dCIgc3R5 bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29t bXVuaXR5LTAzLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U3RhdHVzOiZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1j b21tdW5pdHkvIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctaXBm aXgtYmdwLWNvbW11bml0eS88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkh0bWxpemVkOiZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3At Y29tbXVuaXR5LTAzIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4 LWJncC1jb21tdW5pdHktMDM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkh0bWxpemVkOiZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ct aXBmaXgtYmdwLWNvbW11bml0eS0wMyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh ZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMzwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RGlm ZjombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAzPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QWJzdHJhY3Q6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBj bTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBUaGlzIGRyYWZ0IHVwZGF0ZXMgUkZDNzAxMiBJUEZJWCBpbmZvcm1hdGlvbiBtb2RlbCBieSBp bnRyb2R1Y2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2V2ZXJhbCBpbmZvcm1hdGlvbiBl bGVtZW50cyB0byBlbmFibGUgSVBGSVggdG8gZXhwb3J0IHRoZSBCR1A8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IGNvbW11bml0eSBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIEJHUCBzdGFuZGFyZCBj b21tdW5pdHkgZGVmaW5lZCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgUkZDMTk5NywgQkdQ IGV4dGVuZGVkIGNvbW11bml0eSBkZWZpbmVkIGluIFJGQzQzNjAsIGFuZCBCR1AgbGFyZ2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1T dW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IGNvbW11bml0eSBkZWZpbmVkIGluIFJGQzgwOTIuJm5ic3A7 IE5ldHdvcmsgdHJhZmZpYyBmbG93IGluZm9ybWF0aW9uIGNhbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBw eCAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgdGhlbiBiZSBhY2N1bXVsYXRlZCBhbmQgYW5hbHlzZWQgYXQgdGhlIGdyYW51bGFyaXR5 IHNwZWNpZmllZCBieSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGNtOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEJHUCBjb21tdW5pdGll cywgd2hpY2ggaXMgc3VpdGFibGUgZm9yIGFuZCBuZWVkZWQgYnkgc29tZSB0cmFmZmljPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbjogMHB4IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3Vu OyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBvcHRpbWl6YXRpb24gYXBwbGljYXRpb25zIGxvY2F0ZWQgaW4g SVBGSVggY29sbGVjdG9yLCBTRE4gY29udHJvbGxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg b3IgUENFIChQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bjogMHB4IDBjbTsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMSIgd2lkdGg9IjIxMCIgc3R5bGU9Indp ZHRoOjEyNi4wcHQiIG5vc2hhZGU9IiIgYWxpZ249ImxlZnQiPg0KPC9zcGFuPjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjYuMHB0O21hcmdpbi10b3A6Ni4wcHQ7bWFyZ2lu LXJpZ2h0OjYuMHB0O21hcmdpbi1ib3R0b206Ni4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwY207IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbSIgc3R5 bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPmxpX3poZW5xaWFu Z0Bob3RtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HK2PR0601MB149253011681B569FD5FC44AFC190HK2PR0601MB1492_-- From nobody Tue Jan 2 11:16:50 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D92124207; Tue, 2 Jan 2018 11:16:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 cPU687fooxYF; Tue, 2 Jan 2018 11:16:48 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 1AE7B1200C1; Tue, 2 Jan 2018 11:16:48 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w02JEGiu014704; Tue, 2 Jan 2018 11:16:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=cX6/R2wKRF9lvP1825tPHXt09Ne9XU85NvrAz7fGWNA=; b=0R1HryRzgdohhMwn1/YIG0cTOvjSKXQXcWnLuLIAroC5XYE812WWjTXZXoEFvk9e1jbC OBnqudtir1FJOUlemaqpRu+NGSpIRd+Mr7JFo/AWg8nEGy/qsBLvzh7EhcH+ha4Q8UVu FA4on8JB3vnScijEwdT7nEmsE4GRQ6UtKASVRKDxIlJtD/OlPowTxQSvvR92L/jWgi// xT5u9YtmHyxtV1xt3uclkyQI7zK7xW5pYWpR7O1HRwlmHxNS9N4/hAsnstRafzRFs/Lj sjJ2UAvmq+agq2QnS2b1FHOks15jipXUTBEBdlLQ9BVK9rNd1fqmvKb90X7gxqtx6POe 5A== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0182.outbound.protection.outlook.com [216.32.181.182]) by mx0b-00273201.pphosted.com with ESMTP id 2f8fkkg20s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 Jan 2018 11:16:45 -0800 Received: from SN1PR0501MB2046.namprd05.prod.outlook.com (10.163.227.19) by SN1PR0501MB1693.namprd05.prod.outlook.com (10.163.130.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.4; Tue, 2 Jan 2018 19:16:43 +0000 Received: from SN1PR0501MB2046.namprd05.prod.outlook.com ([10.163.227.19]) by SN1PR0501MB2046.namprd05.prod.outlook.com ([10.163.227.19]) with mapi id 15.20.0386.005; Tue, 2 Jan 2018 19:16:43 +0000 From: Suresh Kumar Vinapamula Venkata To: Joe Clarke , "opsawg@ietf.org" , "draft-ietf-opsawg-nat-yang@ietf.org" Thread-Topic: IPR CALL: Please disclose any IPR related to draft-ietf-opsawg-nat-yang Thread-Index: AQHTezfCdN1syWtMXEuMG6H8Zw9K8aNgf+aA Date: Tue, 2 Jan 2018 19:16:42 +0000 Message-ID: References: <32abe856-ef86-8343-3814-8ebb29becdf6@cisco.com> In-Reply-To: <32abe856-ef86-8343-3814-8ebb29becdf6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.17.0.160611 x-originating-ip: [66.129.239.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1693; 6:3U5+0Fg96MlOyiooz1RUW/I1lDobYt6ry02XfHi5AOi48Kfswhr5f9LW9jxbOoiPwIAWtTjNDst2bNEUfZqJy+uwx1E3xtwtpAoLydQpoMiE21gfBqRf+H8VZ4y4ENSvCsKVwX+edafXDxOvRKDz7ZGDmf4KaS8lmsZzuSdw5BqmiyCzLynDEza6+oilCU2OEnNMFYe/NMHjPAp88SRgvX9rvbQcN7LpirIpw8mtocW7IKJFYsx19mwgLxea62gu7yVRGDTxgll4hjGXzf8IFnJ2Tmz/YvDneiyneqx/sw35/nJO+vm2wbqSKI+a9Wd6qAwDiu+/xYQ2DrMwie/2AZ16sysrpj06S4lMwZlUUvXoZIjJuHp0Xm7l0WD81SpD; 5:NUP6Oq8T6q3xGYYgnuMKhWTGeiqtsL7iROOBqgMyPspSOX66NINF7hO6074TDJMStJ3VeTPDsiMRnCsvSgxjaEP5V9vf6NvnT9pA9VIM45PJyg1rqMMHRYnZgiD4roYdbapLo2++FIfWO2zkg7HKZFjIsRz2mP9/6RiHzZGFNTM=; 24:DEXIhOhuH9l1uQf6PmsMdc2ZreLeynrg3A5CItljyP0UpDXidu17qqAV6LoI49OHSujrlEQo1v0S/B0jHFJOWluYK+RLsdMh+nxIdxcPgqo=; 7:9TCaL6UGiTnP1U554g/J1nk1rUCzzZTADBwFmJx2tOWdQpZHIio5wdZLyiTpHEAOK+x2YrgvU/5gguz9dGj9uvSmHWnhSspW11kIEv0BMZI7HRic36eSPUrwRayy+BhFAo1k/5IqN0zpOzznowEF47oRQuGcUP2k1b+sQ3F1Ey++ZjCj7QytndjG3BSeeJJGqsQb7mFtaqdI4VMmkOw5TlrWFduo2zV0ghGCfkKY56QpcO6EGtS/vB2NvEU5q4xL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 516b2669-9be4-4dce-17d8-08d552155bcf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(5600026)(4604075)(3008032)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7153060); SRVR:SN1PR0501MB1693; x-ms-traffictypediagnostic: SN1PR0501MB1693: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231023)(944501075)(93006095)(93001095)(6055026)(6041268)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:SN1PR0501MB1693; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN1PR0501MB1693; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39380400002)(39860400002)(396003)(24454002)(199004)(189003)(6436002)(97736004)(8936002)(81166006)(66066001)(8676002)(478600001)(53546011)(81156014)(14454004)(6506007)(7736002)(33656002)(102836004)(305945005)(99286004)(76176011)(6512007)(2501003)(36756003)(53936002)(6486002)(2906002)(5660300001)(558084003)(77096006)(25786009)(2900100001)(229853002)(86362001)(6246003)(83716003)(2950100002)(83506002)(316002)(3846002)(6116002)(68736007)(2201001)(105586002)(3280700002)(106356001)(110136005)(230783001)(3660700001)(82746002)(58126008); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1693; H:SN1PR0501MB2046.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: WeDzex69GYvKqH8lz9x84GfFeMFuQRHQ9iQMy4GGpugwcXXXft7TgY6qHqCEZhlEBJwYRv/J9J9xT7DWytONSg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 516b2669-9be4-4dce-17d8-08d552155bcf X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 19:16:43.0570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1693 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-02_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=902 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801020272 Archived-At: Subject: Re: [OPSAWG] IPR CALL: Please disclose any IPR related to draft-ietf-opsawg-nat-yang X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 19:16:50 -0000 SSBoYXZlIG5vIElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQoNCi1TdXJlc2gNCg0KDQoNCg0K T24gMTIvMjIvMTcsIDc6MTUgQU0sICJKb2UgQ2xhcmtlIiA8amNsYXJrZUBjaXNjby5jb20+IHdy b3RlOg0KDQo+T24gYmVoYWxmIG9mIHRoZSBjaGFpcnMsIEknZCBsaWtlIHRvIGRvIGFuIElQUiBj YWxsIGZvciB0aGlzIGRyYWZ0IGFzIGl0DQo+aXMgaW4gV0cgTEMuICBJZiB0aGVyZSBpcyBhbnkg SVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdCwgcGxlYXNlIGRpc2Nsb3NlDQo+aXQgaGVyZSBhcyB3 ZWxsIGFzIHdpdGhpbiBEYXRhIFRyYWNrZXIuDQo+DQo+Sm9lDQo= From nobody Thu Jan 4 10:14:35 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7EBC3124205; Thu, 4 Jan 2018 10:14:22 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E11E1243F6; Thu, 4 Jan 2018 10:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 i5o0H23zTUiL; Thu, 4 Jan 2018 10:14:20 -0800 (PST) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (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 256E8124205; Thu, 4 Jan 2018 10:14:20 -0800 (PST) Received: by mail-pl0-x231.google.com with SMTP id b96so1479955pli.2; Thu, 04 Jan 2018 10:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5i8V+yzFvbFblVZ2Lfw0/GNeqwkJm5HtlcWhkzWhveQ=; b=Pf0+1RAN1jHePEEaaApeWZHa98F+jHZWPKHDGzh3YMnvSMqKALMKN0CMyqq2VlQacQ SrN/mzWO1sxDW+o8egI84pEK1GRCxUO41G2MZR1sGsOFj1uMHdjTysSWhtOaaLKPstwq luaU4CFvsk2qTuW0+HYoFCwDGpqxiSf92qdWxZRjt8Dr5RegubLiuB9DpRWJviX/KAiT sBVdbvtcsFLxxUimQLoI6CaIB2cO48lWJ9iyBIF89rtbe9DvCIUqnqmh8m04A3yYRJw7 pGEGg0kUH+KH4gMAgCX5/wtM0q+VGMMD1CgEJjVp9fIooMMsH9evUIvBkykicX7foHE/ O/Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5i8V+yzFvbFblVZ2Lfw0/GNeqwkJm5HtlcWhkzWhveQ=; b=g4BpP8bVpTymxBYDUMZOFu8OXPBf8XJiiMlLDoMj3D+QcR7sThR14AQiUtuxmyxIF8 K87aoAutNoSedy2ua/OJeNE6DxtPdXL1zfPsJGXNZ7BH8Lv2Oa+O8Leua8E2VD8olHHu +LPvd8fuoZUdiL+7ly1Me2YCgUISXRJh0Ptis4RbbX0x5kNQrl8yHUivrxAZKGmljWVn cL4vC+aun8PIwoc2CEmeAqcSzmUmJ4Qq/8sxu1BiV7jh8ykv7JyDqu3cJ0M0AzTkLs+4 D1fBl3ZozgHwzBdZaok9S56SkKZ0kaXi+J8mW68FcX+EZtxPj170fhpD6Xpy6ToGnfY3 jf0Q== X-Gm-Message-State: AKGB3mI1PQ1+3aWJLiz/UxH5mTZV5cfvqMel6zxKhzxJ2F1513yamEh0 9g2VSD10tvebIvOImaeBMQGvTUDh6X18XBm9Xrg= X-Google-Smtp-Source: ACJfBovqq5brIAfPy6dsl4SscxXdrjZVCsQ45v7fmeGLV7UJQVfHT+t7qM4P4ZjAJPawiUC564aFdsZb/jYrwvjESHo= X-Received: by 10.84.133.77 with SMTP id 71mr375165plf.78.1515089659554; Thu, 04 Jan 2018 10:14:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Thu, 4 Jan 2018 10:13:39 -0800 (PST) In-Reply-To: References: <151302958109.21278.5686525939396201959@ietfa.amsl.com> From: Kathleen Moriarty Date: Thu, 4 Jan 2018 13:13:39 -0500 Message-ID: To: Ines Robles Cc: rtg-dir@ietf.org, draft-mm-wg-effect-encrypt.all@ietf.org, IETF Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180104181422.7EBC3124205@ietfa.amsl.com> Resent-Date: Thu, 4 Jan 2018 10:14:22 -0800 (PST) Archived-At: Subject: Re: [OPSAWG] Rtgdir last call review of draft-mm-wg-effect-encrypt-13 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:14:22 -0000 Hello Ines, Thanks again for your review. Edits have been made in our working version that we hope to post soon. On Mon, Dec 11, 2017 at 9:27 PM, Kathleen Moriarty wrote: > Ines, > > Thank you very much for your review! We're working on the comments > received and the nits you found will be addressed and are much > appreciated. > > Best regards, > Kathleen > > On Mon, Dec 11, 2017 at 4:59 PM, Ines Robles > wrote: >> Reviewer: Ines Robles >> Review result: Ready >> >> RtgDir review: draft-mm-wg-effect-encrypt-13.txt >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. The >> Routing Directorate seeks to review all routing or routing-related drafts as >> they pass through IETF last call and IESG review, and sometimes on special >> request. The purpose of the review is to provide assistance to the Routing ADs. >> For more information about the Routing Directorate, please see >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Although these comments are primarily for the use of the Routing ADs, it would >> be helpful if you could consider them along with any other IETF Last Call >> comments that you receive, and strive to resolve them through discussion or by >> updating the draft. >> >> Document: Effect of Pervasive Encryption on Operators - >> draft-mm-wg-effect-encrypt-13 Reviewer: Ines Robles Review Date: 12-11-2017 >> Intended status: Informational >> >> Summary: >> This document discusses current security and network management practices to >> help guide protocol development in support of manageable, secure networks. >> >> The draft is ready, few typos found. >> >> Comments: >> >> I believe the draft is technically good. This document is well written and >> clear to understand. >> >> Major Issues: >> >> No major issues found. >> >> Minor Issues: >> >> Section 2: >> >> "... Following the Snowden revelations,..." => It would be nice to add some >> references here Yes, the problem we have had so far is finding ones that aren't articles that may not be stable. A quick search pulls up new ones like the following: http://fortune.com/2016/04/25/snowden-encryption-james-clapper/ We'll have to try again to find an academic publication. >> >> Section 2.2.5: >> "DRM..."=> I would expand it to Digital Rights Management (DRM) Added, thank you! >> >> Section 6: >> >> inlcudes=> includes Fixed, thanks. >> >> Section 6.1: >> "information For example" => period missing? Ack, thanks! >> >> Section 6.2: >> "soltuions" -> solutions Fixed. >> >> Section 7.1 title: >> "Encypted" => Encrypted Fixed. Thanks for your review! >> >> > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Fri Jan 5 08:08:27 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4756312D77C; Fri, 5 Jan 2018 08:08:21 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1958512D834; Fri, 5 Jan 2018 08:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 a7LuB_Y9FE0H; Fri, 5 Jan 2018 08:08:17 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 4293412D77C; Fri, 5 Jan 2018 08:08:17 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id j4so2151460pgp.1; Fri, 05 Jan 2018 08:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/U7T4JbbqVcvSdg1kJ5L8y0c2od60QbFdwTDUFVsA+g=; b=LjCTXh0+dFxHEJCni1IgudimJXf4B8iHZXdAD+pYz9ZiopDn3x2x8I/oiAy40LJEVr RUyBxq/XGugEPq8779la7f9KP4RgvuNXzUHBvxxjh87QcYTRxwy8Wg/uy36Na8rh5gwb sTUvbfDRaYV+dKIDLtJHBwgZ1WfZ85b+5ht3IKTCS30ZI3zP5k5Me6W8VdF87eQIzwh2 /GkRzijb0ITOABChcKDPJWFmnJuptF22mzr1Pe0k459OIU2JYCAfryDjxcno+XRZ8oMj Qb/4yLsQ4WMiEUPK8yJ6KQIK/yQfscwDkYuJFWt/fBVAe/X1sN9k5pvDZf0A+4wU3FVH oqRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/U7T4JbbqVcvSdg1kJ5L8y0c2od60QbFdwTDUFVsA+g=; b=TIziccqfyrMGx9NrInBr7PdGIgwQGfrouvB5IGQ+ZvzPojYFGPVv8haXpUUvQH1JWf vh+hT1jqVFhFlTzl6mCsnNkb8MW7dfBJ4qXI8t7I7d0ayvcsqF2jkv9EKIZN/3rGavEu l9vdQmYH7/HwjT2QYB5ZAP0LBfxsRf5uId/l0Fho7oTuxSO2+Q05cRPBk2RgSeuyaj9T RIprR1E+l7eHxE6/rmBuHEeGVDTJBygPvaR86kYIQAkWzgu92JjLCoL6XTYq3oGbnUCH YEi/R7fur2yv9w/v6dkh9Kf94x1VYS+c5ItsrHAloMfN/dTZJXCGrWpNtLpiaJ/eK1MM IoOw== X-Gm-Message-State: AKGB3mLCYEXJ4oor+ds6SdJb+AtJ33TQX3En04IOmCQ6s8GqpGNKeh/a /pfH5RnyoRKD4ujO9oePkkp3vxFNZNCcOtPtdE/5Gg== X-Google-Smtp-Source: ACJfBotvyrrjedaCQ1JpC5Ykwd2Z5HAOP4v1z9XrEo0zLJFgN6XAe1twvUAw9WCRZ8OgJIzdiL4P3Woa7U3iulWMAbw= X-Received: by 10.98.141.141 with SMTP id p13mr3427639pfk.185.1515168496245; Fri, 05 Jan 2018 08:08:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Fri, 5 Jan 2018 08:07:35 -0800 (PST) In-Reply-To: References: <1ecac9b1-685b-8114-780a-a43425fb167d@huitema.net> From: Kathleen Moriarty Date: Fri, 5 Jan 2018 11:07:35 -0500 Message-ID: To: Christian Huitema Cc: IETF Discussion Mailing List , draft-mm-wg-effect-encrypt.all@ietf.org Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180105160821.4756312D77C@ietfa.amsl.com> Resent-Date: Fri, 5 Jan 2018 08:08:21 -0800 (PST) Archived-At: Subject: Re: [OPSAWG] Christian's review of draft-mm-wg-effect-encrypt-13 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 16:08:21 -0000 Christian, Thanks for your review. I'll respond inline to make sure we hit each point raised. The next version posted may not address your points, but the subsequent update should and I expect to have that out soon. On Fri, Dec 8, 2017 at 11:25 AM, Kathleen Moriarty wrote: > Thank you, Christain and others for your reviews. Our running draft > has addressed most comments received by mid-IETF week. We are working > on the others. We also received some comments from Kyle Rose and > Brandon Williams and are working to address those as well. > > We'll respond on list when we get to this set of comments. > > Best regards, > Kathleen > > On Mon, Dec 4, 2017 at 11:23 AM, Christian Huitema wrote: >> The high level summary is that draft-mm-wg-effect-encrypt version 13 is >> significantly improved from previous versions, but that the document >> would benefit a lot from additional work. I am not convinced that the >> sections on data center and enterprises belong in this specific document >> - they seem too high level to bring serious information to readers. >> Maybe stage a separate document to survey enterprise issues in some >> depth? I also feel that section 7 is way too speculative for a survey >> document. Section 7 was previously an appendix and maybe belongs back as an appendix, we need to figure that out. There is one particular case that a commenter saw the value of access (where he didn't in most places) that we may need to figure out how to keep that in the body as helpful text. Since the comments on data center and enterprises is opinion, I'll leave the text in for now. Thanks. >> >> I have been using the "side by side" feature of the IETF web site to >> compare the last draft that I reviewed (draft 10) and the current draft >> (draft 13). That tools shows the high volume of changes and >> reorganization that happens between these two versions. These changes >> generally make the document more balanced, and that's a welcomed >> development. There are however many places where I find that the >> documents lists controversial techniques without sufficient caveats. I >> will list some of them in the reminder of this review. Thanks. There have been a number of conversations on this, the main point I have been left with from those is the up front disclaimer is enough (IESG discussion). The discussion was that it would be redundant to make the point over and over agin, but preferred to work on a neutral tone. >> >> The introduction and the summary have been rewritten to clearly place >> the document in perspective. The previous versions could be read as a >> plea to stop encrypting traffic so previous management practices could >> continue. The new introduction makes clear that the IETF needs to >> prevent pervasive monitoring and improve the users' privacy, and that >> the goal of the document is to list areas in which current management >> practice need to evolve, or areas where substitute practices have to be >> found. I also appreciate the note that "some of (current management >> practices) have been considered controversial from a technical or >> business perspective or contradictory to previous IETF statements" -- >> and the implicit implication that the IETF will not attempt to restore >> all of these. >> >> 2. Network Service Provider Monitoring >> >> Section 2, "Network Service Provider Monitoring", has been reorganized >> to focus on management goals rather than simply provide a list of >> existing management tools. The description of the trouble shooting tasks >> in section 2.2 is useful. It makes the point that "application server >> operators using increased encryption should expect to be called upon >> more frequently to assist with debugging and troubleshooting", and that >> could lead to some interesting work in the IETF. >> >> There is paragraph at the end of section 2.1.2, Troubleshooting, that >> states that "the push for encryption by application providers has been >> motivated by the application of the described techniques." I think that >> paragraph is misplaced. As far as I can tell, the application providers >> are first concerned with "content management" techniques that modify >> the data stream. Any change of content has the potential to generate >> bugs that are difficult for the application provider to fix. The second >> concern is "ossification", when traffic characterization based on >> inferred features of the application traffic leads to adverse >> consequences when the application or transport protocols evolve. Neither >> of those is directly relevant to the "troubleshooting" task. Maybe move >> that paragraph higher in the document, e.g. in the introduction of >> section 2? If not that, then maybe move it to section 2.2.2, since one >> purpose of application encryption is indeed to defeat differential >> treatment in the network. I see your point, but am hesitant to move the text up since there is no other general description text in that section heading and this just covers applications. I want to comb through all of section 2 again after this sweep of comments, so we may do a bit more to improve this as well within a wider scope of organizational changes. >> >> I find the discussion of load balancers in section 2.2.1 somewhat >> confusing. It seems to cover three functions: load balancers in data >> centers, load balancers integrated with the network, and a network >> management function that tries to maintain proper connectivity to >> anycast addresses services in the presence of mobility. It might be >> useful to move the discussion of "classic" load balancers to section 3, >> and to discuss the problem of anycast continuity in a separate >> subsection. The anycast discussion seems to assume that the network >> operator alone has to deal with the supposed inadequacies of the >> application providers. It seems obvious that this problem would be much >> better solved by improved handling of mobility in content distribution >> networks, rather than by some complex machinery in the network itself. >> This might need to be stated. >> >> Section 2.2.2 on Deep Packet Inspection could state that it is very >> often possible to classify traffic based on analysis of the encrypted >> data. Audio stream, video streams and web traffic have very different >> signatures, even when encrypted. At the same time, it should also note >> that many application providers are actively working to defeat the >> "unilateral" traffic classification enabled by these techniques, >> complementing encryption with various techniques like multiplexing or >> padding. We could well observe an arms race between more powerful >> network based analysis and smarter application hiding. >> >> The discussion of performance enhancing proxies in section 2.2.3 states >> that "This optimization at network edges measurably improves real-time >> transmission over long delay Internet paths or networks with large >> capacity-variation (such as mobile/cellular networks)." This is not a >> consensual statement. Operators do indeed hope that deploying such >> proxies will improve performance, but independent measurements have >> shown that such proxies often in fact degrade performance. The studies >> that show improvement tend to be based on old network technologies, or >> on ancient TCP stacks. If the authors want to keep a statement like >> that, they should add references to actual measurements. At a minimum, >> the text should note that many application providers disagree with the >> assessment presented here, and that the development of encrypted >> transports such as QUIC is largely motivated by the desire to mitigate >> the negative effects of such "performance-dehancing" proxies. Do you have references to the studies you are referring to as that would be helpful. Thanks. >> >> The discussion of caching in section 2.2.5 correctly states the tension >> between network usage and application control. It could also state the >> inherent privacy risk associated with network based caches: they will >> provide a log of which users accessed what cached content. There is a >> reference to draft-thomson-http-bc-01, but as far as I know the authors >> have abandoned it, in part because they could not solve the related >> privacy issues. In any case, that draft expired several month ago, and >> the reference is probably not appropriate. Other comments led to that text being updated for the next version. The comments received took this as one of many examples, perhaps there is a better example that could be used instead of this draft? Alternate approaches such as blind caches are being explored to allow caching of encrypted content; however, they still require cooperation between the content owners or CDNs and blind caches and fall outside the scope of what is covered in this document. Content delegation solves a data visibility problem with the delegated cache, the impact remains for the use case where HTTPS encryption limits visibility to offload from congested links. >> >> In section 2.3.3, Application Layer Gateways, I was wishing it would say >> something about IPv6. But then of course most IPv6 deployments today >> involve a form of NAT64... If you have text to suggest, we'd be happy to incorporate it. >> >> Section 2.3.4 documents the "HTTP Header Insertion" technique. The >> relation between that technique and "Network Service Provider >> Monitoring" is unclear -- header insertion is certainly not a network >> monitoring tool. It is also a highly controversial tool, as documented >> for example in >> https://www.theverge.com/2016/3/7/11173010/verizon-supercookie-fine-1-3-million-fcc. >> I wonder whether it is appropriate to describe this at all in a document >> dedicated to network management, and my simple suggestion would be to >> just remove that section altogether. Failing that, the text needs to be >> modified to note the controversial nature of the process, and its impact >> on privacy. The authors could also note that the function could be >> trivially implemented in the client's browsers if it was really needed >> and approved by the users. There is no technical need to have anything >> like that "in the network". I see your point, but operators wanted this text in, so how about a modification to the last sentence to try to balance it out more? As I read the text, it describes invasive uses, so I thought that it was clearly something the was not without controversy. When HTTP connections are encrypted to protect users privacy, mobile network service providers cannot insert headers to accomplish the, sometimes considered controversial, functions above. >> >> 3. Encryption in Hosting SP Environments >> >> After examining network monitoring in section 2, the draft continues >> with an analysis of "Hosting SP Environments" in section 3, and section >> 4 describes "Encryption for Enterprises". I assume that the initials SP >> stand for "Service Provider" -- spelling it out would not hurt. I really >> wonder whether these sections belong in the document at all, rather than >> being published in separate documents. "Hosting Service Provider >> Environments" appears to be a subset of the general "Data Center" >> problem. It is true that some network providers also provide data center >> services for their customers, but these network providers represent only >> a small fraction of the service hosting industry. Similarly, some >> network providers provide services to enterprises, but there is a wide >> variety of enterprises. It is hard to believe that the authors of an >> individual draft have authority to speak at the same time about network >> services, data centers, and enterprises. In my opinion, it would be >> simpler to just excise section 3 and 4 from this draft, and use the >> content as input for specific drafts describing issues in data centers >> and enterprises. >> I'd prefer to keep these sections separate and think others feel the same way. Hosted data centers can occur in several layers as well. I work for a very large company that provides hosted infrastructure as a service, where others offer hybrid cloud options and other outsourcing options (application service providers, etc.) on top of this layer. It seems you may be thinking of this as a higher level of data center offerings than what is deployed in industry. I'd prefer not to get into listing them out as we would certainly miss some and it could be a confusing list that doesn't help the point of the draft. 4 may not be just for enterprise outsourcing options as in the IAAS example provided. >> In any case, I am puzzled by the reference to Data Loss Prevention (DLP) >> in the introduction of section 3.1. Data exfiltration is indeed a >> security issue, but I knew it primarily as an issue in enterprise >> networks. It does indeed become an issue in data centers when an >> enterprise application is hosted outside the data center, but it is a >> bit strange to see the first reference there. I already suggested to >> move section 3 and 4 out to a different document. Failing that, I would >> suggest reversing the order of section 3 and 4, i.e., discuss enterprise >> issues first and data center issues next. I think it was contributed there as a result of offerings to customers. Before removing it, we'd have to get confirmation that it isn't a service provided to many enterprises with outsourced solutions. I am pretty sure I had confirmed this point previously as RSA offers multiple DLP solutions at several layers. With a quick glance, RSA has cloud and data center buzz words in their product offering descriptions in addition to network and endpoint. >> >> The discussion of Customer Access Monitoring in section 3.1.1 is a bit >> strange. Most applications control customer access based on the customer >> identity, not based on the IP addresses of the customer -- the whole >> point of the "cloud" is that applications can be accessed from anywhere. >> Some applications do perform additional checks, mainly as a defense >> against stolen credentials, and would attempt to block access if the >> network location does not look plausible for this specific user. These >> are useful techniques, but the relation with encryption of data is >> somewhat thin. It seems to reinforce my point that data center issues >> would best be discussed in a separate document. >> There are certainly access restrictions based on IP and protocol information, which a 5-tuple and a 2-tuple are often adequate. If you are an administrator from a company who outsourced for infrastructure and some application support, management access of your customer application might be a simple example where this is still used. Sure, users are mobile, but they could VPN to their company network and connect from an approved IP. I think some of the use cases described are examples that are fine and encryption is a very small shift. In some of the examples, they serve as possible ways forward for the other use cases that haven't adapted yet. Boiling down the details and showing that log improvements and transaction monitoring improvements in the application or changes in protocols could ease this transition is important IMO. It's been a helpful process for some of the participants and I hope it helps for future protocol development to engage in these tough discussions understanding the perspectives on either end of this debate better. >> The reminder of section 3 appears to be a high level tutorial on the >> operation of data centers. It is not clear that there is a particular >> problem with encryption there. Indeed, I note that a lot of operators of >> big data centers, such as for example AWS, Azure or Google, have >> voluntarily pushed for increased used of encryption. I don't learn much >> by reading these sections, and I question whether they belong in the draft. I'll read through it again in a final sweep. We haven't gotten complaints about this text, but I'll note your concern in my sweep. >> >> 4. Encryption for Enterprises >> >> The discussion on encryption in enterprises would probably benefit from >> input by a variety of enterprise network managers. I found the >> discussion somewhat hard to read. It seems that the authors want to >> tackle three issues: the enterprise as a target for security attacks, >> the enterprise as an application provider, and the enterprise as a >> network provider. These are discussed in sections 4.1.1, 4.1.2, and >> 4.1.3. >> >> The description of attacks in 4.1.1 is somewhat high level. It starts >> from the statement that "A significant portion of malware hides its >> activity within TLS or other encrypted protocols" to draw a requirement >> to monitor encrypted traffic, when in practice there are many other >> monitoring points, from endpoint monitoring to data base activity logs >> to logs at network authentication servers -- as stated in the last >> paragraph of the section. >> >> The monitoring of application performance in enterprises appears >> strangely focused on the "IPv6 Destination Option Header (DOH) >> implementation of Performance and Diagnostic Metrics (PDM)". I >> understand that most big applications solve their monitoring need by >> implementing some form of telemetry, which is not affected at all by >> encryption, yet I see no mention of this telemetry approach in the >> discussion. Different data centers operate with different architectures and approaches. We'd be happy to get text from other network operators. I'll also do a sweep of this section and see if I can update it a bit more to help along these points. It may come in an update following the next one. >> >> I had a hard time reading section 4.1.3, Enterprise Network Diagnostics >> and Troubleshooting. It seems to cover a variety of techniques meant to >> monitor application services without actually instrumenting the >> application, and as such is not very convincing. Yes, the problem conveyed to us is that there are way too many applications that do a poor job of providing troubleshooting data, that it is hard to get this to an improved state. Since this was discussed a few years ago, I started putting comments on drafts to request text on logging to help in the long term. The organizations with these issues have also started reaching out to offending application developers, but it a long road. It is recognized that it's a better long term option. I'll see what we can do with the text on this front. >> >> The meat of section 4 appears to be in section 4.2, which is covering >> the issue of data loss prevention, and generally detection of data >> exfiltration. Again, this is an issue that would be worth a specialized >> draft. >> >> 5. Security Monitoring for Specific Attack Types >> >> Looks fine, and this review is already very long. Ack, thanks. >> >> 6. Application-based Flow Information Visible to a Network >> >> Do we need this section at all? It seems that most of the information >> could be captured by adding a small subsection to 2.1. Passive Monitoring. IPFIX was added at the request of Benoit to more fully cover network management protocols in the document. Brian Trammell provided that text, so the next version will have an improved section 6. >> >> 7. Impact on Mobility Network Optimizations and New Services >> >> This section appears to be a mix of replication of statements already >> made in section 2, and some speculation on the effect of transport >> header encryption, such as deployed in Web RTC (SCTP over DTLS) or >> planned in QUIC. There are active discussions in the QUIC WG to provide >> alternative to transport header inspection for RTT monitoring, and >> possibly also for packet loss monitoring. >> >> Contrarily to the rest of the document, this section seems speculative >> in nature. It discusses the possible effects of transport header >> encryption on the possible deployment of new services, which do not >> appear to be based on any IETF standard. I think the document would be >> stronger if some of the content of section 7 was moved to the >> appropriate part of section 2, and if the speculative statements were >> published as a separate document. We need to look at section 7 closer and will do so either in the next version or one that follows shortly there after. >> >> 8. Response to Increased Encryption and Looking Forward >> >> Looks reasonable. Thanks for your review and helpful comments! Would you be okay with an ack for your review and comments in the draft? >> >> -- Christian Huitema >> >> > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Fri Jan 5 13:03:50 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 932DE1241F5; Fri, 5 Jan 2018 13:03:43 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEDC1270A3; Fri, 5 Jan 2018 13:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EOoa3ec0hrZG; Fri, 5 Jan 2018 13:03:41 -0800 (PST) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (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 393541241F5; Fri, 5 Jan 2018 13:03:41 -0800 (PST) Received: by mail-pl0-x22a.google.com with SMTP id b96so3742979pli.2; Fri, 05 Jan 2018 13:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7ra7R4NlTLE3c9LezZGDlUHUcCa0jB4liUGHflIyr7g=; b=Dbj7R2y/mOXh+BBVv34j7OUqTPpXf6lvO2NgKW6LFIJ7GIt2yX8afFVIVl4GmajCNR LvtmuwOzbjyO3uQB/9H2K9Lab09lM7IBFc+TtVXeifcxT+dswXTg/D2QFi/QUAiun/TK 9iaS+IXfQOpjolF3JGVv9XTIi7eE6Hhex3P76uDX+KDOOlEOuUyrwl5LQu8aMG59ey8h gE8104dkEe51z4wYButJM9vCqOF02eY4aLDU0Jv4Hg7k6I2T22LPrkZ9C19iiwhVQfWC NjTo0Nas34Nme0rb+5USkf66VDRFjNb6gyxYjDcdgQKi/2ycjWa0Rq2/ERbIhi4oNY9X lNXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7ra7R4NlTLE3c9LezZGDlUHUcCa0jB4liUGHflIyr7g=; b=IkYkJ1BEcwgdsm3OK88OGvXE5lJgPoVe3FY+uHmFOgPtZq3oltPovZhoRbyorsNs22 JR3h56lDEm9rS8XVM0laH14k7LPjr9KLKIheuyf9L0p67mGW7k39IutzaKL3hLjvAAjH +xHucyn2gfb8KGw2q+1lzfC57FbWO+uIZX1RAF0u+9xSMnDQmg6M+gAAEnBKvtZfSkoY ukLYYbtyrofxIUiIP1x7qg6kHrD3o3g07rNvi73DXIDhc33EfMOSt3Kuv/xxXF44TZjZ /Wl0TmLJ8NuM0YyKBGVjUM01o27Gq3RyIRzP8HTYKI2OihbhxYZZBGmb3xgz4p/Erv9x 94HA== X-Gm-Message-State: AKGB3mL00Og8+lfmDMa4/YMpbtONGTv6kuCRrhyxZLEThSMpAacuG22k BDERRk/FFvQyTGq5V+qSgnwoD97WoQN+D0cp7Ug= X-Google-Smtp-Source: ACJfBoubrzYZSZG37MQC8FUG39ilfOIpCwe7bZFohk7DLtUbLgQAje6yumfmbZmTJaGG3EqPJ8CI+RVPl4Z7zFtpW2I= X-Received: by 10.84.251.135 with SMTP id w7mr4321178pll.305.1515186220576; Fri, 05 Jan 2018 13:03:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Fri, 5 Jan 2018 13:03:00 -0800 (PST) In-Reply-To: <8D818A25-1FD6-4FFF-AD64-56C716DF272D@google.com> References: <1ecac9b1-685b-8114-780a-a43425fb167d@huitema.net> <8D818A25-1FD6-4FFF-AD64-56C716DF272D@google.com> From: Kathleen Moriarty Date: Fri, 5 Jan 2018 16:03:00 -0500 Message-ID: To: james woodyatt Cc: Christian Huitema , IETF Discussion Mailing List , draft-mm-wg-effect-encrypt.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180105210343.932DE1241F5@ietfa.amsl.com> Resent-Date: Fri, 5 Jan 2018 13:03:43 -0800 (PST) Archived-At: Subject: Re: [OPSAWG] Christian's review of draft-mm-wg-effect-encrypt-13 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 21:03:43 -0000 Hello James, Thank you for your review and suggestions, responses are inline. On Fri, Dec 8, 2017 at 1:53 PM, james woodyatt wrote: > On Dec 4, 2017, at 08:23, Christian Huitema wrote: >> >> In section 2.3.3, Application Layer Gateways, I was wishing it would say >> something about IPv6. But then of course most IPv6 deployments today >> involve a form of NAT64... > > That section leaves unmentioned a vast array of open questions related to= IPv6-layer security filters and the problem of application layer gateways. If there are specific problems that are encountered with session encryption that you think should be added, please provide text and explain if it is with encryption that leaves a 5-tuple or 2-tuple available and what other metadata is typically used. > > It contains an extended discussion of the ALG functions in one example ca= se-- and not a particularly good one I would say-- the RTSP protocol, which= in the presence of an ALG, depends on the parties performing it in clearte= xt, or it alternatively requires a proxy being a participant in the securit= y protocol. The issues it describes apply to RTSP over both IPv4 and IPv6 i= n the presence of stateful filters that deny unsolicited inbound flows. Bot= h NAT44 and NAT64 depend on such stateful filters, and "Simple Security in = IPv6 Gateway CPE=E2=80=9D [RFC 6092] is an example of a place where the iss= ue applies in the absence of any network address translation. Hmm, we do have text elsewhere in the draft on the problems with RSTP for operators. In looking at RFC6092, that is specific to small offices and home gateways, which we don't cover in this draft. Since the issues are already covered in that RFC, are you suggesting an addition here? I'm not sure it's a fit. > > Some history might be worth recalling here, at the risk of yet again bein= g That Guy Who Told You So. > > Because I=E2=80=99m a bitter old man, I like to go back to =E2=80=9CLocal= Network Protection for IPv6=E2=80=9D [RFC 4864]. Specifically, =C2=A74.2 I= Pv6 and Simple Security. This document, while Informational, is the point i= n our history where IETF formally published a statement acknowledging that = IPv6 would absolutely always have the same problem with needing trustworthy= ALGs and proxies in the network that IPv4 does. I think this also boils down to architectural decisions. There are ways to perform many of the functions multiple ways, this document doesn't go much into the alternate option of proxying the encrypted traffic since that will still be possible with TLS 1.3. > > The key sentence there is this one: > >>> These should provide a default configuration where incoming traffic is = limited to return traffic resulting from outgoing packets (sometimes known = as reflective session state). > > After this document was published, and the howling subsided, some of us t= hought it would be a good idea to describe the behavioral requirements of t= his IPv6 "Simple Security" function in the same way that RFC 4787 and RFC 5= 382 do for UDP and TCP, respectively, in the IPv4/NAT case. Which is why we= now have "Simple Security in IPv6 Gateway CPE=E2=80=9D [RFC 6092]. > > When RFC 6092 was in development, an early draft revision had a section a= bout recommendations for various application layer gateways, e.g. RTSP+RTP,= L2TP+IKE+IPsec/ESP, FTP, et cetera. The final draft didn=E2=80=99t include= any of that, because consensus emerged around the idea that IPv6 simple se= curity functions should not *need* any ALGs, and they should instead includ= e a generic service for applications to use in soliciting inbound flows fro= m unknown remote addresses. This entailed having the usual IETF tussle over= competing non-standard solutions, i.e. UPnP-IGD vs. NAT-PMP. It was unreso= lved at the time RFC 6092 was published. It would still take some time befo= re "Port Control Protocol (PCP)" [RFC 6887] would settle that debate. > > Which is why REC-48 is written with such curiously vague text: > >>> Internet gateways with IPv6 simple security capabilities SHOULD impleme= nt a protocol to permit applications to solicit inbound traffic without adv= ance knowledge of the addresses of exterior nodes with which they expect to= communicate. > > Were we to revise RFC 6092 today, I would like to see this amended to rec= ommend PCP specifically. If there is an RFC anywhere that specifically asse= rts that deploying PCP servers in NAT64 and IPv6 firewall devices is Best C= urrent Practice, then I=E2=80=99m unaware of it. It would be nice. I'm not aware of one either, I don't think that exists. > > With hindsight, I was right to harbor pessimism about the rosy prediction= s, favored by some IETF participants, for the future of IPv6 without simple= security gateways everywhere, entailing the need for an array of ALGs and = proxies in every gateway, with the consequential impediment to application = protocol evolution created thereby. It turns out that =E2=80=9CLocal Networ= k Protection for IPv6=E2=80=9D [RFC 4864] really was a BCP in an Informatio= nal drag, which is the case I remember making here all those years ago. > > With respect to NAT64, it=E2=80=99s worth reviewing =E2=80=9CNAT64 Deploy= ment Options and Experience=E2=80=9D [RFC 7269], which is Informational, an= d it discusses both PCP and "An FTP Application Layer Gateway (ALG) for IPv= 6-to-IPv4 Translation=E2=80=9D [RFC 6384], as an example of a case where we= recognized that ubiquitous stateful filtering and denial of unsolicited in= bound flows would entail the placement of application layer gateways and pr= oxies in the network. Why do IPv6 FTP clients require RFC 6384? Because the= y don=E2=80=99t have PCP clients in them, and there are no PCP servers anyw= ay. > > Now it=E2=80=99s almost 2018, and we are finally discovering that pervasi= ve encryption requires ALGs and proxies to be trusted by all parties in the= application protocol. And this is painful. Because new host application pr= otocols aren=E2=80=99t even developed to use PCP. Because PCP servers haven= =E2=80=99t been deployed anywhere. Because everything is terrible, and ever= yone would love to keep it that way. Or, at least, it seems so to me. Becau= se I=E2=80=99m a bitter old man. > > I honestly don=E2=80=99t know if there is anything useful to say about AL= Gs in this document beyond simply acknowledging somewhere that they=E2=80= =99re all necessarily broken by pervasive end-to-end encryption and operato= rs who value administrative privacy, user tracking and/or topology hiding s= hould consider the utility of secure application level proxies instead. Thanks for your input. We are not including solutions in the draft intentionally (as much as possible). If you have specific text about ALGs that should be added, please do provide it, but please have it specific to the goals of the draft - documenting the function impacted by encryption and the data used currently when sessions are not encrypted so there can be some assessment of impact. Of course the use of proxies are slower than many other solutions and not always an option or good idea. > > > --james woodyatt > > > --=20 Best regards, Kathleen From nobody Fri Jan 5 14:06:13 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A33F312D88C; Fri, 5 Jan 2018 14:06:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , "Paul Hoffman" X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151518996766.32238.6162293089157802450.idtracker@ietfa.amsl.com> Date: Fri, 05 Jan 2018 14:06:07 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-mm-wg-effect-encrypt-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 22:06:08 -0000 A new version (-14) has been submitted for draft-mm-wg-effect-encrypt: https://www.ietf.org/internet-drafts/draft-mm-wg-effect-encrypt-14.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-mm-wg-effect-encrypt-14 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Sat Jan 6 22:02:36 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D28126FB3; Sat, 6 Jan 2018 22:02:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roni Even To: Cc: draft-ietf-opsawg-nat-yang.all@ietf.org, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151530495013.10736.22764279794775204@ietfa.amsl.com> Date: Sat, 06 Jan 2018 22:02:30 -0800 Archived-At: Subject: [OPSAWG] Genart early review of draft-ietf-opsawg-nat-yang-09 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 06:02:30 -0000 Reviewer: Roni Even Review result: Ready I am the assigned Gen-ART reviewer for this draft. THis is an early review. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document:draft-ietf-opsawg-nat-yang-09 Reviewer: Roni Even Review Date: January 7th, 2018 IETF LC End Date: IESG Telechat date: (if known) Summary: I have no comments about the document text. I am not a Yang expert so did not verify the correctness of the Yang module Major issues: Minor issues: Nits/editorial comments: From nobody Sun Jan 7 23:30:50 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C57B126DFF; Sun, 7 Jan 2018 23:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 3tJbbeZx32Ep; Sun, 7 Jan 2018 23:30:47 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6A0126B71; Sun, 7 Jan 2018 23:30:47 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 109FE180F86; Mon, 8 Jan 2018 08:30:46 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id E954A4006C; Mon, 8 Jan 2018 08:30:45 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0361.001; Mon, 8 Jan 2018 08:30:41 +0100 From: To: Joe Clarke , "opsawg@ietf.org" , "draft-ietf-opsawg-nat-yang@ietf.org" CC: "Senthil Sivakumar (ssenthil)" , "JACQUENET Christian IMT/OLN" Thread-Topic: IPR CALL: Please disclose any IPR related to draft-ietf-opsawg-nat-yang Thread-Index: AQHTezfCwwY6rwidMEqYTSk94iSTb6Nprimg Date: Mon, 8 Jan 2018 07:30:41 +0000 Message-ID: <330dd2d3-5ab7-43f7-aad8-252dc71cf387@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <32abe856-ef86-8343-3814-8ebb29becdf6@cisco.com> In-Reply-To: <32abe856-ef86-8343-3814-8ebb29becdf6@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] IPR CALL: Please disclose any IPR related to draft-ietf-opsawg-nat-yang X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 07:30:49 -0000 SGkgSm9lLCBhbGwsIA0KDQpIYXBweSBOZXcgWWVhciAhDQoNCkFwb2xvZ2llcyBmb3IgdGhlIGRl bGF5IHRvIGFuc3dlciB0aGlzIG1lc3NhZ2UgKEkgd2FzIG91dCBvZiBvZmZpY2UpLiANCg0KSSBk b27igJl0IGhhdmUgYW55IElQUiBub3IgSSdtIGF3YXJlIG9mIGFueSByZWxhdGVkIHRvIHRoaXMg ZHJhZnQuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBKb2UgQ2xhcmtlIFttYWlsdG86amNsYXJrZUBjaXNjby5jb21dDQo+IEVudm95w6nC oDogdmVuZHJlZGkgMjIgZMOpY2VtYnJlIDIwMTcgMTY6MTYNCj4gw4DCoDogb3BzYXdnQGlldGYu b3JnOyBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZ0BpZXRmLm9yZw0KPiBPYmpldMKgOiBJUFIg Q0FMTDogUGxlYXNlIGRpc2Nsb3NlIGFueSBJUFIgcmVsYXRlZCB0byBkcmFmdC1pZXRmLW9wc2F3 Zy0NCj4gbmF0LXlhbmcNCj4gDQo+IE9uIGJlaGFsZiBvZiB0aGUgY2hhaXJzLCBJJ2QgbGlrZSB0 byBkbyBhbiBJUFIgY2FsbCBmb3IgdGhpcyBkcmFmdCBhcyBpdA0KPiBpcyBpbiBXRyBMQy4gIElm IHRoZXJlIGlzIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0LCBwbGVhc2UgZGlzY2xvc2UN Cj4gaXQgaGVyZSBhcyB3ZWxsIGFzIHdpdGhpbiBEYXRhIFRyYWNrZXIuDQo+IA0KPiBKb2UNCg== From nobody Sun Jan 7 23:35:34 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7387F126CD8; Sun, 7 Jan 2018 23:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 EwjqxUU6tsXi; Sun, 7 Jan 2018 23:35:30 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722B2126D0C; Sun, 7 Jan 2018 23:35:30 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 62E9FC05FB; Mon, 8 Jan 2018 08:35:28 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 466291A0062; Mon, 8 Jan 2018 08:35:28 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0361.001; Mon, 8 Jan 2018 08:35:25 +0100 From: To: BOUCADAIR Mohamed IMT/OLN , Joe Clarke , "opsawg@ietf.org" , "draft-ietf-opsawg-nat-yang@ietf.org" Thread-Topic: IPR CALL: Please disclose any IPR related to draft-ietf-opsawg-nat-yang Thread-Index: AQHTezfCwwY6rwidMEqYTSk94iSTb6NprimggAABtpA= Date: Mon, 8 Jan 2018 07:35:24 +0000 Message-ID: <7451_1515396928_5A531F40_7451_452_1_ce36c73e-c30d-46f8-9245-22a81c0895e4@OPEXCLILM6C.corporate.adroot.infra.ftgroup> References: <32abe856-ef86-8343-3814-8ebb29becdf6@cisco.com> <330dd2d3-5ab7-43f7-aad8-252dc71cf387@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <330dd2d3-5ab7-43f7-aad8-252dc71cf387@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] IPR CALL: Please disclose any IPR related to draft-ietf-opsawg-nat-yang X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 07:35:32 -0000 RGVhciBhbGwsDQoNCkknbSB0b28gdW5hd2FyZSBvZiBhbnkgSVBSIHRoYXQgcGVydGFpbnMgdG8g dGhpcyBkcmFmdC4NCg0KQ2hlZXJzLA0KDQpDaHJpc3RpYW4uDQoNCi0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KRGXCoDogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSBbbWFpbHRvOm1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21dIA0KRW52b3nDqcKgOiBsdW5kaSA4IGphbnZpZXIg MjAxOCAwODozMQ0Kw4DCoDogSm9lIENsYXJrZTsgb3BzYXdnQGlldGYub3JnOyBkcmFmdC1pZXRm LW9wc2F3Zy1uYXQteWFuZ0BpZXRmLm9yZw0KQ2PCoDogU2VudGhpbCBTaXZha3VtYXIgKHNzZW50 aGlsKTsgSkFDUVVFTkVUIENocmlzdGlhbiBJTVQvT0xODQpPYmpldMKgOiBSRTogSVBSIENBTEw6 IFBsZWFzZSBkaXNjbG9zZSBhbnkgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1vcHNhd2ctbmF0 LXlhbmcNCg0KSGkgSm9lLCBhbGwsIA0KDQpIYXBweSBOZXcgWWVhciAhDQoNCkFwb2xvZ2llcyBm b3IgdGhlIGRlbGF5IHRvIGFuc3dlciB0aGlzIG1lc3NhZ2UgKEkgd2FzIG91dCBvZiBvZmZpY2Up LiANCg0KSSBkb27igJl0IGhhdmUgYW55IElQUiBub3IgSSdtIGF3YXJlIG9mIGFueSByZWxhdGVk IHRvIHRoaXMgZHJhZnQuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiBEZcKgOiBKb2UgQ2xhcmtlIFttYWlsdG86amNsYXJrZUBjaXNjby5jb21dIEVu dm95w6nCoDogdmVuZHJlZGkgMjIgDQo+IGTDqWNlbWJyZSAyMDE3IDE2OjE2IMOAwqA6IG9wc2F3 Z0BpZXRmLm9yZzsgDQo+IGRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nQGlldGYub3JnDQo+IE9i amV0wqA6IElQUiBDQUxMOiBQbGVhc2UgZGlzY2xvc2UgYW55IElQUiByZWxhdGVkIHRvIA0KPiBk cmFmdC1pZXRmLW9wc2F3Zy0gbmF0LXlhbmcNCj4gDQo+IE9uIGJlaGFsZiBvZiB0aGUgY2hhaXJz LCBJJ2QgbGlrZSB0byBkbyBhbiBJUFIgY2FsbCBmb3IgdGhpcyBkcmFmdCBhcyANCj4gaXQgaXMg aW4gV0cgTEMuICBJZiB0aGVyZSBpcyBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdCwgcGxl YXNlIA0KPiBkaXNjbG9zZSBpdCBoZXJlIGFzIHdlbGwgYXMgd2l0aGluIERhdGEgVHJhY2tlci4N Cj4gDQo+IEpvZQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Jan 8 05:18:08 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7F712785F; Mon, 8 Jan 2018 05:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 cT3nwYXxlDUf; Mon, 8 Jan 2018 05:18:03 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5091C120227; Mon, 8 Jan 2018 05:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1515417483; x=1516627083; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=No5GsPyIsh1IOMc8OQrmOG2dSCd3BWJBESSLDhy7U/g=; b=KCZdmE55yMgseUgd/JuH2izQGg0NS5TJg+jb/OT7Q3kBfq03xkCtib6P WPgOWkeSII/M+8u8XzPBJ02/AXKxZtWLIku6JIIN4VzrQXXfOLZnzar6V RaeS7njvkG8tMQGgVOsLUd9mTtm3AJYR/zufRwazKObVvj4K1Hebr4/cO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQDRblNa/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM/gVonB4QAiiSOWIIClyqCFQqFOwIahBg/GAEBAQEBAQEBAWs?= =?us-ascii?q?ohSQGHQYRRRACAQgaAiMDAgICMBQBEAIEAQ0FijGxVYInijABAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgQ+DEYIVg2iDBYMwgW6DFzGCNAEEmW+JbwKVPIIXhhmLWZZ?= =?us-ascii?q?qAhEZAYE7AR85gVBvFWcBgX+EV3iJUYEXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,330,1511827200"; d="scan'208";a="343490126" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2018 13:18:01 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w08DI1Ac010604 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jan 2018 13:18:01 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 8 Jan 2018 07:18:00 -0600 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1320.000; Mon, 8 Jan 2018 07:18:00 -0600 From: "Senthil Sivakumar (ssenthil)" To: "mohamed.boucadair@orange.com" , "Joe Clarke (jclarke)" , "opsawg@ietf.org" , "draft-ietf-opsawg-nat-yang@ietf.org" CC: JACQUENET Christian IMT/OLN Thread-Topic: IPR CALL: Please disclose any IPR related to draft-ietf-opsawg-nat-yang Thread-Index: AQHTezfCwwY6rwidMEqYTSk94iSTb6NprimggAByYQA= Date: Mon, 8 Jan 2018 13:18:00 +0000 Message-ID: References: <32abe856-ef86-8343-3814-8ebb29becdf6@cisco.com> <330dd2d3-5ab7-43f7-aad8-252dc71cf387@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <330dd2d3-5ab7-43f7-aad8-252dc71cf387@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.219.135] Content-Type: text/plain; charset="utf-8" Content-ID: <7800DE0216BAB04F908A5440DCA715E2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] IPR CALL: Please disclose any IPR related to draft-ietf-opsawg-nat-yang X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 13:18:06 -0000 SSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQoNClRoYW5r cw0KU2VudGhpbA0KDQpPbiAxLzgvMTgsIDI6MzAgQU0sICJtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCiAgICBIaSBK b2UsIGFsbCwgDQogICAgDQogICAgSGFwcHkgTmV3IFllYXIgIQ0KICAgIA0KICAgIEFwb2xvZ2ll cyBmb3IgdGhlIGRlbGF5IHRvIGFuc3dlciB0aGlzIG1lc3NhZ2UgKEkgd2FzIG91dCBvZiBvZmZp Y2UpLiANCiAgICANCiAgICBJIGRvbuKAmXQgaGF2ZSBhbnkgSVBSIG5vciBJJ20gYXdhcmUgb2Yg YW55IHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC4NCiAgICANCiAgICBDaGVlcnMsDQogICAgTWVkDQog ICAgDQogICAgPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCiAgICA+IERlIDogSm9lIENs YXJrZSBbbWFpbHRvOmpjbGFya2VAY2lzY28uY29tXQ0KICAgID4gRW52b3nDqSA6IHZlbmRyZWRp IDIyIGTDqWNlbWJyZSAyMDE3IDE2OjE2DQogICAgPiDDgCA6IG9wc2F3Z0BpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmdAaWV0Zi5vcmcNCiAgICA+IE9iamV0IDogSVBSIENBTEw6 IFBsZWFzZSBkaXNjbG9zZSBhbnkgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1vcHNhd2ctDQog ICAgPiBuYXQteWFuZw0KICAgID4gDQogICAgPiBPbiBiZWhhbGYgb2YgdGhlIGNoYWlycywgSSdk IGxpa2UgdG8gZG8gYW4gSVBSIGNhbGwgZm9yIHRoaXMgZHJhZnQgYXMgaXQNCiAgICA+IGlzIGlu IFdHIExDLiAgSWYgdGhlcmUgaXMgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQsIHBsZWFz ZSBkaXNjbG9zZQ0KICAgID4gaXQgaGVyZSBhcyB3ZWxsIGFzIHdpdGhpbiBEYXRhIFRyYWNrZXIu DQogICAgPiANCiAgICA+IEpvZQ0KICAgIA0KDQo= From nobody Mon Jan 8 09:52:18 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5009D127023; Mon, 8 Jan 2018 09:51:59 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D0D12711D; Mon, 8 Jan 2018 09:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 TSJJ8Sj8vgw9; Mon, 8 Jan 2018 09:51:56 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 2DF58127023; Mon, 8 Jan 2018 09:51:56 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id i143so15446125ioa.3; Mon, 08 Jan 2018 09:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4udUrC8EOxnNlPIOm9gTlMzGmJFqwK01s6igOxIBmXU=; b=jWx3RDBVXtZ5lzCQnCs0s+YwYV4+5qrbkaRrV2q1k8zQr2y6oy0rJJTHI9jWZgI2/f A08ev+ZxpELLXYE8AYIILxPXhL+E6WU2DKJ+hVZMdOTOzIK6RD254JWZJvhViC2hw/yB s/uJqyL3S3T6rcUyTJQdhf2x4aDSAYUZ9A3PEyYz5RbjEVlM40OWnDltvMtTUC8qBbHn Rrzxun8TGkS0MyaK98Giu9mdfKlpBXK8ni0FqxXr8HUPTiNXFWxNc3MIZn1Zi5gZAej8 gCJpj2CHuRWn5ZaLlRysouSYR9+dKd+IZYd5+5oVvd/ulXaM5wd0s6OzLT7lhVuoiOnW JJQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4udUrC8EOxnNlPIOm9gTlMzGmJFqwK01s6igOxIBmXU=; b=acgnrs61RdykRfS84fWmCMBV4j3s6gvdzsZbMAipxcflG8GTvcf0dtgoW2yZvAahcG FDi1SXTWfQBY5xD7pGPDMrQZJHxM8IDG77LTmlsLkM0VWLdOpRQnK070IOpBYwk6ofl1 PBS9IGikWNS1914WnGCuM4Ox962LSLqHl/1xIFzK+K4cL5jmQiTuGu6C7Y02RzYtIoAo /jRO9n5UmxHXcf5Sxctk+xUfvoOLku+VJwvBCbdltP2gMKEpG6WcMPsXSNcqrC6yAw0w Yb/XxJFL+8b5oUHVAdv0JJmZ67eSqkdhm3bfRfdJz1G0Hr4bhiLEFyHN0Aqa6Mkoqa+q YnJA== X-Gm-Message-State: AKGB3mICt2lph+z0sW3HM9OiyPjmQ81lKYAqFnxSBMlSA/ror3gVD9Ab 6X/k3dyFZ0/wQhtD3SceFNcn+tTh3tV6arBe4fE= X-Google-Smtp-Source: ACJfBotdu1vwoAVc//0giEjFipjZQxNjJ4KAba1/yccVEHhY4wyppfR/22yIkUO/biyOpo2WmX+w/fMi0CochboLKjI= X-Received: by 10.107.131.157 with SMTP id n29mr12963533ioi.260.1515433915241; Mon, 08 Jan 2018 09:51:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.101.67 with HTTP; Mon, 8 Jan 2018 09:51:54 -0800 (PST) In-Reply-To: References: <151302958109.21278.5686525939396201959@ietfa.amsl.com> From: Ines Robles Date: Mon, 8 Jan 2018 19:51:54 +0200 Message-ID: To: Kathleen Moriarty Cc: rtg-dir@ietf.org, draft-mm-wg-effect-encrypt.all@ietf.org, IETF Content-Type: multipart/alternative; boundary="001a113eb73a32da9e0562477435" Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180108175159.5009D127023@ietfa.amsl.com> Resent-Date: Mon, 8 Jan 2018 09:51:59 -0800 (PST) Archived-At: Subject: Re: [OPSAWG] Rtgdir last call review of draft-mm-wg-effect-encrypt-13 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 17:51:59 -0000 --001a113eb73a32da9e0562477435 Content-Type: text/plain; charset="UTF-8" Hi Kathleen, Ok, thank you for the feedback. Best, Ines. 2018-01-04 20:13 GMT+02:00 Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com>: > Hello Ines, > > Thanks again for your review. Edits have been made in our working > version that we hope to post soon. > > On Mon, Dec 11, 2017 at 9:27 PM, Kathleen Moriarty > wrote: > > Ines, > > > > Thank you very much for your review! We're working on the comments > > received and the nits you found will be addressed and are much > > appreciated. > > > > Best regards, > > Kathleen > > > > On Mon, Dec 11, 2017 at 4:59 PM, Ines Robles > > wrote: > >> Reviewer: Ines Robles > >> Review result: Ready > >> > >> RtgDir review: draft-mm-wg-effect-encrypt-13.txt > >> > >> Hello, > >> > >> I have been selected as the Routing Directorate reviewer for this > draft. The > >> Routing Directorate seeks to review all routing or routing-related > drafts as > >> they pass through IETF last call and IESG review, and sometimes on > special > >> request. The purpose of the review is to provide assistance to the > Routing ADs. > >> For more information about the Routing Directorate, please see > >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > >> > >> Although these comments are primarily for the use of the Routing ADs, > it would > >> be helpful if you could consider them along with any other IETF Last > Call > >> comments that you receive, and strive to resolve them through > discussion or by > >> updating the draft. > >> > >> Document: Effect of Pervasive Encryption on Operators - > >> draft-mm-wg-effect-encrypt-13 Reviewer: Ines Robles Review Date: > 12-11-2017 > >> Intended status: Informational > >> > >> Summary: > >> This document discusses current security and network management > practices to > >> help guide protocol development in support of manageable, secure > networks. > >> > >> The draft is ready, few typos found. > >> > >> Comments: > >> > >> I believe the draft is technically good. This document is well written > and > >> clear to understand. > >> > >> Major Issues: > >> > >> No major issues found. > >> > >> Minor Issues: > >> > >> Section 2: > >> > >> "... Following the Snowden revelations,..." => It would be nice to add > some > >> references here > > Yes, the problem we have had so far is finding ones that aren't > articles that may not be stable. A quick search pulls up new ones > like the following: > http://fortune.com/2016/04/25/snowden-encryption-james-clapper/ > > We'll have to try again to find an academic publication. > > >> > >> Section 2.2.5: > >> "DRM..."=> I would expand it to Digital Rights Management (DRM) > > Added, thank you! > > >> > >> Section 6: > >> > >> inlcudes=> includes > > Fixed, thanks. > >> > >> Section 6.1: > >> "information For example" => period missing? > > Ack, thanks! > >> > >> Section 6.2: > >> "soltuions" -> solutions > Fixed. > >> > >> Section 7.1 title: > >> "Encypted" => Encrypted > Fixed. > > Thanks for your review! > > > >> > >> > > > > > > > > -- > > > > Best regards, > > Kathleen > > > > -- > > Best regards, > Kathleen > --001a113eb73a32da9e0562477435 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kathleen,

Ok, thank you for the feed= back.

Best,

Ines.

2018-01-04 20= :13 GMT+02:00 Kathleen Moriarty <kathleen.moriarty.ietf@gma= il.com>:
Hello Ines,

Thanks again for your review.=C2=A0 Edits have been made in our working
version that we hope to post soon.

On Mon, Dec 11, 2017 at 9:27 PM, Kathleen Moriarty
<kathleen.moriarty.i= etf@gmail.com> wrote:
> Ines,
>
> Thank you very much for your review!=C2=A0 We're working on the co= mments
> received and the nits you found will be addressed and are much
> appreciated.
>
> Best regards,
> Kathleen
>
> On Mon, Dec 11, 2017 at 4:59 PM, Ines Robles
> <mariainesrobles@= googlemail.com> wrote:
>> Reviewer: Ines Robles
>> Review result: Ready
>>
>> RtgDir review: draft-mm-wg-effect-encrypt-13.txt
>>
>> Hello,
>>
>> I have been selected as the Routing Directorate reviewer for this = draft. The
>> Routing Directorate seeks to review all routing or routing-related= drafts as
>> they pass through IETF last call and IESG review, and sometimes on= special
>> request. The purpose of the review is to provide assistance to the= Routing ADs.
>> For more information about the Routing Directorate, please see
>> http://trac.tools.ietf.org/area/rt= g/trac/wiki/RtgDir
>>
>> Although these comments are primarily for the use of the Routing A= Ds, it would
>> be helpful if you could consider them along with any other IETF La= st Call
>> comments that you receive, and strive to resolve them through disc= ussion or by
>> updating the draft.
>>
>> Document: Effect of Pervasive Encryption on Operators -
>> draft-mm-wg-effect-encrypt-13 Reviewer: Ines Robles Review Date: 1= 2-11-2017
>> Intended status: Informational
>>
>> Summary:
>> This document discusses current security and network management pr= actices to
>> help guide protocol development in support of manageable, secure n= etworks.
>>
>> The draft is ready, few typos found.
>>
>> Comments:
>>
>> I believe the draft is technically good. This document is well wri= tten and
>> clear to understand.
>>
>> Major Issues:
>>
>> No major issues found.
>>
>> Minor Issues:
>>
>> Section 2:
>>
>> "... Following the Snowden revelations,..." =3D> It w= ould be nice to add some
>> references here

Yes, the problem we have had so far is finding ones that aren&#= 39;t
articles that may not be stable.=C2=A0 A quick search pulls up new ones
like the following:
http://fortune.com/2016/04/25/sn= owden-encryption-james-clapper/

We'll have to try again to find an academic publication.

>>
>> Section 2.2.5:
>> "DRM..."=3D> I would expand it to=C2=A0 Digital Right= s Management (DRM)

Added, thank you!

>>
>> Section 6:
>>
>> inlcudes=3D> includes

Fixed, thanks.
>>
>> Section 6.1:
>> "information For example" =3D> period missing?

Ack, thanks!
>>
>> Section 6.2:
>> "soltuions" -> solutions
Fixed.
>>
>> Section 7.1 title:
>> "Encypted" =3D> Encrypted
Fixed.

Thanks for your review!


>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen



--

Best regards,
Kathleen

--001a113eb73a32da9e0562477435-- From nobody Tue Jan 9 06:50:26 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B01126D0C for ; Tue, 9 Jan 2018 06:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.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 4_zwrDmUB9yy for ; Tue, 9 Jan 2018 06:50:22 -0800 (PST) Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (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 F2733126C0F for ; Tue, 9 Jan 2018 06:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=Mime-Version:To:Date:Message-Id:Subject: Content-Transfer-Encoding:Content-Type:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=7LDmSJ2q8SVz2gaCjwqsu6yOD8XowBBib1JmIx0Sing=; b=DqnCxnCRohljD3EJZ/9iAkujKc 9vXMkMhGbLRpl1hDsbQaaGxq1meJYd0C66kOYJH4dx19IVjTZDidyBU0KnE8AR7800IxRhGsWHI24 hxWB/8mqI5CQJMT5P6ZBYM4tFT9gzlWCcusidyWLOk0Va+vOQ9o6n1cZmlWPmlcWzNWE=; Received: from 86-44-56-31-dynamic.agg7.bsn.cld-dbn.eircom.net ([86.44.56.31]:49986 helo=[192.168.1.28]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89_1) (envelope-from ) id 1eYvEK-0005pr-8d for opsawg@ietf.org; Tue, 09 Jan 2018 14:50:20 +0000 From: Dave O'Reilly Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <29FE18A1-ADA8-40B7-AD6E-A1C9AF133365@daveor.com> Date: Tue, 9 Jan 2018 14:50:19 +0000 To: opsawg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - daveor.com X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [OPSAWG] Request for feedback on draft-daveor-cgn-logging-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 14:50:24 -0000 Dear friends and colleagues of the OPSAWG mailing list, First of all happy new year to you all! I=E2=80=99m the author of = https://tools.ietf.org/html/draft-daveor-cgn-logging-02, which considers = issues relating to crime attribution in cases involving large scale = address sharing technologies (such as Carrier Grade NAT).=20 Benoit Claise brought this mailing list to my attention and suggested = that it might be worthwhile to advertise the Internet Draft here for = your consideration. For those of you that are also members of v6ops, you = may recall that there was some interesting and very helpful discussion = there relating to this document back in October.=20 I=E2=80=99m very interested in any feedback at all and I appreciate you = taking the time to review the draft linked above.=20 Thanks and best regards, daveor= From nobody Tue Jan 9 07:25:38 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354071205F0 for ; Tue, 9 Jan 2018 07:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, 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 gjVTktVXWZLu for ; Tue, 9 Jan 2018 07:25:35 -0800 (PST) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A4A12D874 for ; Tue, 9 Jan 2018 07:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=301; q=dns/txt; s=iport; t=1515511525; x=1516721125; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=GxRxPZP4kRQs7hLGBZ/WOwtoiIvR7otlfgjiuJBzwkg=; b=GC5+RKe/lhL4cOYViwmHsLokUL3kHNjgX6g48LK7xLPsZeH4lxqPwH6L tnOsls2AMG4i+3x/iJo+TWuKFh1XsVoV97ZX4oaeBp0NAlIJXv+V+IAdH dDesWAqTSerWJ1TXtW2/c2ObIIHyo78d+OKulaP1I9vBRbMgGOEv4Z+e/ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAQDK3VRa/xjFo0hdGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUahC6LGKktCoo6FAEBAQEBAQEBAWsdC4VNgQsCJgJfDQgBAYo?= =?us-ascii?q?trxqCJ4pBAQEBBwEBAQEkgQ+DEYNsghKDBYEwhwWCZQWTOoY2iW+VQYF+ARiGG?= =?us-ascii?q?YNvh2gClxl+PjYigVBMIxWCaIR0I4thAQEB?= X-IronPort-AV: E=Sophos;i="5.46,336,1511827200"; d="scan'208";a="59184189" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2018 15:25:22 +0000 Received: from [10.118.87.84] (rtp-jclarke-nitro3.cisco.com [10.118.87.84]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w09FPKig031402 for ; Tue, 9 Jan 2018 15:25:21 GMT To: "opsawg@ietf.org" From: Joe Clarke Organization: Cisco Message-ID: Date: Tue, 9 Jan 2018 10:25:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] REQUEST FOR SHEPHERD: Need shepherd for draft-ietf-opsawg-nat-yang X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 15:25:37 -0000 With WG LC closing on this document today, we will need a document shepherd. While it would be good to get an operator the lives and breathes NAT, that is not a requirement. Please let the myself or the other co-chairs know if you are interested. Thanks. Joe (and behalf of the co-chairs) From nobody Tue Jan 9 13:16:59 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD01912773A for ; Tue, 9 Jan 2018 13:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 IjsU95G0iUVu for ; Tue, 9 Jan 2018 13:16:49 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 797251275C5 for ; Tue, 9 Jan 2018 13:16:49 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id i40so19590654qti.8 for ; Tue, 09 Jan 2018 13:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=znenHzlrf024yDnMFvajUn5+kfNeP2MV3qE+mVorPA8=; b=G2ZEEelUhG8y2o+Gwwk9F/qZnbqLzkotSxg/ebg7yoY5p7lOwWzsgXiiXjOvi11eRA 4YUTUma/hIN+7EmbK/N/2jZPhveoiIF3ma8VvsdZjOQ3K3zj56XMjk33dqwn6l/8TrHz 2Nk1lK9iDUODPk1Iw5zJK4O196y/gNtC413qE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=znenHzlrf024yDnMFvajUn5+kfNeP2MV3qE+mVorPA8=; b=bs9HfJcqnOjghx2EieYgh8/NJLcIEYWCb5ZAycAkT/BsWyZOd/8KTeJqnsoLzm3QEi XXK78XFW+r68fFfWofs1XzwozekBSKwplW4VyofO56k7vC6FCeE/mlnbgsXTQJ1oJvVA 41Z/bH0alA/yDVRpWp88BAHi6J/Am9Z6/H16IbBLNJ35Crwfya7C9pbim76IzpfqexNl rXtzwUgDvwmYAJi7XysRWQYA24OCDGnN+KIkl2ceBt3DgVcCIfhm8x6hyHskxFhtmeIG WtqwperDHGVWocxDEouHOgjJkrOj8l/saYydgH98scD922TGi89GD7Q0lP8UFo0YnUdu JiUw== X-Gm-Message-State: AKwxytf/SzjueKmE0pVx0cBucGOAMSSq4/9hDdJ8v1d/ovqt4YkDMfi8 Cpy4p6Sx3aaFNwpHT5Gd/P2aAzDPz3SUZQ7PKhYM6g== X-Google-Smtp-Source: ACJfBov1ZVkeUVr2YNkgRPhqNdX8VycwnlChon2EA6rusWSlpRzk/vNRnijVOTrBeqY9YE2rkuVJ9pYNbIg/Yswy0+w= X-Received: by 10.200.8.178 with SMTP id v47mr22562320qth.59.1515532606606; Tue, 09 Jan 2018 13:16:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.160.129 with HTTP; Tue, 9 Jan 2018 13:16:45 -0800 (PST) X-Originating-IP: [2001:4878:a000:3000:d050:b6e0:cb31:f8f2] From: Kyle Rose Date: Tue, 9 Jan 2018 16:16:45 -0500 Message-ID: To: ietf@ietf.org, Kathleen Moriarty , "MORTON, ALFRED C (AL)" , Brandon Williams , Warren Kumari , Paul Hoffman , opsawg@ietf.org Content-Type: multipart/alternative; boundary="001a11c14646a9c75305625e6ed9" Archived-At: Subject: [OPSAWG] draft-mm-wg-effect-encrypt-13 review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 21:16:58 -0000 --001a11c14646a9c75305625e6ed9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Brandon Williams and I reviewed this draft with Kathleen and Al via the IETF etherpad during last call. The link is here: https://etherpad.tools.ietf.org/p/krose-review-draft-mm-wg-effect-encrypt-1= 3 I have attempted to cull the discussion down to something consumable on the mailing list. Apologies in advance for formatting issues. Note that I have not subsequently added any comments to the etherpad: I'll respond to this thread instead with any follow-ups. this mode is deployed. IPsec with authentication has many useful applications and usage has increased for infrastructure applications such as for virtual private networks between data centers. KR> The above paragraph doesn't seem to have a clear point. It's mostly about opportunistic security, but has a few unrelated points inserted (e.g., the final sentence about IPsec with authentication). KM> Looks like final sentence provides contrast with the previous sentence "OS has been implemented as NULL Authentication with IPsec..." the application user, and hosting service providers lease computing, storage, and communications systems in datacenters. In practice, many companies perform two or more service provider roles, but may be historically associated with one. KR> Honestly, all of section 1.1 seems to be a grab bag lacking a thesis, maybe motivating the vague title "Additional Background". I think the information there could be organized in a better way to answer the question posed in the reader's mind after the introduction, which is: give me some examples of monitoring/manipulation for operability that have been defeated by encryption, with evidence that they aren't solvable without additional telemetry or cooperation with middleboxes. The following section is closer to what I wanted after the intro. KM> Initially, we had some examples in the draft, but were asked to remove them. I take your point and am in process of reworking this text to make it more cohesive. The problem in much of this draft was the number of contributions, so your sweep of the draft for points like this are very helpful. AM> As I read it, section 1.1 is describing changes to the communication landscape re: encryption. The exception is the very last paragraph, which could be moved above section 1.1. I agree that the purpose of section 1.1. could be made more clear in the introductory paragraph. I do think that it's useful background to high-light these changes in the encryption landscape, since that's what motivates the draft. KM> Thanks. It is also to ensure the draft is not read as being just about TLS, so I am making that point more clear as well. Moving the last paragraph to the introduction makes sense. Following the Snowden revelations, application service providers responded by encrypting traffic between their data centers (IPsec) to prevent passive monitoring from taking place unbeknownst to them (Yahoo, Google, etc.). Large mail service providers also began to KR> IIRC, companies were already doing this for infrastructure traffic on the public internet: it was their own private backbones on which they started using encryption universally. KM> Yes, good point. I clarified the text to distinguish that, but was careful not to say that they pretty all infrastructure traffic over the Internet was encrypted even though I think that's in line with reality - at least where I worked which included an ISP and a big financial data provider early on. The EFF reported [EFF2014] several network service providers taking steps to prevent the use of SMTP over TLS by breaking STARTTLS KR> I think it's important to use the phrase "downgrade attack" when describing something like this. The word "downgrade" first appears in the references list. KM> Done, thanks. (section 3.2 of [RFC7525]), essentially preventing the negotiation process resulting in fallback to the use of clear text. In other cases, some service providers have relied on middle boxes having access to clear text for the purposes of load balancing, monitoring for attack traffic, meeting regulatory requirements, or for other purposes. These middle box implementations, whether performing functions considered legitimate by the IETF or not, have been impacted by increases in encrypted traffic. Only methods keeping with the goal of balancing network management and PM mitigation in [RFC7258] should be considered in solution work resulting from this document. KR> I feel like this section could be better organized by: * Moving the examples to 1.1 as a bulleted list of sample situations in which network operators attempted to and/or succeeded in defeating encryption to preserve existing operational mechanisms, or in which performance suffered for users (whether of the encrypted flows or of other flows impacted by encrypted flows). KM> Interesting point, but we'd need more examples. I'll think about this more and chat with Al in case he has ideas. For now, I went with Brandon's easier suggestion, but moving to this would be nice for the document readers. AM> Although I see how these examples could be part of the background, I think those who will eventually remove their objections will prefer the reduced emphasis on these examples where they are (in section 2). In one view, the entire memo is background, since nothing new is proposed. KR> * Using this section as an introduction to the methodology for cataloging operational mechanisms depending on cleartext traffic monitoring, with the various caveats on what will be considered (e.g., only mechanisms required heretofore for operability), and for describing the approach to seeking mitigations and/or substitutions. KM> Hmm, interesting point. I'll have to think about this more as it could be alot of work at this stage. AM> Unfortunately, we've already implemented many AD-level suggestions on the organization of Section 2. We're at the stage of *what can everybody live with", and re-re-re-org falls out now, IMO. Network service providers use various techniques to operate, manage, and secure their networks. The following subsections detail the purpose of each technique and which protocol fields are used to accomplish each task. In response to increased encryption of these fields, some network service providers may be tempted to undertake undesirable security practices in order to gain access to the fields in unencrypted data flows. To avoid this situation, ideally new methods could be developed to accomplish the same goals without service providers having the ability to see session data. BW> I think the above paragraph is the core point of the section; describing what the whole of section 2 is about. The previous paragraphs, while important information, don't seem to belong in this section. Perhaps a separate section focused on observed bad behavior would be better. KM> That would get at both your point and Kyle's, thanks. AM> I agree this last paragraph could be moved-up (after the definition of Network SP). The Snowden and EFF paragraphs would be best positioned as footnotes to the first sentence "Network service providers use various techniques ...", but we don't have that mechanism available. Also, the neutral exposition that we've been asked to provide a million times actually comes from multiple perspectives expressed in contributions that we would combine in a balanced way, without value judgements (no good or bad). Where we lack balance, we lack specific contributions. (So, I think the new -14 section 1.2 does not have an appropriate title.) heuristics grows, and accuracy suffers. For example, the traffic patterns between server and browser are dependent on browser supplier and version, even when the sessions use the same server application (e.g., web e-mail access). It remains to be seen whether more complex inferences can be mastered to produce the same monitoring accuracy. KR> This might be too formal of an approach for this doc, but it might be possible to construct a taxonomy of layers of metadata made unavailable by encryption at each layer to show the completeness/comprehensiveness of the survey. So, for instance: * Protocol and port number are still available as a way of characterizing traffic over the public internet even if the payload is encrypted, but this information is lost if (e.g.) the traffic is traversing an IPsec tunnel or if radically different kinds of traffic all use port 443/tcp without any other way to distinguish between them. * TCP is open to optimization/measurement even if using TLS, except when tunneled encrypted: congestion signals (like rexmits) previously transparent to the middlebox, for instance, are then lost. * Encrypting the payload defeats attempts to survey traffic by user agent (if there's no other way to distinguish, e.g., by fingerprinting). KM> I think this would be a really helpful follow on document. I'd be willing to work on it if you're game. I've been thining about something similar, specific to TLS, but should be broadened. It is important to note that the push for encryption by application providers has been motivated by the application of the described techniques. Some application providers have noted degraded performance and/or user experience when network-based optimization or enhancement of their traffic has occurred, and such cases may result in additional operator troubleshooting, as well. KR> Observation: additionally, I think you'll encounter the argument that the responsibility for diagnosing bad interactions between applications and networks falls on the application owner rather than the network operator. Basically, I feel like the desire among protocol designers is for operators to provide a pipe with certain key characteristics that interact well with established transport protocol mechanisms, and otherwise to leave the traffic alone and let the application developers do what they want to within the expected constraints. If that's infeasible (e.g., in edge cases, or with respect to new technologies that interact badly with existing transports, such as the loss=3Dcongestion assumption of TCP that interacts badly with wifi), that's precisely the case needs to be made by this document. KM> We have encountered this argument already. It's a tough one as SPs have the SLAs with customers, so they are the first call. Many don't know how to get in touch with APP providers. I understand the application developers perspecive, but also see that there has to be some ability to troubleshoot. Sure, providers could wrap the protocols for transport to provide some way of measuring, but information is lost. IPv6 with flow identifiers is another way to do it, but you might not be able to prioritize a call or protocol that has little tolerance for delay over one that does for instance. And I realize that app providers just want all traffic to have the same priority, but emergency calls are important. BW> I think the point made by the document is correct though: operators are nearly always the first call, not the application provider. KM> We were asked to remove text that said that. I agree that it is the case as the providers have the SLAs and you don't typlically have a number for App providers. BW> The operators are looking for ways to demonstrate that they did not cause the problem (or determine that they did) for efficient hand-off to the correct party for resolution. There are certainly problems an approach that changes the behavior of the protocol, but it's difficult to argue with the diagnostic need. AM> Using Netflix as an example, the first source of problem they mention is the network when addressing the question "Why doesn't Netflix work?": "If Netflix isn=E2=80=99t working, you may be experiencing a network connectivity issue, an issue with your device, or an issue with your Netflix app or account." from https://help.netflix.com/en/node/461?ui_action=3Dkb-article-popular-categor= ies They previously had even stronger wording, something like "First, make sure your network connection meets the Netflix requirements ... URL" One of the causes of re-buffering are CDN-related pauses when accessing the next segment: completely hidden from users so far. Additional frequent cause: the unlicensed WiFi network owned and operated by the customer. Another way to look at this strategy: App providers are transferring as much overhead cost to the network operators as possible (troubleshooting customer problems is expensive - rolling a truck negates months of revenue), while preserving as much value/control/revenue as they can for themselves. The greed-thingy plays poorly over time. A user-focused strategy would be to form partnerships for troubleshooting of shared customers, but that might result in exposing the real causes and some would rather hide for now, it seems. For example, browser fingerprints are comprised of many characteristics, including User Agent, HTTP Accept headers, browser plug-in details, screen size and color details, system fonts and time zone. A monitoring system could easily identify a specific browser, and by correlating other information, identify a specific user. KR> Subsections of 2.1 cover the following in what feels like arbitrary and inconsistent order: technique description, justification for the technique, reason why the technique is bad (for privacy), how the technique is defeated by protocol designers, and examples of the technique. It really reads like a laundry list rather than a systematic analysis of the problems faced, the metadata required for diagnostics, and how these techniques are defeated by encryption. KM> Hmm, this section was reorganized by others in the last IESG review, so that's probbaly part of the problem. I'll read through and see what I can do to help it out more. It cleared a discuss to make the changes. ** didn't tacle this one and will go back to it. AM> To re-iterate: this isn't the optimization phase. We've done 10 months of that. We've reached "what can you live with" phase, IMO. packet is able to provide stateless load balancing. This ability confers great reliability and scaleability advantages even if the flow remains in a single POP, because the load balancing system is not required to keep state of each flow. Even more importantly, there's no requirement to continuously synchronize such state among the pool of load balancers. KR> An important point is that an integrated load balancer repurposing limited existing bits in transport flow state must maintain and synchronize per-flow state occasionally: using the sequence number as a cookie only works for so long given that there aren't that many bits available to divide across a pool of machines. KM> I added in this point, but have to check back on flow of text. Current protocols, such as TCP, allow the development of stateless integrated load balancers by availing such load balancers of additional plain text information in client-to-server packets. In case of TCP, such information can be encoded by having server- generated sequence numbers (that are ACK'd by the client), segment values, lengths of the packet sent, etc. KR> Is it worth mentioning that the use of some of these mechanisms for load balancing negates some of the security assumptions associated with those primitives (e.g., that an off-path attacker guessing valid sequence numbers for a flow is hard)? KM> I added the above in as it may offer some balance to the discussion. KR> A dedicated mechanism for storing load balancer state, such as QUIC's proposed connection ID, is strictly better from the load balancer's point of view, and is probably even better from a privacy perspective than bolting it on to an unrelated transport signal because it can be tightly controlled by one of the endpoints and rotated to avoid roving client linkability: in other words, being a specific, separate signal, it can be governed in a way that is finely targeted at that specific use-case. (I'm thinking the advantages of separate mechanisms belongs in a different part of the doc; this section is more like the problem statement than the solution statement.) KM> This (above) needs to be reworded to be neutral and this does go towards solution space, which we were trying to avoid. How about: Another possibility is a dedicated mechanism for storing load balancer state, such as QUIC's proposed connection ID to provide visibility to the load balancer. An identifier could be used for tracking purposes, but this may provide an option that is an improvement from bolting it on to an unrelated transport signal. This method allows for tight control by one of the endpoints and can be rotated to avoid roving client linkability: in other words, being a specific, separate signal, it can be governed in a way that is finely targeted at that specific use-case. In future Network Function Virtualization (NFV) architectures, load balancing functions are likely to be more prevalent (deployed at locations throughout operators' networks)[. NFV environments will require some type of identifier (IPv6 flow identifiers, the Proposed QUIC connection ID, etc.) for managing] traffic using encrypted tunnels.[ The shift to increased encryption will have an impact to visibility of flow information and will require adjustments to perform similar load balancing functions within an NFV.] KR> I'm not sure what architecture this paragraph is discussing: are you talking about encrypted tunnels between NFV nodes? Is this something obvious to people involved in NFV? A diagram (or informational reference) would be helpeful to me here. KM> I see your point, the langauage here could be more clear. Do the above adjustments (ed: in []) help? 2.2.2. Differential Treatment based on Deep Packet Inspection (DPI) ... These effects and potential alternative solutions have been discussed at the accord BoF [ACCORD] at IETF95. KR> This section is labeled DPI, but really, the underlying issue is what you stated in the first paragraph: different kinds of traffic have different QoS needs, yet a network provider can't rely on a voluntary signal from an untrusted device to decide on QoS or every packet is simply going to be marked "high importance" and so we're back to treating all traffic equivalently. I'd argue against one of the memes I heard at the accord BoF, that it's down to latency vs. throughput, by pointing out that some applications (e.g., live video with low hand-wave latency) need both. Even after reading this, I'm still skeptical of the need for any more granularity than flow, and using AQM on a per-flow (e.g., 5-tuple) or flow-aggregate (some subset of the 5-tuple) to prevent an application or user from consuming resources unfairly. What, for instance, prevents a carrier from privileging VoIP traffic by looking at endpoints? Would there be a way for someone else to masquerade non-VoIP traffic as VoIP traffic given this kind of setup? This is the kind of question that I need answered by this doc. BW> It might be useful to note in this section that QUIC and H2 both combine multiple micro-flows, possibly of different types, within a single encrypted transport-layer flow. They share this with IPsec tunnels and the like. IOW, the increased use of encrypted aggregating encapsulation can hide even the the most basic representation of a flow from the differentiated service element. This same concern applies to load balancing elements discussed in section 2.2.1. KM> ** Want to talk with Al on this set of comments. AM> We were asked not to refer to QUIC, for various reasons (e.g., still under development). There will always be areas where network can make the best decision, because of the information available to the network operators (and the lack of that same info at end-points). When network resources are constrained, only the network can manage priorities. This has been organized according to applications that can be identified, but there can be other solutions requiring cooperation between user devices and the network according to subscription to a special service (QCI above). 2.2.3. Network Congestion Management For User Plane Congestion Management (3GPP UPCON) - ability to understand content and manage network during congestion. Mitigating techniques such as deferred download, off-peak acceleration, and outbound roamers. KR> This seems like a special case of 2.2.2. KM> Al - is there a reason this shouldn't get moved into AM> I think there is some text missing here. The text seems to have been one list item in old section 7.2, dating back to version 11. The list decription was: "7.2. Effect of Encrypted Transport Headers When the Transport Header is encrypted, it prevents the following mobile network features from operating: " I suggest to delete this text, but... Kathleen - if you delete this section, Please leave the section header marked "Blank - to be deleted" to keep the section numbering as-is, and the diffs/comments will still correlate easily. Thanks! 2.2.4. Performance-enhancing Proxies Due to the characteristics of the mobile link, performance-enhancing TCP proxies may perform local retransmission at the mobile edge. In TCP, duplicated ACKs are detected and potentially concealed when the proxy retransmits a segment that was lost on the mobile link without involvement of the far end (see section 2.1.1 of [RFC3135] and section 3.5 of [I-D.dolson-plus-middlebox-benefits]). BW> Starting the first paragraph in this way suggests that such use cases are for mobile links only, which is not correct. Performance enhancing proxies of this sort can be used on any long RTT path to improve performance over a constrained uplink. KM> How about: Performance-enhancing TCP proxies may perform local retransmission at the network edge, this also applies to mobile networks. This optimization at network edges measurably improves real-time transmission over long delay Internet paths or networks with large capacity-variation (such as mobile/cellular networks). AM> FYI - The folowing sentence was added here in the -14pre version I sent on Nov 19: However, such optimizations can also cause problems with performance, for example if the characteristics of some packet streams begin to vary significantly from those considered in the proxy design. This was intended to address one of Mark Nottingham's comments. An application-type-aware network edge (middlebox) can further control pacing, limit simultaneous HD videos, or prioritize active videos against new videos, etc. KR> Observation: This subsection provides the first really compelling argument I've seen for exposing flow metadata to the path. On long paths, physics gets in the way of tight control feedback loops. If nothing else, this should provide motivation for protocol designers and operators to break down the characteristics of different kinds of flows, determine where control points are needed in each of them, and figure out how to implement those. I think there is this conceit among protocol designers that quality problems can all be solved at the endpoints without any cooperation from path elements; the really killer arguments are examples of where that cannot possibly be the case. ECN is a great example of this, and is a signal explicitly targeted at middleboxes with opt-in by the endpoints: it allows a middlebox to report congestion without dropping packets, which produces measurably better QoS for the user. KM> Ack, thanks. You're not looking for additional text here, is that right? If so, what are you thinking should be added? Content replication in caches (for example live video, DRM protected content) is used to most efficiently utilize the available limited bandwidth and thereby maximize the user's Quality of Experience (QoE). Especially in mobile networks, duplicating every stream through the transit network increases backhaul cost for live TV. The Enhanced Multimedia Broadcast/Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate delivering same stream to different users, using either unicast or multicast depending on channel conditions to the user. KR> There are on-going efforts to support multicast inside carrier networks while preserving end-to-end security: AMT, for instance, allows CDNs to deliver a single (potentially encrypted) copy of a live stream to a carrier network over the public internet and for the carrier to then distribute that live stream as efficiently as possible within its own network using multicast. KM> Text added, thanks. Alternate approaches such as blind caches [I-D.thomson-http-bc] are being explored to allow caching of encrypted content; however, they still need to intercept the end-to-end transport connection. KM> [s/need to intercept the end-to-end transport connection/require cooperation between the content owners/CDNs and blind caches and fall outside the scope of what is covered in this document/ Content delegation solves a data visibility problem with the delegated cache, the impact remains for the use case where HTTPS encryption limits visibility to offload from congested links.] KR> This last point isn't strictly speaking true: many proposals (including I believe Martin's) require cooperation between content owners/CDNs and these blind caches. From Martin's draft: q( This document describes a method for conditionally delegating the hosting of secure content to the same server. This delegation allows a client to send a request for an "https" resource via a proxy rather than insisting on an end-to-end TLS connection. This enables shared caching for a limited set of "https" resources, as selected by the server. ) BW> I'm not sure that use cases where there is explicit cooperation between the content provider and the cache are necessarily relevant for this document, since in those cases the cache is an extension of the content provider (by some definition) and the cache will most likely not be inhibited by increased encryption. The more relevant caching case is one meant for network offload on the receiver side where there is no explicit cooperation between the content provider and the cache. That's the case where the use of HTTPS inhibits the cache's ability to offload from congested links. IOW, content delegation solves a data visibility problem with the delegated cache; it does not solve a problem introduced to the cache through the use of encryption. 2.2.6. Content Compression In addition to caching, various applications exist to provide data compression in order to conserve the life of the user's mobile data plan and optimize delivery over the mobile link. The compression proxy access can be built into a specific user level application, such as a browser, or it can be available to all applications using a system level application. The primary method is for the mobile application to connect to a centralized server as a proxy, with the data channel between the client application and the server using compression to minimize bandwidth utilization. The effectiveness of such systems depends on the server having access to unencrypted data flows. KR> Observation: given the side channels exposed by data compression that is blind to content, the inability to compress arbitrary payloads is likely to be regarded as a feature of encryption. (Though I recognize this is a catalog, not an endorsement.) Furthermore, in most cases eliminating compression is still 2-competitive with compression, so I'm not sure it's a really compelling use-case. BW> Per-object content compression might not be a compelling use case here. Aggregated data stream content compressions that spans objects and data sources is compelling, though. If there is a network element close to the receiver that sees all content destined for the receiver and can treat it all as part of a unified compression scheme (e.g., through the use of a shared segment store) will often be much more effective at providing data off-load. KM> Thanks, we'll add this text (modified) to make those helpful points clear. How about: Aggregated data stream content compression that spans objects and data sources that can be treated as part of a unified compression scheme (e.g., through the use of a shared segment store) is often effective at providing data offload when there is a network element close to the receiver that has access to see all the content. Another form of content filtering is called parental control, where some users are deliberately denied access to age-sensitive content as a feature to the service subscriber. Some sites involve a mixture of universal and age-sensitive content and filtering software. In these cases, more granular (application layer) metadata may be used to analyze and block traffic. Methods that accessed cleartext application-layer metadata no longer work when sessions are encrypted. This type of granular filtering could occur at the endpoint. However, the lack of ability to efficiently manage endpoints as a service reduces providers' ability to offer parental control. KR> It might be worth discussing the typical opt-in strategy for these things in the presence of TLS, adding a new intercept CA to willing clients, which has the downside that it potentially exposes every https connection to an active MitM. BW> +1 KM> OK, we hadn't done that before since the option doesn't change, but you make a good point, so I'll add in text. Thanks. I added the following: This method is also used by other types of network providers enabling traffic inspection, but not modification. Content filtering via a proxy can also utilize an intercepting certificate where the client's session is terminated at the proxy enabling for cleartext inspection of the traffic. A new session is created from the intercepting device to the client's destination, this is an opt-in strategy for the client. Changes t= o TLSv1.3 do not impact this more invasive method of interception, where this has the potential to expose every HTTPS session to an active man in the middle (MitM). KR> Random comment: especially with respect to government content filtering, I'm worried that the IETF's current approach of playing chicken with regulators on end-to-end encryption is going to result in normalization of intercept CAs, which will be strictly worse than a compromise solution in which a subset of traffic can be inspected (but not modified) with the user's knowledge and consent (e.g., distinct optics in the browser). I wouldn't like either outcome, frankly, but it would be nice if we had a game plan for what to do for user privacy if intercept CAs become a requirement for using the web in large parts of the world (something we might be one "crisis" away from), and an honest evaluation of the alternatives. Fundamentally, I don't like it when discussion gets shut down because people want to bury their heads in the sand in the name of ideology. BW> +1. I also note that this concern applies to some of the other performance related use cases too. KM> I think the real argument here is a control one between the application and management folks and not security/privacy even though that's what is often discussed. This is all about control. In addition, mobile network operator often sell tariffs that allow free-data access to certain sites, known as 'zero rating'. A session to visit such a site incurs no additional cost or data usage to the user. This feature is impacted if encryption hides the details of the content domain from the network. KR> There's the related issue that zero-rating by-implementation typically applies only to direct connections to a particular endpoint (e.g., by IP): if a user accidentally tunnels traffic from Spotify through a corporate VPN, that traffic won't be zero-rated, encrypted tunnel or not. (This goes back to the taxonomy of metadata layers comment I made near the top.) Carriers aren't going to trust e.g., a Host header for zero-rating, because that provides a simple way to tunnel traffic for free: consequently, determination of zero-rating will always involve some hard-to-impersonate credential, like an IP address or server certificate in the public trust web. KM> Not sure what to add here, any ideas, AL? When RTSP stream content is encrypted, the 5-tuple information within the payload is not visible to these ALG implementations, and therefore they cannot provision their associated middelboxes with that information. KR> I would argue that this is a protocol design issue. This was originally a problem with firewalls and NATs, with content inspection as a hack to work around the protocol/network impedance mismatch. I'm not the only one who would argue the right solution today is to design protocols to not require linkage across connections by middleboxes that do basic filtering. KM> I think we are in agreement here for solution direction, but the document specificly tries to avoid solutions. This example has been raised in the IESG by Warren and the apps side hadn't considered his view of it previously. It would be good for protocols to have these considerations in their designs, they were mostly thinking it didn't matter and were end-to-end. But poor video streaming sessions are an issue. Not sure we should add any text here??? 2.3.4. HTTP Header Insertion Some mobile carriers use HTTP header insertion (see section 3.2.1 of [RFC7230]) to provide information about their customers to third parties or to their own internal systems [Enrich]. Third parties use the inserted information for analytics, customization, advertising, to bill the customer, or to selectively allow or block content. HTTP header insertion is also used to pass information internally between a mobile service provider's sub-systems, thus keeping the internal systems loosely coupled. When HTTP connections are encrypted, mobile network service providers cannot insert headers to accomplish the functions above. KR> See my first comment re: compression. I'm dithering on how best to present these cases that are going to trigger some folks. ;-) KM> Yes, this one is a hot button. For the compression one, I clarified with added text and a use case that Brandon provided. 3.1. Management Access Security ... Application service providers, by their very nature, control the application endpoint. As such, much of the information gleaned from sessions are still available on that endpoint. However, when a gap exists in the application's logging and debugging capabilities, this has led the application service provider to access data-in-transport for monitoring and debugging. BW> How is DLP part of the management access discussion? It seems like a separate use case to me. The above two paragraphs seem out of place in this section. KM> Good point, I moved this to the SP Content monitoring of Applications subsection and added a bullet for DLP. Overlay networks (e.g. VXLAN, Geneve, etc.) may be used to indicate desired isolation, but this is not sufficient to prevent deliberate attacks that are aware of the use of the overlay network. It is possible to use an overlay header in combination with IPsec, but this adds the requirement for authentication infrastructure and may reduce packet transfer performance. Additional extension mechanisms to provide integrity and/or privacy protections are being investigated for overlay encapsulations. Section 7 of [RFC7348] describes some of the security issues possible when deploying VXLAN on Layer 2 networks. Rogue endpoints can join the multicast groups that carry broadcast traffic, for example. BW> I'm a little confused about the overall point of this section. I think that it might be "Hosted environment sometimes use content inspection to differentiate between management traffic and service traffic." but I don't think this point is very clearly stated. Or is there a different central point? KM> It was supposed to be management access, but text got added and the DLP doesn't fit, so that has been moved. I can reach out to Alia who contributed the VXLAN text to work that better into the intent of this section as I can see your point on lack of flow. Data center operators may also maintain packet recordings in order to be able to investigate attacks, breach of internal processes, etc. In some industries, organizations may be legally required to maintain such information for compliance purposes. Investigations of this KR> I think you'll get a "[citation needed]" from folks on the TLS mailing list. KM> I suspect this is one you have that recorded text, you have to maintain it for chain of custody with investigation handling. I'll have to figure out if there is anything that would require the capture, I suspect not, but could be wrong. 3.2. Hosted Applications Organizations are increasingly using hosted applications rather than in-house solutions that require maintenance of equipment and software. Examples include Enterprise Resource Planning (ERP) solutions, payroll service, time and attendance, travel and expense reporting among others. Organizations may require some level of management access to these hosted applications and will typically require session encryption or a dedicated channel for this activity. KR> I'm not sure how encryption of the management session is relevant to this doc. The way I've framed this document in my mind is "What information from flows is being used for network management by entities other than the endpoints, who have a need-to-know for the cleartext payload?", where "management" includes things like compliance and satisfying regulatory requirements. KM> Leaving as-is for now. While there is no impact since these sessions are already encrypted, it is one more connection point to using encryption successfully? Al? 3.2.2. Mail Service Providers ... STARTTLS ought have zero effect on anti-SPAM efforts for SMTP traffic. Anti-SPAM services could easily be performed on an SMTP gateway, eliminating the need for TLS decryption services. The impact to Anti-SPAM service providers should be limited to a change in tools, where middle boxes were deployed to perform these functions. KR> Here you're discussing a potential change to the operational technique, which doesn't match the rest of the subsections. KM> You're right. This text came in from Stephen when he was the sonsoring AD. The point is valid, but doen't fit exactly, but I'm hesitant to remove it. 3.3. Data Storage BW> I'm having trouble with the Data Storage section at large. For the most part, it seems to be describing use cases for the deployment of encryption, as opposed to things that people are doing today that would be harder if the network flows were encrypted. KM> Flow were encrypted in recent years per customer demand and the engineers worked to ensure monitoring was possible, improving logging, etc. I'll try to make that more clear in the introduction. This is a positive example, at least it was meant that way and for completeness. 3.3.1. Object-level Encryption KR> End-to-end or object encryption seems like a better description here: host-level encryption implies that anything on the originating or target host has access to it, when (for instance) it could be encrypted to a TPM resident key or an SGX enclave key. The distinguishing question seems to be "Do middleboxes/intermediate nodes have access to the cleartext?" KM> You're right. The term host-level is an internal one and shouldn't be in the document. I'll fix that, thanks. No, middleboxes don't have access in the EMC use cases at least. This is specific to object level encryption= . 3.3.1.1. Monitoring for Hosted Storage BW> This is one of the few subsections that seems to be describing an method in current use that will be made more difficult if all the data flows are encrypted. 3.3.2.1. Monitoring Session Flows for DAR Solutions Monitoring for transport of data to storage platforms, where object level encryption is performed close to or on the storage platform are similar to those described in the section on Monitoring for Hosted Storage. The primary difference for these solutions is the possible exposure of sensitive information, which could include privacy related data, financial information, or intellectual property if session encryption via TLS is not deployed. Session encryption is typically used with these solutions, but that decision would be based on a risk assessment. BW> What would be a monitoring use case in current use that will be made more difficult due to the increased use of encryption? The previous sentence seems to be suggesting that session encryption is already prevalent, so I would think that people deploying DAR solutions have already come up with different monitoring approaches. KM> The storage engineers improved monitoring capabilities through logging, etc. This was a requirement, so they made it happen with full agreement on direction. There are use cases where DAR or disk-level encryption is required. Examples include preventing exposure of data if physical disks are stolen or lost. KR> I don't see these last two sentences are relevant, as they have nothing to do with the network flows. KM> I'm happy to remove. DO they help a reader who is not familiar with the technology to understand the layers of encryption used at all or is it better to remove the sentence? In the case where TLS is in use, monitoring and the exposure of data is limited to a 5-tuple. KR> This is an example of implicit use of the taxonomy I referred to earlier. I feel like this should be used systematically throughout the survey (i.e., what metadata does your technique rely on, and why?). KM> That was the intent, but we didn't get that information from enough contributors. I provided the above in a very early draft. We'll have to go back through and see if that's possible at this point. I know it would be helpful. 3.3.3.1. Monitoring Of IPSec for Data Replication Services Monitoring for data replication services are described in this subsection. Monitoring of data flows between data centers may be performed for security and operational purposes and would typically concentrate more on operational aspects since these flows are essentially virtual private networks (VPN) between data centers. Operational considerations include capacity and availability monitoring. The security monitoring may be to detect anomalies in the data flows, similar to what was described in the "Monitoring for Hosted Storage Section". If IPsec tunnel mode is in use, monitoring is limited to a 2-tuple, or with transport mode, a 5-tuple. BW> What monitoring is done when encryption is not in use? Is there something being done that requires access to higher layer protocols? If this traffic is already most-often encrypted, then maybe the use case isn't relevant for this document. KM> It's just here for completeness Security monitoring in the enterprise may also be performed at the endpoint with numerous current solutions that mitigate the same problems as some of the above mentioned solutions. Since the software agents operate on the device, they are able to monitor traffic before it is encrypted, monitor for behavior changes, and lock down devices to use only the expected set of applications. Session encryption does not affect these solutions. Some might argue that scaling is an issue in the enterprise, but some large enterprises have used these tools effectively. KR> This is another example of mixing proposed solutions in among the problem statement. I would argue for a clear separation, which may mean that this document needs to have a single-minded focus on "here are the problems and here's how enterprises currently address them." BW> Also, enterprises increasingly allow BYOD programs for their employees, and such programs make it more difficult to ensure that adequate endpoint-based defenses are active. This is especially true when the area of risk in question is the above #5 "track misuse and abuse by employees". Note too that endpoint-based defenses can be less effective when the device is already compromised, in which case detection of the compromised device and effective remediation can be made more effective through the additional use of an on-path element. KM> [made some subsequent edits to this section] 4.1.3.2. TCP Pipelining/Session Multiplexing TCP Pipelining/Session Multiplexing used mainly by middle boxes today allow for multiple end user sessions to share the same TCP connection. [This rasises several points of interest with an increased use of encryption. TCP session multiplexing should still be possible when TLS or TCPcrypt is in use since the TCP header information is exposed leaving the 5-tuple accessible. The use TCP session multiplexing of an IP layer encyption, e.g. IPsec, that only exposes a 2-tuple would not be possible. Troubleshooting capabilities with encrypted sessions from the middlebox may limit troubleshooting to the use of logs from the end points performing the TCP multiplexing or from the middleboxes prior to any additional encryption that may be added to tunnel the TCP multiplexed traffic.] KM> I deleted the following, after adding in some of this content above where I think it makes more sense: [Today's network troubleshooter often relies upon session decryption to tell which packet belongs to which end user, since the logs are currently inadequate for the analysis performed.] KR> It's not clear to me how these two sentences are related. KM> Good point. I think deleting the second sentence is important as it's a general point and not specific to this section. E2E with FS should prevent the use of this multiplexing as I read it, so that is an impact that should be fine to document on it's own. [edits subsequently above; maybe best viewed from the etherpad] Increased use of HTTP/2 will likely further increase the prevalence of session multiplexing, both on the Internet and in the private data center.[ HTTP pipelining requires both the client and server to participate and visibilty of packets once encrypted will hide the use of HTTP pipelining for any monitoring that takes place outside of the endpoint or proxy solution. Visibility for middleboxes includes anything exposed by TLS and the 5-tuple. Note: left the text like this as SNI encryption will be optional, so it may also be exposed and this could vary by version used.] KR> And further complicate analysis of cleartext payloads from individual packets. 4.2. Techniques for Monitoring Internet Session Traffic ... (PII), or personal health information (PHI). Various techniques are used to intercept HTTP/TLS sessions for DLP and other purposes, and are described in "Summarizing Known Attacks on TLS and DTLS" [RFC7457]. Note: many corporate policies allow access to personal financial and other sites for users without interception. Another option is to terminate a TLS session prior to the point where monitoring is performed. KR> The last two sentences seem like a non-sequitur. KM> Leaving as-is for now. 5.4. Botnets Botnet detection and mitigation is complex and may involve hundreds or thousands of hosts with numerous Command and Control (C&C) servers. The techniques and data used to monitor and detect each may vary. Connections to C&C servers are typically encrypted, therefore a move to an increasingly encrypted Internet may not affect the detection and sharing methods used. KR> This is one of a general category of traffic that is intentionally protected from interference by the application. BW> For that reason, this one almost seems like a counter example ... botnets encrypt to evade many of the earlier described methods, therefore many of the earlier described methods are already inadequate. On the other hand, maybe the point is that increased use of encryption for botnet C&C demands new methods to handle many of the previously described use cases. KM> Well, from an incident investigation standpoint, many advanced operators have found detection methods that don't hinder their capabilities when traffic is encrypted. Maybe I need to make this text more clear as I think I may have written it, not positive. I think I'm going to leave the text alone as I think it reads as a positive example, one which techniques could be applied to other areas. The DoS section talks a little about use of fingerprinting traffic already, which is one common technique. 5.7. Further work Although incident response work will continue, new methods to prevent system compromise through security automation and continuous monitoring [SACM] may provide alternate approaches where system security is maintained as a preventative measure. KR> Not clear how the unknowns relate to the purpose of this document. Being sarcastic for a minute, I'm interpreting this as "Any cleartext metadata just *might* be used in the future for some kind of enterprise security monitoring!" KM> Hmm, it's meant to say endpoints (which you control) should be used and technology like what is expected out of SACM will help with automating this. We are open to text suggestions. 6.1. IP Flow Information Export ... The collection of IPFIX data itself, of course, provides a point of centralization for potentially business- and privacy-critical information. The IPFIX File Format specification [RFC5655] recommends encryption for this data at rest, and the IP Flow Anonymization specification [RFC6235] defines a metadata format for describing the anonymization functions applied to an IPFIX dataset, if anonymization is employed for data sharing of IPFIX information between enterprises or network operators. KR> I don't understand how IPFIX relates to the purpose of this document. Each of the IEs should be covered by one of the functional categories described earlier in the document. KM> Leaving as-is for now. Was added per Benoit and Brian Trammell for completeness on network management and encryption. 6.4. Content Length, BitRate and Pacing Although block ciphers utilise padding, this makes a negligible difference. Bitrate and pacing are generally application specific, and do not change much when the content is encrypted. Multiplexed formats (such as HTTP/2 and QUIC) may however incorporate several application streams over one connection, which makes the bitrate/pacing no longer application-specific. KR> Are the four items listed here all the application-level flow information available to the network for encrypted flows? I think I need some more comprehensive top-down analysis to be confident of that. It seems like this could be folded into the metadata taxonomy, if you decide to go that route. This section is also weird in that it doesn't describe a problem caused by encrypted flows. There's a lack of parallelism in structure between the other sections and this one. KM> Good point, but not my area and am open to suggestions. Is it just anothe example where things are ok when encrypted? I think a few of those are a good thing. 7. Impact on Mobility Network Optimizations and New Services This section considers the effects of transport level encryption on existing forms of mobile network optimization techniques, as well as potential new services. The material in this section assumes familiarity with mobile network concepts, specifications, and architectures. KR> Good warning, but the entire section is very specific to a particular set of technologies, while the rest of the document is much more general. This feels like a case of "writing to what you know", which is fine in principle, but it feels out of place in this document to use so much jargon and to discuss metrics in the context of a single technology when many of these KPIs have equivalents outside of 3GPP. c. Performance-enhancing proxy with low RTT determines the responsiveness of TCP flow control, and enables faster adaptation in a delay & capacity varying network due to user mobility. Low RTT permits use of a smaller send window, which makes the flow control loop more responsive to changing mobile network conditions. KR> Again, as with section 2.2.4, this section provides the clearest and most convincing arguments for the need for middlebox cooperation on flows. --001a11c14646a9c75305625e6ed9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brandon Williams and I reviewed this draft with Kathl= een and Al via the IETF etherpad during last call. The link is here:
https://etherpad.tools.ietf.org/p/krose-review-draft-mm-wg-e= ffect-encrypt-13

I have attempted to cull the discussion d= own to something consumable on the mailing list. Apologies in advance for f= ormatting issues. Note that I have not subsequently added any comments to t= he etherpad: I'll respond to this thread instead with any follow-ups.

=C2=A0=C2=A0 this mode is deployed.=C2=A0 IPsec with authenticati= on has many useful
=C2=A0=C2=A0 applications and usage has increased for= infrastructure applications
=C2=A0=C2=A0 such as for virtual private ne= tworks between data centers.

KR> The above paragraph doesn't = seem to have a clear point. It's mostly about opportunistic security, b= ut has a few unrelated points inserted (e.g., the final sentence about IPse= c with authentication).

KM> Looks like final sentence provides co= ntrast with the previous sentence
"OS has been implemented as NULL = Authentication with IPsec..."


=C2=A0=C2=A0 the application = user, and hosting service providers lease computing,
=C2=A0=C2=A0 storag= e, and communications systems in datacenters.=C2=A0 In practice,
=C2=A0= =C2=A0 many companies perform two or more service provider roles, but may b= e
=C2=A0=C2=A0 historically associated with one.

KR> Honestly,= all of section 1.1 seems to be a grab bag lacking a thesis, maybe motivati= ng the vague title "Additional Background". I think the informati= on there could be organized in a better way to answer the question posed in= the reader's mind after the introduction, which is: give me some examp= les of monitoring/manipulation for operability that have been defeated by e= ncryption, with evidence that they aren't solvable without additional t= elemetry or cooperation with middleboxes. The following section is closer t= o what I wanted after the intro.

KM> Initially, we had some examp= les in the draft, but were asked to remove them.=C2=A0 I take your point an= d am in process of reworking this text to make it more cohesive.=C2=A0 The = problem in much of this draft was the number of contributions, so your swee= p of the draft for points like this are very helpful.

AM> As I re= ad it, section 1.1 is describing changes to the communication landscape re:= encryption. The exception is the very last paragraph, which could be moved= above section 1.1. I agree that the purpose of section 1.1. could be made = more clear in the introductory paragraph. I do think that it's useful b= ackground to high-light these changes in the encryption landscape, since th= at's what motivates the draft.

KM> Thanks.=C2=A0 It is also t= o ensure the draft is not read as being just about TLS, so I am making that= point more clear as well.=C2=A0 Moving the last paragraph to the introduct= ion makes sense.


=C2=A0=C2=A0 Following the Snowden revelations,= application service providers
=C2=A0=C2=A0 responded by encrypting traf= fic between their data centers (IPsec) to
=C2=A0=C2=A0 prevent passive m= onitoring from taking place unbeknownst to them
=C2=A0=C2=A0 (Yahoo, Goo= gle, etc.).=C2=A0 Large mail service providers also began to

KR> = IIRC, companies were already doing this for infrastructure traffic on the p= ublic internet: it was their own private backbones on which they started us= ing encryption universally.

KM> Yes, good point.=C2=A0 I clarifie= d the text to distinguish that, but was careful not to say that they pretty= all infrastructure traffic over the Internet was encrypted even though I t= hink that's in line with reality - at least where I worked which includ= ed an ISP and a big financial data provider early on.

=C2=A0=C2=A0 T= he EFF reported [EFF2014] several network service providers taking
=C2= =A0=C2=A0 steps to prevent the use of SMTP over TLS by breaking STARTTLS
KR> I think it's important to use the phrase "downgrade at= tack" when describing something like this. The word "downgrade&qu= ot; first appears in the references list.

KM> Done, thanks.

=C2=A0=C2=A0 (section 3.2 of [RFC7525]), essentially preventing the n= egotiation
=C2=A0=C2=A0 process resulting in fallback to the use of clea= r text.=C2=A0 In other
=C2=A0=C2=A0 cases, some service providers have r= elied on middle boxes having
=C2=A0=C2=A0 access to clear text for the p= urposes of load balancing, monitoring
=C2=A0=C2=A0 for attack traffic, m= eeting regulatory requirements, or for other
=C2=A0=C2=A0 purposes.=C2= =A0 These middle box implementations, whether performing
=C2=A0=C2=A0 fu= nctions considered legitimate by the IETF or not, have been
=C2=A0=C2=A0= impacted by increases in encrypted traffic.=C2=A0 Only methods keeping
= =C2=A0=C2=A0 with the goal of balancing network management and PM mitigatio= n in
=C2=A0=C2=A0 [RFC7258] should be considered in solution work result= ing from this
=C2=A0=C2=A0 document.

KR> I feel like this sect= ion could be better organized by:
=C2=A0* Moving the examples to 1.1 as = a bulleted list of sample situations in which network operators attempted t= o and/or succeeded in defeating encryption to preserve existing operational= mechanisms, or in which performance suffered for users (whether of the enc= rypted flows or of other flows impacted by encrypted flows).

KM> = Interesting point, but we'd need more examples.=C2=A0 I'll think ab= out this more and chat with Al in case he has ideas.=C2=A0 For now, I went = with Brandon's easier suggestion, but moving to this would be nice for = the document readers.

AM> Although I see how these examples could= be part of the background, I think those who will
eventually remove the= ir objections will prefer the reduced emphasis on these examples where
t= hey are (in section 2). In one view, the entire memo is background, since n= othing new is proposed.

KR>
=C2=A0* Using this section as an i= ntroduction to the methodology for cataloging operational mechanisms depend= ing on cleartext traffic monitoring, with the various caveats on what will = be considered (e.g., only mechanisms required heretofore for operability), = and for describing the approach to seeking mitigations and/or substitutions= .

KM> Hmm, interesting point.=C2=A0 I'll have to think about = this more as it could be alot of work at this stage.

AM> Unfortun= ately, we've already implemented many AD-level suggestions on the organ= ization of Section 2.
We're at the stage of *what can everybody live= with", and re-re-re-org falls out now, IMO.


=C2=A0=C2=A0 N= etwork service providers use various techniques to operate, manage,
=C2= =A0=C2=A0 and secure their networks.=C2=A0 The following subsections detail= the
=C2=A0=C2=A0 purpose of each technique and which protocol fields ar= e used to
=C2=A0=C2=A0 accomplish each task.=C2=A0 In response to increa= sed encryption of these
=C2=A0=C2=A0 fields, some network service provid= ers may be tempted to undertake
=C2=A0=C2=A0 undesirable security practi= ces in order to gain access to the fields
=C2=A0=C2=A0 in unencrypted da= ta flows.=C2=A0 To avoid this situation, ideally new
=C2=A0=C2=A0 method= s could be developed to accomplish the same goals without
=C2=A0=C2=A0 s= ervice providers having the ability to see session data.

BW> I th= ink the above paragraph is the core point of the section; describing what t= he whole of section 2 is about.=C2=A0 The previous paragraphs, while import= ant information, don't seem to belong in this section. Perhaps a separa= te section focused on observed bad behavior would be better.

KM> = That would get at both your point and Kyle's, thanks.

AM> I a= gree this last paragraph could be moved-up (after the definition of Network= SP).
The Snowden and EFF paragraphs would be best positioned as footnot= es to the
first sentence "Network service providers use various tec= hniques ...", but we don't
have that mechanism available.
Also, the neutral exposition that we've been asked to provide a milli= on times actually
comes from multiple perspectives expressed in contribu= tions that we would combine
in a balanced way, without value judgements = (no good or bad).
Where we lack balance, we lack specific contributions.=

(So, I think the new -14 section 1.2 does not have an appropriate t= itle.)


=C2=A0=C2=A0 heuristics grows, and accuracy suffers.=C2= =A0 For example, the traffic
=C2=A0=C2=A0 patterns between server and br= owser are dependent on browser supplier
=C2=A0=C2=A0 and version, even w= hen the sessions use the same server application
=C2=A0=C2=A0 (e.g., web= e-mail access).=C2=A0 It remains to be seen whether more
=C2=A0=C2=A0 c= omplex inferences can be mastered to produce the same monitoring
=C2=A0= =C2=A0 accuracy.

KR> This might be too formal of an approach for = this doc, but it might be possible to construct a taxonomy of layers of met= adata made unavailable by encryption at each layer to show the completeness= /comprehensiveness of the survey. So, for instance:
=C2=A0* Protocol and= port number are still available as a way of characterizing traffic over th= e public internet even if the payload is encrypted, but this information is= lost if (e.g.) the traffic is traversing an IPsec tunnel or if radically d= ifferent kinds of traffic all use port 443/tcp without any other way to dis= tinguish between them.
=C2=A0* TCP is open to optimization/measurement e= ven if using TLS, except when tunneled encrypted: congestion signals (like = rexmits) previously transparent to the middlebox, for instance, are then lo= st.
=C2=A0* Encrypting the payload defeats attempts to survey traffic by= user agent (if there's no other way to distinguish, e.g., by fingerpri= nting).

KM> I think this would be a really helpful follow on docu= ment.=C2=A0 I'd be willing to work on it if you're game.=C2=A0 I= 9;ve been thining about something similar, specific to TLS, but should be b= roadened.


=C2=A0=C2=A0 It is important to note that the push for= encryption by application
=C2=A0=C2=A0 providers has been motivated by = the application of the described
=C2=A0=C2=A0 techniques.=C2=A0 Some app= lication providers have noted degraded
=C2=A0=C2=A0 performance and/or u= ser experience when network-based optimization or
=C2=A0=C2=A0 enhanceme= nt of their traffic has occurred, and such cases may result
=C2=A0=C2=A0= in additional operator troubleshooting, as well.

KR> Observation= : additionally, I think you'll encounter the argument that the responsi= bility for diagnosing bad interactions between applications and networks fa= lls on the application owner rather than the network operator. Basically, I= feel like the desire among protocol designers is for operators to provide = a pipe with certain key characteristics that interact well with established= transport protocol mechanisms, and otherwise to leave the traffic alone an= d let the application developers do what they want to within the expected c= onstraints. If that's infeasible (e.g., in edge cases, or with respect = to new technologies that interact badly with existing transports, such as t= he loss=3Dcongestion assumption of TCP that interacts badly with wifi), tha= t's precisely the case needs to be made by this document.

KM>= We have encountered this argument already.=C2=A0 It's a tough one as S= Ps have the SLAs with customers, so they are the first call.=C2=A0 Many don= 't know how to get in touch with APP providers.=C2=A0 I understand the = application developers perspecive, but also see that there has to be some a= bility to troubleshoot.=C2=A0 Sure, providers could wrap the protocols for = transport to provide some way of measuring, but information is lost.=C2=A0 = IPv6 with flow identifiers is another way to do it, but you might not be ab= le to prioritize a call or protocol that has little tolerance for delay ove= r one that does for instance.=C2=A0 And I realize that app providers just w= ant all traffic to have the same priority, but emergency calls are importan= t.

BW> I think the point made by the document is correct though: = operators are nearly always the first call, not the application provider.
KM> We were asked to remove text that said that.=C2=A0 I agree tha= t it is the case as the providers have the SLAs and you don't typlicall= y have a number for App providers.

BW> The operators are looking = for ways to demonstrate that they did not cause the problem (or determine t= hat they did) for efficient hand-off to the correct party for resolution. T= here are certainly problems an approach that changes the behavior of the pr= otocol, but it's difficult to argue with the diagnostic need.

AM= > Using Netflix as an example, the first source of problem they mention = is the network when
addressing the question "Why doesn't Netfli= x work?":
=C2=A0=C2=A0=C2=A0 "If Netflix isn=E2=80=99t working= , you may be experiencing a network connectivity issue, an issue with your = device, or an issue with your Netflix app or account."
=C2=A0=C2=A0= =C2=A0 from https://help.netflix.com/en/node/461?ui_action= =3Dkb-article-popular-categories
They previously had even stronger w= ording, something like "First, make sure your network connection meets= the Netflix requirements ... URL"
One of the causes of re-bufferin= g are CDN-related pauses when accessing the next segment:=C2=A0 completely = hidden from users so far.
Additional frequent cause: the unlicensed WiFi= network owned and operated by the customer.

Another way to look at = this strategy: App providers are transferring as much overhead cost to the = network operators as possible
(troubleshooting customer problems is expe= nsive - rolling a truck negates months of revenue), while preserving as
= much value/control/revenue as they can for themselves. The greed-thingy pla= ys poorly over time.
A user-focused strategy would be to form partnershi= ps for troubleshooting of shared customers, but that might result in exposi= ng
the real causes and some would rather hide for now, it seems.

=
=C2=A0=C2=A0 For example, browser fingerprints are comprised of many=C2=A0=C2=A0 characteristics, including User Agent, HTTP Accept headers, b= rowser
=C2=A0=C2=A0 plug-in details, screen size and color details, syst= em fonts and time
=C2=A0=C2=A0 zone.=C2=A0 A monitoring system could eas= ily identify a specific browser,
=C2=A0=C2=A0 and by correlating other i= nformation, identify a specific user.

KR> Subsections of 2.1 cove= r the following in what feels like arbitrary and inconsistent order: techni= que description, justification for the technique, reason why the technique = is bad (for privacy), how the technique is defeated by protocol designers, = and examples of the technique. It really reads like a laundry list rather t= han a systematic analysis of the problems faced, the metadata required for = diagnostics, and how these techniques are defeated by encryption.

KM= > Hmm, this section was reorganized by others in the last IESG review, s= o that's probbaly part of the problem.=C2=A0 I'll read through and = see what I can do to help it out more. It cleared a discuss to make the cha= nges.
** didn't tacle this one and will go back to it.

AM>= To re-iterate: this isn't the optimization phase. We've done 10 mo= nths of that.
We've reached "what can you live with" phase= , IMO.


=C2=A0=C2=A0 packet is able to provide stateless load bal= ancing.=C2=A0 This ability
=C2=A0=C2=A0 confers great reliability and sc= aleability advantages even if the
=C2=A0=C2=A0 flow remains in a single = POP, because the load balancing system is
=C2=A0=C2=A0 not required to k= eep state of each flow.=C2=A0 Even more importantly,
=C2=A0=C2=A0 there&= #39;s no requirement to continuously synchronize such state among
=C2=A0= =C2=A0 the pool of load balancers.

KR> An important point is that= an integrated load balancer repurposing limited existing bits in transport= flow state must maintain and synchronize per-flow state occasionally: usin= g the sequence number as a cookie only works for so long given that there a= ren't that many bits available to divide across a pool of machines.
=
KM> I added in this point, but have to check back on flow of text.

=C2=A0=C2=A0 Current protocols, such as TCP, allow the developmen= t of stateless
=C2=A0=C2=A0 integrated load balancers by availing such l= oad balancers of
=C2=A0=C2=A0 additional plain text information in clien= t-to-server packets.=C2=A0 In
=C2=A0=C2=A0 case of TCP, such information= can be encoded by having server-
=C2=A0=C2=A0 generated sequence number= s (that are ACK'd by the client), segment
=C2=A0=C2=A0 values, lengt= hs of the packet sent, etc.

KR> Is it worth mentioning that the u= se of some of these mechanisms for load balancing negates some of the secur= ity assumptions associated with those primitives (e.g., that an off-path at= tacker guessing valid sequence numbers for a flow is hard)?

KM> I= added the above in as it may offer some balance to the discussion.

= KR> A dedicated mechanism for storing load balancer state, such as QUIC&= #39;s proposed connection ID, is strictly better from the load balancer'= ;s point of view, and is probably even better from a privacy perspective th= an bolting it on to an unrelated transport signal because it can be tightly= controlled by one of the endpoints and rotated to avoid roving client link= ability: in other words, being a specific, separate signal, it can be gover= ned in a way that is finely targeted at that specific use-case. (I'm th= inking the advantages of separate mechanisms belongs in a different part of= the doc; this section is more like the problem statement than the solution= statement.)

KM> This (above) needs to be reworded to be neutral = and this does go towards solution space, which we were trying to avoid. How= about:

Another possibility is a dedicated mechanism for storing loa= d balancer state, such as QUIC's proposed connection ID to provide visi= bility to the load balancer.=C2=A0 An identifier could be used for tracking= purposes, but this may provide an option that is an improvement from=C2=A0= bolting it on to an unrelated transport signal. This method allows for tig= ht control by one of the endpoints and can be rotated to avoid roving clien= t linkability: in other words, being a specific, separate signal, it can be= governed in a way that is finely targeted at that specific use-case.

=C2=A0=C2=A0 In future Network Function Virtualization (NFV) architec= tures, load
=C2=A0=C2=A0 balancing functions are likely to be more preva= lent (deployed at
=C2=A0=C2=A0 locations throughout operators' netwo= rks)[.=C2=A0 NFV environments will
=C2=A0=C2=A0 require some type of ide= ntifier (IPv6 flow identifiers, the Proposed
=C2=A0=C2=A0=C2=A0 QUIC con= nection ID, etc.) for managing]
=C2=A0=C2=A0 traffic using encrypted tun= nels.[=C2=A0 The shift to increased encryption
=C2=A0=C2=A0 will have an= impact to visibility of flow information and will require
=C2=A0=C2=A0 = adjustments to perform similar load balancing functions within an NFV.]
=
KR> I'm not sure what architecture this paragraph is discussing:= are you talking about encrypted tunnels between NFV nodes? Is this somethi= ng obvious to people involved in NFV? A diagram (or informational reference= ) would be helpeful to me here.

KM> I see your point, the langaua= ge here could be more clear. Do the above adjustments (ed: in []) help?
=

2.2.2.=C2=A0 Differential Treatment based on Deep Packet Inspection= (DPI)
=C2=A0=C2=A0 ...
=C2=A0=C2=A0 These effects and potential alte= rnative solutions have been discussed
=C2=A0=C2=A0 at the accord BoF [AC= CORD] at IETF95.

KR> This section is labeled DPI, but really, the= underlying issue is what you stated in the first paragraph: different kind= s of traffic have different QoS needs, yet a network provider can't rel= y on a voluntary signal from an untrusted device to decide on QoS or every = packet is simply going to be marked "high importance" and so we&#= 39;re back to treating all traffic equivalently. I'd argue against one = of the memes I heard at the accord BoF, that it's down to latency vs. t= hroughput, by pointing out that some applications (e.g., live video with lo= w hand-wave latency) need both.

Even after reading this, I'm sti= ll skeptical of the need for any more granularity than flow, and using AQM = on a per-flow (e.g., 5-tuple) or flow-aggregate (some subset of the 5-tuple= ) to prevent an application or user from consuming resources unfairly. What= , for instance, prevents a carrier from privileging VoIP traffic by looking= at endpoints? Would there be a way for someone else to masquerade non-VoIP= traffic as VoIP traffic given this kind of setup? This is the kind of ques= tion that I need answered by this doc.

BW> It might be useful to = note in this section that QUIC and H2 both combine multiple micro-flows, po= ssibly of different types, within a single encrypted transport-layer flow. = They share this with IPsec tunnels and the like. IOW, the increased use of = encrypted aggregating encapsulation can hide even the the most basic repres= entation of a flow from the differentiated service element. This same conce= rn applies to load balancing elements discussed in section 2.2.1.

KM= > **=C2=A0 Want to talk with Al on this set of comments.

AM> W= e were asked not to refer to QUIC, for various reasons (e.g., still under d= evelopment).

There will always be areas where network can make the b= est decision, because of the
information available to the network operat= ors (and the lack of that same info at end-points).

When network res= ources are constrained, only the network can manage priorities.
This has= been organized according to applications that can be identified, but there=
can be other solutions requiring cooperation between user devices and t= he network
according to subscription to a special service (QCI above).

2.2.3.=C2=A0 Network Congestion Management

=C2=A0=C2=A0 Fo= r User Plane Congestion Management (3GPP UPCON) - ability to
=C2=A0=C2= =A0 understand content and manage network during congestion.=C2=A0 Mitigati= ng
=C2=A0=C2=A0 techniques such as deferred download, off-peak accelerat= ion, and
=C2=A0=C2=A0 outbound roamers.

KR> This seems like a = special case of 2.2.2.

KM> Al - is there a reason this shouldn= 9;t get moved into

AM> I think there is some text missing here.The text seems to have been one list item in old
section 7.2, dating b= ack to version 11.=C2=A0 The list decription was:

"7.2.=C2=A0 E= ffect of Encrypted Transport Headers

=C2=A0=C2=A0 When the Transport= Header is encrypted, it prevents the following
=C2=A0=C2=A0 mobile netw= ork features from operating:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <an= d then a list of many items> "

I suggest to delete this text= , but...

Kathleen - if you delete this section, Please leave the sec= tion header
marked "Blank - to be deleted" to keep the section= numbering as-is,
and the diffs/comments will still correlate easily.=C2= =A0 Thanks!


2.2.4.=C2=A0 Performance-enhancing Proxies

= =C2=A0=C2=A0 Due to the characteristics of the mobile link, performance-enh= ancing
=C2=A0=C2=A0 TCP proxies may perform local retransmission at the = mobile edge.=C2=A0 In
=C2=A0=C2=A0 TCP, duplicated ACKs are detected and= potentially concealed when the
=C2=A0=C2=A0 proxy retransmits a segment= that was lost on the mobile link without
=C2=A0=C2=A0 involvement of th= e far end (see section 2.1.1 of [RFC3135] and
=C2=A0=C2=A0 section 3.5 o= f [I-D.dolson-plus-middlebox-benefits]).

BW> Starting the first p= aragraph in this way suggests that such use cases are for mobile links only= , which is not correct. Performance enhancing proxies of this sort can be u= sed on any long RTT path to improve performance over a constrained uplink.<= br>
KM> How about:=C2=A0 Performance-enhancing TCP proxies may perfor= m local retransmission at the network edge, this also applies to mobile net= works.

=C2=A0=C2=A0 This optimization at network edges measurably im= proves real-time
=C2=A0=C2=A0 transmission over long delay Internet path= s or networks with large
=C2=A0=C2=A0 capacity-variation (such as mobile= /cellular networks).

AM> FYI -=C2=A0=C2=A0=C2=A0 The folowing sen= tence was added here in the -14pre version I sent on Nov 19:

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, such optimizations can also c= ause problems with performance,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 for example if the characteristics of some packet streams begin to vary=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 significantly from those con= sidered in the proxy design.

This was intended to address one of Mar= k Nottingham's comments.


=C2=A0=C2=A0 An application-type-aw= are network edge (middlebox) can further
=C2=A0=C2=A0 control pacing, li= mit simultaneous HD videos, or prioritize active
=C2=A0=C2=A0 videos aga= inst new videos, etc.

KR> Observation: This subsection provides t= he first really compelling argument I've seen for exposing flow metadat= a to the path. On long paths, physics gets in the way of tight control feed= back loops. If nothing else, this should provide motivation for protocol de= signers and operators to break down the characteristics of different kinds = of flows, determine where control points are needed in each of them, and fi= gure out how to implement those.

I think there is this conceit among= protocol designers that quality problems can all be solved at the endpoint= s without any cooperation from path elements; the really killer arguments a= re examples of where that cannot possibly be the case. ECN is a great examp= le of this, and is a signal explicitly targeted at middleboxes with opt-in = by the endpoints: it allows a middlebox to report congestion without droppi= ng packets, which produces measurably better QoS for the user.

KM>= ; Ack, thanks.=C2=A0 You're not looking for additional text here, is th= at right?=C2=A0 If so, what are you thinking should be added?


= =C2=A0=C2=A0 Content replication in caches (for example live video, DRM pro= tected
=C2=A0=C2=A0 content) is used to most efficiently utilize the ava= ilable limited
=C2=A0=C2=A0 bandwidth and thereby maximize the user'= s Quality of Experience
=C2=A0=C2=A0 (QoE).=C2=A0 Especially in mobile n= etworks, duplicating every stream
=C2=A0=C2=A0 through the transit netwo= rk increases backhaul cost for live TV.=C2=A0 The
=C2=A0=C2=A0 Enhanced = Multimedia Broadcast/Multicast Services (3GPP eMBMS) -
=C2=A0=C2=A0 trus= ted edge proxies facilitate delivering same stream to different
=C2=A0= =C2=A0 users, using either unicast or multicast depending on channel
=C2= =A0=C2=A0 conditions to the user.

KR> There are on-going efforts = to support multicast inside carrier networks while preserving end-to-end se= curity: AMT, for instance, allows CDNs to deliver a single (potentially enc= rypted) copy of a live stream to a carrier network over the public internet= and for the carrier to then distribute that live stream as efficiently as = possible within its own network using multicast.

KM> Text added, = thanks.


=C2=A0=C2=A0 Alternate approaches such as blind caches [= I-D.thomson-http-bc] are
=C2=A0=C2=A0 being explored to allow caching of= encrypted content; however, they
=C2=A0=C2=A0 still need to intercept t= he end-to-end transport connection.

KM> [s/need to intercept the = end-to-end transport connection/require cooperation between the content own= ers/CDNs and blind caches and fall outside the scope of what is covered in = this document/

Content delegation solves a data visibility problem w= ith the delegated cache, the impact remains for the use case where HTTPS en= cryption limits visibility to offload from congested links.]

KR> = This last point isn't strictly speaking true: many proposals (including= I believe Martin's) require cooperation between content owners/CDNs an= d these blind caches. From Martin's draft:
=C2=A0=C2=A0 q( This docu= ment describes a method for conditionally delegating the
=C2=A0=C2=A0 ho= sting of secure content to the same server.=C2=A0 This delegation allows=C2=A0=C2=A0 a client to send a request for an "https" resource = via a proxy rather
=C2=A0=C2=A0 than insisting on an end-to-end TLS conn= ection.=C2=A0 This enables shared
=C2=A0=C2=A0 caching for a limited set= of "https" resources, as selected by the
=C2=A0=C2=A0 server.= )

BW> I'm not sure that use cases where there is explicit co= operation between the content provider and the cache are necessarily releva= nt for this document, since in those cases the cache is an extension of the= content provider (by some definition) and the cache will most likely not b= e inhibited by increased encryption. The more relevant caching case is one = meant for network offload on the receiver side where there is no explicit c= ooperation between the content provider and the cache. That's the case = where the use of HTTPS inhibits the cache's ability to offload from con= gested links. IOW, content delegation solves a data visibility problem with= the delegated cache; it does not solve a problem introduced to the cache t= hrough the use of encryption.


2.2.6.=C2=A0 Content Compression
=C2=A0=C2=A0 In addition to caching, various applications exist to pr= ovide data
=C2=A0=C2=A0 compression in order to conserve the life of the= user's mobile data
=C2=A0=C2=A0 plan and optimize delivery over the= mobile link.=C2=A0 The compression
=C2=A0=C2=A0 proxy access can be bui= lt into a specific user level application,
=C2=A0=C2=A0 such as a browse= r, or it can be available to all applications using a
=C2=A0=C2=A0 syste= m level application.=C2=A0 The primary method is for the mobile
=C2=A0= =C2=A0 application to connect to a centralized server as a proxy, with the<= br>=C2=A0=C2=A0 data channel between the client application and the server = using
=C2=A0=C2=A0 compression to minimize bandwidth utilization.=C2=A0 = The effectiveness of
=C2=A0=C2=A0 such systems depends on the server hav= ing access to unencrypted data
=C2=A0=C2=A0 flows.

KR> Observa= tion: given the side channels exposed by data compression that is blind to = content, the inability to compress arbitrary payloads is likely to be regar= ded as a feature of encryption. (Though I recognize this is a catalog, not = an endorsement.) Furthermore, in most cases eliminating compression is stil= l 2-competitive with compression, so I'm not sure it's a really com= pelling use-case.

BW> Per-object content compression might not be= a compelling use case here. Aggregated data stream content compressions th= at spans objects and data sources is compelling, though. If there is a netw= ork element close to the receiver that sees all content destined for the re= ceiver and can treat it all as part of a unified compression scheme (e.g., = through the use of a shared segment store) will often be much more effectiv= e at providing data off-load.

KM> Thanks, we'll add this text= (modified) to make those helpful points clear.

How about:
=C2=A0= =C2=A0=C2=A0 Aggregated data stream content compression that spans objects = and data sources that can be treated as part of a unified compression schem= e (e.g., through the use of a shared segment store) is often effective at p= roviding data offload when there is a network element close to the receiver= that has access to see all the content.


=C2=A0=C2=A0 Another fo= rm of content filtering is called parental control, where
=C2=A0=C2=A0 s= ome users are deliberately denied access to age-sensitive content as
=C2= =A0=C2=A0 a feature to the service subscriber.=C2=A0 Some sites involve a m= ixture of
=C2=A0=C2=A0 universal and age-sensitive content and filtering= software.=C2=A0 In these
=C2=A0=C2=A0 cases, more granular (application= layer) metadata may be used to
=C2=A0=C2=A0 analyze and block traffic.= =C2=A0 Methods that accessed cleartext
=C2=A0=C2=A0 application-layer me= tadata no longer work when sessions are
=C2=A0=C2=A0 encrypted.=C2=A0 Th= is type of granular filtering could occur at the
=C2=A0=C2=A0 endpoint.= =C2=A0 However, the lack of ability to efficiently manage
=C2=A0=C2=A0 e= ndpoints as a service reduces providers' ability to offer parental
= =C2=A0=C2=A0 control.

KR> It might be worth discussing the typica= l opt-in strategy for these things in the presence of TLS, adding a new int= ercept CA to willing clients, which has the downside that it potentially ex= poses every https connection to an active MitM.

BW> +1

KM&= gt; OK, we hadn't done that before since the option doesn't change,= but you make a good point, so I'll add in text.=C2=A0 Thanks.

I= added the following:

=C2=A0=C2=A0=C2=A0 This method is also used by= other types of network providers enabling
=C2=A0=C2=A0=C2=A0=C2=A0 traf= fic inspection, but not modification.</t>

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <t>Content fil= tering via a proxy can also utilize an intercepting
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 certificate where the client's ses= sion is terminated at the proxy
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 enabling for cleartext inspection of the traffic.=C2=A0 A n= ew session
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is cre= ated from the intercepting device to the client's
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 destination, this is an opt-in strateg= y for the client. Changes to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 TLSv1.3 do not impact this more invasive method of interceptio= n, where
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this has= the potential to expose every HTTPS session to an active
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 man in the middle (MitM). </t= >

KR> Random comment: especially with respect to government co= ntent filtering, I'm worried that the IETF's current approach of pl= aying chicken with regulators on end-to-end encryption is going to result i= n normalization of intercept CAs, which will be strictly worse than a compr= omise solution in which a subset of traffic can be inspected (but not modif= ied) with the user's knowledge and consent (e.g., distinct optics in th= e browser). I wouldn't like either outcome, frankly, but it would be ni= ce if we had a game plan for what to do for user privacy if intercept CAs b= ecome a requirement for using the web in large parts of the world (somethin= g we might be one "crisis" away from), and an honest evaluation o= f the alternatives. Fundamentally, I don't like it when discussion gets= shut down because people want to bury their heads in the sand in the name = of ideology.</rant>

BW> +1. I also note that this concern a= pplies to some of the other performance related use cases too.

KM>= ; I think the real argument here is a control one between the application a= nd management folks and not security/privacy even though that's what is= often discussed.=C2=A0 This is all about control.


=C2=A0=C2=A0 = In addition, mobile network operator often sell tariffs that allow
=C2= =A0=C2=A0 free-data access to certain sites, known as 'zero rating'= .=C2=A0 A session
=C2=A0=C2=A0 to visit such a site incurs no additional= cost or data usage to the
=C2=A0=C2=A0 user.=C2=A0 This feature is impa= cted if encryption hides the details of
=C2=A0=C2=A0 the content domain = from the network.

KR> There's the related issue that zero-rat= ing by-implementation typically applies only to direct connections to a par= ticular endpoint (e.g., by IP): if a user accidentally tunnels traffic from= Spotify through a corporate VPN, that traffic won't be zero-rated, enc= rypted tunnel or not. (This goes back to the taxonomy of metadata layers co= mment I made near the top.) Carriers aren't going to trust e.g., a Host= header for zero-rating, because that provides a simple way to tunnel traff= ic for free: consequently, determination of zero-rating will always involve= some hard-to-impersonate credential, like an IP address or server certific= ate in the public trust web.

KM> Not sure what to add here, any i= deas, AL?


=C2=A0=C2=A0 When RTSP stream content is encrypted, th= e 5-tuple information within
=C2=A0=C2=A0 the payload is not visible to = these ALG implementations, and
=C2=A0=C2=A0 therefore they cannot provis= ion their associated middelboxes with
=C2=A0=C2=A0 that information.
=
KR> I would argue that this is a protocol design issue. This was ori= ginally a problem with firewalls and NATs, with content inspection as a hac= k to work around the protocol/network impedance mismatch. I'm not the o= nly one who would argue the right solution today is to design protocols to = not require linkage across connections by middleboxes that do basic filteri= ng.

KM> I think we are in agreement here for solution direction, = but the document specificly tries to avoid solutions.=C2=A0 This example ha= s been raised in the IESG by Warren and the apps side hadn't considered= his view of it previously.=C2=A0 It would be good for protocols to have th= ese considerations in their designs, they were mostly thinking it didn'= t matter and were end-to-end.=C2=A0 But poor video streaming sessions are a= n issue.=C2=A0 Not sure we should add any text here???


2.3.4.=C2= =A0 HTTP Header Insertion

=C2=A0=C2=A0 Some mobile carriers use HTTP= header insertion (see section 3.2.1 of
=C2=A0=C2=A0 [RFC7230]) to provi= de information about their customers to third
=C2=A0=C2=A0 parties or to= their own internal systems [Enrich].=C2=A0 Third parties use
=C2=A0=C2= =A0 the inserted information for analytics, customization, advertising,
= =C2=A0=C2=A0 to bill the customer, or to selectively allow or block content= .=C2=A0 HTTP
=C2=A0=C2=A0 header insertion is also used to pass informat= ion internally between
=C2=A0=C2=A0 a mobile service provider's sub-= systems, thus keeping the internal
=C2=A0=C2=A0 systems loosely coupled.= =C2=A0 When HTTP connections are encrypted, mobile
=C2=A0=C2=A0 network = service providers cannot insert headers to accomplish the
=C2=A0=C2=A0 f= unctions above.

KR> See my first comment re: compression. I'm= dithering on how best to present these cases that are going to trigger som= e folks. ;-)

KM> Yes, this one is a hot button.=C2=A0 For the com= pression one, I clarified with added text and a use case that Brandon provi= ded.


3.1.=C2=A0 Management Access Security
=C2=A0=C2=A0 ...=C2=A0=C2=A0 Application service providers, by their very nature, control= the
=C2=A0=C2=A0 application endpoint.=C2=A0 As such, much of the infor= mation gleaned from
=C2=A0=C2=A0 sessions are still available on that en= dpoint.=C2=A0 However, when a gap
=C2=A0=C2=A0 exists in the application= 's logging and debugging capabilities, this
=C2=A0=C2=A0 has led the= application service provider to access data-in-transport
=C2=A0=C2=A0 f= or monitoring and debugging.

BW> How is DLP part of the managemen= t access discussion? It seems like a separate use case to me. The above two= paragraphs seem out of place in this section.

KM> Good point, I = moved this to the SP Content monitoring of Applications subsection and adde= d a bullet for DLP.


=C2=A0=C2=A0 Overlay networks (e.g.=C2=A0 VX= LAN, Geneve, etc.) may be used to indicate
=C2=A0=C2=A0 desired isolatio= n, but this is not sufficient to prevent deliberate
=C2=A0=C2=A0 attacks= that are aware of the use of the overlay network.=C2=A0 It is
=C2=A0=C2= =A0 possible to use an overlay header in combination with IPsec, but this=C2=A0=C2=A0 adds the requirement for authentication infrastructure and m= ay reduce
=C2=A0=C2=A0 packet transfer performance.=C2=A0 Additional ext= ension mechanisms to
=C2=A0=C2=A0 provide integrity and/or privacy prote= ctions are being investigated
=C2=A0=C2=A0 for overlay encapsulations.= =C2=A0 Section 7 of [RFC7348] describes some of
=C2=A0=C2=A0 the securit= y issues possible when deploying VXLAN on Layer 2
=C2=A0=C2=A0 networks.= =C2=A0 Rogue endpoints can join the multicast groups that carry
=C2=A0= =C2=A0 broadcast traffic, for example.

BW> I'm a little confu= sed about the overall point of this section. I think that it might be "= ;Hosted environment sometimes use content inspection to differentiate betwe= en management traffic and service traffic." but I don't think this= point is very clearly stated. Or is there a different central point?
KM> It was supposed to be management access, but text got added and th= e DLP doesn't fit, so that has been moved.=C2=A0 I can reach out to Ali= a who contributed the VXLAN text to work that better into the intent of thi= s section as I can see your point on lack of flow.


=C2=A0=C2=A0 = Data center operators may also maintain packet recordings in order to
= =C2=A0=C2=A0 be able to investigate attacks, breach of internal processes, = etc.
=C2=A0=C2=A0 In some industries, organizations may be legally requi= red to maintain
=C2=A0=C2=A0 such information for compliance purposes.= =C2=A0 Investigations of this

KR> I think you'll get a "= [citation needed]" from folks on the TLS mailing list.

KM> I= suspect this is one you have that recorded text, you have to maintain it f= or chain of custody with investigation handling.=C2=A0 I'll have to fig= ure out if there is anything that would require the capture, I suspect not,= but could be wrong.


3.2.=C2=A0 Hosted Applications

=C2= =A0=C2=A0 Organizations are increasingly using hosted applications rather t= han
=C2=A0=C2=A0 in-house solutions that require maintenance of equipmen= t and
=C2=A0=C2=A0 software.=C2=A0 Examples include Enterprise Resource = Planning (ERP)
=C2=A0=C2=A0 solutions, payroll service, time and attenda= nce, travel and expense
=C2=A0=C2=A0 reporting among others.=C2=A0 Organ= izations may require some level of
=C2=A0=C2=A0 management access to the= se hosted applications and will typically
=C2=A0=C2=A0 require session e= ncryption or a dedicated channel for this activity.

KR> I'm n= ot sure how encryption of the management session is relevant to this doc. T= he way I've framed this document in my mind is "What information f= rom flows is being used for network management by entities other than the e= ndpoints, who have a need-to-know for the cleartext payload?", where &= quot;management" includes things like compliance and satisfying regula= tory requirements.

KM> Leaving as-is for now.=C2=A0 While there i= s no impact since these sessions are already encrypted, it is one more conn= ection point to using encryption successfully?
Al?


3.2.2.=C2= =A0 Mail Service Providers
=C2=A0=C2=A0 ...
=C2=A0=C2=A0 STARTTLS oug= ht have zero effect on anti-SPAM efforts for SMTP
=C2=A0=C2=A0 traffic.= =C2=A0 Anti-SPAM services could easily be performed on an SMTP
=C2=A0=C2= =A0 gateway, eliminating the need for TLS decryption services.=C2=A0 The=C2=A0=C2=A0 impact to Anti-SPAM service providers should be limited to a = change
=C2=A0=C2=A0 in tools, where middle boxes were deployed to perfor= m these
=C2=A0=C2=A0 functions.

KR> Here you're discussing= a potential change to the operational technique, which doesn't match t= he rest of the subsections.

KM> You're right.=C2=A0 This text= came in from Stephen when he was the sonsoring AD.=C2=A0 The point is vali= d, but doen't fit exactly, but I'm hesitant to remove it.

3.3.=C2=A0 Data Storage

BW> I'm having trouble with the Dat= a Storage section at large. For the most part, it seems to be describing us= e cases for the deployment of encryption, as opposed to things that people = are doing today that would be harder if the network flows were encrypted.
KM> Flow were encrypted in recent years per customer demand and th= e engineers worked to ensure monitoring was possible, improving logging, et= c.=C2=A0 I'll try to make that more clear in the introduction.=C2=A0 Th= is is a positive example, at least it was meant that way and for completene= ss.


3.3.1.=C2=A0 Object-level Encryption

KR> End-to-en= d or object encryption seems like a better description here: host-level enc= ryption implies that anything on the originating or target host has access = to it, when (for instance) it could be encrypted to a TPM resident key or a= n SGX enclave key. The distinguishing question seems to be "Do middleb= oxes/intermediate nodes have access to the cleartext?"

KM> Y= ou're right.=C2=A0 The term host-level is an internal one and shouldn&#= 39;t be in the document.=C2=A0 I'll fix that, thanks.=C2=A0 No, middleb= oxes don't have access in the EMC use cases at least.=C2=A0 This is spe= cific to object level encryption.


3.3.1.1.=C2=A0 Monitoring for = Hosted Storage

BW> This is one of the few subsections that seems = to be describing an method in current use that will be made more difficult = if all the data flows are encrypted.


3.3.2.1.=C2=A0 Monitoring S= ession Flows for DAR Solutions

=C2=A0=C2=A0 Monitoring for transport= of data to storage platforms, where object
=C2=A0=C2=A0 level encryptio= n is performed close to or on the storage platform are
=C2=A0=C2=A0 simi= lar to those described in the section on Monitoring for Hosted
=C2=A0=C2= =A0 Storage.=C2=A0 The primary difference for these solutions is the possib= le
=C2=A0=C2=A0 exposure of sensitive information, which could include p= rivacy
=C2=A0=C2=A0 related data, financial information, or intellectual= property if
=C2=A0=C2=A0 session encryption via TLS is not deployed.=C2= =A0 Session encryption is
=C2=A0=C2=A0 typically used with these solutio= ns, but that decision would be based
=C2=A0=C2=A0 on a risk assessment.<= br>
BW> What would be a monitoring use case in current use that will = be made more difficult due to the increased use of encryption? The previous= sentence seems to be suggesting that session encryption is already prevale= nt, so I would think that people deploying DAR solutions have already come = up with different monitoring approaches.

KM> The storage engineer= s improved monitoring capabilities through logging, etc.=C2=A0 This was a r= equirement, so they made it happen with full agreement on direction.

=C2=A0=C2=A0 There are use cases where DAR or disk-level
=C2=A0=C2= =A0 encryption is required.=C2=A0 Examples include preventing exposure of d= ata
=C2=A0=C2=A0 if physical disks are stolen or lost.

KR> I d= on't see these last two sentences are relevant, as they have nothing to= do with the network flows.

KM> I'm happy to remove.=C2=A0 DO= they help a reader who is not familiar with the technology to understand t= he layers of encryption used at all or is it better to remove the sentence?=


=C2=A0=C2=A0 In the case where TLS is in
=C2=A0=C2=A0 use, m= onitoring and the exposure of data is limited to a 5-tuple.

KR> T= his is an example of implicit use of the taxonomy I referred to earlier. I = feel like this should be used systematically throughout the survey (i.e., w= hat metadata does your technique rely on, and why?).

KM> That was= the intent, but we didn't get that information from enough contributor= s.=C2=A0 I provided the above in a very early draft.=C2=A0 We'll have t= o go back through and see if that's possible at this point.=C2=A0 I kno= w it would be helpful.


3.3.3.1.=C2=A0 Monitoring Of IPSec for Da= ta Replication Services

=C2=A0=C2=A0 Monitoring for data replication= services are described in this
=C2=A0=C2=A0 subsection.

=C2=A0= =C2=A0 Monitoring of data flows between data centers may be performed for=C2=A0=C2=A0 security and operational purposes and would typically concen= trate
=C2=A0=C2=A0 more on operational aspects since these flows are ess= entially virtual
=C2=A0=C2=A0 private networks (VPN) between data center= s.=C2=A0 Operational
=C2=A0=C2=A0 considerations include capacity and av= ailability monitoring.=C2=A0 The
=C2=A0=C2=A0 security monitoring may be= to detect anomalies in the data flows,
=C2=A0=C2=A0 similar to what was= described in the "Monitoring for Hosted Storage
=C2=A0=C2=A0 Secti= on".=C2=A0 If IPsec tunnel mode is in use, monitoring is limited to a<= br>=C2=A0=C2=A0 2-tuple, or with transport mode, a 5-tuple.

BW> W= hat monitoring is done when encryption is not in use? Is there something be= ing done that requires access to higher layer protocols? If this traffic is= already most-often encrypted, then maybe the use case isn't relevant f= or this document.

KM> It's just here for completeness

= =C2=A0=C2=A0 Security monitoring in the enterprise may also be performed at= the
=C2=A0=C2=A0 endpoint with numerous current solutions that mitigate= the same
=C2=A0=C2=A0 problems as some of the above mentioned solutions= .=C2=A0 Since the
=C2=A0=C2=A0 software agents operate on the device, th= ey are able to monitor
=C2=A0=C2=A0 traffic before it is encrypted, moni= tor for behavior changes, and
=C2=A0=C2=A0 lock down devices to use only= the expected set of applications.
=C2=A0=C2=A0 Session encryption does = not affect these solutions.=C2=A0 Some might argue
=C2=A0=C2=A0 that sca= ling is an issue in the enterprise, but some large
=C2=A0=C2=A0 enterpri= ses have used these tools effectively.

KR> This is another exampl= e of mixing proposed solutions in among the problem statement. I would argu= e for a clear separation, which may mean that this document needs to have a= single-minded focus on "here are the problems and here's how ente= rprises currently address them."

BW> Also, enterprises incre= asingly allow BYOD programs for their employees, and such programs make it = more difficult to ensure that adequate endpoint-based defenses are active. = This is especially true when the area of risk in question is the above #5 &= quot;track misuse and abuse by employees". Note too that endpoint-base= d defenses can be less effective when the device is already compromised, in= which case detection of the compromised device and effective remediation c= an be made more effective through the additional use of an on-path element.=

KM> [made some subsequent edits to this section]


4.1.= 3.2.=C2=A0 TCP Pipelining/Session Multiplexing

=C2=A0=C2=A0 TCP Pipe= lining/Session Multiplexing used mainly by middle boxes today
=C2=A0=C2= =A0 allow for multiple end user sessions to share the same TCP
=C2=A0=C2= =A0 connection. [This rasises several points of interest with an
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 increased use = of encryption.=C2=A0 TCP session multiplexing should still
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be possible when TLS= or TCPcrypt is in use since the TCP header
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information is exposed leaving the = 5-tuple accessible.=C2=A0 The use
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TCP session multiplexing of an IP layer ency= ption, e.g. IPsec,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 that only exposes a 2-tuple would not be possible.=C2=A0 Tr= oubleshooting
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 capabilities with encrypted sessions from the middlebox may limit=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 trou= bleshooting to the use of logs from the end points performing
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the TCP multiplex= ing or from the middleboxes prior to any
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 additional encryption that may be adde= d to tunnel the TCP multiplexed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 traffic.]
=C2=A0=C2=A0 KM> I deleted the = following, after adding in some of this content above where I think it make= s more sense:
=C2=A0=C2=A0 [Today's network troubleshooter often rel= ies upon session
=C2=A0=C2=A0 decryption to tell which packet belongs to= which end user, since the
=C2=A0=C2=A0 logs are currently inadequate fo= r the analysis performed.]

KR> It's not clear to me how these= two sentences are related.

KM> Good point.=C2=A0 I think deletin= g the second sentence is important as it's a general point and not spec= ific to this section.=C2=A0 E2E with FS should prevent the use of this mult= iplexing as I read it, so that is an impact that should be fine to document= on it's own. [edits subsequently above; maybe best viewed from the eth= erpad]


=C2=A0=C2=A0 Increased use of HTTP/2 will likely further = increase the prevalence
=C2=A0=C2=A0 of session multiplexing, both on th= e Internet and in the private data
=C2=A0=C2=A0 center.[=C2=A0 HTTP pipe= lining requires both the client and server to participate
=C2=A0=C2=A0 a= nd visibilty of packets once encrypted will hide the use of HTTP pipelining= for any monitoring that takes place outside of the endpoint or proxy solut= ion.=C2=A0 Visibility for middleboxes includes anything exposed by TLS and = the 5-tuple.
=C2=A0=C2=A0 Note: left the text like this as SNI encryptio= n will be optional, so it may also be exposed and this could vary by versio= n used.]

KR> And further complicate analysis of cleartext payload= s from individual packets.


4.2.=C2=A0 Techniques for Monitoring = Internet Session Traffic
=C2=A0=C2=A0 ...
=C2=A0=C2=A0 (PII), or pers= onal health information (PHI).=C2=A0 Various techniques are
=C2=A0=C2=A0= used to intercept HTTP/TLS sessions for DLP and other purposes, and
=C2= =A0=C2=A0 are described in "Summarizing Known Attacks on TLS and DTLS&= quot;
=C2=A0=C2=A0 [RFC7457].=C2=A0 Note: many corporate policies allow = access to personal
=C2=A0=C2=A0 financial and other sites for users with= out interception.=C2=A0 Another
=C2=A0=C2=A0 option is to terminate a TL= S session prior to the point where
=C2=A0=C2=A0 monitoring is performed.=

KR> The last two sentences seem like a non-sequitur.

KM&g= t; Leaving as-is for now.


5.4.=C2=A0 Botnets

=C2=A0=C2=A0= Botnet detection and mitigation is complex and may involve hundreds
=C2= =A0=C2=A0 or thousands of hosts with numerous Command and Control (C&C)=
=C2=A0=C2=A0 servers.=C2=A0 The techniques and data used to monitor and= detect each may
=C2=A0=C2=A0 vary.=C2=A0 Connections to C&C servers= are typically encrypted, therefore
=C2=A0=C2=A0 a move to an increasing= ly encrypted Internet may not affect the
=C2=A0=C2=A0 detection and shar= ing methods used.

KR> This is one of a general category of traffi= c that is intentionally protected from interference by the application.
=
BW> For that reason, this one almost seems like a counter example ..= . botnets encrypt to evade many of the earlier described methods, therefore= many of the earlier described methods are already inadequate. On the other= hand, maybe the point is that increased use of encryption for botnet C&= ;C demands new methods to handle many of the previously described use cases= .

KM> Well, from an incident investigation standpoint, many advan= ced operators have found detection methods that don't hinder their capa= bilities when traffic is encrypted.=C2=A0 Maybe I need to make this text mo= re clear as I think I may have written it, not positive.

I think I&#= 39;m going to leave the text alone as I think it reads as a positive exampl= e, one which techniques could be applied to other areas.=C2=A0 The DoS sect= ion talks a little about use of fingerprinting traffic already, which is on= e common technique.


5.7.=C2=A0 Further work

=C2=A0=C2=A0 = Although incident response work will continue, new methods to prevent
= =C2=A0=C2=A0 system compromise through security automation and continuous=C2=A0=C2=A0 monitoring [SACM] may provide alternate approaches where sys= tem
=C2=A0=C2=A0 security is maintained as a preventative measure.
KR> Not clear how the unknowns relate to the purpose of this document.= Being sarcastic for a minute, I'm interpreting this as "Any clear= text metadata just *might* be used in the future for some kind of enterpris= e security monitoring!"

KM> Hmm, it's meant to say endpo= ints (which you control) should be used and technology like what is expecte= d out of SACM will help with automating this.=C2=A0 We are open to text sug= gestions.


6.1.=C2=A0 IP Flow Information Export
=C2=A0=C2=A0 = ...
=C2=A0=C2=A0 The collection of IPFIX data itself, of course, provide= s a point of
=C2=A0=C2=A0 centralization for potentially business- and p= rivacy-critical
=C2=A0=C2=A0 information.=C2=A0 The IPFIX File Format sp= ecification [RFC5655]
=C2=A0=C2=A0 recommends encryption for this data a= t rest, and the IP Flow
=C2=A0=C2=A0 Anonymization specification [RFC623= 5] defines a metadata format for
=C2=A0=C2=A0 describing the anonymizati= on functions applied to an IPFIX dataset,
=C2=A0=C2=A0 if anonymization = is employed for data sharing of IPFIX information
=C2=A0=C2=A0 between e= nterprises or network operators.

KR> I don't understand how I= PFIX relates to the purpose of this document. Each of the IEs should be cov= ered by one of the functional categories described earlier in the document.=

KM> Leaving as-is for now.=C2=A0 Was added per Benoit and Brian = Trammell for completeness on network management and encryption.


= 6.4.=C2=A0 Content Length, BitRate and Pacing

=C2=A0=C2=A0 Although = block ciphers utilise padding, this makes a
=C2=A0=C2=A0 negligible diff= erence.=C2=A0 Bitrate and pacing are generally application
=C2=A0=C2=A0 = specific, and do not change much when the content is encrypted.
=C2=A0= =C2=A0 Multiplexed formats (such as HTTP/2 and QUIC) may however incorporat= e
=C2=A0=C2=A0 several application streams over one connection, which ma= kes the
=C2=A0=C2=A0 bitrate/pacing no longer application-specific.
<= br>KR> Are the four items listed here all the application-level flow inf= ormation available to the network for encrypted flows? I think I need some = more comprehensive top-down analysis to be confident of that. It seems like= this could be folded into the metadata taxonomy, if you decide to go that = route.

This section is also weird in that it doesn't describe a = problem caused by encrypted flows. There's a lack of parallelism in str= ucture between the other sections and this one.

KM> Good point, b= ut not my area and am open to suggestions.=C2=A0 Is it just anothe example = where things are ok when encrypted?=C2=A0 I think a few of those are a good= thing.


7.=C2=A0 Impact on Mobility Network Optimizations and Ne= w Services

=C2=A0=C2=A0 This section considers the effects of transp= ort level encryption on
=C2=A0=C2=A0 existing forms of mobile network op= timization techniques, as well as
=C2=A0=C2=A0 potential new services.= =C2=A0 The material in this section assumes
=C2=A0=C2=A0 familiarity wit= h mobile network concepts, specifications, and
=C2=A0=C2=A0 architecture= s.

KR> Good warning, but the entire section is very specific to a= particular set of technologies, while the rest of the document is much mor= e general. This feels like a case of "writing to what you know", = which is fine in principle, but it feels out of place in this document to u= se so much jargon and to discuss metrics in the context of a single technol= ogy when many of these KPIs have equivalents outside of 3GPP.


= =C2=A0=C2=A0 c.=C2=A0 Performance-enhancing proxy with low RTT determines t= he
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 responsiveness of TCP flow contr= ol, and enables faster adaptation
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i= n a delay & capacity varying network due to user mobility.=C2=A0 Low=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RTT permits use of a smaller send win= dow, which makes the flow
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 control l= oop more responsive to changing mobile network
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 conditions.

KR> Again, as with section 2.2.4, this s= ection provides the clearest and most convincing arguments for the need for= middlebox cooperation on flows.

--001a11c14646a9c75305625e6ed9-- From nobody Wed Jan 10 09:46:28 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883C112DA4E for ; Wed, 10 Jan 2018 09:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 MKYg0ymN6C-r for ; Wed, 10 Jan 2018 09:46:22 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 2CB9412D890 for ; Wed, 10 Jan 2018 09:46:22 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id b76so11078166qkc.1 for ; Wed, 10 Jan 2018 09:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=JNZfIn29doVyDt8rz3GWWJn9iK1BLEP3qnDkka+XChE=; b=fb3j/Q5sSTD2qo6SGlRq7bU9zUJJLcl/NKTqzETfGI/7YsNbQh7TXk4Xj11CC/pKXu kwISP2+8wJu7mh3D0cE24w2c97EWJmwOTAXW8slzLyDA119Jukcti3lcbGQ86AZ/uMN+ 6lPMzF+JMlZmqZ2BqnPoBLpivj0L7l7vftB9I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=JNZfIn29doVyDt8rz3GWWJn9iK1BLEP3qnDkka+XChE=; b=SFhVLzVD9fzqt8HHmvFleZ/WwfD/mQGE3r8mptTFPzMgGUh9Ar5aN4ZQLl2rmk/JHB JPJz45Ki2eN4Bywxzt1YbftEam/TOEYokvIWyrpfSMrAXnT0O9fcSXoQgvHv13a2XHC+ QFXK1lM33adpcdaoXHHf1iQn5tOL889aCuX+BUEzJ/Wtyxj0oede2UiCp9AcJjegTii9 G2iFlM5kFn0+vs55+WIdA31OwBwu1Jq6Oqrz6vwF1WCdlkAYwqTtJsRvpaDrmiTrrbxW uxA5YdK7oCsfJBi45Udl3MnZiDcrD8c14ukuhV2gm3cG2+AoW2NpAe0dwvo6fO23QXqA 84Yw== X-Gm-Message-State: AKwxytdsYVPZV6opQzGek4w1vMCZKIZUih0np+6NpBjCF3uSX1Is7xgU ptYEyYOs9EYWMUmz6PRfiG1t61Q8uOm2VUjyItNu5A== X-Google-Smtp-Source: ACJfBov/Y4DzDMa/r5jxdWCq5g50LtKxM8UuxkyQDqJthB5mazW95av7cMJoIDNJ83UiLkkFNgF5hz/1F27FSw8fCTM= X-Received: by 10.200.39.167 with SMTP id w36mr28004992qtw.206.1515606380626; Wed, 10 Jan 2018 09:46:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.160.129 with HTTP; Wed, 10 Jan 2018 09:46:19 -0800 (PST) X-Originating-IP: [2001:4878:a000:3000:7144:b146:6dc:2a74] In-Reply-To: References: From: Kyle Rose Date: Wed, 10 Jan 2018 12:46:19 -0500 Message-ID: To: ietf@ietf.org, Kathleen Moriarty , "MORTON, ALFRED C (AL)" , Brandon Williams , Warren Kumari , Paul Hoffman , opsawg@ietf.org Content-Type: multipart/alternative; boundary="001a1135ac76efd8ad05626f9bd4" Archived-At: Subject: Re: [OPSAWG] draft-mm-wg-effect-encrypt-13 review X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 17:46:28 -0000 --001a1135ac76efd8ad05626f9bd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would put each of my comments in the etherpad into one of three buckets: observations and commentary, minor points and clarifications, and points that I think require more discussion. I'm only really going to address the last bucket: the others I raised but don't feel particularly strongly about, at least at this late stage in the document's life. (section 3.2 of [RFC7525]), essentially preventing the negotiation > process resulting in fallback to the use of clear text. In other > cases, some service providers have relied on middle boxes having > access to clear text for the purposes of load balancing, monitoring > for attack traffic, meeting regulatory requirements, or for other > purposes. These middle box implementations, whether performing > functions considered legitimate by the IETF or not, have been > impacted by increases in encrypted traffic. Only methods keeping > with the goal of balancing network management and PM mitigation in > [RFC7258] should be considered in solution work resulting from this > document. > > KR> I feel like this section could be better organized by: > * Moving the examples to 1.1 as a bulleted list of sample situations in > which network operators attempted to and/or succeeded in defeating > encryption to preserve existing operational mechanisms, or in which > performance suffered for users (whether of the encrypted flows or of othe= r > flows impacted by encrypted flows). > > KM> Interesting point, but we'd need more examples. I'll think about thi= s > more and chat with Al in case he has ideas. For now, I went with Brandon= 's > easier suggestion, but moving to this would be nice for the document > readers. > > AM> Although I see how these examples could be part of the background, I > think those who will > eventually remove their objections will prefer the reduced emphasis on > these examples where > they are (in section 2). In one view, the entire memo is background, sinc= e > nothing new is proposed. > > KR> > * Using this section as an introduction to the methodology for catalogin= g > operational mechanisms depending on cleartext traffic monitoring, with th= e > various caveats on what will be considered (e.g., only mechanisms require= d > heretofore for operability), and for describing the approach to seeking > mitigations and/or substitutions. > > KM> Hmm, interesting point. I'll have to think about this more as it > could be alot of work at this stage. > > AM> Unfortunately, we've already implemented many AD-level suggestions on > the organization of Section 2. > We're at the stage of *what can everybody live with", and re-re-re-org > falls out now, IMO. > This is a reasonable objection, but I am mostly concerned about satisfying the target audience. ISTM that audience is something like "IETF participants who are skeptical about, or ignorant of, the operational difficulties posed by widespread encryption of flows". If the document meets your goals as-is, then further refinement is unnecessary. Does it? Or is it impossible to know at this point? > AM> Also, the neutral exposition that we've been asked to provide a > million times actually > comes from multiple perspectives expressed in contributions that we would > combine > in a balanced way, without value judgements (no good or bad). > Where we lack balance, we lack specific contributions. > "Neutral" meaning "without advocacy"? It's a fine line. The document still has a thesis, which (if I am reading it correctly) is to inform the community of current operational practices that are encumbered in some way by encryption. To wit, q( It provides network operators' perspectives about the motivations and objectives of those practices as well as effects anticipated by operators as use of encryption increases. ) Without that thesis, which some might interpret as advocacy, it's not clear the document would have enough focus to be useful. I'd like folks to see this doc as *at worst* devil's advocacy, and preferably as a challenge to come up with better arguments and to find alternative methods for dealing with network management problems. > > heuristics grows, and accuracy suffers. For example, the traffic > patterns between server and browser are dependent on browser supplier > and version, even when the sessions use the same server application > (e.g., web e-mail access). It remains to be seen whether more > complex inferences can be mastered to produce the same monitoring > accuracy. > > KR> This might be too formal of an approach for this doc, but it might be > possible to construct a taxonomy of layers of metadata made unavailable b= y > encryption at each layer to show the completeness/comprehensiveness of th= e > survey. So, for instance: > * Protocol and port number are still available as a way of characterizin= g > traffic over the public internet even if the payload is encrypted, but th= is > information is lost if (e.g.) the traffic is traversing an IPsec tunnel o= r > if radically different kinds of traffic all use port 443/tcp without any > other way to distinguish between them. > * TCP is open to optimization/measurement even if using TLS, except when > tunneled encrypted: congestion signals (like rexmits) previously > transparent to the middlebox, for instance, are then lost. > * Encrypting the payload defeats attempts to survey traffic by user agen= t > (if there's no other way to distinguish, e.g., by fingerprinting). > > KM> I think this would be a really helpful follow on document. I'd be > willing to work on it if you're game. I've been thining about something > similar, specific to TLS, but should be broadened. > I'm afraid this topic might be more of a research project than it initially appears, but it's probably a reasonable exercise to see what we can produce for a plaintext protocol vs. that same protocol over TLS. Ping me. > It is important to note that the push for encryption by application > providers has been motivated by the application of the described > techniques. Some application providers have noted degraded > performance and/or user experience when network-based optimization or > enhancement of their traffic has occurred, and such cases may result > in additional operator troubleshooting, as well. > > KR> Observation: additionally, I think you'll encounter the argument that > the responsibility for diagnosing bad interactions between applications a= nd > networks falls on the application owner rather than the network operator. > Basically, I feel like the desire among protocol designers is for operato= rs > to provide a pipe with certain key characteristics that interact well wit= h > established transport protocol mechanisms, and otherwise to leave the > traffic alone and let the application developers do what they want to > within the expected constraints. If that's infeasible (e.g., in edge case= s, > or with respect to new technologies that interact badly with existing > transports, such as the loss=3Dcongestion assumption of TCP that interact= s > badly with wifi), that's precisely the case needs to be made by this > document. > > KM> We have encountered this argument already. It's a tough one as SPs > have the SLAs with customers, so they are the first call. Many don't kno= w > how to get in touch with APP providers. I understand the application > developers perspecive, but also see that there has to be some ability to > troubleshoot. Sure, providers could wrap the protocols for transport to > provide some way of measuring, but information is lost. IPv6 with flow > identifiers is another way to do it, but you might not be able to > prioritize a call or protocol that has little tolerance for delay over on= e > that does for instance. And I realize that app providers just want all > traffic to have the same priority, but emergency calls are important. > > BW> I think the point made by the document is correct though: operators > are nearly always the first call, not the application provider. > > KM> We were asked to remove text that said that. I agree that it is the > case as the providers have the SLAs and you don't typlically have a numbe= r > for App providers. > > BW> The operators are looking for ways to demonstrate that they did not > cause the problem (or determine that they did) for efficient hand-off to > the correct party for resolution. There are certainly problems an approac= h > that changes the behavior of the protocol, but it's difficult to argue wi= th > the diagnostic need. > > AM> Using Netflix as an example, the first source of problem they mention > is the network when > addressing the question "Why doesn't Netflix work?": > "If Netflix isn=E2=80=99t working, you may be experiencing a network > connectivity issue, an issue with your device, or an issue with your > Netflix app or account." > from https://help.netflix.com/en/node/461?ui_action=3Dkb-article- > popular-categories > They previously had even stronger wording, something like "First, make > sure your network connection meets the Netflix requirements ... URL" > One of the causes of re-buffering are CDN-related pauses when accessing > the next segment: completely hidden from users so far. > Additional frequent cause: the unlicensed WiFi network owned and operated > by the customer. > > Another way to look at this strategy: App providers are transferring as > much overhead cost to the network operators as possible > (troubleshooting customer problems is expensive - rolling a truck negates > months of revenue), while preserving as > much value/control/revenue as they can for themselves. The greed-thingy > plays poorly over time. > A user-focused strategy would be to form partnerships for troubleshooting > of shared customers, but that might result in exposing > the real causes and some would rather hide for now, it seems. > I agree with all the points you've made. How do we square reality (users blame network operators) with the current approach to protocol design at the IETF (keep the network dumb)? I feel like creating a conversation about this apparent cognitive dissonance will be one of the most important outcomes of publishing this document. I have no doubt the conflict will resolve itself somehow: CDNs, for instance, act as an intelligent overlay over dumb networks and can therefore provide the most consistent user experience when deeply deployed into carrier networks the structure of which they have intimate knowledge. Is the right solution to continue to effectively delegate this responsibility by encouraging breaking of connections at the edge, or should the IETF be trying to optimize the end-to-end performance of its protocols on the public internet? Anyway, I digress. This isn't a conversation I'm proposing you have in this document; just that the doc should raise these kinds of questions in the reader. packet is able to provide stateless load balancing. This ability > confers great reliability and scaleability advantages even if the > flow remains in a single POP, because the load balancing system is > not required to keep state of each flow. Even more importantly, > there's no requirement to continuously synchronize such state among > the pool of load balancers. > > KR> An important point is that an integrated load balancer repurposing > limited existing bits in transport flow state must maintain and synchroni= ze > per-flow state occasionally: using the sequence number as a cookie only > works for so long given that there aren't that many bits available to > divide across a pool of machines. > > KM> I added in this point, but have to check back on flow of text. > I checked the wording in -14.I'm going to propose slightly different language: q( This ability confers great reliability and scalability advantages even if the flow remains in a single POP, because the load balancing system is not required to keep state of each flow. There is value even when the repurposed bits are strictly insufficient for encoding all state: an integrated load balancer repurposing limited existing bits in transport flow state must still maintain and synchronize per-flow state occasionally (using the sequence number as a cookie only works for so long given that there aren't that many bits available to divide across a pool of machines), but there is no longer a requirement for such synchronization to be continuous or instantaneous. ) KR> A dedicated mechanism for storing load balancer state, such as QUIC's > proposed connection ID, is strictly better from the load balancer's point > of view, and is probably even better from a privacy perspective than > bolting it on to an unrelated transport signal because it can be tightly > controlled by one of the endpoints and rotated to avoid roving client > linkability: in other words, being a specific, separate signal, it can be > governed in a way that is finely targeted at that specific use-case. (I'm > thinking the advantages of separate mechanisms belongs in a different par= t > of the doc; this section is more like the problem statement than the > solution statement.) > > KM> This (above) needs to be reworded to be neutral and this does go > towards solution space, which we were trying to avoid. How about: > > Another possibility is a dedicated mechanism for storing load balancer > state, such as QUIC's proposed connection ID to provide visibility to the > load balancer. An identifier could be used for tracking purposes, but th= is > may provide an option that is an improvement from bolting it on to an > unrelated transport signal. This method allows for tight control by one o= f > the endpoints and can be rotated to avoid roving client linkability: in > other words, being a specific, separate signal, it can be governed in a w= ay > that is finely targeted at that specific use-case. > SGTM. Maybe s/improvement from bolting it on to/improvement compared to co-opting/. In future Network Function Virtualization (NFV) architectures, load > balancing functions are likely to be more prevalent (deployed at > locations throughout operators' networks)[. NFV environments will > require some type of identifier (IPv6 flow identifiers, the Proposed > QUIC connection ID, etc.) for managing] > traffic using encrypted tunnels.[ The shift to increased encryption > will have an impact to visibility of flow information and will require > adjustments to perform similar load balancing functions within an NFV.= ] > > KR> I'm not sure what architecture this paragraph is discussing: are you > talking about encrypted tunnels between NFV nodes? Is this something > obvious to people involved in NFV? A diagram (or informational reference) > would be helpeful to me here. > > KM> I see your point, the langauage here could be more clear. Do the abov= e > adjustments (ed: in []) help? > I am still a little confused. Is the idea that load balancing in NFV environments has a unique need for stateless (or reduced-state) load balancing that other applications don't have? I'm having a hard time wrapping my head around why that would be the case. Or is the point here just to highlight NFV as just another use case to consider? > 2.2.2. Differential Treatment based on Deep Packet Inspection (DPI) > ... > These effects and potential alternative solutions have been discussed > at the accord BoF [ACCORD] at IETF95. > > KR> This section is labeled DPI, but really, the underlying issue is what > you stated in the first paragraph: different kinds of traffic have > different QoS needs, yet a network provider can't rely on a voluntary > signal from an untrusted device to decide on QoS or every packet is simpl= y > going to be marked "high importance" and so we're back to treating all > traffic equivalently. I'd argue against one of the memes I heard at the > accord BoF, that it's down to latency vs. throughput, by pointing out tha= t > some applications (e.g., live video with low hand-wave latency) need both= . > > Even after reading this, I'm still skeptical of the need for any more > granularity than flow, and using AQM on a per-flow (e.g., 5-tuple) or > flow-aggregate (some subset of the 5-tuple) to prevent an application or > user from consuming resources unfairly. What, for instance, prevents a > carrier from privileging VoIP traffic by looking at endpoints? Would ther= e > be a way for someone else to masquerade non-VoIP traffic as VoIP traffic > given this kind of setup? This is the kind of question that I need answer= ed > by this doc. > > BW> It might be useful to note in this section that QUIC and H2 both > combine multiple micro-flows, possibly of different types, within a singl= e > encrypted transport-layer flow. They share this with IPsec tunnels and th= e > like. IOW, the increased use of encrypted aggregating encapsulation can > hide even the the most basic representation of a flow from the > differentiated service element. This same concern applies to load balanci= ng > elements discussed in section 2.2.1. > Good point: an example of this is sending both Youtube and search responses over the same QUIC or H2 connection, with no way for the network to throttle one without throttling the other. AM> We were asked not to refer to QUIC, for various reasons (e.g., still > under development). > > There will always be areas where network can make the best decision, > because of the > information available to the network operators (and the lack of that same > info at end-points). > > When network resources are constrained, only the network can manage > priorities. > This has been organized according to applications that can be identified, > but there > can be other solutions requiring cooperation between user devices and the > network > according to subscription to a special service (QCI above). > Got it. Is DPI the right framing for this, or is something more generic (e.g., "content-aware traffic management") what is really required? E.g., the network doesn't necessarily need to know which video you're watching, only that it is video, and maybe what the available bitrates are and associated quality. > An application-type-aware network edge (middlebox) can further > control pacing, limit simultaneous HD videos, or prioritize active > videos against new videos, etc. > > KR> Observation: This subsection provides the first really compelling > argument I've seen for exposing flow metadata to the path. On long paths, > physics gets in the way of tight control feedback loops. If nothing else, > this should provide motivation for protocol designers and operators to > break down the characteristics of different kinds of flows, determine whe= re > control points are needed in each of them, and figure out how to implemen= t > those. > > I think there is this conceit among protocol designers that quality > problems can all be solved at the endpoints without any cooperation from > path elements; the really killer arguments are examples of where that > cannot possibly be the case. ECN is a great example of this, and is a > signal explicitly targeted at middleboxes with opt-in by the endpoints: i= t > allows a middlebox to report congestion without dropping packets, which > produces measurably better QoS for the user. > > KM> Ack, thanks. You're not looking for additional text here, is that > right? If so, what are you thinking should be added? > No, just an observation that this was one of the more thought-provoking sections of the doc for me. > Alternate approaches such as blind caches [I-D.thomson-http-bc] are > being explored to allow caching of encrypted content; however, they > still need to intercept the end-to-end transport connection. > > KM> [s/need to intercept the end-to-end transport connection/require > cooperation between the content owners/CDNs and blind caches and fall > outside the scope of what is covered in this document/ > SGTM. > 2.2.6. Content Compression > > In addition to caching, various applications exist to provide data > compression in order to conserve the life of the user's mobile data > plan and optimize delivery over the mobile link. The compression > proxy access can be built into a specific user level application, > such as a browser, or it can be available to all applications using a > system level application. The primary method is for the mobile > application to connect to a centralized server as a proxy, with the > data channel between the client application and the server using > compression to minimize bandwidth utilization. The effectiveness of > such systems depends on the server having access to unencrypted data > flows. > > KR> Observation: given the side channels exposed by data compression that > is blind to content, the inability to compress arbitrary payloads is like= ly > to be regarded as a feature of encryption. (Though I recognize this is a > catalog, not an endorsement.) Furthermore, in most cases eliminating > compression is still 2-competitive with compression, so I'm not sure it's= a > really compelling use-case. > > BW> Per-object content compression might not be a compelling use case > here. Aggregated data stream content compressions that spans objects and > data sources is compelling, though. If there is a network element close t= o > the receiver that sees all content destined for the receiver and can trea= t > it all as part of a unified compression scheme (e.g., through the use of = a > shared segment store) will often be much more effective at providing data > off-load. > > KM> Thanks, we'll add this text (modified) to make those helpful points > clear. > > How about: > Aggregated data stream content compression that spans objects and dat= a > sources that can be treated as part of a unified compression scheme (e.g.= , > through the use of a shared segment store) is often effective at providin= g > data offload when there is a network element close to the receiver that h= as > access to see all the content. > Sounds good. This is general enough to cover the case of networks with limited uplinks wanting to cache content that is conceptually shared (e.g., VOD) but delivered independently to end users via individual TLS connections. > KR> It might be worth discussing the typical opt-in strategy for these > things in the presence of TLS, adding a new intercept CA to willing > clients, which has the downside that it potentially exposes every https > connection to an active MitM. > > BW> +1 > > KM> OK, we hadn't done that before since the option doesn't change, but > you make a good point, so I'll add in text. Thanks. > > I added the following: > > This method is also used by other types of network providers enabling > traffic inspection, but not modification. > > Content filtering via a proxy can also utilize an > intercepting > certificate where the client's session is terminated at the pro= xy > enabling for cleartext inspection of the traffic. A new sessio= n > is created from the intercepting device to the client's > destination, this is an opt-in strategy for the client. Changes > to > TLSv1.3 do not impact this more invasive method of interception= , > where > this has the potential to expose every HTTPS session to an acti= ve > man in the middle (MitM). > Mostly sounds good. Is there a reason to mention TLS 1.3 specifically here? > KR> Random comment: especially with respect to government content > filtering, I'm worried that the IETF's current approach of playing chicke= n > with regulators on end-to-end encryption is going to result in > normalization of intercept CAs, which will be strictly worse than a > compromise solution in which a subset of traffic can be inspected (but no= t > modified) with the user's knowledge and consent (e.g., distinct optics in > the browser). I wouldn't like either outcome, frankly, but it would be ni= ce > if we had a game plan for what to do for user privacy if intercept CAs > become a requirement for using the web in large parts of the world > (something we might be one "crisis" away from), and an honest evaluation = of > the alternatives. Fundamentally, I don't like it when discussion gets shu= t > down because people want to bury their heads in the sand in the name of > ideology. > > BW> +1. I also note that this concern applies to some of the other > performance related use cases too. > > KM> I think the real argument here is a control one between the > application and management folks and not security/privacy even though > that's what is often discussed. This is all about control. > Right, but the core issue being addressed by this document is that measures intended for reasons of privacy and security (encryption) are impacting something over which there is much less consensus (content-aware flow management and path intelligence). I'm not proposing any language here, only pontificating that the purity approach might backfire, and I'm not sure we have a backup plan. > In addition, mobile network operator often sell tariffs that allow > free-data access to certain sites, known as 'zero rating'. A session > to visit such a site incurs no additional cost or data usage to the > user. This feature is impacted if encryption hides the details of > the content domain from the network. > > KR> There's the related issue that zero-rating by-implementation typicall= y > applies only to direct connections to a particular endpoint (e.g., by IP)= : > if a user accidentally tunnels traffic from Spotify through a corporate > VPN, that traffic won't be zero-rated, encrypted tunnel or not. (This goe= s > back to the taxonomy of metadata layers comment I made near the top.) > Carriers aren't going to trust e.g., a Host header for zero-rating, becau= se > that provides a simple way to tunnel traffic for free: consequently, > determination of zero-rating will always involve some hard-to-impersonate > credential, like an IP address or server certificate in the public trust > web. > > KM> Not sure what to add here, any ideas, AL? > I think the only change I'd make here is to change "content domain" to "content origin", because domain implies hostname where the origin is often an IP. > When RTSP stream content is encrypted, the 5-tuple information within > the payload is not visible to these ALG implementations, and > therefore they cannot provision their associated middelboxes with > that information. > > KR> I would argue that this is a protocol design issue. This was > originally a problem with firewalls and NATs, with content inspection as = a > hack to work around the protocol/network impedance mismatch. I'm not the > only one who would argue the right solution today is to design protocols = to > not require linkage across connections by middleboxes that do basic > filtering. > > KM> I think we are in agreement here for solution direction, but the > document specificly tries to avoid solutions. This example has been rais= ed > in the IESG by Warren and the apps side hadn't considered his view of it > previously. It would be good for protocols to have these considerations = in > their designs, they were mostly thinking it didn't matter and were > end-to-end. But poor video streaming sessions are an issue. Not sure we > should add any text here??? > This was just another random observation. > Data center operators may also maintain packet recordings in order to > be able to investigate attacks, breach of internal processes, etc. > In some industries, organizations may be legally required to maintain > such information for compliance purposes. Investigations of this > > KR> I think you'll get a "[citation needed]" from folks on the TLS mailin= g > list. > > KM> I suspect this is one you have that recorded text, you have to > maintain it for chain of custody with investigation handling. I'll have = to > figure out if there is anything that would require the capture, I suspect > not, but could be wrong. > Just making the point that this has been contended several times on various mailing lists and at meetings, so it would be nice to get the oft-cited cases documented somewhere as an informational reference. There are use cases where DAR or disk-level > encryption is required. Examples include preventing exposure of data > if physical disks are stolen or lost. > > KR> I don't see these last two sentences are relevant, as they have > nothing to do with the network flows. > > KM> I'm happy to remove. DO they help a reader who is not familiar with > the technology to understand the layers of encryption used at all or is i= t > better to remove the sentence? > I'm not sure. I'm actually a bit confused about this section in general. It seems to be discussing monitoring of data during transport to/from the storage cluster in the same paragraph as encryption of data at rest, but I'm not sure what point it's trying to make. Is it that operators have a threat model that doesn't include the network connection between the storage cluster and the client, but which does include exfiltration of the disks in the cluster? > Security monitoring in the enterprise may also be performed at the > endpoint with numerous current solutions that mitigate the same > problems as some of the above mentioned solutions. Since the > software agents operate on the device, they are able to monitor > traffic before it is encrypted, monitor for behavior changes, and > lock down devices to use only the expected set of applications. > Session encryption does not affect these solutions. Some might argue > that scaling is an issue in the enterprise, but some large > enterprises have used these tools effectively. > > KR> This is another example of mixing proposed solutions in among the > problem statement. I would argue for a clear separation, which may mean > that this document needs to have a single-minded focus on "here are the > problems and here's how enterprises currently address them." > > BW> Also, enterprises increasingly allow BYOD programs for their > employees, and such programs make it more difficult to ensure that adequa= te > endpoint-based defenses are active. This is especially true when the area > of risk in question is the above #5 "track misuse and abuse by employees"= . > Note too that endpoint-based defenses can be less effective when the devi= ce > is already compromised, in which case detection of the compromised device > and effective remediation can be made more effective through the addition= al > use of an on-path element. > > KM> [made some subsequent edits to this section] > LGTM. 5.7. Further work > > Although incident response work will continue, new methods to prevent > system compromise through security automation and continuous > monitoring [SACM] may provide alternate approaches where system > security is maintained as a preventative measure. > > KR> Not clear how the unknowns relate to the purpose of this document. > Being sarcastic for a minute, I'm interpreting this as "Any cleartext > metadata just *might* be used in the future for some kind of enterprise > security monitoring!" > > KM> Hmm, it's meant to say endpoints (which you control) should be used > and technology like what is expected out of SACM will help with automatin= g > this. We are open to text suggestions. > Yeah, I think I must have misread it the first time, because I get only your meaning now. Kyle --001a1135ac76efd8ad05626f9bd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I wo= uld put each of my comments in the etherpad into one of three buckets: obse= rvations and commentary, minor points and clarifications, and points that I= think require more discussion. I'm only really going to address the la= st bucket: the others I raised but don't feel particularly strongly abo= ut, at least at this late stage in the document's life.

=
=C2=A0=C2=A0 (section 3.2 of [RFC7525]), essentially preve= nting the negotiation
=C2=A0=C2=A0 process resulting in fallback to the = use of clear text.=C2=A0 In other
=C2=A0=C2=A0 cases, some service provi= ders have relied on middle boxes having
=C2=A0=C2=A0 access to clear tex= t for the purposes of load balancing, monitoring
=C2=A0=C2=A0 for attack= traffic, meeting regulatory requirements, or for other
=C2=A0=C2=A0 pur= poses.=C2=A0 These middle box implementations, whether performing
=C2=A0= =C2=A0 functions considered legitimate by the IETF or not, have been
=C2= =A0=C2=A0 impacted by increases in encrypted traffic.=C2=A0 Only methods ke= eping
=C2=A0=C2=A0 with the goal of balancing network management and PM = mitigation in
=C2=A0=C2=A0 [RFC7258] should be considered in solution wo= rk resulting from this
=C2=A0=C2=A0 document.

KR> I feel like = this section could be better organized by:
=C2=A0* Moving the examples t= o 1.1 as a bulleted list of sample situations in which network operators at= tempted to and/or succeeded in defeating encryption to preserve existing op= erational mechanisms, or in which performance suffered for users (whether o= f the encrypted flows or of other flows impacted by encrypted flows).
KM> Interesting point, but we'd need more examples.=C2=A0 I'll= think about this more and chat with Al in case he has ideas.=C2=A0 For now= , I went with Brandon's easier suggestion, but moving to this would be = nice for the document readers.

AM> Although I see how these examp= les could be part of the background, I think those who will
eventually r= emove their objections will prefer the reduced emphasis on these examples w= here
they are (in section 2). In one view, the entire memo is background= , since nothing new is proposed.

KR>
=C2=A0* Using this sectio= n as an introduction to the methodology for cataloging operational mechanis= ms depending on cleartext traffic monitoring, with the various caveats on w= hat will be considered (e.g., only mechanisms required heretofore for opera= bility), and for describing the approach to seeking mitigations and/or subs= titutions.

KM> Hmm, interesting point.=C2=A0 I'll have to thi= nk about this more as it could be alot of work at this stage.

AM>= Unfortunately, we've already implemented many AD-level suggestions on = the organization of Section 2.
We're at the stage of *what can every= body live with", and re-re-re-org falls out now, IMO.

This is a reasonable objection, but I am mostly c= oncerned about satisfying the target audience. ISTM that audience is someth= ing like "IETF participants who are skeptical about, or ignorant of, t= he operational difficulties posed by widespread encryption of flows". = If the document meets your goals as-is, then further refinement is unnecess= ary. Does it? Or is it impossible to know at this point?
=C2= =A0
AM> Also, the neutral exposition that we've been asked to provide a= million times actually
comes from multiple perspectives expressed in co= ntributions that we would combine
in a balanced way, without value judge= ments (no good or bad).
Where we lack balance, we lack specific contribu= tions.

"Neutral" meanin= g "without advocacy"? It's a fine line. The document still ha= s a thesis, which (if I am reading it correctly) is to inform the community= of current operational practices that are encumbered in some way by encryp= tion. To wit, q( It provides network operators' perspectives about the = motivations and objectives of those practices as well as effects anticipate= d by operators as use of encryption increases. ) Without that thesis, which= some might interpret as advocacy, it's not clear the document would ha= ve enough focus to be useful. I'd like folks to see this doc as *at wor= st* devil's advocacy, and preferably as a challenge to come up with bet= ter arguments and to find alternative methods for dealing with network mana= gement problems.
=C2=A0
=C2=A0=C2=A0 heuristics grows, and accuracy suffers= .=C2=A0 For example, the traffic
=C2=A0=C2=A0 patterns between server an= d browser are dependent on browser supplier
=C2=A0=C2=A0 and version, ev= en when the sessions use the same server application
=C2=A0=C2=A0 (e.g.,= web e-mail access).=C2=A0 It remains to be seen whether more
=C2=A0=C2= =A0 complex inferences can be mastered to produce the same monitoring
= =C2=A0=C2=A0 accuracy.

KR> This might be too formal of an approac= h for this doc, but it might be possible to construct a taxonomy of layers = of metadata made unavailable by encryption at each layer to show the comple= teness/comprehensiveness of the survey. So, for instance:
=C2=A0* Protoc= ol and port number are still available as a way of characterizing traffic o= ver the public internet even if the payload is encrypted, but this informat= ion is lost if (e.g.) the traffic is traversing an IPsec tunnel or if radic= ally different kinds of traffic all use port 443/tcp without any other way = to distinguish between them.
=C2=A0* TCP is open to optimization/measure= ment even if using TLS, except when tunneled encrypted: congestion signals = (like rexmits) previously transparent to the middlebox, for instance, are t= hen lost.
=C2=A0* Encrypting the payload defeats attempts to survey traf= fic by user agent (if there's no other way to distinguish, e.g., by fin= gerprinting).

KM> I think this would be a really helpful follow o= n document.=C2=A0 I'd be willing to work on it if you're game.=C2= =A0 I've been thining about something similar, specific to TLS, but sho= uld be broadened.

I'm afraid = this topic might be more of a research project than it initially appears, b= ut it's probably a reasonable exercise to see what we can produce for a= plaintext protocol vs. that same protocol over TLS. Ping me.
=C2=A0
=C2=A0=C2=A0 It is important to note that the push for encryption by a= pplication
=C2=A0=C2=A0 providers has been motivated by the application = of the described
=C2=A0=C2=A0 techniques.=C2=A0 Some application provide= rs have noted degraded
=C2=A0=C2=A0 performance and/or user experience w= hen network-based optimization or
=C2=A0=C2=A0 enhancement of their traf= fic has occurred, and such cases may result
=C2=A0=C2=A0 in additional o= perator troubleshooting, as well.

KR> Observation: additionally, = I think you'll encounter the argument that the responsibility for diagn= osing bad interactions between applications and networks falls on the appli= cation owner rather than the network operator. Basically, I feel like the d= esire among protocol designers is for operators to provide a pipe with cert= ain key characteristics that interact well with established transport proto= col mechanisms, and otherwise to leave the traffic alone and let the applic= ation developers do what they want to within the expected constraints. If t= hat's infeasible (e.g., in edge cases, or with respect to new technolog= ies that interact badly with existing transports, such as the loss=3Dconges= tion assumption of TCP that interacts badly with wifi), that's precisel= y the case needs to be made by this document.

KM> We have encount= ered this argument already.=C2=A0 It's a tough one as SPs have the SLAs= with customers, so they are the first call.=C2=A0 Many don't know how = to get in touch with APP providers.=C2=A0 I understand the application deve= lopers perspecive, but also see that there has to be some ability to troubl= eshoot.=C2=A0 Sure, providers could wrap the protocols for transport to pro= vide some way of measuring, but information is lost.=C2=A0 IPv6 with flow i= dentifiers is another way to do it, but you might not be able to prioritize= a call or protocol that has little tolerance for delay over one that does = for instance.=C2=A0 And I realize that app providers just want all traffic = to have the same priority, but emergency calls are important.

BW>= I think the point made by the document is correct though: operators are ne= arly always the first call, not the application provider.

KM> We = were asked to remove text that said that.=C2=A0 I agree that it is the case= as the providers have the SLAs and you don't typlically have a number = for App providers.

BW> The operators are looking for ways to demo= nstrate that they did not cause the problem (or determine that they did) fo= r efficient hand-off to the correct party for resolution. There are certain= ly problems an approach that changes the behavior of the protocol, but it&#= 39;s difficult to argue with the diagnostic need.

AM> Using Netfl= ix as an example, the first source of problem they mention is the network w= hen
addressing the question "Why doesn't Netflix work?":=C2=A0=C2=A0=C2=A0 "If Netflix isn=E2=80=99t working, you may be exp= eriencing a network connectivity issue, an issue with your device, or an is= sue with your Netflix app or account."
=C2=A0=C2=A0=C2=A0 from https://help.netflix.com/en/node/461?ui_= action=3Dkb-article-popular-categories
They previously had even= stronger wording, something like "First, make sure your network conne= ction meets the Netflix requirements ... URL"
One of the causes of = re-buffering are CDN-related pauses when accessing the next segment:=C2=A0 = completely hidden from users so far.
Additional frequent cause: the unli= censed WiFi network owned and operated by the customer.

Another way = to look at this strategy: App providers are transferring as much overhead c= ost to the network operators as possible
(troubleshooting customer probl= ems is expensive - rolling a truck negates months of revenue), while preser= ving as
much value/control/revenue as they can for themselves. The greed= -thingy plays poorly over time.
A user-focused strategy would be to form= partnerships for troubleshooting of shared customers, but that might resul= t in exposing
the real causes and some would rather hide for now, it see= ms.

I agree with all the points y= ou've made. How do we square reality (users blame network operators) wi= th the current approach to protocol design at the IETF (keep the network du= mb)? I feel like creating a conversation about this apparent cognitive diss= onance will be one of the most important outcomes of publishing this docume= nt.

I have no doubt the conflict will resolve itse= lf somehow: CDNs, for instance, act as an intelligent overlay over dumb net= works and can therefore provide the most consistent user experience when de= eply deployed into carrier networks the structure of which they have intima= te knowledge. Is the right solution to continue to effectively delegate thi= s responsibility by encouraging breaking of connections at the edge, or sho= uld the IETF be trying to optimize the end-to-end performance of its protoc= ols on the public internet?

Anyway, I digress. Thi= s isn't a conversation I'm proposing you have in this document; jus= t that the doc should raise these kinds of questions in the reader.

=C2=A0=C2=A0 packet is able to provide stateless load balancing.= =C2=A0 This ability
=C2=A0=C2=A0 confers great reliability and scaleabil= ity advantages even if the
=C2=A0=C2=A0 flow remains in a single POP, be= cause the load balancing system is
=C2=A0=C2=A0 not required to keep sta= te of each flow.=C2=A0 Even more importantly,
=C2=A0=C2=A0 there's n= o requirement to continuously synchronize such state among
=C2=A0=C2=A0 = the pool of load balancers.

KR> An important point is that an int= egrated load balancer repurposing limited existing bits in transport flow s= tate must maintain and synchronize per-flow state occasionally: using the s= equence number as a cookie only works for so long given that there aren'= ;t that many bits available to divide across a pool of machines.

KM&= gt; I added in this point, but have to check back on flow of text.

I checked the wording in -14.I'm goin= g to propose slightly different language:

q( T= his ability
=C2=A0=C2=A0 confers great reliability and scalability advan= tages even if the
=C2=A0=C2=A0 flow remains in a single POP, because the= load balancing system is
=C2=A0=C2=A0 not required to keep state of eac= h flow. There is value even when the
=C2=A0=C2=A0 repurposed bits= are strictly insufficient for encoding all state: an integrated load balan= cer repurposing
=C2=A0=C2=A0 limited existing bits in transport flow sta= te must still maintain and
=C2=A0=C2=A0 synchronize per-flow state occas= ionally (using the sequence number as
=C2=A0=C2=A0 a cookie only works f= or so long given that there aren't that many
=C2=A0=C2=A0 bits avail= able to divide across a pool of machines), but there is no longer
=C2=A0=C2=A0 a requirement for such synchronization to be continuous or in= stantaneous. )

KR> A dedicated mechanism for stor= ing load balancer state, such as QUIC's proposed connection ID, is stri= ctly better from the load balancer's point of view, and is probably eve= n better from a privacy perspective than bolting it on to an unrelated tran= sport signal because it can be tightly controlled by one of the endpoints a= nd rotated to avoid roving client linkability: in other words, being a spec= ific, separate signal, it can be governed in a way that is finely targeted = at that specific use-case. (I'm thinking the advantages of separate mec= hanisms belongs in a different part of the doc; this section is more like t= he problem statement than the solution statement.)

KM> This (abov= e) needs to be reworded to be neutral and this does go towards solution spa= ce, which we were trying to avoid. How about:

Another possibility is= a dedicated mechanism for storing load balancer state, such as QUIC's = proposed connection ID to provide visibility to the load balancer.=C2=A0 An= identifier could be used for tracking purposes, but this may provide an op= tion that is an improvement from=C2=A0 bolting it on to an unrelated transp= ort signal. This method allows for tight control by one of the endpoints an= d can be rotated to avoid roving client linkability: in other words, being = a specific, separate signal, it can be governed in a way that is finely tar= geted at that specific use-case.

= SGTM. Maybe s/improvement from bolting it on to/improvement compared to co-= opting/.

=C2=A0=C2=A0 In future Network Function Virtual= ization (NFV) architectures, load
=C2=A0=C2=A0 balancing functions are l= ikely to be more prevalent (deployed at
=C2=A0=C2=A0 locations throughou= t operators' networks)[.=C2=A0 NFV environments will
=C2=A0=C2=A0 re= quire some type of identifier (IPv6 flow identifiers, the Proposed
=C2= =A0=C2=A0=C2=A0 QUIC connection ID, etc.) for managing]
=C2=A0=C2=A0 tra= ffic using encrypted tunnels.[=C2=A0 The shift to increased encryption
= =C2=A0=C2=A0 will have an impact to visibility of flow information and will= require
=C2=A0=C2=A0 adjustments to perform similar load balancing func= tions within an NFV.]

KR> I'm not sure what architecture this= paragraph is discussing: are you talking about encrypted tunnels between N= FV nodes? Is this something obvious to people involved in NFV? A diagram (o= r informational reference) would be helpeful to me here.

KM> I se= e your point, the langauage here could be more clear. Do the above adjustme= nts (ed: in []) help?

I am still = a little confused. Is the idea that load balancing in NFV environments has = a unique need for stateless (or reduced-state) load balancing that other ap= plications don't have? I'm having a hard time wrapping my head arou= nd why that would be the case. Or is the point here just to highlight NFV a= s just another use case to consider?
=C2=A0
2.2.2.=C2=A0 Differe= ntial Treatment based on Deep Packet Inspection (DPI)
=C2=A0=C2=A0 ...=C2=A0=C2=A0 These effects and potential alternative solutions have been = discussed
=C2=A0=C2=A0 at the accord BoF [ACCORD] at IETF95.

KR&g= t; This section is labeled DPI, but really, the underlying issue is what yo= u stated in the first paragraph: different kinds of traffic have different = QoS needs, yet a network provider can't rely on a voluntary signal from= an untrusted device to decide on QoS or every packet is simply going to be= marked "high importance" and so we're back to treating all t= raffic equivalently. I'd argue against one of the memes I heard at the = accord BoF, that it's down to latency vs. throughput, by pointing out t= hat some applications (e.g., live video with low hand-wave latency) need bo= th.

Even after reading this, I'm still skeptical of the need for= any more granularity than flow, and using AQM on a per-flow (e.g., 5-tuple= ) or flow-aggregate (some subset of the 5-tuple) to prevent an application = or user from consuming resources unfairly. What, for instance, prevents a c= arrier from privileging VoIP traffic by looking at endpoints? Would there b= e a way for someone else to masquerade non-VoIP traffic as VoIP traffic giv= en this kind of setup? This is the kind of question that I need answered by= this doc.

BW> It might be useful to note in this section that QU= IC and H2 both combine multiple micro-flows, possibly of different types, w= ithin a single encrypted transport-layer flow. They share this with IPsec t= unnels and the like. IOW, the increased use of encrypted aggregating encaps= ulation can hide even the the most basic representation of a flow from the = differentiated service element. This same concern applies to load balancing= elements discussed in section 2.2.1.

=
Good point: an example of this is sending both Youtube and search resp= onses over the same QUIC or H2 connection, with no way for the network to t= hrottle one without throttling the other.

AM> We were as= ked not to refer to QUIC, for various reasons (e.g., still under developmen= t).

There will always be areas where network can make the best decis= ion, because of the
information available to the network operators (and = the lack of that same info at end-points).

When network resources ar= e constrained, only the network can manage priorities.
This has been org= anized according to applications that can be identified, but there
can b= e other solutions requiring cooperation between user devices and the networ= k
according to subscription to a special service (QCI above).
<= /blockquote>

Got it. Is DPI the right framing for this, = or is something more generic (e.g., "content-aware traffic management&= quot;) what is really required? E.g., the network doesn't necessarily n= eed to know which video you're watching, only that it is video, and may= be what the available bitrates are and associated quality.
= =C2=A0
=C2=A0=C2=A0 An application-type-aware network edge (middlebox) can fur= ther
=C2=A0=C2=A0 control pacing, limit simultaneous HD videos, or prior= itize active
=C2=A0=C2=A0 videos against new videos, etc.

KR> = Observation: This subsection provides the first really compelling argument = I've seen for exposing flow metadata to the path. On long paths, physic= s gets in the way of tight control feedback loops. If nothing else, this sh= ould provide motivation for protocol designers and operators to break down = the characteristics of different kinds of flows, determine where control po= ints are needed in each of them, and figure out how to implement those.
=
I think there is this conceit among protocol designers that quality pro= blems can all be solved at the endpoints without any cooperation from path = elements; the really killer arguments are examples of where that cannot pos= sibly be the case. ECN is a great example of this, and is a signal explicit= ly targeted at middleboxes with opt-in by the endpoints: it allows a middle= box to report congestion without dropping packets, which produces measurabl= y better QoS for the user.

KM> Ack, thanks.=C2=A0 You're not = looking for additional text here, is that right?=C2=A0 If so, what are you = thinking should be added?

No, jus= t an observation that this was one of the more thought-provoking sections o= f the doc for me.
=C2=A0
=C2=A0=C2=A0 Alternate approaches such = as blind caches [I-D.thomson-http-bc] are
=C2=A0=C2=A0 being explored to= allow caching of encrypted content; however, they
=C2=A0=C2=A0 still ne= ed to intercept the end-to-end transport connection.

KM> [s/need = to intercept the end-to-end transport connection/require cooperation betwee= n the content owners/CDNs and blind caches and fall outside the scope of wh= at is covered in this document/

S= GTM.
=C2=A0
2.2.6.=C2=A0 Content Compression

=C2=A0=C2=A0= In addition to caching, various applications exist to provide data
=C2= =A0=C2=A0 compression in order to conserve the life of the user's mobil= e data
=C2=A0=C2=A0 plan and optimize delivery over the mobile link.=C2= =A0 The compression
=C2=A0=C2=A0 proxy access can be built into a specif= ic user level application,
=C2=A0=C2=A0 such as a browser, or it can be = available to all applications using a
=C2=A0=C2=A0 system level applicat= ion.=C2=A0 The primary method is for the mobile
=C2=A0=C2=A0 application= to connect to a centralized server as a proxy, with the
=C2=A0=C2=A0 da= ta channel between the client application and the server using
=C2=A0=C2= =A0 compression to minimize bandwidth utilization.=C2=A0 The effectiveness = of
=C2=A0=C2=A0 such systems depends on the server having access to unen= crypted data
=C2=A0=C2=A0 flows.

KR> Observation: given the si= de channels exposed by data compression that is blind to content, the inabi= lity to compress arbitrary payloads is likely to be regarded as a feature o= f encryption. (Though I recognize this is a catalog, not an endorsement.) F= urthermore, in most cases eliminating compression is still 2-competitive wi= th compression, so I'm not sure it's a really compelling use-case.<= br>
BW> Per-object content compression might not be a compelling use = case here. Aggregated data stream content compressions that spans objects a= nd data sources is compelling, though. If there is a network element close = to the receiver that sees all content destined for the receiver and can tre= at it all as part of a unified compression scheme (e.g., through the use of= a shared segment store) will often be much more effective at providing dat= a off-load.

KM> Thanks, we'll add this text (modified) to mak= e those helpful points clear.

How about:
=C2=A0=C2=A0=C2=A0 Aggre= gated data stream content compression that spans objects and data sources t= hat can be treated as part of a unified compression scheme (e.g., through t= he use of a shared segment store) is often effective at providing data offl= oad when there is a network element close to the receiver that has access t= o see all the content.

Sounds goo= d. This is general enough to cover the case of networks with limited uplink= s wanting to cache content that is conceptually shared (e.g., VOD) but deli= vered independently to end users via individual TLS connections.
<= div>=C2=A0
KR> It might be worth discussing the typical opt-in strategy fo= r these things in the presence of TLS, adding a new intercept CA to willing= clients, which has the downside that it potentially exposes every https co= nnection to an active MitM.

BW> +1

KM> OK, we hadn'= t done that before since the option doesn't change, but you make a good= point, so I'll add in text.=C2=A0 Thanks.

I added the following= :

=C2=A0=C2=A0=C2=A0 This method is also used by other types of netw= ork providers enabling
=C2=A0=C2=A0=C2=A0=C2=A0 traffic inspection, but = not modification.</t>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <t>Content filtering via a proxy ca= n also utilize an intercepting
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 certificate where the client's session is terminated at= the proxy
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enabli= ng for cleartext inspection of the traffic.=C2=A0 A new session
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is created from the interc= epting device to the client's
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 destination, this is an opt-in strategy for the client. = Changes to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TLSv1.= 3 do not impact this more invasive method of interception, where
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this has the potential to = expose every HTTPS session to an active
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 man in the middle (MitM). </t>

Mostly sounds good. Is there a reason to menti= on TLS 1.3 specifically here?
=C2=A0
KR> Random comment: es= pecially with respect to government content filtering, I'm worried that= the IETF's current approach of playing chicken with regulators on end-= to-end encryption is going to result in normalization of intercept CAs, whi= ch will be strictly worse than a compromise solution in which a subset of t= raffic can be inspected (but not modified) with the user's knowledge an= d consent (e.g., distinct optics in the browser). I wouldn't like eithe= r outcome, frankly, but it would be nice if we had a game plan for what to = do for user privacy if intercept CAs become a requirement for using the web= in large parts of the world (something we might be one "crisis" = away from), and an honest evaluation of the alternatives. Fundamentally, I = don't like it when discussion gets shut down because people want to bur= y their heads in the sand in the name of ideology.</rant>

BW&g= t; +1. I also note that this concern applies to some of the other performan= ce related use cases too.

KM> I think the real argument here is a= control one between the application and management folks and not security/= privacy even though that's what is often discussed.=C2=A0 This is all a= bout control.

Right, but the core= issue being addressed by this document is that measures intended for reaso= ns of privacy and security (encryption) are impacting something over which = there is much less consensus (content-aware flow management and path intell= igence). I'm not proposing any language here, only pontificating that t= he purity approach might backfire, and I'm not sure we have a backup pl= an.
=C2=A0
=C2=A0=C2=A0 In addition, mobile network operator often sell= tariffs that allow
=C2=A0=C2=A0 free-data access to certain sites, know= n as 'zero rating'.=C2=A0 A session
=C2=A0=C2=A0 to visit such a= site incurs no additional cost or data usage to the
=C2=A0=C2=A0 user.= =C2=A0 This feature is impacted if encryption hides the details of
=C2= =A0=C2=A0 the content domain from the network.

KR> There's th= e related issue that zero-rating by-implementation typically applies only t= o direct connections to a particular endpoint (e.g., by IP): if a user acci= dentally tunnels traffic from Spotify through a corporate VPN, that traffic= won't be zero-rated, encrypted tunnel or not. (This goes back to the t= axonomy of metadata layers comment I made near the top.) Carriers aren'= t going to trust e.g., a Host header for zero-rating, because that provides= a simple way to tunnel traffic for free: consequently, determination of ze= ro-rating will always involve some hard-to-impersonate credential, like an = IP address or server certificate in the public trust web.

KM> Not= sure what to add here, any ideas, AL?

I think the only change I'd make here is to change "content = domain" to "content origin", because domain implies hostname= where the origin is often an IP.
=C2=A0
=C2=A0=C2=A0 When RTSP = stream content is encrypted, the 5-tuple information within
=C2=A0=C2=A0= the payload is not visible to these ALG implementations, and
=C2=A0=C2= =A0 therefore they cannot provision their associated middelboxes with
= =C2=A0=C2=A0 that information.

KR> I would argue that this is a p= rotocol design issue. This was originally a problem with firewalls and NATs= , with content inspection as a hack to work around the protocol/network imp= edance mismatch. I'm not the only one who would argue the right solutio= n today is to design protocols to not require linkage across connections by= middleboxes that do basic filtering.

KM> I think we are in agree= ment here for solution direction, but the document specificly tries to avoi= d solutions.=C2=A0 This example has been raised in the IESG by Warren and t= he apps side hadn't considered his view of it previously.=C2=A0 It woul= d be good for protocols to have these considerations in their designs, they= were mostly thinking it didn't matter and were end-to-end.=C2=A0 But p= oor video streaming sessions are an issue.=C2=A0 Not sure we should add any= text here???

This was just anoth= er random observation.
=C2=A0
=C2=A0=C2=A0 Data center operators= may also maintain packet recordings in order to
=C2=A0=C2=A0 be able to= investigate attacks, breach of internal processes, etc.
=C2=A0=C2=A0 In= some industries, organizations may be legally required to maintain
=C2= =A0=C2=A0 such information for compliance purposes.=C2=A0 Investigations of= this

KR> I think you'll get a "[citation needed]" = from folks on the TLS mailing list.

KM> I suspect this is one you= have that recorded text, you have to maintain it for chain of custody with= investigation handling.=C2=A0 I'll have to figure out if there is anyt= hing that would require the capture, I suspect not, but could be wrong.
=

Just making the point that this has = been contended several times on various mailing lists and at meetings, so i= t would be nice to get the oft-cited cases documented somewhere as an infor= mational reference.

=C2=A0=C2=A0 There are use cases where= DAR or disk-level
=C2=A0=C2=A0 encryption is required.=C2=A0 Examples i= nclude preventing exposure of data
=C2=A0=C2=A0 if physical disks are st= olen or lost.

KR> I don't see these last two sentences are re= levant, as they have nothing to do with the network flows.

KM> I&= #39;m happy to remove.=C2=A0 DO they help a reader who is not familiar with= the technology to understand the layers of encryption used at all or is it= better to remove the sentence?

I= 'm not sure. I'm actually a bit confused about this section in gene= ral. It seems to be discussing monitoring of data during transport to/from = the storage cluster in the same paragraph as encryption of data at rest, bu= t I'm not sure what point it's trying to make. Is it that operators= have a threat model that doesn't include the network connection betwee= n the storage cluster and the client, but which does include exfiltration o= f the disks in the cluster?
=C2=A0
=C2=A0=C2=A0 Security monitor= ing in the enterprise may also be performed at the
=C2=A0=C2=A0 endpoint= with numerous current solutions that mitigate the same
=C2=A0=C2=A0 pro= blems as some of the above mentioned solutions.=C2=A0 Since the
=C2=A0= =C2=A0 software agents operate on the device, they are able to monitor
= =C2=A0=C2=A0 traffic before it is encrypted, monitor for behavior changes, = and
=C2=A0=C2=A0 lock down devices to use only the expected set of appli= cations.
=C2=A0=C2=A0 Session encryption does not affect these solutions= .=C2=A0 Some might argue
=C2=A0=C2=A0 that scaling is an issue in the en= terprise, but some large
=C2=A0=C2=A0 enterprises have used these tools = effectively.

KR> This is another example of mixing proposed solut= ions in among the problem statement. I would argue for a clear separation, = which may mean that this document needs to have a single-minded focus on &q= uot;here are the problems and here's how enterprises currently address = them."

BW> Also, enterprises increasingly allow BYOD program= s for their employees, and such programs make it more difficult to ensure t= hat adequate endpoint-based defenses are active. This is especially true wh= en the area of risk in question is the above #5 "track misuse and abus= e by employees". Note too that endpoint-based defenses can be less eff= ective when the device is already compromised, in which case detection of t= he compromised device and effective remediation can be made more effective = through the additional use of an on-path element.

KM> [made some = subsequent edits to this section]

LGTM.

5.7.=C2=A0 Further work

=C2=A0=C2=A0 Although incident resp= onse work will continue, new methods to prevent
=C2=A0=C2=A0 system comp= romise through security automation and continuous
=C2=A0=C2=A0 monitorin= g [SACM] may provide alternate approaches where system
=C2=A0=C2=A0 secu= rity is maintained as a preventative measure.

KR> Not clear how t= he unknowns relate to the purpose of this document. Being sarcastic for a m= inute, I'm interpreting this as "Any cleartext metadata just *migh= t* be used in the future for some kind of enterprise security monitoring!&q= uot;

KM> Hmm, it's meant to say endpoints (which you control)= should be used and technology like what is expected out of SACM will help = with automating this.=C2=A0 We are open to text suggestions.

Yeah, I think I must have misread it the first = time, because I get only your meaning now.

Kyle
--001a1135ac76efd8ad05626f9bd4-- From nobody Wed Jan 10 14:50:46 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEEC126D85 for ; Wed, 10 Jan 2018 14:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 VkrU63u11msg for ; Wed, 10 Jan 2018 14:50:43 -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 C38FA1241FC for ; Wed, 10 Jan 2018 14:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=975; q=dns/txt; s=iport; t=1515624643; x=1516834243; h=subject:from:to:references:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=nYZVyi1iFjxGoUpIn6e3MMoYgqo+bkWWMET0fROxC6g=; b=UsRGXPXzxeu5VHUeHbZhwNM7IoFhNPq34UV5U4iZ7fyHtWw9N5iLeIDC HUibLG2zhDCEZq17z5QQTDBvG/M9eC5bE9Patdn1EaNoMXTigPEkxRnpj wx7gQ+jhB08n9Cv+t27Z0RCpNQepjIo6+3M4QgZC0Uqo5vFpI+du9li/U Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfCQBMmFZa/5ldJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNBZnQnhAeZAoICmUYCCBgLhElPAoRGRBMBAQEBAQEBAQFrHQu?= =?us-ascii?q?FJAEBAQMBARsGSxsjAgImAgInMAYNBgIBAYovEK4GAYE0gieKPwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHAU0W4MRghWBV4IShjQBAQIBAYUEgmUFkzyQKIgLjTqCGIYcg2+?= =?us-ascii?q?HaQKNO4lmgTw3IYFQTCMVPYIqhHUjN4tgAQEB?= X-IronPort-AV: E=Sophos;i="5.46,342,1511827200"; d="scan'208";a="123820535" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2018 22:50:43 +0000 Received: from [10.118.87.84] (rtp-jclarke-nitro3.cisco.com [10.118.87.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0AMogG2026478 for ; Wed, 10 Jan 2018 22:50:43 GMT From: Joe Clarke To: "opsawg@ietf.org" References: Organization: Cisco Message-ID: <12bb2a07-25a8-c5a9-17f8-d41d28df40e9@cisco.com> Date: Wed, 10 Jan 2018 17:50:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] CLOSED: WG LC: Calling for comments on draft-ietf-opsawg-nat-yang X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 22:50:45 -0000 The WG LC on this draft has closed. Based on comments from directorates as well as previous comments on the list, we are ready to call consensus on this work. No IPR has been disclosed, and all authors have reported there is no known IPR. The outstanding issue is that we need a shepherd for this document. If you are interested, please let the chairs know. Joe On 12/19/17 18:11, Joe Clarke wrote: > Hello, opsawg. As discussed in Singapore, we are starting a WG LC on > draft-ietf-opsawg-nat-yang (currently at version -09). This document > has received a number of reviews and comments already. We will hold a > four week WG LC for this to allow for the upcoming holiday. > > The WG LC will close on January 9, 2017. > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/ > > Joe > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Fri Jan 12 14:54:26 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A223012D876; Fri, 12 Jan 2018 14:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 WcnTbvR0rUxk; Fri, 12 Jan 2018 14:54:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12D7124BE8; Fri, 12 Jan 2018 14:54:01 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5BB80B82161; Fri, 12 Jan 2018 14:53:38 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, opsawg@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180112225338.5BB80B82161@rfc-editor.org> Date: Fri, 12 Jan 2018 14:53:38 -0800 (PST) Archived-At: Subject: [OPSAWG] =?utf-8?q?RFC_8309_on_Service_Models_Explained?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 22:54:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8309 Title: Service Models Explained Author: Q. Wu, W. Liu, A. Farrel Status: Informational Stream: IETF Date: January 2018 Mailbox: bill.wu@huawei.com, liushucheng@huawei.com, afarrel@juniper.net Pages: 23 Characters: 54082 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-service-model-explained-05.txt URL: https://www.rfc-editor.org/info/rfc8309 DOI: 10.17487/RFC8309 The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Jan 15 11:07:02 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7930212EB2C; Mon, 15 Jan 2018 11:06:49 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EAD126C3D; Mon, 15 Jan 2018 11:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 27odCG8NUcOH; Mon, 15 Jan 2018 11:06:47 -0800 (PST) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 26B0C12EB2C; Mon, 15 Jan 2018 11:06:47 -0800 (PST) Received: by mail-pl0-x22d.google.com with SMTP id p5so4342701plo.12; Mon, 15 Jan 2018 11:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o3/yrEcnOkA/b0JAbDcE9Jq/phiqpvkH1itLTIa9Nho=; b=Afp3FtyjdS8RhDG4EKZmtHfgtERfmCJ79Aap17H7GMKUO4zGeAyfDwLw49SiSnW3cy M1qy7xNYyB9pVitnJFJiAe7M4VHOzK3nLX3xxIYG7SLBohDUZyP3jKA8XGfvcrzumlef Byy5d3Dh1hPKRCwAZc9V6IjqAK/Px2TPK0Ve1ZPUdZCZzxOOL2VF2KOg8/HXQCUAL6a1 20fcd57WtQGKM6YnwKssGlxNS3r73b/VgSfe0+QoXFUjKPYxLpH4XGw4xzej6aOY5b2L VhLPZ3R+oLBoUb2n9miF7v1e72VA3zc0pE8Ryg2zZakrVCAck3DmigjISJZJ3o2h2IXG vTBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o3/yrEcnOkA/b0JAbDcE9Jq/phiqpvkH1itLTIa9Nho=; b=qveDjrSLoyxfGGADDWTDv1vKndoYGHTUvKe6iP5zFsBnve8Usbsp/3qC8SdTF3gX6q P0uxRe+5AZUhpPNpL2qNT4ikADYfYlwtEOxsgqo/V082p5PfjUT0bIaUgNyGT3+VLiVu fvEx2oFkD0EJq3KaDIKY3BETAP+N/xqPVkz+WfCaw0edEG3kvlznk+VYIT60t1PCMRsW m7C1rpwYVqtSKzshb1eBaoqbxp8d0CNv2qJ1yumvDMw2QFy7YuXPqK66nELekxYyaHJP IHHLG9YIjAc2u2YVZdc/33OfNvZkCe8nBTVyGgb1yk6V8gaO8rcYieTDMeDaiCTZgLrv 905Q== X-Gm-Message-State: AKGB3mL7oxl2oT3Femz1hSDVD5R34puS3lKtvDZIpFVWkRr9FEdGI80y 2ly4D7H/uiw14C59vfIxuQVjbqlgUmvat+MEy2I= X-Google-Smtp-Source: ACJfBoudAZbOS1Ym4uFAlBHrHiLt+PezsSRuHYJlt8fEuR3Fj5npnoHLdV2/NpQs//H3674Ua2xODvcF/mycJ88Xz5E= X-Received: by 10.84.245.23 with SMTP id i23mr36455078pll.219.1516043206710; Mon, 15 Jan 2018 11:06:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.143 with HTTP; Mon, 15 Jan 2018 11:06:06 -0800 (PST) In-Reply-To: References: <151302958109.21278.5686525939396201959@ietfa.amsl.com> From: Kathleen Moriarty Date: Mon, 15 Jan 2018 14:06:06 -0500 Message-ID: To: Ines Robles Cc: rtg-dir@ietf.org, draft-mm-wg-effect-encrypt.all@ietf.org, IETF Content-Type: text/plain; charset="UTF-8" Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180115190649.7930212EB2C@ietfa.amsl.com> Resent-Date: Mon, 15 Jan 2018 11:06:49 -0800 (PST) Archived-At: Subject: Re: [OPSAWG] Rtgdir last call review of draft-mm-wg-effect-encrypt-13 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 19:06:49 -0000 Hi Ines, We added the following reference into the working version per your comment: http://www.jjsylvia.com/bigdatacourse/wp-content/uploads/2016/04/p14-verble-1.pdf Thank you, Kathleen On Mon, Jan 8, 2018 at 12:51 PM, Ines Robles wrote: > Hi Kathleen, > > Ok, thank you for the feedback. > > Best, > > Ines. > > 2018-01-04 20:13 GMT+02:00 Kathleen Moriarty > : >> >> Hello Ines, >> >> Thanks again for your review. Edits have been made in our working >> version that we hope to post soon. >> >> On Mon, Dec 11, 2017 at 9:27 PM, Kathleen Moriarty >> wrote: >> > Ines, >> > >> > Thank you very much for your review! We're working on the comments >> > received and the nits you found will be addressed and are much >> > appreciated. >> > >> > Best regards, >> > Kathleen >> > >> > On Mon, Dec 11, 2017 at 4:59 PM, Ines Robles >> > wrote: >> >> Reviewer: Ines Robles >> >> Review result: Ready >> >> >> >> RtgDir review: draft-mm-wg-effect-encrypt-13.txt >> >> >> >> Hello, >> >> >> >> I have been selected as the Routing Directorate reviewer for this >> >> draft. The >> >> Routing Directorate seeks to review all routing or routing-related >> >> drafts as >> >> they pass through IETF last call and IESG review, and sometimes on >> >> special >> >> request. The purpose of the review is to provide assistance to the >> >> Routing ADs. >> >> For more information about the Routing Directorate, please see >> >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> >> >> Although these comments are primarily for the use of the Routing ADs, >> >> it would >> >> be helpful if you could consider them along with any other IETF Last >> >> Call >> >> comments that you receive, and strive to resolve them through >> >> discussion or by >> >> updating the draft. >> >> >> >> Document: Effect of Pervasive Encryption on Operators - >> >> draft-mm-wg-effect-encrypt-13 Reviewer: Ines Robles Review Date: >> >> 12-11-2017 >> >> Intended status: Informational >> >> >> >> Summary: >> >> This document discusses current security and network management >> >> practices to >> >> help guide protocol development in support of manageable, secure >> >> networks. >> >> >> >> The draft is ready, few typos found. >> >> >> >> Comments: >> >> >> >> I believe the draft is technically good. This document is well written >> >> and >> >> clear to understand. >> >> >> >> Major Issues: >> >> >> >> No major issues found. >> >> >> >> Minor Issues: >> >> >> >> Section 2: >> >> >> >> "... Following the Snowden revelations,..." => It would be nice to add >> >> some >> >> references here >> >> Yes, the problem we have had so far is finding ones that aren't >> articles that may not be stable. A quick search pulls up new ones >> like the following: >> http://fortune.com/2016/04/25/snowden-encryption-james-clapper/ >> >> We'll have to try again to find an academic publication. >> >> >> >> >> Section 2.2.5: >> >> "DRM..."=> I would expand it to Digital Rights Management (DRM) >> >> Added, thank you! >> >> >> >> >> Section 6: >> >> >> >> inlcudes=> includes >> >> Fixed, thanks. >> >> >> >> Section 6.1: >> >> "information For example" => period missing? >> >> Ack, thanks! >> >> >> >> Section 6.2: >> >> "soltuions" -> solutions >> Fixed. >> >> >> >> Section 7.1 title: >> >> "Encypted" => Encrypted >> Fixed. >> >> Thanks for your review! >> >> >> >> >> >> >> > >> > >> > >> > -- >> > >> > Best regards, >> > Kathleen >> >> >> >> -- >> >> Best regards, >> Kathleen > > -- Best regards, Kathleen From nobody Wed Jan 17 01:09:32 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F112D12FACF; Wed, 17 Jan 2018 01:09:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151618016696.15498.2685576211866933423@ietfa.amsl.com> Date: Wed, 17 Jan 2018 01:09:26 -0800 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-10.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2018 09:09:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : A YANG Data Model for Network Address Translation (NAT) and Network Prefix Translation (NPT) Authors : Mohamed Boucadair Senthil Sivakumar Christian Jacquenet Suresh Vinapamula Qin Wu Filename : draft-ietf-opsawg-nat-yang-10.txt Pages : 97 Date : 2018-01-17 Abstract: For the sake of network automation and the need for programming Network Address Translation (NAT) function in particular, a data model for configuring and managing the NAT is essential. This document defines a YANG module for the NAT function. NAT44, Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Stateless IP/ ICMP Translation (SIIT), Explicit Address Mappings for Stateless IP/ ICMP Translation (SIIT EAM), and IPv6 Network Prefix Translation (NPTv6) are covered in this document. Editorial Note (To be removed by RFC Editor) Please update these statements with the RFC number to be assigned to this document: "This version of this YANG module is part of RFC XXXX;" "RFC XXXX: A YANG Data Model for Network Address Translation (NAT) and Network Prefix Translation (NPT)"; "reference: RFC XXXX" The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-10 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat-yang-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 17 05:27:20 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55611120727 for ; Wed, 17 Jan 2018 05:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 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 aJE8YciFUoDt for ; Wed, 17 Jan 2018 05:27:12 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04AE127601 for ; Wed, 17 Jan 2018 05:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20252; q=dns/txt; s=iport; t=1516195631; x=1517405231; h=references:subject:to:from:message-id:date:mime-version: in-reply-to; bh=SalArwVRGRk+bJWeTiLBUiflMIVI3HKUDkIQozAdfHw=; b=Zoew1k1fGvIeHtyWhKo/6wKuWZS0n0H0gzsfg6ISF+yIKrjsdMpozOdz PQGqB+w+L0zFQAkfnjMj+oL4C/BSjUc/E7WNDWj8yaLlj74b3mkhwF+Kf R5Wo8szNR+GAeBhV7hoJZSnol+XJJ4ZS4e4hAGRC0nJ08s1wiHTqA7qVP o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAQCJTl9a/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQndCeEE4sYj0kniQeOO4ICBwMYC4RJTwKFJBQBAQEBAQEBAQF?= =?us-ascii?q?rHQuFIwEBAQMBAQEhBEcQCyMqAgIhBiYKBg0GAgEBihcDDQgQpUSBbTqHOw2CB?= =?us-ascii?q?AEBAQEBAQEDAQEBAQEBAQERD4oRKQyCeYJrRAEBAgEBF4E+gy+CZQWjLT2EWII?= =?us-ascii?q?wgQWIQYUDghlnhTaDb4dsimmCWECJKIE8NiKBUDIaCBsVGSSCKgmET0A3i2sBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.46,372,1511827200"; d="asc'?eml'208?scan'208,208";a="1500701" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 13:27:09 +0000 Received: from [10.61.81.178] (ams3-vpn-dhcp4531.cisco.com [10.61.81.178]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0HDR9Zx025816 for ; Wed, 17 Jan 2018 13:27:09 GMT References: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com> To: "opsawg@ietf.org" From: Eliot Lear X-Forwarded-Message-Id: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com> Message-ID: <07c55ca8-89dc-6d8b-0701-565c54c402ce@cisco.com> Date: Wed, 17 Jan 2018 14:27:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RH9eKW6FhveBln3EfqwsSetQxCeDxX11i" Archived-At: Subject: [OPSAWG] Fwd: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2018 13:27:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RH9eKW6FhveBln3EfqwsSetQxCeDxX11i Content-Type: multipart/mixed; boundary="H544DIcPaJAlN0suXmnjinbJ9jFWDq6LP"; protected-headers="v1" From: Eliot Lear To: "opsawg@ietf.org" Message-ID: <07c55ca8-89dc-6d8b-0701-565c54c402ce@cisco.com> Subject: Fwd: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt References: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com> In-Reply-To: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com> --H544DIcPaJAlN0suXmnjinbJ9jFWDq6LP Content-Type: multipart/mixed; boundary="------------97C8FEAD1D2C1234F0E388D3" Content-Language: en-US This is a multi-part message in MIME format. --------------97C8FEAD1D2C1234F0E388D3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Based on=C2=A0 this update, I will update draft-ietf-opsawg-mud to match = the model.=C2=A0 In my opinion, while the changes in the ACL draft are substantial, their impact on MUD is minimal. --------------97C8FEAD1D2C1234F0E388D3 Content-Type: message/rfc822; name="Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15_txt."; filename*1="eml" X-Mozilla-Keys: Received: from xch-rtp-002.cisco.com (64.101.220.142) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Mailbox Transport; Tue, 16 Jan 2018 21:17:24 -0600 Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 16 Jan 2018 22:17:23 -0500 Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 16 Jan 2018 22:17:22 -0500 Received: from alln-iport-4.cisco.com (173.37.142.91) by mail.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 16 Jan 2018 22:17:21 -0500 Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 03:17:21 +0000 Received: from alln-inbound-m.cisco.com (alln-inbound-m.cisco.com [173.37.147.243]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0H3H5Pu007250 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK); Wed, 17 Jan 2018 03:17:19 GMT Received-SPF: Pass (alln-inbound-m.cisco.com: domain of netmod-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) identity=mailfrom; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-m.cisco.com; envelope-from="netmod-bounces@ietf.org"; x-sender="netmod-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-m.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-m.cisco.com; envelope-from="netmod-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-m.cisco.com; spf=Pass smtp.mailfrom=netmod-bounces@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dkim=pass (signature verified) header.i=@ietf.org; dkim=hardfail (body hash did not verify [final]) header.i=@gmail.com; dmarc=fail (p=none dis=none) d=gmail.com X-from-outside-Cisco: 2001:1900:3001:11::2c IronPort-PHdr: =?us-ascii?q?9a23=3Agsv6nRUt6M6zfy6k1TX4toFgqL/V8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZxCAtadThVPEFb/W9+hDw7KP9fy4ACpYud6oizMrSNR0TRgLiM?= =?us-ascii?q?EbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVr?= =?us-ascii?q?O+/7BpDdj9it1+C15pbffxhEiCCybL9uMRm6txndutULioZ+N6g9zQfErGFVcO?= =?us-ascii?q?pM32NoIlyTnxf45siu+ZNo7jpdtfE8+cNeSKv2Z6s3Q6BWAzQgKGA1+dbktQLf?= =?us-ascii?q?QguV53sTSXsZnxxVCAXY9h76X5Pxsizntuph3SSRIMP7QawoVTmk8qxmUwHjhj?= =?us-ascii?q?sZODEl8WHXks1wg7xdoBK9vBx03orYbJiIOPZiYq/ReNUXTndDUMlMTSxMGoOy?= =?us-ascii?q?YIQBAeoPI+hXrYrzqVwToxumBwSiBuzixiJGi3PqwaI03PouERrd0Qw8Hd8OtW?= =?us-ascii?q?jYrNXpOKsMV+2+0anGzS/Eb/NTwTrz75LHchA/rvGXXbJ7bM7fxlczFwPFlFqQ?= =?us-ascii?q?r5bqPzWI2esXtWib7vdrWOWqi24ltQ5xvjivyd0qiobTgIIa10rL9SN4wIsuKt?= =?us-ascii?q?24TVR0Yd+gEJdKqy6aMI52T9okTmp1tig6zbgGtoS6fCgM0JknxgDQa+CJc4SS?= =?us-ascii?q?5RLjTumRLDFlj3xmYLKynwi+/VS8xuHhU8S4zVJHojZZntTJuH0BywDf5tWCR/?= =?us-ascii?q?dg40us3DOC2x7P5e1cP0w5lLbXJ4Ikz7ItlJcfrVjPEyrol0rrl6CaakAp9+um?= =?us-ascii?q?6+v6frnro5uROoB1hw3iN6kjm82yAeo6PwULUGWW+fqw2bnm8ELiXLpHgOA6n6?= =?us-ascii?q?/Eu57AP8sbvLS2AwpN34Yj9Rm/CzCm3cwdnXYdLVJFfAiLj4n3NFHSLvD0F/C/?= =?us-ascii?q?g06jkDtzxvDGOKPuAonVI3TdjLvtYatx5ktBxAc30dxT+5dZB78dLP7vR0P8sc?= =?us-ascii?q?HUAgI8PgGx3eroFM1x1oYEVmKOBq+ZPrnSsViN5u83JemDepMVuDP6K/c4/vLh?= =?us-ascii?q?lng5mUIbfaa1w5QXc2u1HvV4LEWFb3rgmNABEX0FvgYmVuzllEWCUSJPZ3a1R6?= =?us-ascii?q?8z/C00B5y4AorYWo+tgaeB0zu8HpFMem9GDVWMG2/yd4qYQ/cMdD6SIsh5nzMe?= =?us-ascii?q?VrihUZQs2g2vtA/h17VnKfDY9TEftZLmzNJ1/fHclQku9TxoCMSQy3uCT2VvkW?= =?us-ascii?q?wWXT82wK9/oUtmx1if0Kh4mOBXFdtJ6/xVVQc6MIbWz/ZmBNDqRgLBYtCJRU68?= =?us-ascii?q?TdWiBTEwTtQxzsQSbEZ8ANWtkhfD0zC2DL8SkryBHIY0/b7E33jtO8Z9zG7L27?= =?us-ascii?q?Mkj1Y9XstPL2ymhrZl+AXIG4HJkl6ZmLqtdagGwCHN82KDx3KUvE5ESA5wTbnF?= =?us-ascii?q?XXcHa0TMqNT2+kfCQKWyBrQnNgtM0tKNKqpRatL1ilVKXuvsONPbY2ipgWe/GQ?= =?us-ascii?q?6Ixq+QbIrtY2gSxj7dB1YYnAAT+naGKBUxCzy9rGLfFzxhCVXvb1nw/ul5rXOx?= =?us-ascii?q?VlU0wB2Sb019y7q1/QYYiuadSvMTw70LoiEhqzZ1HFumw93WCsGAqBZmfKlGfd?= =?us-ascii?q?w951JH33rDtwNhJpygM7xihlkGfgtso0zu0w94CoRbkcc0t34l0AtyKbmE31NG?= =?us-ascii?q?bT+XwZfwOrjPIGno4B+vc7LW2k3Z0NuO5qgA8vE4q1L4sw63DEoi/G5q3MVU03?= =?us-ascii?q?uH+prKCxAeXo72UkYy7xJ6va3VYjEh54PI0n1hKbW7szHD29ItGeQq1A2gcsxD?= =?us-ascii?q?P6OFDw/9D8oaC9KyJ+wtnlijdggEM/xK9K4oI8OmcOOL17OwM+Zkhj2mjH5H7Z?= =?us-ascii?q?th3UKN7CpzVunI04wZzPGf2wuNTy38g0u5ssDrhYBEYikfEXe/ySjmHoFRZ6ty?= =?us-ascii?q?cJ0XBmevOM242tJ+i4TxVH5f8V6pH0kG19OxeRqOc1z92hVd2lkToXO9lyu31S?= =?us-ascii?q?F0nC0orqeEwCPOwv/iewYAOmJRWGZiilLsK5Cuj98GREiocxQplBy96Enkxqhb?= =?us-ascii?q?or5wL3PVQUdOZCX5M2BiUrCsubqFecJA9JQosSBPWuSmfV+aUqL9owcd0y77AW?= =?us-ascii?q?Re2jc7dzC2upjigxN6iXmdI2p0rHbDZc5wwhLf7sTGRfFNxjoGWDV4iT7PC1iz?= =?us-ascii?q?Jdap59WVlpnesu2lS22hV4ZTfjXszY+aqCS74mhqCwWln/+vgt3nDRQ60Sjj2t?= =?us-ascii?q?llWiXHthL8Yoju16uhL+1qZVVnBF7n68VmHYFyiJc/hJYV2XICnJWa4WIHkXvv?= =?us-ascii?q?MdVcwa/+Y3sNRTkOw9HP+gjlxExjI2mVyIL4TXWS3sxha8OmbWMR3yI399pKB7?= =?us-ascii?q?uM7LxYgSt1pUK1rQLeYfhgmzcS0+Au6GIEjOwSpAUtzz6dDawVHUVCISPskBGI?= =?us-ascii?q?5cikrKpLfGavbaSw1E1mkNCjEL6CphtTWGz6epg8BiJ/8sR/MEnQ33308I3rZN?= =?us-ascii?q?7QbdcLvB2OjxjAl/RVKI42lvcShypnPHzysmA7y+ElkBNjxo21vImcK2px+6K1?= =?us-ascii?q?GAJXNjrwZ8kL4DHikb5entqK34CoBphhGDILXJ7yQvKsDD0SsvDnOh2SHz09sX?= =?us-ascii?q?eUBb3fERWD50dhqnLFC4qrOG2PJHkF0dViQwGQJE9Cjw8KQjo6gJ85Gxu2y8zg?= =?us-ascii?q?a0d2+jcR6kTkpRtLz+JiLwP/XXvHpAe0djc0T4CSLB5I4Q5Y/UfYKtCR7uNoHy?= =?us-ascii?q?5E+Z2tthCCKmueZw5QF2EGRlSEB0z/Prmp/dTA9vKXCfa/L/TQYrWDsvBRV/aT?= =?us-ascii?q?xZ2z1Ytq5SqDNsKKPnN6Ff00xlJDXWxlG8TegzgPTjYYlz7Db8GBvxi8+zd4o9?= =?us-ascii?q?uj//TqQwLg+YyPB6FOPtVo/hC8mb2DOPKIhCZlNTZY0YsBxXrWx7cFwVESjDtu?= =?us-ascii?q?dza2HLsctC7NV77fmqhNAxEHbCNzMdNC77gg0QlVJc7bltT126Z9jv41EVhFT0?= =?us-ascii?q?DhmsW3as0KOGyyKFLHBF2XO7SBPzHE38b3YaakQ71KkOpUrwGwuSqcE0L7OzSD?= =?us-ascii?q?kDrpWAqqMeFLkCGbOwdTt528chZ2FWfjS8jqZQG8MN9ylTc226E7hmvWNW4ANj?= =?us-ascii?q?hxa0ZNrrqN7SNcnvp/G3ZO7nx+IOaYmiaZ9PXXKpEMvfR3BSR0kvpQ4G4mxLtN?= =?us-ascii?q?8CFEWPt1lTPXrt5zuVGpiO2Pyjt5UBdVtjlLhZmLslllOanD6pZAXnPE9goX7W?= =?us-ascii?q?qMExQKu8dlCtr3tqBV19jPiKLzKCpZ/t3I/MscHNTbKMWdPHU9NhrpHSbeDBEZ?= =?us-ascii?q?Qj6zKWHfm0tdnemX9nyVsJc6t57smJUVR7BHVVw1De8VCkN/ENMeJ5d3Wysuka?= =?us-ascii?q?SHg84Q+Xq+sB7RSd1Cvp/ZSvKdH/fvKDGfjbZafBYH3bL4LZ8POY38wUBtdl56?= =?us-ascii?q?nIHSEUrKQd9NujFhbhMzoEhV6Hh+QWwz20bkag62/HATFOW0kQIxigdkfest8z?= =?us-ascii?q?Ls6U8tJlXWvCswjFUxmdL9jDCJcz7+NqWwXZpMBCfvq0cxM4j7TBpybQGogUNk?= =?us-ascii?q?MzLETapLj7R8bWBrlBPcuZxXFP5ESq1FbhsQyuuKaPUpyllTtiSnxVRb6uvCE5?= =?us-ascii?q?dtiAwqcZu0pXJaxw1jdMI1JbDXJKdR1lhQnK2Oviio1uAw3A8ROV0A/3+TeC4T?= =?us-ascii?q?pEMIMaMqKDav/uxp8QaCgSdMeHAQV/o2pfJn7ls9O/6Fzy361b5DLFq+OveDIK?= =?us-ascii?q?OYoGjPicmITkks2UMPkklP5aJ23ts7c0qIS0Avy6OcFwwJNMXcLQFVa9Bd9HnI?= =?us-ascii?q?cCmSsOXN2o56P4KnGu/0Su+Osb4egli4EwYxA4QM8sMBE4G20E7CL8fnLaAFxg?= =?us-ascii?q?826Qv3JVWFF+hGeBWRnDgbpMG/yYd93ZNBKTEFHWV9LSK3667Npg8knfqDRtE2?= =?us-ascii?q?bWkBXosfLX85RMy6mzVFsHRHFjW4zuUZyA2a5T/muivQFCX8b8ZkZPqMfxNsCd?= =?us-ascii?q?62+TI486erjF7Y6I7TKH37NdR5ptDP7vkWqIqAC/NRVbN9qVvTm5FER3y2VG7C?= =?us-ascii?q?CcS1J5//a4Y2Ytz0Dne6XUakhj0pTsfxJ8qiLq+SjQ70QoZUtZGR3Co/Os+lCj?= =?us-ascii?q?EeBxBwqvkZ5KJmfwIDY587bgTutwklK6O/IRyY3cmpQ2q3NTRWSPxfx/2gZ7NL?= =?us-ascii?q?1yoscvO6yHw4Q5Egwei38EoNRI0NjhHY3vuse4heUTPvFXxaYQnAuS05l215PO?= =?us-ascii?q?Yo3ug/2A/IsUUbMz2Tb+xmc3ZLv94mClOWPHV2EHE1SEOdjYrY/gGs2Koe8Dda?= =?us-ascii?q?n9ZRyedFqmTxvofDYDKwX6ymsY7Vsyo9bdg+uaJ+LIzjI8uduZzCnzzfV4Xfsg?= =?us-ascii?q?qfXCGmEPpan8BaIDhET/lQhWElJcsGtJJa6UoqTMg+J6ZACLM2qbCscjdrES8S?= =?us-ascii?q?zTQFWIOHxjANnuC8276J3iqWa4koZRwYrI1Z0JxaTDFpJCITuKHlUJ/Z0GqNS2?= =?us-ascii?q?wOKQFU6hxQ5QUGjch2c/zg54abcZlX1jQDpvt1VjfMRJ9l6178RiSMjEHlRe69?= =?us-ascii?q?u+2kwQwUy+jjhcIGUhxyAlQI2uBNi0EzI6t2IaRDgomflBK0UGTW9F3q0uinIl?= =?us-ascii?q?YZ5tfTakWwWIzIqW/7XgUd9GEaA4hVxyeMO44Vll9cYaYmv1UEAo26ek/47joo?= =?us-ascii?q?zoJoV+29V823x18jpHAKTiGrO9VEAuBi9lnQXWs2MNiQtJz5NsAKESdr85qHpg?= =?us-ascii?q?IcyR01an/r+d9nM8hIpwU0cn1KqDSZssG1TZQbi857E5FKJc1w6S6kRfF0faOJ?= =?us-ascii?q?qnhzgYTBj3/U/zdl7QW/zTS3Xa61U+wf+HcRSF0k?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A8GlAADYvl5afQAZASCDgISAEQAsWxkBA?= =?us-ascii?q?QEBAQEBAQEBAQEHAQEBAQGCbFJpgRuPK41ugVsnl0KBPzoTGAuESU+EXkIVAQE?= =?us-ascii?q?BAQEBAQEBAQIQAQELFAhXgjgFAgMaAQUJSyoDAQEBAQEBJgEBAQEBAQEBAQEfA?= =?us-ascii?q?isTLAEBAQECAQEBASQTBgEFCgwSDAIBAQEBAgYBAQUFCw0eCAgDAR0CBA0BBQE?= =?us-ascii?q?cBhMFihUBAw0JAgILmVtAjgAYBQEcgwsFg2YKGScNWYErAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBFQIGEoY/gVeBaSkMgnmCa0QBAQIBAReBPi2DM4I0AQSTPo9rPYg?= =?us-ascii?q?NiD6FAoIZZ4U2g16HfY08AkCFYIMaAgQCBAUCBhQlgRU3I4FRby4kKgEHgXgJN?= =?us-ascii?q?oIGgjNXiXOBcwEBAQ?= X-IPAS-Result: =?us-ascii?q?A8GlAADYvl5afQAZASCDgISAEQAsWxkBAQEBAQEBAQEBAQE?= =?us-ascii?q?HAQEBAQGCbFJpgRuPK41ugVsnl0KBPzoTGAuESU+EXkIVAQEBAQEBAQEBAQIQA?= =?us-ascii?q?QELFAhXgjgFAgMaAQUJSyoDAQEBAQEBJgEBAQEBAQEBAQEfAisTLAEBAQECAQE?= =?us-ascii?q?BASQTBgEFCgwSDAIBAQEBAgYBAQUFCw0eCAgDAR0CBA0BBQEcBhMFihUBAw0JA?= =?us-ascii?q?gILmVtAjgAYBQEcgwsFg2YKGScNWYErAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQI?= =?us-ascii?q?GEoY/gVeBaSkMgnmCa0QBAQIBAReBPi2DM4I0AQSTPo9rPYgNiD6FAoIZZ4U2g?= =?us-ascii?q?16HfY08AkCFYIMaAgQCBAUCBhQlgRU3I4FRby4kKgEHgXgJNoIGgjNXiXOBcwE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.46,371,1511827200"; d="scan'208";a="52586493" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([IPv6:2001:1900:3001:11::2c]) by alln-inbound-m.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 03:17:16 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A15412EC45; Tue, 16 Jan 2018 19:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1516159035; bh=eCGrh/v07S6hQDK3XLvr0G45HbiX6Pl6zBHzXCjtucs=; h=From:Date:References:To:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=bwMB3cWNlWPPiTzZlDerXHW/uaVC2yNq24mLpZjpVcHwx8WaaD5bUBE4rIJyWS/W8 paVzSReAkNZIacRK6rWQ1Q1RdxXRxP+OdpCq9MOKtel26vJ+XMhPgxj7P3BJHzz09P a2FL01CRkYe4sKY1aQcdg086V2/L1GyoZPR/0Su0= X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED8A612EB93 for ; Tue, 16 Jan 2018 19:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 aTZxFMuEvRnh for ; Tue, 16 Jan 2018 19:17:12 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 3ADEE12D949 for ; Tue, 16 Jan 2018 19:17:12 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id a70so12151031oib.1 for ; Tue, 16 Jan 2018 19:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=bNOyaV6Iml9LyOczFv5stNdyYipgSHLguHfxjWN0iaU=; b=oriZu3nhgY6FFUAK66m/nxmsJapRxezDu4Fv+s8FJ5DAdvaVzy+aQ3NuCz+cws7LaX PyJfyHaLQxdygyc4lcUt2jSWdtCs36zfgoT+a10i+G4F7IUwuykaBdPa4SiKbO6VNkIv NIU1OVAWmmZtIvun2FhPr0uVgKOQlVHAebcT7c091aRI1zYNVSujsFq3UG9JjPWavc0r dFYV9CyOWTFGX9YrrGX6Ayc6P+NSdPeAlQVxrGiNEIE7GVZnit3IO111FZAVbf/dSNdt wL9GSUO5McyC2ChDTmxh3txzEpAPK6W6eM1vxnW1JSOIsVPU2KS+Xvyi4a/bqD506WBG s4LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=bNOyaV6Iml9LyOczFv5stNdyYipgSHLguHfxjWN0iaU=; b=HFW3qEsbhQT/Y/aWdkCnCwPE1Hu50L7jP+h+F+yzp6397aIq5ALgPGzjRUBtG2GdpD lf4vJsPxIdG8z2ztdNIspLWLU6Y60jh2M+3MHNe4MbtNMk7lyxVkD0C4kbD51V70mc7G mKu+SpnDOmOXiiEa8juMUC2wBiwgbVQq/DPJS38v1RaDNKk06nQcMd2Ol/YSbzKHQXhH 7QasOTO3iDRMlE4yhN0TbucYrNySJAlOyXU+SM9+43hzgr+KA5t42kSmvavAP50P8T4R AdoghyKJ9J//pXF/VBGY3nNYx7pkY+pxLI31bkUSS5oHa2UNpXIUU2T4jw74+uW0gpUg 4BYA== X-Gm-Message-State: AKwxytfBVDHh+gXGbYj38hmlIYLxci4Vcj5LaCgButJdP9jI41lDFqaE MqF2m1V4+fVvfaOXb5AKl1SGBuvX X-Google-Smtp-Source: ACJfBostmQQ6Cr4eGRlKC3wSsafzZkJf44S5YV26w3XPNLkQYBuypE1YP71oPsuu16HCCyPW2LLMGw== X-Received: by 10.202.68.215 with SMTP id r206mr303071oia.80.1516159031180; Tue, 16 Jan 2018 19:17:11 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:9460:66f7:4529:bc31]) by smtp.gmail.com with ESMTPSA id w2sm1749693ota.5.2018.01.16.19.17.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jan 2018 19:17:10 -0800 (PST) From: Mahesh Jethanandani Date: Tue, 16 Jan 2018 19:17:08 -0800 References: <151615867250.15562.7858111799192763218@ietfa.amsl.com> To: NETMOD Working Group In-Reply-To: <151615867250.15562.7858111799192763218@ietfa.amsl.com> Message-ID: <411FD00B-42CD-4108-AC45-72CFA2A392D3@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-15.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: netmod-bounces@ietf.org Sender: netmod Return-Path: netmod-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-RTP-001.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: 570774ca-7e56-4275-0c92-08d55d58d361 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 This version of the drafts addresses comments received during the last run of the LC. We, the authors, believe that this document is ready for LC. > On Jan 16, 2018, at 7:11 PM, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Modeling WG of the IETF. > > Title : Network Access Control List (ACL) YANG Data Model > Authors : Mahesh Jethanandani > Lisa Huang > Sonal Agarwal > Dana Blair > Filename : draft-ietf-netmod-acl-model-15.txt > Pages : 51 > Date : 2018-01-16 > > Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. > > Editorial Note (To be removed by RFC Editor) > > This draft contains many placeholder values that need to be replaced > with finalized values at the time of publication. This note > summarizes all of the substitutions that are needed. Please note > that no other RFC Editor instructions are specified anywhere else in > this document. > > Artwork in this document contains shorthand references to drafts in > progress. Please apply the following replacements > > o "XXXX" --> the assigned RFC value for this draft both in this > draft and in the YANG models under the revision statement. > > o Revision date in model needs to get updated with the date the > draft gets approved. The date also needs to get reflected on the > line with . > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-acl-model-15 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-15 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --------------97C8FEAD1D2C1234F0E388D3-- --H544DIcPaJAlN0suXmnjinbJ9jFWDq6LP-- --RH9eKW6FhveBln3EfqwsSetQxCeDxX11i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpfTywACgkQh7ZrRtnS ejNdkwf/ZzAP7CO4SQ4elDUQ8jwb8eIoxSzJX8o27joGn7XHDdg9texMngkYA8ZI h8fTCcCQCLjj2MP+HReDtA0tcBIaSsXc/M2EW7NeyaVMF239p4HOfuhmDeWA4bTr mFmJy38Vg023MflxL63bJDw7EhBIA6vkITB9IFvi/mRTQ/G1jBxdH2fb931q/BBr 0/387vhSTMWTtaB/InwteaIv80qYg1EktbzwY2zgWfyL5iE+NeaCKiQ7k6ol2irp tr9BPkCST9TSjxds+6mzrPnh1msBs8RSXGAgWXZhGqVXPl9vhAc6rg7GOPdvBPAK +UT/sJPai6eev8NURgs7cObuoiyOCw== =+Ov6 -----END PGP SIGNATURE----- --RH9eKW6FhveBln3EfqwsSetQxCeDxX11i-- From nobody Wed Jan 17 19:06:50 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C88212D94D; Wed, 17 Jan 2018 19:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uk2GjgOBxj4H; Wed, 17 Jan 2018 19:06:48 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 6534B12D88C; Wed, 17 Jan 2018 19:06:48 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 65FD820F58A4A; Thu, 18 Jan 2018 03:06:45 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 18 Jan 2018 03:06:46 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Thu, 18 Jan 2018 11:06:41 +0800 From: Tianran Zhou To: "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for draft-ietf-opsawg-ipfix-bgp-community Thread-Index: AdOQCV9j2OxCryuCStaCuXJblDRHdA== Date: Thu, 18 Jan 2018 03:06:41 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 03:06:49 -0000 Hi WG, The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the latest= drafts to the mailing list, and believe that the document is ready for LC. This starts a 2 week WG LC on https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04 Please read the above draft and send any issues, comments, or corrections t= o this mailing list.=20 All supports and concerns are welcome and helpful for the authors. We are also looking for a document shepherd, best with operator background,= to help the following procedures. =20 The WG LC will close on Feb 1, 2018. Authors please indicate whether you are aware of any IPR for the draft. Thanks, Tianran, as OPSAWG co-chair From nobody Thu Jan 18 18:14:52 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453A012D838; Thu, 18 Jan 2018 18:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 kdyMzHDCIMPy; Thu, 18 Jan 2018 18:14:49 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 0356D1270A3; Thu, 18 Jan 2018 18:14:49 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3FC3E33CF341F; Fri, 19 Jan 2018 02:14:45 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 19 Jan 2018 02:14:46 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Fri, 19 Jan 2018 10:14:37 +0800 From: Duzongpeng To: Tianran Zhou , "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for draft-ietf-opsawg-ipfix-bgp-community Thread-Index: AdOQCV9j2OxCryuCStaCuXJblDRHdAAv4Vcg Date: Fri, 19 Jan 2018 02:14:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 02:14:50 -0000 Hi All, IMHO, it is ready for publish. The mechanism will benefit the network oper= ation.=20 Best Regards Zongpeng Du -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Thursday, January 18, 2018 11:07 AM To: opsawg@ietf.org Cc: opsawg-chairs@ietf.org Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community Hi WG, The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the latest= drafts to the mailing list, and believe that the document is ready for LC. This starts a 2 week WG LC on https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04 Please read the above draft and send any issues, comments, or corrections t= o this mailing list.=20 All supports and concerns are welcome and helpful for the authors. We are also looking for a document shepherd, best with operator background,= to help the following procedures. =20 The WG LC will close on Feb 1, 2018. Authors please indicate whether you are aware of any IPR for the draft. Thanks, Tianran, as OPSAWG co-chair _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Jan 19 02:20:38 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CAD3A12D7E9; Fri, 19 Jan 2018 02:20:28 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D73127AD4; Fri, 19 Jan 2018 02:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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=googlemail.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 oV8inIWgsZ4L; Fri, 19 Jan 2018 02:20:24 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 31BEA12D832; Fri, 19 Jan 2018 02:20:21 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id t22so1669221ioa.7; Fri, 19 Jan 2018 02:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YDJuydtvwnyyuEvZMDSRw5Du6brP3oqQ1iXTUhF8BLQ=; b=QrRrJRUR/FluPfKJOwQ/u68xg/QhC8Qa/6hE281y4+E1QoUjKm+sNUgQdDMqRL7b3L AF9wjqApmE9vZDr5NVlI2lLRAPGiSG5jFO3LhpQqdhdsPU6pTRALudGc5hv0rHMi6L3z rx56P3oN65tC6jBXY31kiE+OdD+3lPqF3myMkFBX0h4Q3hkM822iqX1p7HU7DOii110K C8vE0YncRmx/3G7W4j/f4+g6rW6VcuC2ipbmoqLOz0DxnlQkDpBDettnNN1idL8zVIh9 LRSW04r6cVjpw1/a8fdkd/KAz6KgfwPHKpIyPSuG5JUQuob8GaQg+VmRYxhX3VRCj33d qNhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YDJuydtvwnyyuEvZMDSRw5Du6brP3oqQ1iXTUhF8BLQ=; b=n1V7CcR/mKNLC+mlzw8TZ0vGkWB9ZLJ+Tdgf7wvBeWUUCW+iVfIeCsGyyrpcC9mg6+ OJ9a0tW3i+cBLFOTPmP1Q9UZLq4CVKjE6wLowcAL7mY4a+mX/w+Pzvccyvn0sqsQuxpb egWt2AZjBaN1qAh/ux6g5KNuFaHxIvHLOP3U0rK+uJNTVNIsFF5DVzKjQMysWEQqqr1b iWClim5h6ht7opUuU9Z3hi4zAdSobuGl5DFv7Tk/P+zSx5whoGrZ8rmBeUfVK2euzwyQ Pmh0i5MtI9Tl8hEFHUtwFzo39cHoxevy8v7BjYuAXsAFLIML5gMzSBOZE2QvzMv3NHax Al4Q== X-Gm-Message-State: AKwxytfiesTcp9r2Wb6tYVTAa4Y3GD9KsHZgl9/KtVXuh1cAZSofE0hM T5J8sHl5FJha+b2BJ3KUxPu6ddQamV41dONsX+g= X-Google-Smtp-Source: ACJfBovhd7UT2N/NlgjX8n2Aa9jKd5jj/++QGBt8aBL8431uZkS288Ozp1oLSiPKSBnnWIk1fcpc2pphAKNr5VzWhR8= X-Received: by 10.107.107.24 with SMTP id g24mr9057439ioc.125.1516357220252; Fri, 19 Jan 2018 02:20:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.207.7 with HTTP; Fri, 19 Jan 2018 02:20:19 -0800 (PST) In-Reply-To: References: <151302958109.21278.5686525939396201959@ietfa.amsl.com> From: Ines Robles Date: Fri, 19 Jan 2018 12:20:19 +0200 Message-ID: To: Kathleen Moriarty Cc: rtg-dir@ietf.org, draft-mm-wg-effect-encrypt.all@ietf.org, IETF Content-Type: multipart/alternative; boundary="089e0825e98877434b05631e6d66" Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180119102028.CAD3A12D7E9@ietfa.amsl.com> Resent-Date: Fri, 19 Jan 2018 02:20:28 -0800 (PST) Archived-At: Subject: Re: [OPSAWG] Rtgdir last call review of draft-mm-wg-effect-encrypt-13 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 10:20:29 -0000 --089e0825e98877434b05631e6d66 Content-Type: text/plain; charset="UTF-8" Excellent! Thank you very much Cheers, Ines. 2018-01-15 21:06 GMT+02:00 Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com>: > Hi Ines, > > We added the following reference into the working version per your comment: > > http://www.jjsylvia.com/bigdatacourse/wp-content/ > uploads/2016/04/p14-verble-1.pdf > > Thank you, > Kathleen > > On Mon, Jan 8, 2018 at 12:51 PM, Ines Robles > wrote: > > Hi Kathleen, > > > > Ok, thank you for the feedback. > > > > Best, > > > > Ines. > > > > 2018-01-04 20:13 GMT+02:00 Kathleen Moriarty > > : > >> > >> Hello Ines, > >> > >> Thanks again for your review. Edits have been made in our working > >> version that we hope to post soon. > >> > >> On Mon, Dec 11, 2017 at 9:27 PM, Kathleen Moriarty > >> wrote: > >> > Ines, > >> > > >> > Thank you very much for your review! We're working on the comments > >> > received and the nits you found will be addressed and are much > >> > appreciated. > >> > > >> > Best regards, > >> > Kathleen > >> > > >> > On Mon, Dec 11, 2017 at 4:59 PM, Ines Robles > >> > wrote: > >> >> Reviewer: Ines Robles > >> >> Review result: Ready > >> >> > >> >> RtgDir review: draft-mm-wg-effect-encrypt-13.txt > >> >> > >> >> Hello, > >> >> > >> >> I have been selected as the Routing Directorate reviewer for this > >> >> draft. The > >> >> Routing Directorate seeks to review all routing or routing-related > >> >> drafts as > >> >> they pass through IETF last call and IESG review, and sometimes on > >> >> special > >> >> request. The purpose of the review is to provide assistance to the > >> >> Routing ADs. > >> >> For more information about the Routing Directorate, please see > >> >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > >> >> > >> >> Although these comments are primarily for the use of the Routing ADs, > >> >> it would > >> >> be helpful if you could consider them along with any other IETF Last > >> >> Call > >> >> comments that you receive, and strive to resolve them through > >> >> discussion or by > >> >> updating the draft. > >> >> > >> >> Document: Effect of Pervasive Encryption on Operators - > >> >> draft-mm-wg-effect-encrypt-13 Reviewer: Ines Robles Review Date: > >> >> 12-11-2017 > >> >> Intended status: Informational > >> >> > >> >> Summary: > >> >> This document discusses current security and network management > >> >> practices to > >> >> help guide protocol development in support of manageable, secure > >> >> networks. > >> >> > >> >> The draft is ready, few typos found. > >> >> > >> >> Comments: > >> >> > >> >> I believe the draft is technically good. This document is well > written > >> >> and > >> >> clear to understand. > >> >> > >> >> Major Issues: > >> >> > >> >> No major issues found. > >> >> > >> >> Minor Issues: > >> >> > >> >> Section 2: > >> >> > >> >> "... Following the Snowden revelations,..." => It would be nice to > add > >> >> some > >> >> references here > >> > >> Yes, the problem we have had so far is finding ones that aren't > >> articles that may not be stable. A quick search pulls up new ones > >> like the following: > >> http://fortune.com/2016/04/25/snowden-encryption-james-clapper/ > >> > >> We'll have to try again to find an academic publication. > >> > >> >> > >> >> Section 2.2.5: > >> >> "DRM..."=> I would expand it to Digital Rights Management (DRM) > >> > >> Added, thank you! > >> > >> >> > >> >> Section 6: > >> >> > >> >> inlcudes=> includes > >> > >> Fixed, thanks. > >> >> > >> >> Section 6.1: > >> >> "information For example" => period missing? > >> > >> Ack, thanks! > >> >> > >> >> Section 6.2: > >> >> "soltuions" -> solutions > >> Fixed. > >> >> > >> >> Section 7.1 title: > >> >> "Encypted" => Encrypted > >> Fixed. > >> > >> Thanks for your review! > >> > >> > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > > >> > Best regards, > >> > Kathleen > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > > > > > -- > > Best regards, > Kathleen > --089e0825e98877434b05631e6d66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Excellent!

Thank you very much

=
Cheers,

Ines.

2018-01-15 21:06 GMT+02:0= 0 Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com&g= t;:
Hi Ines,

We added the following reference into the working version per your comment:=

http://www.jjsylvia= .com/bigdatacourse/wp-content/uploads/2016/04/p14-verble-1.p= df

Thank you,
Kathleen

On Mon, Jan 8, 2018 at 12:51 PM, Ines=C2=A0 Robles
<mariainesrobles@googlemail.com> wrote:
> Hi Kathleen,
>
> Ok, thank you for the feedback.
>
> Best,
>
> Ines.
>
> 2018-01-04 20:13 GMT+02:00 Kathleen Moriarty
> <kathleen.moria= rty.ietf@gmail.com>:
>>
>> Hello Ines,
>>
>> Thanks again for your review.=C2=A0 Edits have been made in our wo= rking
>> version that we hope to post soon.
>>
>> On Mon, Dec 11, 2017 at 9:27 PM, Kathleen Moriarty
>> <kathleen.m= oriarty.ietf@gmail.com> wrote:
>> > Ines,
>> >
>> > Thank you very much for your review!=C2=A0 We're working = on the comments
>> > received and the nits you found will be addressed and are muc= h
>> > appreciated.
>> >
>> > Best regards,
>> > Kathleen
>> >
>> > On Mon, Dec 11, 2017 at 4:59 PM, Ines Robles
>> > <mariain= esrobles@googlemail.com> wrote:
>> >> Reviewer: Ines Robles
>> >> Review result: Ready
>> >>
>> >> RtgDir review: draft-mm-wg-effect-encrypt-13.txt
>> >>
>> >> Hello,
>> >>
>> >> I have been selected as the Routing Directorate reviewer = for this
>> >> draft. The
>> >> Routing Directorate seeks to review all routing or routin= g-related
>> >> drafts as
>> >> they pass through IETF last call and IESG review, and som= etimes on
>> >> special
>> >> request. The purpose of the review is to provide assistan= ce to the
>> >> Routing ADs.
>> >> For more information about the Routing Directorate, pleas= e see
>> >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>> >>
>> >> Although these comments are primarily for the use of the = Routing ADs,
>> >> it would
>> >> be helpful if you could consider them along with any othe= r IETF Last
>> >> Call
>> >> comments that you receive, and strive to resolve them thr= ough
>> >> discussion or by
>> >> updating the draft.
>> >>
>> >> Document: Effect of Pervasive Encryption on Operators - >> >> draft-mm-wg-effect-encrypt-13 Reviewer: Ines Robles Revie= w Date:
>> >> 12-11-2017
>> >> Intended status: Informational
>> >>
>> >> Summary:
>> >> This document discusses current security and network mana= gement
>> >> practices to
>> >> help guide protocol development in support of manageable,= secure
>> >> networks.
>> >>
>> >> The draft is ready, few typos found.
>> >>
>> >> Comments:
>> >>
>> >> I believe the draft is technically good. This document is= well written
>> >> and
>> >> clear to understand.
>> >>
>> >> Major Issues:
>> >>
>> >> No major issues found.
>> >>
>> >> Minor Issues:
>> >>
>> >> Section 2:
>> >>
>> >> "... Following the Snowden revelations,..." =3D= > It would be nice to add
>> >> some
>> >> references here
>>
>> Yes, the problem we have had so far is finding ones that aren'= t
>> articles that may not be stable.=C2=A0 A quick search pulls up new= ones
>> like the following:
>> http://fortune.com/2016/04/2= 5/snowden-encryption-james-clapper/
>>
>> We'll have to try again to find an academic publication.
>>
>> >>
>> >> Section 2.2.5:
>> >> "DRM..."=3D> I would expand it to=C2=A0 Digi= tal Rights Management (DRM)
>>
>> Added, thank you!
>>
>> >>
>> >> Section 6:
>> >>
>> >> inlcudes=3D> includes
>>
>> Fixed, thanks.
>> >>
>> >> Section 6.1:
>> >> "information For example" =3D> period missin= g?
>>
>> Ack, thanks!
>> >>
>> >> Section 6.2:
>> >> "soltuions" -> solutions
>> Fixed.
>> >>
>> >> Section 7.1 title:
>> >> "Encypted" =3D> Encrypted
>> Fixed.
>>
>> Thanks for your review!
>>
>>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > Best regards,
>> > Kathleen
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>



--

Best regards,
Kathleen

--089e0825e98877434b05631e6d66-- From nobody Fri Jan 19 08:28:47 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A4C12DA29; Fri, 19 Jan 2018 08:28:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , "Paul Hoffman" X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151637932073.2356.7015501311930603944.idtracker@ietfa.amsl.com> Date: Fri, 19 Jan 2018 08:28:40 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-mm-wg-effect-encrypt-15.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 16:28:41 -0000 A new version (-15) has been submitted for draft-mm-wg-effect-encrypt: https://www.ietf.org/internet-drafts/draft-mm-wg-effect-encrypt-15.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-mm-wg-effect-encrypt-15 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Fri Jan 19 08:46:05 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3841412DA4F; Fri, 19 Jan 2018 08:45:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , "Paul Hoffman" X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151638035722.2417.503701381264209617.idtracker@ietfa.amsl.com> Date: Fri, 19 Jan 2018 08:45:57 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] Datatracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 16:45:57 -0000 IESG state changed: New State: IESG Evaluation (The previous state was Waiting for AD Go-Ahead) Datatracker URL: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ From nobody Fri Jan 19 08:46:52 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E91912DA53; Fri, 19 Jan 2018 08:46:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "The IESG" , , , , , , "Paul Hoffman" X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151638040816.2459.3227594498315362140.idtracker@ietfa.amsl.com> Date: Fri, 19 Jan 2018 08:46:48 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] Telechat update notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 16:46:48 -0000 Telechat date has been changed to 2018-02-08 from 2017-04-13 Datatracker URL: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ From nobody Fri Jan 19 19:25:15 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C55BC1271DF; Fri, 19 Jan 2018 19:25:13 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9713E1273B1 for ; Fri, 19 Jan 2018 19:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 iZtAc8crPj9w for ; Fri, 19 Jan 2018 19:25:10 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 725401271DF for ; Fri, 19 Jan 2018 19:25:10 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ecjmF-0005zT-Kd for draft-mm-wg-effect-encrypt.all@ietf.org; Sat, 20 Jan 2018 04:25:08 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ecjmC-0000Se-Bg for draft-mm-wg-effect-encrypt.all@ietf.org; Fri, 19 Jan 2018 22:25:04 -0500 Received: (qmail 22567 invoked from network); 20 Jan 2018 03:25:01 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 20 Jan 2018 03:25:01 -0000 To: Kathleen Moriarty References: <1ecac9b1-685b-8114-780a-a43425fb167d@huitema.net> Cc: draft-mm-wg-effect-encrypt.all@ietf.org From: Christian Huitema Message-ID: Date: Fri, 19 Jan 2018 17:24:59 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5oy0i7HmHMN69YM10NvZmIMXv9krsgRhBn0ayn6qsUc7InBZ12RzAnfB ETrOZYNjIXKaajk3XDi+BsF1NYTF5nIFtwJEKaklq458dUTNtx6IYETbgrveScIQj/s9kzeg2uKV se1sVhWabI0/+PN3sIJV0oqgDt6uIMJQLNWWX/KRwVuupfPltUa0ahCspw/cF75jlatt7W0MNi2d 0V/iMmZqbSw0FVRJK9H3d0zNEAUTOthv1Ou3CmmtB22h9g/KPA2e3QJODyA5SR2vbuhrBKvynvLP LrRh0/EOaSVotjFa+xL2pvLWAu8MmUOH8wfPvnFaPc0PnFRbqEtbatkSOSrjKiXZ6WyzC708Oxxz g1wN5Oj564+e6R2rCFo8ZeVUGoQTehXIN8sVozy06XZAec9bkKHNkJb4Y+D0fBYZ0C4t+QmxyYwW Tu+AkpEP/xGNwycC359BPtk4NdYFkImQjwM+PyfpdAljEJHtH65Ir9noASJFC/49WOPBr5nlEUI4 xEUmWV4AHV0hG5cVBfgVto4TtOAtPZUVrjHikzxmb0PvxMyEzcjYt9zTs5MDCF+RrWUm8Kp82b01 wG3F8P89dsnvk1fRjoItx7YLhvGGM0RwEezyEW9535MlAMHubjwbnLqle6mV8bL7QVpQgH0OJtkm 9Zn0z87p5WpuuLVDQ7z/rN6SEDk6VYNDwN2YVhhkMI8wzO7BnK/sKKmCC7HFY25opGC5JL/QUi9o rw58QwcyIFZKgL3fAWtSsNto2jgelxeGLy+kHML0RBhDfH9SZerDqcigOvSxdRnthmhn8Zn6buGO ZiQZY1DAQ45HLrO2p7c/Iw99FQBjLIKvgjXrQbbHaImbMLkGaJ3cdSMzBM+Y/2rAztFeklLxGNN3 KHaPkGqVzcn9qarTSlKOcdnaEybtCZkpqk1NBbXoyWiBudPrNGP0PwcsocAqk8Y/wQ+e4Kylr4RY cArUTDzywdlBS5A= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180120032513.C55BC1271DF@ietfa.amsl.com> Resent-Date: Fri, 19 Jan 2018 19:25:13 -0800 (PST) Archived-At: Subject: Re: [OPSAWG] Christian's review of draft-mm-wg-effect-encrypt-13 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 03:25:14 -0000 I will look at the latest version soon, but let's answer first an editorial point. On 1/5/2018 6:07 AM, Kathleen Moriarty wrote: > Thanks for your review and helpful comments! Would you be okay with > an ack for your review and comments in the draft? I am fine with that, as long as this does not appear as an endorsement of the various atrocities described in the draft... -- Christian Huitema From nobody Sat Jan 20 18:57:46 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F308127286; Sat, 20 Jan 2018 18:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 cXgtYQjYFYQi; Sat, 20 Jan 2018 18:57:42 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254021.outbound.protection.outlook.com [40.92.254.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F7912025C; Sat, 20 Jan 2018 18:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=s8pRb4HHpkzaepbmQ7+nfKQdYffFDNs4o1jj7aTx0PY=; b=GFnhpBNfOz8Pp7G6bCtLr3n2vzm3aZ1j1WCF8oPYQ1gGq2Nvlf3h+bnGMHTHvT8RB1/xY0dNhiyshbKrt2Qezvgfm9W+Of+ePuuZqrrrp8B7nkbOo2B7HSpZcKpwRMkO4b7GFRvyIDfW7tGYFK4HFlKDTxJkesG3EmbuQRruXguaYmXVCdty+vjpyFB6UdrdE5lW5HTblewjkmtzDZNuuCyKkiHKK0u0qo1th+dfjK9AxbQLjLIJkR2/Vo3yMrXNbg+8UbevesbTlgSqQUAPlQa+dgAwrq/T9VBf6FqbBabi0lOytmEpp6X5hmiYLUcPPtWxASq4MtRPvrHbcD7z2g== Received: from PU1APC01FT026.eop-APC01.prod.protection.outlook.com (10.152.252.51) by PU1APC01HT110.eop-APC01.prod.protection.outlook.com (10.152.253.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.19; Sun, 21 Jan 2018 02:57:38 +0000 Received: from HK2PR0601MB1492.apcprd06.prod.outlook.com (10.152.252.53) by PU1APC01FT026.mail.protection.outlook.com (10.152.252.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.19 via Frontend Transport; Sun, 21 Jan 2018 02:57:39 +0000 Received: from HK2PR0601MB1492.apcprd06.prod.outlook.com ([fe80::582d:7489:e2a7:f1e2]) by HK2PR0601MB1492.apcprd06.prod.outlook.com ([fe80::582d:7489:e2a7:f1e2%14]) with mapi id 15.20.0428.019; Sun, 21 Jan 2018 02:57:39 +0000 From: li zhenqiang To: Zhoutianran , opsawg CC: opsawg-chairs Thread-Topic: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community Thread-Index: AQHTkmOY1BU4Tu2sc02MZT1DKCw5oA== Date: Sun, 21 Jan 2018 02:57:38 +0000 Message-ID: References: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:F0D85A51CAFBF4849000DB3030B80667610BC0E1D42162B903646D44584F1C72; UpperCasedChecksum:E4AD4DB7A81F5A10BC5D01CB6391B571979B8B53036803F0D8F9AE1C0626887E; SizeAsReceived:7133; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [2UtlzJOWJ5nx4iUsWN1oNCCqeQFegnzl] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT110; 6:uxpChWVq3WsbHT/XTBomdiu9WdnX3alg7wOzbqD34y4hVU19QsJousijKNvaZFVDtl4nC8wvX9XzTsnoAeNjBghiNdS6ntlByhiseQmixdhXHcFCj3x2MZfxW/Z5stuNaH8Y2hVOZJrr6g69gf2LBsIcsuJNZL6tG/Gyv9C/CBJZ4I0BdL7QFom3wnsmJpDPbsbpSWYpGuuqrK+pkDuD6OPkNdE2mqewy2fbETaXO4HaeSNcATLlX4B0iSm0XgAACb4AEO9Zu6OgwsY6S+dqulsd39mQCFmnJXFZKDoeruKQACc4Ojzjzl5HwXLgGOd148+rBtwAjeDKzFErg6aECOHOmwStQXivOR7eLGF5wC4=; 5:Jgwd54ACbdst01k/tUee2rxsoPpVQmNlb3/4eroVX52AEJ5v6GLgAvq4EJTOBLwyww2Ws91lj/2H79CM1c/b79gulrYOLWaMV7sokS5xqgKXR9xkq+JNlVl8O58QBHQ+jRy8crNZGZXLMADtfBsqISeSJMCZn1mv69JcIgmsGSA=; 24:ZynnlCacHcXYgtDXLHjuOI+vViUTAuHpUDev18z6fMohX60YKNiXbbeAPxOOJgXMNedDIdSMkJL9u8ezvPoZjQiD7/lCAxOpk15Jzebq4Tg=; 7:PS+TNMqKu/FLxHrmhkHvAz4/NMjBWM5hAodKnxgB+WX+DtesJ8DK4J4ccO1nSGpFIeBH03Z4kCcBgf36B377rfKm2yntM+cMLwV3JDALPqf14rldD6TeDG0wurk5gObahhxfQhPSlDd4eUS4OeRuqVQSFPhyYX2d8FefO36eFzMW9T80rPWuMGRtEtdzLScFVywwcJW0gXsB5fTJ9P1oPK+cOUteluKEKuVF1gHIa4+7a49xmjqn9CAwQ04DF7Xn x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:PU1APC01HT110; x-ms-traffictypediagnostic: PU1APC01HT110: x-ms-office365-filtering-correlation-id: f4233655-4e8d-4772-2993-08d5607abab3 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT110; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT110; x-forefront-prvs: 0559FB9674 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT110; H:HK2PR0601MB1492.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB1492A1796398496E7ADE15F8FCED0HK2PR0601MB1492_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4233655-4e8d-4772-2993-08d5607abab3 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2018 02:57:38.9561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT110 Archived-At: Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 02:57:44 -0000 --_000_HK2PR0601MB1492A1796398496E7ADE15F8FCED0HK2PR0601MB1492_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, As a co-author, I think the document is ready to be published. As for the IPR, I am aware of one patent application that may relate to th= is draft. The owner of the related patent is China Mobile whose legal depar= tment is taking the procedure to disclose. Thank you all for your support! Best Regards, Zhenqiang Li ________________________________ li_zhenqiang@hotmail.com From: Tianran Zhou Date: 2018-01-18 11:06 To: opsawg@ietf.org CC: opsawg-chairs@ietf.org Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community Hi WG, The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the latest= drafts to the mailing list, and believe that the document is ready for LC. This starts a 2 week WG LC on https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04 Please read the above draft and send any issues, comments, or corrections t= o this mailing list. All supports and concerns are welcome and helpful for the authors. We are also looking for a document shepherd, best with operator background,= to help the following procedures. The WG LC will close on Feb 1, 2018. Authors please indicate whether you are aware of any IPR for the draft. Thanks, Tianran, as OPSAWG co-chair _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_HK2PR0601MB1492A1796398496E7ADE15F8FCED0HK2PR0601MB1492_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <16D4CF9ED705144DB502C8F128B52E1F@apcprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Dear all,

As a co-author, I think the document is ready to be published. 
As for the IPR, I am aware of one patent a= pplication that may  relate to this draf= t. The owner of the related patent is&nb= sp;China Mobile whose legal department is tak= ing the procedure to disclose.

Thank you all for your support!

Best Regards,
Zhenqiang Li
li_zhenqiang@hotmail.com
 
Date: 2018-01-18 11:06
Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-co= mmunity
Hi WG,
 
The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the l= atest drafts to the mailing list, and believe that the document is ready fo= r LC.
 
This starts a 2 week WG LC on
https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04
 
Please read the above draft and send any issues, comments, or correcti= ons to this mailing list.
All supports and concerns are welcome and helpful for the authors.
 
We are also looking for a document shepherd, best with operator backgr= ound, to help the following procedures. 
 
The WG LC will close on Feb 1, 2018.
Authors please indicate whether you are aware of any IPR for the draft= .
 
Thanks,
Tianran, as OPSAWG co-chair
 
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
--_000_HK2PR0601MB1492A1796398496E7ADE15F8FCED0HK2PR0601MB1492_-- From nobody Sun Jan 21 22:38:10 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F26F120726; Sun, 21 Jan 2018 22:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 AmlHQJb56KNQ; Sun, 21 Jan 2018 22:38:06 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255054.outbound.protection.outlook.com [40.92.255.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705EF120047; Sun, 21 Jan 2018 22:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WIYcbRxthvh/pLTtcY2YCzgSvcLTO4sDavGinkO3Yi8=; b=R7ds6tw46RT3yOO0dT6GLr5UaqdNIJ3yk4r6Z1Qpl0kbGyLSmjEAos/tWrorzmurUhWNp0sPb5LpqZqlWcHfoO6fPqWZYymezlqBwZsYtpQcT9V+4tqMvz9oqlP5hx1sNqwr2XoBDTKcl59XILorIyzZ5nnSKt6d3xMzAz81ntqIJ31Fig2Jbry/75aXcNfW0iD7Lm9pQhjEmSJfoX9ucPpPtHR0XCj0NyJd9c7fj474MvaNXVS1r/rL2g97YjkufKUwCSYNZHXUvd4ioNuaWXuJgSsE4cTA6fO+m18RxhTP+ttoo/fcrJFFbL71rJh9q+YR4VNWLYKBTEEIDzGHUw== Received: from HK2APC01FT023.eop-APC01.prod.protection.outlook.com (10.152.248.53) by HK2APC01HT084.eop-APC01.prod.protection.outlook.com (10.152.249.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.12; Mon, 22 Jan 2018 06:38:00 +0000 Received: from SG2PR0201MB2256.apcprd02.prod.outlook.com (10.152.248.55) by HK2APC01FT023.mail.protection.outlook.com (10.152.248.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.12 via Frontend Transport; Mon, 22 Jan 2018 06:38:00 +0000 Received: from SG2PR0201MB2256.apcprd02.prod.outlook.com ([fe80::c1e9:886c:2367:fbae]) by SG2PR0201MB2256.apcprd02.prod.outlook.com ([fe80::c1e9:886c:2367:fbae%14]) with mapi id 15.20.0428.019; Mon, 22 Jan 2018 06:38:00 +0000 From: =?gb2312?B?ucsgyNY=?= To: Tianran Zhou , "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for draft-ietf-opsawg-ipfix-bgp-community Thread-Index: AdOQCV9j2OxCryuCStaCuXJblDRHdADQRrN4 Date: Mon, 22 Jan 2018 06:38:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:3090C90EED5696B3E0B158A4E22386BEC182313168C57AF10F58B718AF533EF2; UpperCasedChecksum:073009550F4DA7040037E29D95617B3D87AF3DC2D127CB053CA9DAA612ED8BFE; SizeAsReceived:7254; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [k+cIqVBJFDX91TnZxki0Uf1OvKjuSdyZdwXngerHne8=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK2APC01HT084; 6:qVwJ4xrmFOb9rW66pyCKrOxlytE8ccP09sT6G3IEl1my0bCQIdqA0MKR0AbM+yrEP1cN1vQTM/jakTiQLpcUQeayRMUCRfawLi5H/nYj95dmh29MctleFohAy7AVq8DDFcVyjH8TgwEJ+wxJUGKBMSDcpYfCbsB70oLcL2HF/l7JcPZjieRvrcx+9zaehLaxb7++0dmJZUbgs9IzFrYqqzQFOEK6n1D/6jRyGeVWzxLkHhxRqGUqL7gXd2S1Ua9pQKplXIGPmGKwiyiib7Zdm0689qgivtNjN5HLJEeut8sBEZUYXMfnMM23ZtFcTNcJc+NmVk87fhrt8dCLrbyNoA==; 5:hwIxqAWCboVPZtL08q28/oEs/JT0Q0LC5Z8zH55xN4xyCS61jMY4axDC41tUMQo6GSL4meVm2xZhsG2ej+uViEXpUfjDWwbeB/NPm7q9XuSB163kRmyDWZPgmK9DhBHM+La7B9o43dhs46R9zdrnroHeo+cQARKxZAJSJrBG0WY=; 24:Q2mzjO8wpRItBGZ8FEFJ2TdF7bsBHKf29/Axo9Y/MVB7zXN3gFdALbpAHZUeeNtkcss3Drfcp+Nre7uvqsHB9UnPG5r99zk8OzzDGKqBixI=; 7:2wAb2KiNTHWRPCz77rBfMzf3m+xCXZKKzh/JguSrJ1KtjrXF/qiVpzOAZzM0iEBaf+f5MW0u8iWqQO8zio6SlGkJR3iZPKY3X9yOIn6MxfhEH0/uZ4r9Sdly18D7EFzQEMcEpa3DPwrf93wwePenKOK6C/pY8NLUP4C8gLXKPvDpsGr5u7VEQXnlL8Ibf4xB2HsBcX52xa5WajCO5CHVKXA4SDzKLqKHVHtH09BytkCn5v0sybKZ5quzOYaViaVV x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:HK2APC01HT084; x-ms-traffictypediagnostic: HK2APC01HT084: x-ms-office365-filtering-correlation-id: d6027ca0-e543-4d4a-b2e4-08d56162aeb8 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:HK2APC01HT084; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HK2APC01HT084; x-forefront-prvs: 0560A2214D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT084; H:SG2PR0201MB2256.apcprd02.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SG2PR0201MB2256547DE8662B722ACF655B8BEC0SG2PR0201MB2256_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d6027ca0-e543-4d4a-b2e4-08d56162aeb8 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2018 06:38:00.8353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT084 Archived-At: Subject: [OPSAWG] =?gb2312?b?tPC4tDogV0cgTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdn?= =?gb2312?b?LWlwZml4LWJncC1jb21tdW5pdHk=?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 06:38:08 -0000 --_000_SG2PR0201MB2256547DE8662B722ACF655B8BEC0SG2PR0201MB2256_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGRlYXIgYWxsLg0KQXMgdGhlIGNvLWF1dGhvciwgSSBzdXBwb3J0IHRoZSBXb3JrIEdyb3Vw IGRyYWZ0IHRvIGJlIHB1Ymxpc2hlZC4NCg0KR3UgUm9uZw0KZ3Vyb25nX2NtY2NAb3V0bG9vay5j b20NCmd1cm9uZ0BjaGluYW1vYmlsZS5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQq3orz+yMs6IE9QU0FXRyA8b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmc+ILT6se0gVGlhbnJh biBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPg0Kt6LLzcqxvOQ6IDIwMTjE6jHUwjE4yNUg MzowNjo0MQ0KytW8/sjLOiBvcHNhd2dAaWV0Zi5vcmcNCrOty806IG9wc2F3Zy1jaGFpcnNAaWV0 Zi5vcmcNCtb3zOI6IFtPUFNBV0ddIFdHIExDIGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1i Z3AtY29tbXVuaXR5DQoNCkhpIFdHLA0KDQpUaGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLW9wc2F3 Zy1pcGZpeC1iZ3AtY29tbXVuaXR5IGhhdmUgcG9zdGVkIHRoZSBsYXRlc3QgZHJhZnRzIHRvIHRo ZSBtYWlsaW5nIGxpc3QsIGFuZCBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZv ciBMQy4NCg0KVGhpcyBzdGFydHMgYSAyIHdlZWsgV0cgTEMgb24NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA0DQoNClBs ZWFzZSByZWFkIHRoZSBhYm92ZSBkcmFmdCBhbmQgc2VuZCBhbnkgaXNzdWVzLCBjb21tZW50cywg b3IgY29ycmVjdGlvbnMgdG8gdGhpcyBtYWlsaW5nIGxpc3QuDQpBbGwgc3VwcG9ydHMgYW5kIGNv bmNlcm5zIGFyZSB3ZWxjb21lIGFuZCBoZWxwZnVsIGZvciB0aGUgYXV0aG9ycy4NCg0KV2UgYXJl IGFsc28gbG9va2luZyBmb3IgYSBkb2N1bWVudCBzaGVwaGVyZCwgYmVzdCB3aXRoIG9wZXJhdG9y IGJhY2tncm91bmQsIHRvIGhlbHAgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmVzLg0KDQpUaGUgV0cg TEMgd2lsbCBjbG9zZSBvbiBGZWIgMSwgMjAxOC4NCkF1dGhvcnMgcGxlYXNlIGluZGljYXRlIHdo ZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIGZvciB0aGUgZHJhZnQuDQoNClRoYW5rcywN ClRpYW5yYW4sIGFzIE9QU0FXRyBjby1jaGFpcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT1BTQVdHIG1haWxpbmcgbGlzdA0KT1BTQVdHQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KT1BTQVdH IEluZm8gUGFnZSAtIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2U8aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c+DQp3d3cuaWV0Zi5vcmcNCk9wZXJhdGlv bnMgYW5kIE1hbmFnZW1lbnQgQXJlYSBXb3JraW5nIEdyb3VwIE1haWwgTGlzdC4gVG8gc2VlIHRo ZSBjb2xsZWN0aW9uIG9mIHByaW9yIHBvc3RpbmdzIHRvIHRoZSBsaXN0LCB2aXNpdCB0aGUgT1BT QVdHIEFyY2hpdmVzIG9yIE9QU0FXRyBNSG9uQXJjIEFyY2hpdmVzDQoNCg0KDQo= --_000_SG2PR0201MB2256547DE8662B722ACF655B8BEC0SG2PR0201MB2256_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi, dear all.
As the co-author, I support the Work Group draft to be published.

Gu Rong
gurong_cmcc@outlook.com
gurong@chinamobile.com
=B7=A2=BC=FE=C8=CB: OPSAWG = <opsawg-bounces@ietf.org> =B4=FA=B1=ED Tianran Zhou <zhoutianran@h= uawei.com>
=B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA1=D4=C218=C8=D5 3:06:41
=CA=D5=BC=FE=C8=CB: opsawg@ietf.org
=B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-communi= ty
 
Hi WG,

The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the latest= drafts to the mailing list, and believe that the document is ready for LC.=

This starts a 2 week WG LC on
https://tools.ietf.org/htm= l/draft-ietf-opsawg-ipfix-bgp-community-04

Please read the above draft and send any issues, comments, or corrections t= o this mailing list.
All supports and concerns are welcome and helpful for the authors.

We are also looking for a document shepherd, best with operator background,= to help the following procedures. 

The WG LC will close on Feb 1, 2018.
Authors please indicate whether you are aware of any IPR for the draft.

Thanks,
Tianran, as OPSAWG co-chair

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
www.ietf.org
Operations and Management Area Working Group Mail List. To see the collecti= on of prior postings to the list, visit the OPSAWG Archives or OPSAWG MHonA= rc Archives


--_000_SG2PR0201MB2256547DE8662B722ACF655B8BEC0SG2PR0201MB2256_-- From nobody Sun Jan 21 23:01:10 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C8A120047; Sun, 21 Jan 2018 23:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TNEQdRFH_2n1; Sun, 21 Jan 2018 23:01:06 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 69118124B17; Sun, 21 Jan 2018 23:01:06 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C961B36AC8CED; Mon, 22 Jan 2018 07:01:02 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 22 Jan 2018 07:01:04 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Mon, 22 Jan 2018 15:00:53 +0800 From: "Dongjie (Jimmy)" To: Tianran Zhou , "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for draft-ietf-opsawg-ipfix-bgp-community Thread-Index: AdOQCV9j2OxCryuCStaCuXJblDRHdADRPqZg Date: Mon, 22 Jan 2018 07:00:53 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927982886CE@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 07:01:08 -0000 Hi,=20 I (as coauthor) support the publication of this document. Best regards, Jie > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran Zhou > Sent: Thursday, January 18, 2018 11:07 AM > To: opsawg@ietf.org > Cc: opsawg-chairs@ietf.org > Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community >=20 > Hi WG, >=20 > The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the late= st > drafts to the mailing list, and believe that the document is ready for LC= . >=20 > This starts a 2 week WG LC on > https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04 >=20 > Please read the above draft and send any issues, comments, or corrections= to > this mailing list. > All supports and concerns are welcome and helpful for the authors. >=20 > We are also looking for a document shepherd, best with operator backgroun= d, to > help the following procedures. >=20 > The WG LC will close on Feb 1, 2018. > Authors please indicate whether you are aware of any IPR for the draft. >=20 > Thanks, > Tianran, as OPSAWG co-chair >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Sun Jan 21 23:03:16 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DF6124B17; Sun, 21 Jan 2018 23:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 M2F3ig8fPkcW; Sun, 21 Jan 2018 23:03:14 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 F1F92120047; Sun, 21 Jan 2018 23:03:13 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A1CC15E952223; Mon, 22 Jan 2018 07:03:10 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 22 Jan 2018 07:03:12 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Mon, 22 Jan 2018 15:03:03 +0800 From: "Dongjie (Jimmy)" To: "Dongjie (Jimmy)" , Tianran Zhou , "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for draft-ietf-opsawg-ipfix-bgp-community Thread-Index: AdOQCV9j2OxCryuCStaCuXJblDRHdADRPqZgAAAee1A= Date: Mon, 22 Jan 2018 07:03:03 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927982886DF@NKGEML515-MBX.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C927982886CE@NKGEML515-MBX.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927982886CE@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 07:03:15 -0000 I'm not aware of any IPR related to this document.=20 -Jie > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Dongjie (Jimmy= ) > Sent: Monday, January 22, 2018 3:01 PM > To: Tianran Zhou ; opsawg@ietf.org > Cc: opsawg-chairs@ietf.org > Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community >=20 > Hi, >=20 > I (as coauthor) support the publication of this document. >=20 > Best regards, > Jie >=20 > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran > > Zhou > > Sent: Thursday, January 18, 2018 11:07 AM > > To: opsawg@ietf.org > > Cc: opsawg-chairs@ietf.org > > Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community > > > > Hi WG, > > > > The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the > > latest drafts to the mailing list, and believe that the document is rea= dy for LC. > > > > This starts a 2 week WG LC on > > https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04 > > > > Please read the above draft and send any issues, comments, or > > corrections to this mailing list. > > All supports and concerns are welcome and helpful for the authors. > > > > We are also looking for a document shepherd, best with operator > > background, to help the following procedures. > > > > The WG LC will close on Feb 1, 2018. > > Authors please indicate whether you are aware of any IPR for the draft. > > > > Thanks, > > Tianran, as OPSAWG co-chair > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Sun Jan 21 23:45:54 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DD9120726; Sun, 21 Jan 2018 23:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 Yl5gUTRb6I2A; Sun, 21 Jan 2018 23:45:49 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 DA17C120047; Sun, 21 Jan 2018 23:45:48 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 333DA41FDEAA13B7509D; Mon, 22 Jan 2018 15:45:46 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Forcepoint Email with ESMTPS id 0B8B2C1C4944AD01E502; Mon, 22 Jan 2018 15:45:46 +0800 (CST) Received: from xgxapp01.zte.com.cn ([10.30.14.22]) by mse02.zte.com.cn with SMTP id w0M7jEOK068167; Mon, 22 Jan 2018 15:45:14 +0800 (GMT-8) (envelope-from hu.fangwei@zte.com.cn) Received: from mapi (xgxapp02[null]) by mapi (Zmail) with MAPI id mid71; Mon, 22 Jan 2018 15:45:17 +0800 (CST) Date: Mon, 22 Jan 2018 15:45:17 +0800 (CST) X-Zmail-TransId: 2afa5a65968dffffffffd6e-4fc2f X-Mailer: Zmail v1.0 Message-ID: <201801221545170136916@zte.com.cn> In-Reply-To: <000c01d39354$0b00e3e0$2102aba0$@chinamobile.com> References: HK2PR0601MB1492ACA133659594CA048592FCEF0@HK2PR0601MB1492.apcprd06.prod.outlook.com, 000c01d39354$0b00e3e0$2102aba0$@chinamobile.com Mime-Version: 1.0 From: To: Cc: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse02.zte.com.cn w0M7jEOK068167 Archived-At: Subject: Re: [OPSAWG] =?utf-8?q?WG_LC_for_draft-ietf-opsawg-ipfix-bgp-communi?= =?utf-8?q?ty?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 07:45:52 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGnvvIxBbGwNCg0KDQpJIHJlYWQgdGhlIGRvY3VtZW50IGFuZCBzdXBwb3J0IGl0IHRvIGJlIHB1 Ymxpc2hlZC4gDQoNCg0KDQoNCg0KDQpSZWdhcmRzDQoNCg0KRmFuZ3dlaS4NCg0KDQoNCg0KDQoN Cg0KDQpGcm9tOiBUaWFucmFuIFpob3UNCg0KDQoNCkRhdGU6IDIwMTgtMDEtMTggMTE6MDYNCg0K DQoNClRvOiBvcHNhd2dAaWV0Zi5vcmcNCg0KDQoNCkNDOiBvcHNhd2ctY2hhaXJzQGlldGYub3Jn DQoNCg0KDQpTdWJqZWN0OiBbT1BTQVdHXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctaXBm aXgtYmdwLWNvbW11bml0eQ0KDQoNCg0KDQoNCkhpIFdHLA0KDQoNCg0KIA0KDQoNClRoZSBhdXRo b3JzIG9mIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkgaGF2ZSBwb3N0ZWQg dGhlIGxhdGVzdCBkcmFmdHMgdG8gdGhlIG1haWxpbmcgbGlzdCwgYW5kIGJlbGlldmUgdGhhdCB0 aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIExDLg0KDQoNCg0KIA0KDQoNClRoaXMgc3RhcnRzIGEg MiB3ZWVrIFdHIExDIG9uDQoNCg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wNA0KDQoNCg0KIA0KDQoNClBsZWFzZSBy ZWFkIHRoZSBhYm92ZSBkcmFmdCBhbmQgc2VuZCBhbnkgaXNzdWVzLCBjb21tZW50cywgb3IgY29y cmVjdGlvbnMgdG8gdGhpcyBtYWlsaW5nIGxpc3QuDQoNCg0KDQpBbGwgc3VwcG9ydHMgYW5kIGNv bmNlcm5zIGFyZSB3ZWxjb21lIGFuZCBoZWxwZnVsIGZvciB0aGUgYXV0aG9ycy4NCg0KDQoNCiAN Cg0KDQpXZSBhcmUgYWxzbyBsb29raW5nIGZvciBhIGRvY3VtZW50IHNoZXBoZXJkLCBiZXN0IHdp dGggb3BlcmF0b3IgYmFja2dyb3VuZCwgdG8gaGVscCB0aGUgZm9sbG93aW5nIHByb2NlZHVyZXMu IA0KDQoNCg0KIA0KDQoNClRoZSBXRyBMQyB3aWxsIGNsb3NlIG9uIEZlYiAxLCAyMDE4Lg0KDQoN Cg0KQXV0aG9ycyBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9mIGFueSBJ UFIgZm9yIHRoZSBkcmFmdC4NCg0KDQoNCiANCg0KDQpUaGFua3MsDQoNCg0KDQpUaWFucmFuLCBh cyBPUFNBV0cgY28tY2hhaXINCg0KDQoNCiANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KT1BTQVdHIG1haWxpbmcgbGlzdA0KDQoNCg0K T1BTQVdHQGlldGYub3JnDQoNCg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2F3Zw== --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPkhp77yMQWxsPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog5b6u6L2v6ZuF6buRLCBzYW5z LXNlcmlmOyBsaW5lLWhlaWdodDogMjBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+SSByZWFkIHRoZSBkb2N1bWVudCBhbmQgc3VwcG9ydCBpdCB0byBiZSBwdWJsaXNo ZWQuJm5ic3A7PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6 YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlh bDsiPlJlZ2FyZHM8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFs OyI+RmFuZ3dlaS48L3A+PGRpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeVJvdyIgc3R5bGU9ImRpc3Bs YXk6YmxvY2siPjxkaXYgaWQ9Inp3cml0ZUhpc3RvcnlDb250YWluZXIiPjxkaXYgY2xhc3M9ImNv bnRyb2wtZ3JvdXAgemhpc3RvcnlQYW5lbCI+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48 ZGl2PjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjYuMHB0Ij48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+PGRpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxzdHJvbmc+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWlsdG86emhv dXRpYW5yYW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlRpYW5yYW4gWmhvdTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDojRUZFRkVGIj48c3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5EYXRlOjwvc3Bhbj48L3N0cm9uZz48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7MjAxOC0wMS0xOCZuYnNwOzExOjA2PG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 I0VGRUZFRiI+PHN0cm9uZz48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ VG86PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDs8YSBocmVmPSJtYWlsdG86b3BzYXdnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ b3BzYXdnQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxzdHJvbmc+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNDOjwvc3Bhbj48L3N0cm9uZz48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PGEgaHJlZj0ibWFpbHRv Om9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vcHNhd2ctY2hhaXJzQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxzdHJvbmc+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlN1YmplY3Q6PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDtbT1BTQVdHXSBXRyBMQyBmb3Ig ZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eTxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IaSBXRyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPlRoZSBhdXRob3JzIG9mIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJn cC1jb21tdW5pdHkgaGF2ZSBwb3N0ZWQgdGhlIGxhdGVzdCBkcmFmdHMgdG8gdGhlIG1haWxpbmcg bGlzdCwgYW5kIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIExDLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF 6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+VGhpcyBzdGFydHMgYSAyIHdlZWsgV0cgTEMgb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA0 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5QbGVhc2UgcmVhZCB0aGUgYWJvdmUgZHJhZnQgYW5kIHNlbmQgYW55IGlzc3VlcywgY29tbWVu dHMsIG9yIGNvcnJlY3Rpb25zIHRvIHRoaXMgbWFpbGluZyBsaXN0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QWxsIHN1cHBvcnRzIGFuZCBjb25jZXJucyBhcmUg d2VsY29tZSBhbmQgaGVscGZ1bCBmb3IgdGhlIGF1dGhvcnMuPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5XZSBhcmUgYWxzbyBsb29raW5nIGZvciBhIGRvY3VtZW50IHNoZXBoZXJkLCBiZXN0IHdp dGggb3BlcmF0b3IgYmFja2dyb3VuZCwgdG8gaGVscCB0aGUgZm9sbG93aW5nIHByb2NlZHVyZXMu Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgV0cgTEMgd2lsbCBjbG9zZSBvbiBG ZWIgMSwgMjAxOC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkF1 dGhvcnMgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIGZv ciB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaWFucmFuLCBhcyBPUFNBV0cgY28tY2hh aXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5PUFNBV0cgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86T1BTQVdHQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+T1BTQVdHQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v cHNhd2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2F3ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ibG9ja3F1 b3RlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwPjxicj48L3A+ PC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Mon Jan 22 00:02:10 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AD8126B6D; Mon, 22 Jan 2018 00:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 vXs3XR9LEnDE; Mon, 22 Jan 2018 00:02:02 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254095.outbound.protection.outlook.com [40.92.254.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91061120047; Mon, 22 Jan 2018 00:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jOGLi+1fyoRGV2hB/CPvCF+b/0gkDnqXKwNTdIRvdgY=; b=JW5Wq+spDlww2Sx07m+yEIKS62WPESOQyeWcZZC1r9jlE5vtypJSlecnrQy06+kM1RLn4MKAM2DsF7qNF9Mx03neNWJV51ZuDdWNUhZ8sit3oeD6JZNHxUPG7zDTwzu3UcRxyi+wvzeMziVFFBd9r+IFAWzkIN4U22W3Nhxk5MEkKJNrURYtus929mSai6SX05gZOyn4cqAnitclj6hexfF1Yoc0rc3AY8LfVOP0dvFiGCFRKsTUZRwcU4oc84HOALwLQlHqlucY8PRrfBaGQB3Ysnxza0qv9x6g+WIXCHDBWz1nax3ZatTEjgQvJUIb5n1twXSmQg/ExOVf14HGUA== Received: from PU1APC01FT039.eop-APC01.prod.protection.outlook.com (10.152.252.52) by PU1APC01HT027.eop-APC01.prod.protection.outlook.com (10.152.253.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.19; Mon, 22 Jan 2018 08:01:57 +0000 Received: from SG2PR0201MB2256.apcprd02.prod.outlook.com (10.152.252.54) by PU1APC01FT039.mail.protection.outlook.com (10.152.253.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.19 via Frontend Transport; Mon, 22 Jan 2018 08:01:58 +0000 Received: from SG2PR0201MB2256.apcprd02.prod.outlook.com ([fe80::c1e9:886c:2367:fbae]) by SG2PR0201MB2256.apcprd02.prod.outlook.com ([fe80::c1e9:886c:2367:fbae%14]) with mapi id 15.20.0428.019; Mon, 22 Jan 2018 08:01:57 +0000 From: =?gb2312?B?ucsgyNY=?= To: "Dongjie (Jimmy)" , Tianran Zhou , "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for draft-ietf-opsawg-ipfix-bgp-community Thread-Index: AdOQCV9j2OxCryuCStaCuXJblDRHdADRPqZgAAAee1AAAhQahg== Date: Mon, 22 Jan 2018 08:01:57 +0000 Message-ID: References: <76CD132C3ADEF848BD84D028D243C927982886CE@NKGEML515-MBX.china.huawei.com>, <76CD132C3ADEF848BD84D028D243C927982886DF@NKGEML515-MBX.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C927982886DF@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:101FE05A2968CAD81A77A004C2FB58D34A81A1897F34F2DC716807B1558D324E; UpperCasedChecksum:640B676C12453CAAB659605D9D7E2413DF7B92DC756762B076E83C3AEA93A818; SizeAsReceived:7425; Count:46 x-tmn: [JFIeI1kIomlCnv3sRogB6/8PSVkJVB6uUcXOJbsFh/g=] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT027; 6:u+hVL+laghd5sJREYMU6K+qwlYGOpyqO11geAY1inTG1GDZ5IC9s5NR0A6mkq7lEGe61DbgpttNjJfWrbfFF0SsDcVMvnBk63k6JdI6qd/IKJV/LfXEV+XWrahuRUh8K/XPjMCyDd6FrgOHnctiDbSx8zffiERbbKojEYN0W6MBllX9bMNBUXVm5yQ2q62ignh13GiqzYANhPGDr2QMBEi3G/9UDuEKX1jBT6uso9lGo8HU9E0VNZnATANBC6YDIAJofmAPzZGpwvf+tpwQ9hRgWcaXWeilPMot26FU0RsU7Nk0Ek5yYp2NIkIVyeqxWLrka+3g4dfIcfr1AvCid71IT0lj5b667V1IgM8pgHqY=; 5:6dy/Wzu7q98dIELzEEPzW7YffOP70zGbX7fShdTPIHRhrsecgIPqfvg5jctReihupS+as6FkW00a2wNlNEIpfuDhTZAUXY+CB2dz7oAO2Q1hMlmzmbps9b0Z1mFVyUWaSGBB4gw/TJ5AbgbNY4CU5fIkNvawVriC7Bkcg5g0bgs=; 24:AkTeSWG62Zpy1cJb/rHn8ypld+df2j6yZlMTLyfEBeo3W4fEcEGMl/oO9wfeE3+EomvnBVXe06P/mq1Jkrv26wAB0SomLxb6Y0xdoN+TbAU=; 7:yrJb9X6HkjTK2P7KyY5vyN3slgjX/NXug5RvnwRvZYLREdC7GUeOVOZ/x6d5FuUkesHiK6nZaV4e6aMS+eIDP6XCjPuv8HStCI21SOr5GOjV1jLfUXUVGYui3Vd55eY9zjdlu1j0GYQ92zTXPrNz1fkD9mOyhgv4aL0gD9fjmBa+zla5AMdwyiWf7yBEWqNRTjgEjoY4w9pp4MvbsB4zSnaY0tU+bccH42C7gdEFTlygP4wXGD/gAyF9YnEgP/zU x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:PU1APC01HT027; x-ms-traffictypediagnostic: PU1APC01HT027: x-ms-office365-filtering-correlation-id: 4f2b6636-fe8e-4626-96dd-08d5616e6900 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT027; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT027; x-forefront-prvs: 0560A2214D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT027; H:SG2PR0201MB2256.apcprd02.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SG2PR0201MB225685108F51D0F45B7801768BEC0SG2PR0201MB2256_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f2b6636-fe8e-4626-96dd-08d5616e6900 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2018 08:01:57.6080 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT027 Archived-At: Subject: [OPSAWG] =?gb2312?b?tPC4tDogV0cgTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdn?= =?gb2312?b?LWlwZml4LWJncC1jb21tdW5pdHk=?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 08:02:09 -0000 --_000_SG2PR0201MB225685108F51D0F45B7801768BEC0SG2PR0201MB2256_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGRlYXIgY2hhaXJzLiBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlz IGRvY3VtZW50IGFzIHdlbGwgYXMgdGhlIGNvLWF1dGhvci4NCg0KDQpHdSBSb25nDQoNCmd1cm9u Z19jbWNjQG91dGxvb2suY29tDQoNCmd1cm9uZ0BjaGluYW1vYmlsZS5jb20NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogT1BTQVdHIDxvcHNhd2ctYm91bmNlc0Bp ZXRmLm9yZz4gtPqx7SBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb20+DQq3osvN yrG85DogMjAxOMTqMdTCMjLI1SA3OjAzOjAzDQrK1bz+yMs6IERvbmdqaWUgKEppbW15KTsgVGlh bnJhbiBaaG91OyBvcHNhd2dAaWV0Zi5vcmcNCrOty806IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmcN Ctb3zOI6IFJlOiBbT1BTQVdHXSBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdw LWNvbW11bml0eQ0KDQpJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRv Y3VtZW50Lg0KDQotSmllDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog T1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEb25n amllIChKaW1teSkNCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDIyLCAyMDE4IDM6MDEgUE0NCj4g VG86IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbT47IG9wc2F3Z0BpZXRmLm9y Zw0KPiBDYzogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW09QU0FXR10g V0cgTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkNCj4NCj4gSGks DQo+DQo+IEkgKGFzIGNvYXV0aG9yKSBzdXBwb3J0IHRoZSBwdWJsaWNhdGlvbiBvZiB0aGlzIGRv Y3VtZW50Lg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IEppZQ0KPg0KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBUaWFucmFuDQo+ID4gWmhvdQ0KPiA+IFNlbnQ6IFRodXJzZGF5 LCBKYW51YXJ5IDE4LCAyMDE4IDExOjA3IEFNDQo+ID4gVG86IG9wc2F3Z0BpZXRmLm9yZw0KPiA+ IENjOiBvcHNhd2ctY2hhaXJzQGlldGYub3JnDQo+ID4gU3ViamVjdDogW09QU0FXR10gV0cgTEMg Zm9yIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkNCj4gPg0KPiA+IEhpIFdH LA0KPiA+DQo+ID4gVGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNv bW11bml0eSBoYXZlIHBvc3RlZCB0aGUNCj4gPiBsYXRlc3QgZHJhZnRzIHRvIHRoZSBtYWlsaW5n IGxpc3QsIGFuZCBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBMQy4NCj4g Pg0KPiA+IFRoaXMgc3RhcnRzIGEgMiB3ZWVrIFdHIExDIG9uDQo+ID4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDQNCj4g Pg0KPiA+IFBsZWFzZSByZWFkIHRoZSBhYm92ZSBkcmFmdCBhbmQgc2VuZCBhbnkgaXNzdWVzLCBj b21tZW50cywgb3INCj4gPiBjb3JyZWN0aW9ucyB0byB0aGlzIG1haWxpbmcgbGlzdC4NCj4gPiBB bGwgc3VwcG9ydHMgYW5kIGNvbmNlcm5zIGFyZSB3ZWxjb21lIGFuZCBoZWxwZnVsIGZvciB0aGUg YXV0aG9ycy4NCj4gPg0KPiA+IFdlIGFyZSBhbHNvIGxvb2tpbmcgZm9yIGEgZG9jdW1lbnQgc2hl cGhlcmQsIGJlc3Qgd2l0aCBvcGVyYXRvcg0KPiA+IGJhY2tncm91bmQsIHRvIGhlbHAgdGhlIGZv bGxvd2luZyBwcm9jZWR1cmVzLg0KPiA+DQo+ID4gVGhlIFdHIExDIHdpbGwgY2xvc2Ugb24gRmVi IDEsIDIwMTguDQo+ID4gQXV0aG9ycyBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3 YXJlIG9mIGFueSBJUFIgZm9yIHRoZSBkcmFmdC4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBUaWFu cmFuLCBhcyBPUFNBV0cgY28tY2hhaXINCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT1BTQVdHIG1haWxpbmcgbGlzdA0KPiA+IE9Q U0FXR0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b3BzYXdnDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IE9QU0FXRyBtYWlsaW5nIGxpc3QNCj4gT1BTQVdHQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNBV0cgbWFpbGluZyBsaXN0DQpPUFNB V0dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdn DQo= --_000_SG2PR0201MB225685108F51D0F45B7801768BEC0SG2PR0201MB2256_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, dear chairs. I'm not aware of= any IPR related to this document as well as the co-author.


Gu Rong

gurong_cmcc@outlook.com

gurong@chinamobile.com

=B7=A2=BC=FE=C8=CB: OPSAWG = <opsawg-bounces@ietf.org> =B4=FA=B1=ED Dongjie (Jimmy) <jie.dong@h= uawei.com>
=B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA1=D4=C222=C8=D5 7:03:03
=CA=D5=BC=FE=C8=CB: Dongjie (Jimmy); Tianran Zhou; opsawg@ietf.org =B3=AD=CB=CD: opsawg-chairs@ietf.org
=D6=F7=CC=E2: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-com= munity
 
I'm not aware of any IPR related to this document.=

-Jie

> -----Original Message-----
> From: OPSAWG [mailto:opsawg= -bounces@ietf.org] On Behalf Of Dongjie (Jimmy)
> Sent: Monday, January 22, 2018 3:01 PM
> To: Tianran Zhou <zhoutianran@huawei.com>; opsawg@ietf.org
> Cc: opsawg-chairs@ietf.org
> Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community<= br> >
> Hi,
>
> I (as coauthor) support the publication of this document.
>
> Best regards,
> Jie
>
> > -----Original Message-----
> > From: OPSAWG [mailto:o= psawg-bounces@ietf.org] On Behalf Of Tianran
> > Zhou
> > Sent: Thursday, January 18, 2018 11:07 AM
> > To: opsawg@ietf.org
> > Cc: opsawg-chairs@ietf.org
> > Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community=
> >
> > Hi WG,
> >
> > The authors of draft-ietf-opsawg-ipfix-bgp-community have posted = the
> > latest drafts to the mailing list, and believe that the document = is ready for LC.
> >
> > This starts a 2 week WG LC on
> > https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04 > >
> > Please read the above draft and send any issues, comments, or
> > corrections to this mailing list.
> > All supports and concerns are welcome and helpful for the authors= .
> >
> > We are also looking for a document shepherd, best with operator > > background, to help the following procedures.
> >
> > The WG LC will close on Feb 1, 2018.
> > Authors please indicate whether you are aware of any IPR for the = draft.
> >
> > Thanks,
> > Tianran, as OPSAWG co-chair
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://= www.ietf.org/mailman/listinfo/opsawg
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.i= etf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.o= rg/mailman/listinfo/opsawg
--_000_SG2PR0201MB225685108F51D0F45B7801768BEC0SG2PR0201MB2256_-- From nobody Mon Jan 22 02:00:27 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2712C126DED for ; Mon, 22 Jan 2018 02:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NB0FmIKJwITJ for ; Mon, 22 Jan 2018 02:00:05 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 DF74A126C3D for ; Mon, 22 Jan 2018 02:00:04 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6ECC5C57044C5 for ; Mon, 22 Jan 2018 10:00:00 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 22 Jan 2018 10:00:01 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0361.001; Mon, 22 Jan 2018 17:59:57 +0800 From: Qin Wu To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community Thread-Index: AQEzgUHy2OxCryuCStaCuXJblDRHdKS/pRbggAAAg+CAACco0A== Date: Mon, 22 Jan 2018 09:59:57 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.67] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AD40CAAnkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 10:00:25 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9AD40CAAnkgeml513mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBhbmQgSSBoYXZlIG5vIGlzc3VlIHdpdGggaXQuDQoNCi1RaW4NCkZyb206IFRpYW5y YW4gWmhvdTxtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbT4NCkRhdGU6IDIwMTgtMDEtMTgg MTE6MDYNClRvOiBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCkNDOiBv cHNhd2ctY2hhaXJzQGlldGYub3JnPG1haWx0bzpvcHNhd2ctY2hhaXJzQGlldGYub3JnPg0KU3Vi amVjdDogW09QU0FXR10gV0cgTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21t dW5pdHkNCkhpIFdHLA0KDQpUaGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1i Z3AtY29tbXVuaXR5IGhhdmUgcG9zdGVkIHRoZSBsYXRlc3QgZHJhZnRzIHRvIHRoZSBtYWlsaW5n IGxpc3QsIGFuZCBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBMQy4NCg0K VGhpcyBzdGFydHMgYSAyIHdlZWsgV0cgTEMgb24NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA0DQoNClBsZWFzZSByZWFk IHRoZSBhYm92ZSBkcmFmdCBhbmQgc2VuZCBhbnkgaXNzdWVzLCBjb21tZW50cywgb3IgY29ycmVj dGlvbnMgdG8gdGhpcyBtYWlsaW5nIGxpc3QuDQpBbGwgc3VwcG9ydHMgYW5kIGNvbmNlcm5zIGFy ZSB3ZWxjb21lIGFuZCBoZWxwZnVsIGZvciB0aGUgYXV0aG9ycy4NCg0KV2UgYXJlIGFsc28gbG9v a2luZyBmb3IgYSBkb2N1bWVudCBzaGVwaGVyZCwgYmVzdCB3aXRoIG9wZXJhdG9yIGJhY2tncm91 bmQsIHRvIGhlbHAgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmVzLg0KDQpUaGUgV0cgTEMgd2lsbCBj bG9zZSBvbiBGZWIgMSwgMjAxOC4NCkF1dGhvcnMgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91 IGFyZSBhd2FyZSBvZiBhbnkgSVBSIGZvciB0aGUgZHJhZnQuDQoNClRoYW5rcywNClRpYW5yYW4s IGFzIE9QU0FXRyBjby1jaGFpcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT1BTQVdHIG1haWxpbmcgbGlzdA0KT1BTQVdHQGlldGYub3JnPG1haWx0 bzpPUFNBV0dAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29wc2F3Zw0K --_000_B8F9A780D330094D99AF023C5877DABA9AD40CAAnkgeml513mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovk vZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L 5L2TO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyDQoJe21z by1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueazqOahhuaWh+acrDsNCglmb250LWZhbWlseTrlrovk vZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TdXBwb3J0IGFuZCBJIGhhdmUgbm8gaXNzdWUgd2l0aCBpdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVFpbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDo2LjBwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8YSBocmVmPSJtYWlsdG86emhvdXRpYW5yYW5AaHVhd2VpLmNvbSI+VGlh bnJhbg0KIFpob3U8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRhdGU6PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7MjAxOC0wMS0xOCZuYnNwOzExOjA2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRUZFRiI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRvOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5vcmciPm9wc2F3Z0BpZXRmLm9y ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q0M6PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PGEgaHJlZj0i bWFpbHRvOm9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmciPm9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6I0VGRUZFRiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlN1YmplY3Q6PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7W09QU0FXR10N CiBXRyBMQyBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIGF1dGhvcnMgb2Yg ZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eSBoYXZlIHBvc3RlZCB0aGUgbGF0 ZXN0IGRyYWZ0cyB0byB0aGUgbWFpbGluZyBsaXN0LCBhbmQgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1 bWVudCBpcyByZWFkeSBmb3IgTEMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoaXMgc3RhcnRzIGEgMiB3ZWVr IFdHIExDIG9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wNCI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDQ8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPlBsZWFzZSByZWFkIHRoZSBhYm92ZSBkcmFmdCBhbmQgc2VuZCBhbnkgaXNzdWVz LCBjb21tZW50cywgb3IgY29ycmVjdGlvbnMgdG8gdGhpcyBtYWlsaW5nIGxpc3QuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFs bCBzdXBwb3J0cyBhbmQgY29uY2VybnMgYXJlIHdlbGNvbWUgYW5kIGhlbHBmdWwgZm9yIHRoZSBh dXRob3JzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XZSBhcmUgYWxzbyBsb29raW5nIGZvciBhIGRvY3VtZW50 IHNoZXBoZXJkLCBiZXN0IHdpdGggb3BlcmF0b3IgYmFja2dyb3VuZCwgdG8gaGVscCB0aGUgZm9s bG93aW5nIHByb2NlZHVyZXMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlIFdHIExDIHdpbGwg Y2xvc2Ugb24gRmViIDEsIDIwMTguPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BdXRob3JzIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVy IHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiBmb3IgdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5UaWFucmFuLCBhcyBPUFNBV0cgY28tY2hhaXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buR JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v 6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk9QU0FXRyBt YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmciPk9QU0FXR0Bp ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb3BzYXdnIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3 ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B8F9A780D330094D99AF023C5877DABA9AD40CAAnkgeml513mbschi_-- From nobody Mon Jan 22 06:04:31 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DBF1252BA for ; Mon, 22 Jan 2018 06:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 WXQKTaPhXLnu for ; Mon, 22 Jan 2018 06:04:27 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 8815B1200E5 for ; Mon, 22 Jan 2018 06:04:26 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C72C8F7EA8A54 for ; Mon, 22 Jan 2018 14:04:21 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 22 Jan 2018 14:04:23 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML702-CHM.china.huawei.com ([169.254.4.179]) with mapi id 14.03.0382.000; Mon, 22 Jan 2018 06:04:18 -0800 From: Huaimo Chen To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community Thread-Index: AQEzgUHy1BU4Tu2sc02MZT1DKCw5oKS/pRbggAAAg+CAACco0IAAQ7lg Date: Mon, 22 Jan 2018 14:04:16 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D463A44D8B@sjceml521-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.48] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D463A44D8Bsjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 14:04:30 -0000 --_000_5316A0AB3C851246A7CA5758973207D463A44D8Bsjceml521mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KQmVzdCBSZWdhcmRzLA0KSHVhaW1vDQpGcm9tOiBUaWFucmFuIFpob3U8bWFp bHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+DQpEYXRlOiAyMDE4LTAxLTE4IDExOjA2DQpUbzog b3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpDQzogb3BzYXdnLWNoYWly c0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtPUFNB V0ddIFdHIExDIGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5DQpIaSBX RywNCg0KVGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0 eSBoYXZlIHBvc3RlZCB0aGUgbGF0ZXN0IGRyYWZ0cyB0byB0aGUgbWFpbGluZyBsaXN0LCBhbmQg YmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgTEMuDQoNClRoaXMgc3RhcnRz IGEgMiB3ZWVrIFdHIExDIG9uDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wNA0KDQpQbGVhc2UgcmVhZCB0aGUgYWJvdmUg ZHJhZnQgYW5kIHNlbmQgYW55IGlzc3VlcywgY29tbWVudHMsIG9yIGNvcnJlY3Rpb25zIHRvIHRo aXMgbWFpbGluZyBsaXN0Lg0KQWxsIHN1cHBvcnRzIGFuZCBjb25jZXJucyBhcmUgd2VsY29tZSBh bmQgaGVscGZ1bCBmb3IgdGhlIGF1dGhvcnMuDQoNCldlIGFyZSBhbHNvIGxvb2tpbmcgZm9yIGEg ZG9jdW1lbnQgc2hlcGhlcmQsIGJlc3Qgd2l0aCBvcGVyYXRvciBiYWNrZ3JvdW5kLCB0byBoZWxw IHRoZSBmb2xsb3dpbmcgcHJvY2VkdXJlcy4NCg0KVGhlIFdHIExDIHdpbGwgY2xvc2Ugb24gRmVi IDEsIDIwMTguDQpBdXRob3JzIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBhcmUgYXdhcmUg b2YgYW55IElQUiBmb3IgdGhlIGRyYWZ0Lg0KDQpUaGFua3MsDQpUaWFucmFuLCBhcyBPUFNBV0cg Y28tY2hhaXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9yZzxtYWlsdG86T1BTQVdHQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg== --_000_5316A0AB3C851246A7CA5758973207D463A44D8Bsjceml521mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0 IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0IFlhSGVpIjsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OlNpbVN1bjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWls eTpTaW1TdW47fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpwLmEsIGxpLmEsIGRpdi5hDQoJe21zby1zdHlsZS1uYW1lOuaJueazqOah huaWh+acrDsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG 5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrm ibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnNwYW4uRW1haWxTdHlsZTIz DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SHVhaW1vPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjYuMHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRkVGRUYi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxhIGhyZWY9 Im1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tIj5UaWFucmFuDQogWmhvdTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+RGF0ZTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mbmJzcDsyMDE4LTAxLTE4Jm5ic3A7MTE6MDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDoj RUZFRkVGIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VG86PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PGEg aHJlZj0ibWFpbHRvOm9wc2F3Z0BpZXRmLm9yZyI+b3BzYXdnQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOiNFRkVGRUYiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5DQzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDs8YSBocmVmPSJtYWlsdG86b3BzYXdnLWNoYWlyc0BpZXRmLm9yZyI+b3BzYXdn LWNoYWlyc0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDojRUZFRkVGIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U3ViamVjdDo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDtbT1BTQVdHXSBXRw0K IExDIGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPkhpIFdHLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5UaGUgYXV0aG9ycyBvZiBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29t bXVuaXR5IGhhdmUgcG9zdGVkIHRoZSBsYXRlc3QgZHJhZnRzIHRvIHRoZSBtYWlsaW5nIGxpc3Qs IGFuZCBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5DQogZm9yIExDLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtN aWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGlzIHN0YXJ0 cyBhIDIgd2VlayBXRyBMQyBvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTA0PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5QbGVhc2Ug cmVhZCB0aGUgYWJvdmUgZHJhZnQgYW5kIHNlbmQgYW55IGlzc3VlcywgY29tbWVudHMsIG9yIGNv cnJlY3Rpb25zIHRvIHRoaXMgbWFpbGluZyBsaXN0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5BbGwgc3VwcG9ydHMgYW5kIGNvbmNlcm5zIGFy ZSB3ZWxjb21lIGFuZCBoZWxwZnVsIGZvciB0aGUgYXV0aG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlh SGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQg WWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+V2UgYXJlIGFsc28gbG9va2luZyBm b3IgYSBkb2N1bWVudCBzaGVwaGVyZCwgYmVzdCB3aXRoIG9wZXJhdG9yIGJhY2tncm91bmQsIHRv IGhlbHAgdGhlIGZvbGxvd2luZyBwcm9jZWR1cmVzLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZ YUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0 IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSBXRyBMQyB3aWxsIGNsb3Nl IG9uIEZlYiAxLCAyMDE4LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+QXV0aG9ycyBwbGVhc2UgaW5kaWNhdGUgd2hldGhlciB5b3UgYXJlIGF3YXJl IG9mIGFueSBJUFIgZm9yIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGlhbnJhbiwgYXMgT1BTQVdHIGNvLWNoYWlyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m dCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PUFNBV0cgbWFpbGluZyBsaXN0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBo cmVmPSJtYWlsdG86T1BTQVdHQGlldGYub3JnIj5PUFNBV0dAaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01p Y3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5316A0AB3C851246A7CA5758973207D463A44D8Bsjceml521mbschi_-- From nobody Mon Jan 22 15:05:11 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A6E126DCA; Mon, 22 Jan 2018 15:05:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , "Paul Hoffman" , , X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151666231106.3949.16675552965416751428.idtracker@ietfa.amsl.com> Date: Mon, 22 Jan 2018 15:05:11 -0800 From: IETF Secretariat Archived-At: Subject: [OPSAWG] Datatracker State Update Notice: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 23:05:11 -0000 IANA review state changed to "IANA OK - No Actions Needed" Datatracker URL: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ From nobody Tue Jan 23 19:37:39 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8265F12D775; Tue, 23 Jan 2018 19:37:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, Tianran Zhou , warren@kumari.net, opsawg-chairs@ietf.org, zhoutianran@huawei.com, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151676505752.24181.16152395977449682862.idtracker@ietfa.amsl.com> Date: Tue, 23 Jan 2018 19:37:37 -0800 Archived-At: Subject: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 03:37:38 -0000 Ben Campbell has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -1, 3rd paragraph after figure 1: We should avoid using lawful intercept as a justification for protocol mechanisms. -1.3: Serving as an "archival record" seems like an odd use of "experimental". That sounds more "informational" to me. -7: I agree with Kathleen's comments about the security considerations. Editorial Comments and Nits: - The abbreviations that were expanded in the abstract should be expanded again on the body. -1, paragraph after figure 1: Missing article before the first occurrence of "CAPWAP". -1.3, first sentence: " Service Provider's " should either be " Service Providers' " or "the Service Provider's -2, 3rd paragraph after figure 5: Missing article before WTP (multiple occurrences). From nobody Wed Jan 24 00:29:42 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C42E912D962; Wed, 24 Jan 2018 00:29:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151678258073.24096.1546664821566754428@ietfa.amsl.com> Date: Wed, 24 Jan 2018 00:29:40 -0800 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 08:29:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Manufacturer Usage Description Specification Authors : Eliot Lear Ralph Droms Dan Romascanu Filename : draft-ietf-opsawg-mud-14.txt Pages : 56 Date : 2018-01-24 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix specification, an X.509 certificate extension and a means to sign and verify the descriptions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-14 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-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 Wed Jan 24 00:34:17 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6AF12D96D for ; Wed, 24 Jan 2018 00:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.489 X-Spam-Level: X-Spam-Status: No, score=-13.489 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 He57_iDJpWsM for ; Wed, 24 Jan 2018 00:34:13 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848BE12DA01 for ; Wed, 24 Jan 2018 00:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8600; q=dns/txt; s=iport; t=1516782851; x=1517992451; h=subject:cc:references:from:message-id:date:mime-version: in-reply-to; bh=xTdj2xgG7pXltqET5Ba1bXpmdwlszPHIumYqEXENonI=; b=d4jQF8oTOZYTEpcpfoKVgNZGh3xzRgkmaxcwcJojaihG37PFCzIUVvO9 NXHu1Uch8DUGuV90F4bT8gZAGDdPX/LhOXulzjiV/ZYATha3KQI3MTcSn DLwoTGSNjxmKIahwDwmwO6yDxrrjilUZ+8hl7ZbMNwJle3sdyf4CxaVn/ Q=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAQCmQ2ha/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodBgPg12LGI90kWqFVIIXBwMYAQqESU8CJoUpFgEBAQEBAQE?= =?us-ascii?q?BAmsohRsJAQEEAQEhSwsQCxIGKgICJyIOEwYCAQGFb4RCELNGgicmii4BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQ8PhEuFVCmDBYMvAQECAQEXhG0UglEFim2ZGYRegjG?= =?us-ascii?q?BBY1NghtnhTiDcYd5iniCYIl+gTwmBS2BUDMaCBsVGSSBBAiBHgmET0A3jiABA?= =?us-ascii?q?QU?= X-IronPort-AV: E=Sophos;i="5.46,406,1511827200"; d="asc'?scan'208,217";a="1619207" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 08:34:09 +0000 Received: from [10.61.242.27] ([10.61.242.27]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0O8Y8mF024013; Wed, 24 Jan 2018 08:34:09 GMT Cc: opsawg@ietf.org, Warren Kumari , Mahesh Jethanandani , Mark Nottingham References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> From: Eliot Lear Message-ID: <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> Date: Wed, 24 Jan 2018 09:34:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <151678258073.24096.1546664821566754428@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B16t250KeUJFJrKQGrs7LBXlTCLpN9eLD" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 08:34:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B16t250KeUJFJrKQGrs7LBXlTCLpN9eLD Content-Type: multipart/mixed; boundary="mi5X6uAK67vV9IccExwVfadR0CC2bPEBa"; protected-headers="v1" From: Eliot Lear Cc: opsawg@ietf.org, Warren Kumari , Mahesh Jethanandani , Mark Nottingham Message-ID: <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> In-Reply-To: <151678258073.24096.1546664821566754428@ietfa.amsl.com> --mi5X6uAK67vV9IccExwVfadR0CC2bPEBa Content-Type: multipart/alternative; boundary="------------23A9BEB2373BB36801B339C4" Content-Language: en-US This is a multi-part message in MIME format. --------------23A9BEB2373BB36801B339C4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This update primarily focuses on two elements that were agreed during WGL= C: * The update to the ACL model.=C2=A0 That update has taken longer than = I would have liked, but it is now at least close to finished.=C2=A0 Not= e: the MUD model does not yet match the published ACL model, but it does match the agreed changes that will be produced in the next ACL draft. * Mark Nottingham had commented that it is not appropriate to have versioning information in the MUD-URL itself, but that it should be in the model.=C2=A0 We agreed on this change, as well as some wording= around how HTTP is handled. Based on these changes, I would like to move this document forward to IETF LC. Eliot On 24.01.18 09:29, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Operations and Management Area Working= Group WG of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename : draft-ietf-opsawg-mud-14.txt > Pages : 56 > Date : 2018-01-24 > > Abstract: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for= > Things to signal to the network what sort of access and network > functionality they require to properly function. The initial focus > is on access control. Later work can delve into other aspects. > > This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an= > LLDP TLV, a URL suffix specification, an X.509 certificate extension= > and a means to sign and verify the descriptions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-14 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-14 > > > Please note that it may take a couple of minutes from the time of submi= ssion > 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/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --------------23A9BEB2373BB36801B339C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

This update primarily focuses on two elements that were agreed during WGLC:

  • The update to the ACL model.=C2=A0 That update has taken longer= than I would have liked, but it is now at least close to finished.=C2=A0 Note: the MUD model does not yet match the publis= hed ACL model, but it does match the agreed changes that will be produced in the next ACL draft.
  • Mark Nottingham had commented that it is not appropriate to have versioning information in the MUD-URL itself, but that it should be in the model.=C2=A0 We agreed on this change, as well a= s some wording around how HTTP is handled.

Based on these changes, I would like to move this document forward to IETF LC.

Eliot


On 24.01.18 09:29, internet-drafts@ietf.org wrote:
= 
A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
This draft is a work item of the Operations and Management Area Working G=
roup WG of the IETF.

        Title           : Manufacturer Usage Description Specification
        Authors         : Eliot Lear
                          Ralph Droms
                          Dan Romascanu
	Filename        : draft-ietf-opsawg-mud-14.txt
	Pages           : 56
	Date            : 2018-01-24

Abstract:
   This memo specifies a component-based architecture for manufacturer
   usage descriptions (MUD).  The goal of MUD is to provide a means for
   Things to signal to the network what sort of access and network
   functionality they require to properly function.  The initial focus
   is on access control.  Later work can delve into other aspects.

   This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
   LLDP TLV, a URL suffix specification, an X.509 certificate extension
   and a means to sign and verify the descriptions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-op=
sawg-mud/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-mud=
-14
https://datatracker.ietf.org/doc/html/d=
raft-ietf-opsawg-mud-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft=
-ietf-opsawg-mud-14


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

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

_______________________________________________
OPSAWG mailing list
OPS=
AWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------23A9BEB2373BB36801B339C4-- --mi5X6uAK67vV9IccExwVfadR0CC2bPEBa-- --B16t250KeUJFJrKQGrs7LBXlTCLpN9eLD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpoRQIACgkQh7ZrRtnS ejNSnAgAnPHePWq/VaM9KD56jAdSt4+hlJymZ8dZYDTUqtoMkP7/e3p2QEHgelx/ ousdgJErEr8k6s2vN7FmuZcK/xtpRAKKrjJT1obGoC7Bu/F4ZDbQDUFf+R5igUyD TyoPZd7lLJdCnRhQY+YcNbvF24Bm0W+wXhBbZuXzfZ0S+goW4BTtpcDrfmHX5DMR wbtfGuML9aAUnYPRLM4QJDExIhjHTVZ+jxR2qQbo9HSix9XPVbLBV5a3F7HTBScU bjnqBpaZLro1lAf9QjdXzXVtPQcwrot74wi2lvMh8+/uAfVSAG2vjXqudRZYmMfX 2yIxICeoYCm5q4gsb97NBKVsKyRQ8g== =y1r1 -----END PGP SIGNATURE----- --B16t250KeUJFJrKQGrs7LBXlTCLpN9eLD-- From nobody Wed Jan 24 01:52:19 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C1F12DA0C for ; Wed, 24 Jan 2018 01:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 Gn_ylNIDABDx for ; Wed, 24 Jan 2018 01:52:15 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B450712D94E for ; Wed, 24 Jan 2018 01:52:14 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 297F716087F; Wed, 24 Jan 2018 10:52:13 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id F40A74006F; Wed, 24 Jan 2018 10:52:12 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0382.000; Wed, 24 Jan 2018 10:52:12 +0100 From: To: Eliot Lear CC: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham Thread-Topic: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt Thread-Index: AQHTlO4ijwfw7fdn00+sxY/M7KbCAqOCvqXQ Date: Wed, 24 Jan 2018 09:52:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> In-Reply-To: <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0C5FDDOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 09:52:17 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0C5FDDOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWxpb3QsDQoNCg0KU29tZSBxdWljayBjb21tZW50czoNCg0KKiBQbGVhc2Ugbm90ZSB0aGF0 ICJhY2wtdHlwZSIgc2hvdWxkIGJlIOKAnHR5cGXigJ0gYW5kICJydWxlLW5hbWUiIHNob3VsZCBi ZSBjaGFuZ2VkIHRvIOKAnG5hbWXigJ0uIFRoaXMgY2FuIGJlIGVhc2lseSBmaXhlZCBpbiB0aGUg ZXhhbXBsZXMuDQoNCiogVGhpcyBzZW50ZW5jZSBzaG91bGQgYmUgY2FyZWZ1bGx5IHVwZGF0ZWQg YXMgd2VsbDog4oCcV2l0aCB0aGUgZXhjZXB0aW9ucyBvZiAibmFtZSIsICJhY2wtdHlwZSIsICJy dWxlLW5hbWUiLCBhbmQgVENQIGFuZOKAnS4NCg0KKiBJIGd1ZXNzIHRoZSBleGFtcGxlcyBzaG91 bGQgYmUgY2hlY2tlZCB0byBhbGlnbiB3aXRoIHRoZSBuZXcgQUNMIHN0cnVjdHVyZS4gRm9yIGV4 YW1wbGUsDQoNCiAtIOKAnGlwdjYtYWNs4oCdIGVudHJpZXMgc2hvdWxkIGJlIHVwZGF0ZWQgdG8g 4oCcaXB2NuKAnS4NCg0KIC0gYWRkIOKAnGwz4oCdIGVudHJ5IGJlZm9yZSDigJxpcHY04oCdIGFu ZCDigJxpcHY24oCdLg0KDQoqIEl0IHdvdWxkIHVzZWZ1bCB0byBhZGQgYSBqdXN0aWZpY2F0aW9u IHdoeSBpdCBpcyBub3QgcmVjb21tZW5kZWQgdG8gc3VwcG9ydCAncmVqZWN0JyBhY3Rpb24uDQoN CiogVW5sZXNzIEnigJltIG1pc3Rha2VuLCB0aGUgbXVkIHVzZSBjYXNlIGRvZXMgbm90IHJlcXVp cmUgdGhlIHN1cHBvcnQgb2YgaW50ZXJmYWNlcyBhcyBhbiBhdHRhY2htZW50IHBvaW50LiBJdCBt YXkgYmUgdXNlZnVsIHRvIGFkZCBzb21ldGhpbmcgYW1vbmcgdGhvc2UgbGluZXM6DQoNCiAgIEdp dmVuIHRoYXQgTVVEIGRvZXMgbm90IGRlYWwgd2l0aCBpbnRlcmZhY2VzLCB0aGUNCiAgIHN1cHBv cnQgb2YgdGhlICJpZXRmLWludGVyZmFjZXMiIG1vZHVsZSBbUkZDNzIyMzxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzIyMz5dIGlzIG5vdA0KICAgcmVxdWlyZWQuIFNwZWNpZmljYWxs eSwgdGhlIHN1cHBvcnQgb2YgaW50ZXJmYWNlLXJlbGF0ZWQNCiAgIGZlYXR1cmVzIGFuZCBicmFu Y2hlcyAoZS5nLiwgaW50ZXJmYWNlLWF0dGFjaG1lbnQgYW5kIGludGVyZmFjZS1zdGF0cykNCiAg IG9mIHRoZSBBQ0wgWUFORyBtb2R1bGUgaXMgbm90IHJlcXVpcmVkLg0KDQoNCg0KQ2hlZXJzLA0K DQpNZWQNCg0KRGUgOiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gRGUg bGEgcGFydCBkZSBFbGlvdCBMZWFyDQpFbnZvecOpIDogbWVyY3JlZGkgMjQgamFudmllciAyMDE4 IDA5OjM0DQpDYyA6IE1haGVzaCBKZXRoYW5hbmRhbmk7IG9wc2F3Z0BpZXRmLm9yZzsgTWFyayBO b3R0aW5naGFtDQpPYmpldCA6IFJlOiBbT1BTQVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9w c2F3Zy1tdWQtMTQudHh0DQoNCg0KVGhpcyB1cGRhdGUgcHJpbWFyaWx5IGZvY3VzZXMgb24gdHdv IGVsZW1lbnRzIHRoYXQgd2VyZSBhZ3JlZWQgZHVyaW5nIFdHTEM6DQoNCiAgKiAgIFRoZSB1cGRh dGUgdG8gdGhlIEFDTCBtb2RlbC4gIFRoYXQgdXBkYXRlIGhhcyB0YWtlbiBsb25nZXIgdGhhbiBJ IHdvdWxkIGhhdmUgbGlrZWQsIGJ1dCBpdCBpcyBub3cgYXQgbGVhc3QgY2xvc2UgdG8gZmluaXNo ZWQuICBOb3RlOiB0aGUgTVVEIG1vZGVsIGRvZXMgbm90IHlldCBtYXRjaCB0aGUgcHVibGlzaGVk IEFDTCBtb2RlbCwgYnV0IGl0IGRvZXMgbWF0Y2ggdGhlIGFncmVlZCBjaGFuZ2VzIHRoYXQgd2ls bCBiZSBwcm9kdWNlZCBpbiB0aGUgbmV4dCBBQ0wgZHJhZnQuDQogICogICBNYXJrIE5vdHRpbmdo YW0gaGFkIGNvbW1lbnRlZCB0aGF0IGl0IGlzIG5vdCBhcHByb3ByaWF0ZSB0byBoYXZlIHZlcnNp b25pbmcgaW5mb3JtYXRpb24gaW4gdGhlIE1VRC1VUkwgaXRzZWxmLCBidXQgdGhhdCBpdCBzaG91 bGQgYmUgaW4gdGhlIG1vZGVsLiAgV2UgYWdyZWVkIG9uIHRoaXMgY2hhbmdlLCBhcyB3ZWxsIGFz IHNvbWUgd29yZGluZyBhcm91bmQgaG93IEhUVFAgaXMgaGFuZGxlZC4NCg0KQmFzZWQgb24gdGhl c2UgY2hhbmdlcywgSSB3b3VsZCBsaWtlIHRvIG1vdmUgdGhpcyBkb2N1bWVudCBmb3J3YXJkIHRv IElFVEYgTEMuDQoNCkVsaW90DQoNCk9uIDI0LjAxLjE4IDA5OjI5LCBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCg0KDQpB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuDQoNClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJlYSBXb3JraW5nIEdyb3VwIFdHIG9mIHRoZSBJ RVRGLg0KDQoNCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBNYW51ZmFjdHVyZXIgVXNhZ2Ug RGVzY3JpcHRpb24gU3BlY2lmaWNhdGlvbg0KDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IEVs aW90IExlYXINCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBSYWxwaCBEcm9tcw0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgIERhbiBSb21hc2NhbnUNCg0KIEZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtb3BzYXdnLW11ZC0xNC50eHQNCg0KIFBhZ2VzICAgICAgICAgICA6IDU2DQoN CiBEYXRlICAgICAgICAgICAgOiAyMDE4LTAxLTI0DQoNCg0KDQpBYnN0cmFjdDoNCg0KICAgVGhp cyBtZW1vIHNwZWNpZmllcyBhIGNvbXBvbmVudC1iYXNlZCBhcmNoaXRlY3R1cmUgZm9yIG1hbnVm YWN0dXJlcg0KDQogICB1c2FnZSBkZXNjcmlwdGlvbnMgKE1VRCkuICBUaGUgZ29hbCBvZiBNVUQg aXMgdG8gcHJvdmlkZSBhIG1lYW5zIGZvcg0KDQogICBUaGluZ3MgdG8gc2lnbmFsIHRvIHRoZSBu ZXR3b3JrIHdoYXQgc29ydCBvZiBhY2Nlc3MgYW5kIG5ldHdvcmsNCg0KICAgZnVuY3Rpb25hbGl0 eSB0aGV5IHJlcXVpcmUgdG8gcHJvcGVybHkgZnVuY3Rpb24uICBUaGUgaW5pdGlhbCBmb2N1cw0K DQogICBpcyBvbiBhY2Nlc3MgY29udHJvbC4gIExhdGVyIHdvcmsgY2FuIGRlbHZlIGludG8gb3Ro ZXIgYXNwZWN0cy4NCg0KDQoNCiAgIFRoaXMgbWVtbyBzcGVjaWZpZXMgdHdvIFlBTkcgbW9kdWxl cywgSVB2NCBhbmQgSVB2NiBESENQIG9wdGlvbnMsIGFuDQoNCiAgIExMRFAgVExWLCBhIFVSTCBz dWZmaXggc3BlY2lmaWNhdGlvbiwgYW4gWC41MDkgY2VydGlmaWNhdGUgZXh0ZW5zaW9uDQoNCiAg IGFuZCBhIG1lYW5zIHRvIHNpZ24gYW5kIHZlcmlmeSB0aGUgZGVzY3JpcHRpb25zLg0KDQoNCg0K DQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1tdWQv DQoNCg0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQoN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1tdWQtMTQNCg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1t dWQtMTQNCg0KDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3Bz YXdnLW11ZC0xNA0KDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCg0KdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9QU0FXRyBtYWls aW5nIGxpc3QNCg0KT1BTQVdHQGlldGYub3JnPG1haWx0bzpPUFNBV0dAaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQoNCg0KDQo= --_000_787AE7BB302AE849A7480A190F8B93300A0C5FDDOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpw cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0 w6kgSFRNTCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj azt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOp IEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBy w6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250 LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5pbnNlcnQNCgl7bXNv LXN0eWxlLW5hbWU6aW5zZXJ0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44 NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjIwOTE2MzI4Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozNzU5NzUxNDQgLTIyMTQx MjU0IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3 IDY3ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQt YXQ6MzsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTg1MDM3MDgxNzsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTE0NTM2OTUzNDg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgRWxpb3Qs DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Tb21lIHF1aWNrIGNvbW1lbnRzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj4qIFBsZWFzZSBub3RlIHRoYXQgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+JnF1b3Q7YWNsLXR5cGUmcXVvdDsgc2hvdWxkIGJlIOKAnHR5cGXi gJ0gYW5kICZxdW90O3J1bGUtbmFtZSZxdW90OyBzaG91bGQgYmUgY2hhbmdlZCB0byDigJxuYW1l 4oCdLiBUaGlzIGNhbiBiZSBlYXNpbHkgZml4ZWQgaW4gdGhlIGV4YW1wbGVzLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0Ij4qIFRoaXMgc2VudGVuY2Ugc2hvdWxkIGJlIGNhcmVmdWxseSB1cGRhdGVkIGFzIHdl bGw6IOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+V2l0aCB0aGUgZXhjZXB0aW9ucyBvZiA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4mcXVvdDtuYW1lJnF1b3Q7LDwvc3Bhbj4gJnF1b3Q7YWNsLXR5 cGUmcXVvdDssICZxdW90O3J1bGUtbmFtZSZxdW90OywgYW5kIFRDUCBhbmQ8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij7igJ0uPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+KiBJIGd1ZXNzIHRoZSBleGFtcGxlcyBzaG91bGQgYmUgY2hlY2tlZCB0byBhbGlnbiB3aXRo IHRoZSBuZXcgQUNMIHN0cnVjdHVyZS4gRm9yIGV4YW1wbGUsIDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZu YnNwOy0g4oCcaXB2Ni1hY2zigJ0gZW50cmllcyBzaG91bGQgYmUgdXBkYXRlZCB0byDigJxpcHY2 4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPiAtIGFkZCDigJxsM+KAnSBlbnRyeSBiZWZvcmUg4oCcaXB2 NOKAnSBhbmQg4oCcaXB2NuKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4qIEl0IHdvdWxkIHVzZWZ1bCB0 byBhZGQgYSBqdXN0aWZpY2F0aW9uIHdoeSBpdCBpcyBub3QgcmVjb21tZW5kZWQgdG8gc3VwcG9y dCAncmVqZWN0JyBhY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+KiBVbmxlc3MgSeKAmW0gbWlzdGFr ZW4sIHRoZSBtdWQgdXNlIGNhc2UgZG9lcyBub3QgcmVxdWlyZSB0aGUgc3VwcG9ydCBvZiBpbnRl cmZhY2VzIGFzIGFuIGF0dGFjaG1lbnQgcG9pbnQuIEl0IG1heSBiZSB1c2VmdWwgdG8gYWRkIHNv bWV0aGluZyBhbW9uZyB0aG9zZSBsaW5lczogJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBHaXZl biB0aGF0IE1VRCBkb2VzIG5vdCBkZWFsIHdpdGggaW50ZXJmYWNlcywgdGhlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBzdXBwb3J0IG9mIHRoZSAmcXVvdDtpZXRmLWlu dGVyZmFjZXMmcXVvdDsgbW9kdWxlIFs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMjMiIHRpdGxlPSImcXVv dDtBIFlBTkcgRGF0YSBNb2RlbCBmb3IgSW50ZXJmYWNlIE1hbmFnZW1lbnQmcXVvdDsiPjxzcGFu IGxhbmc9IkVOLVVTIj5SRkM3MjIzPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPl0NCiBpcyBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4 dCI+Jm5ic3A7Jm5ic3A7IHJlcXVpcmVkLiBTcGVjaWZpY2FsbHksIHRoZSBzdXBwb3J0IG9mIGlu dGVyZmFjZS1yZWxhdGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyBm ZWF0dXJlcyBhbmQgYnJhbmNoZXMgKGUuZy4sIGludGVyZmFjZS1hdHRhY2htZW50IGFuZCBpbnRl cmZhY2Utc3RhdHMpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7b2YgdGhlIEFDTCBZQU5HIG1vZHVsZSBpcyBub3QgcmVxdWlyZWQuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkNoZWVycyw8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0Ij5NZWQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gT1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBFbGlvdCBMZWFyPGJyPg0KPGI+RW52b3nD qSZuYnNwOzo8L2I+IG1lcmNyZWRpIDI0IGphbnZpZXIgMjAxOCAwOTozNDxicj4NCjxiPkNjJm5i c3A7OjwvYj4gTWFoZXNoIEpldGhhbmFuZGFuaTsgb3BzYXdnQGlldGYub3JnOyBNYXJrIE5vdHRp bmdoYW08YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbT1BTQVdHXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLW9wc2F3Zy1tdWQtMTQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+ VGhpcyB1cGRhdGUgcHJpbWFyaWx5IGZvY3VzZXMgb24gdHdvIGVsZW1lbnRzIHRoYXQgd2VyZSBh Z3JlZWQgZHVyaW5nIFdHTEM6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NClRoZSB1cGRhdGUg dG8gdGhlIEFDTCBtb2RlbC4mbmJzcDsgVGhhdCB1cGRhdGUgaGFzIHRha2VuIGxvbmdlciB0aGFu IEkgd291bGQgaGF2ZSBsaWtlZCwgYnV0IGl0IGlzIG5vdyBhdCBsZWFzdCBjbG9zZSB0byBmaW5p c2hlZC4mbmJzcDsgTm90ZTogdGhlIE1VRCBtb2RlbCBkb2VzIG5vdCB5ZXQgbWF0Y2ggdGhlIHB1 Ymxpc2hlZCBBQ0wgbW9kZWwsIGJ1dCBpdCBkb2VzIG1hdGNoIHRoZSBhZ3JlZWQgY2hhbmdlcyB0 aGF0IHdpbGwgYmUgcHJvZHVjZWQgaW4gdGhlDQogbmV4dCBBQ0wgZHJhZnQuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KTWFy ayBOb3R0aW5naGFtIGhhZCBjb21tZW50ZWQgdGhhdCBpdCBpcyBub3QgYXBwcm9wcmlhdGUgdG8g aGF2ZSB2ZXJzaW9uaW5nIGluZm9ybWF0aW9uIGluIHRoZSBNVUQtVVJMIGl0c2VsZiwgYnV0IHRo YXQgaXQgc2hvdWxkIGJlIGluIHRoZSBtb2RlbC4mbmJzcDsgV2UgYWdyZWVkIG9uIHRoaXMgY2hh bmdlLCBhcyB3ZWxsIGFzIHNvbWUgd29yZGluZyBhcm91bmQgaG93IEhUVFAgaXMgaGFuZGxlZC48 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPkJhc2VkIG9uIHRoZXNlIGNoYW5nZXMsIEkgd291bGQg bGlrZSB0byBtb3ZlIHRoaXMgZG9jdW1lbnQgZm9yd2FyZCB0byBJRVRGIExDLjxvOnA+PC9vOnA+ PC9wPg0KPHA+RWxpb3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI0LjAxLjE4 IDA5OjI5LCA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj4NCmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg T3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBBcmVhIFdvcmtpbmcgR3JvdXAgV0cgb2YgdGhlIElF VEYuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOzogTWFu dWZhY3R1cmVyIFVzYWdlIERlc2NyaXB0aW9uIFNwZWNpZmljYXRpb248bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9y cyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IEVsaW90 IExlYXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgUmFscGggRHJvbXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGFuIFJvbWFzY2FudTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiBGaWxlbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6 IGRyYWZ0LWlldGYtb3BzYXdnLW11ZC0xNC50eHQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gUGFn ZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgOiA1NjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBEYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjAxOC0w MS0yNDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIG1lbW8g c3BlY2lmaWVzIGEgY29tcG9uZW50LWJhc2VkIGFyY2hpdGVjdHVyZSBmb3IgbWFudWZhY3R1cmVy PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHVzYWdlIGRlc2NyaXB0aW9ucyAo TVVEKS4mbmJzcDsgVGhlIGdvYWwgb2YgTVVEIGlzIHRvIHByb3ZpZGUgYSBtZWFucyBmb3I8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhpbmdzIHRvIHNpZ25hbCB0byB0aGUg bmV0d29yayB3aGF0IHNvcnQgb2YgYWNjZXNzIGFuZCBuZXR3b3JrPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IGZ1bmN0aW9uYWxpdHkgdGhleSByZXF1aXJlIHRvIHByb3Blcmx5 IGZ1bmN0aW9uLiZuYnNwOyBUaGUgaW5pdGlhbCBmb2N1czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBpcyBvbiBhY2Nlc3MgY29udHJvbC4mbmJzcDsgTGF0ZXIgd29yayBjYW4g ZGVsdmUgaW50byBvdGhlciBhc3BlY3RzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIG1lbW8gc3BlY2lmaWVzIHR3 byBZQU5HIG1vZHVsZXMsIElQdjQgYW5kIElQdjYgREhDUCBvcHRpb25zLCBhbjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBMTERQIFRMViwgYSBVUkwgc3VmZml4IHNwZWNpZmlj YXRpb24sIGFuIFguNTA5IGNlcnRpZmljYXRlIGV4dGVuc2lvbjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBhbmQgYSBtZWFucyB0byBzaWduIGFuZCB2ZXJpZnkgdGhlIGRlc2Ny aXB0aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1t dWQvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1t dWQvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPlRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vcHNhd2ctbXVkLTE0Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1vcHNhd2ctbXVkLTE0PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctbXVk LTE0Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3Bz YXdnLW11ZC0xNDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzYXdnLW11ZC0xNCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzYXdnLW11ZC0xNDwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+ dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8iPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9h PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48 L3ByZT4NCjxwcmU+T1BTQVdHIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxh IGhyZWY9Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmciPk9QU0FXR0BpZXRmLm9yZzwvYT48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29wc2F3ZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNh d2c8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93300A0C5FDDOPEXCLILMA3corp_-- From nobody Wed Jan 24 02:05:21 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD2E12DA0C for ; Wed, 24 Jan 2018 02:05:20 -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, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, 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 h3Fj76b7zi_Y for ; Wed, 24 Jan 2018 02:05:17 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB8F612D94E for ; Wed, 24 Jan 2018 02:05:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30611; q=dns/txt; s=iport; t=1516788316; x=1517997916; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Jl0WdOOYql0SCocZUNIIgnQriceY5Oel+Df4liqBtEo=; b=IZAEvze6ZX3Dnn6l2tlCjqfIYnsfPATUSqPyPGwAvwRYKQRKU0SItajS 23xEt1pCWLDvg6nFEPrnS3slzht9V4zVKty5ZWNTvsXgR+NcefQ7RmeBJ vQVGeVu4QPyW/vDkQYoR0+Ds0pUIPGu8GnLnsXGrL9xR56az9TuXup4oZ A=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.46,406,1511827200"; d="asc'?scan'208,217";a="1622329" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 10:05:15 +0000 Received: from [10.61.241.55] ([10.61.241.55]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0OA5EXL025125; Wed, 24 Jan 2018 10:05:14 GMT To: mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham , "Saswat Praharaj (saspraha)" References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Eliot Lear Message-ID: Date: Wed, 24 Jan 2018 11:05:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rHCcJw3qkTpTaIQNmQcEejxiEU4fQK812" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 10:05:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rHCcJw3qkTpTaIQNmQcEejxiEU4fQK812 Content-Type: multipart/mixed; boundary="6PiswfVOF2HOIjniSfAV5UKhPbjHw3Cb3"; protected-headers="v1" From: Eliot Lear To: mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham , "Saswat Praharaj (saspraha)" Message-ID: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> --6PiswfVOF2HOIjniSfAV5UKhPbjHw3Cb3 Content-Type: multipart/alternative; boundary="------------7B54044DF6B67DB68DFDC094" Content-Language: en-US This is a multi-part message in MIME format. --------------7B54044DF6B67DB68DFDC094 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Med, On 24.01.18 10:52, mohamed.boucadair@orange.com wrote: > > Hi Eliot, > > =C2=A0 > > Some quick comments: > * Please note that "acl-type" should be =E2=80=9Ctype=E2=80=9D and "rul= e-name" should > be changed to =E2=80=9Cname=E2=80=9D. This can be easily fixed in the e= xamples. My understanding from draft-ietf-netmod-acl-model-14 is that acl-type remains acl-type.=C2=A0 acl-name became name.=C2=A0 But you're right- rul= e-name became name as well.=C2=A0 I will adjust the text accordingly. > * This sentence should be carefully updated as well: =E2=80=9CWith the > exceptions of "name", "acl-type", "rule-name", and TCP and=E2=80=9D. > * I guess the examples should be checked to align with the new ACL > structure. For example, > =C2=A0- =E2=80=9Cipv6-acl=E2=80=9D entries should be updated to =E2=80=9C= ipv6=E2=80=9D. Which is the text I adjusted ;-) > - add =E2=80=9Cl3=E2=80=9D entry before =E2=80=9Cipv4=E2=80=9D and =E2=80= =9Cipv6=E2=80=9D. I think this is done in the normative text but you're right- it needs to be corrected in the examples. > * It would useful to add a justification why it is not recommended to > support 'reject' action. Ok, I'll add some text. > * Unless I=E2=80=99m mistaken, the mud use case does not require the su= pport > of interfaces as an attachment point. It may be useful to add > something among those lines: =C2=A0 > > =C2=A0 > > =C2=A0=C2=A0 Given that MUD does not deal with interfaces, the > > =C2=A0=C2=A0 support of the "ietf-interfaces" module [RFC7223 > ] is not > > =C2=A0=C2=A0 required. Specifically, the support of interface-related > > =C2=A0=C2=A0 features and branches (e.g., interface-attachment and inte= rface-stats) > > =C2=A0=C2=A0=C2=A0of the ACL YANG module is not required. > ok. In addition, I have received the following requests for data elements to be added to the core model: * Manufacturer-Name * Device-Type * Model-Number * Software-version Unless I hear objections, I am disposed to add these as non-mandatory leaf-nodes as strings underneath the top-level MUD object. Eliot > > =C2=A0 > Cheers, > Med > > =C2=A0 > > *De=C2=A0:*OPSAWG [mailto:opsawg-bounces@ietf.org] *De la part de* Elio= t Lear > *Envoy=C3=A9=C2=A0:* mercredi 24 janvier 2018 09:34 > *Cc=C2=A0:* Mahesh Jethanandani; opsawg@ietf.org; Mark Nottingham > *Objet=C2=A0:* Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt > > =C2=A0 > > This update primarily focuses on two elements that were agreed during > WGLC: > > * The update to the ACL model.=C2=A0 That update has taken longer tha= n I > would have liked, but it is now at least close to finished.=C2=A0 N= ote: > the MUD model does not yet match the published ACL model, but it > does match the agreed changes that will be produced in the next > ACL draft. > * Mark Nottingham had commented that it is not appropriate to have > versioning information in the MUD-URL itself, but that it should > be in the model.=C2=A0 We agreed on this change, as well as some > wording around how HTTP is handled. > > Based on these changes, I would like to move this document forward to > IETF LC. > > Eliot > > =C2=A0 > > On 24.01.18 09:29, internet-drafts@ietf.org > wrote: > > =C2=A0 > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > This draft is a work item of the Operations and Management Area Wor= king Group WG of the IETF. > > =C2=A0 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0: Manufacturer Usage Description = Specification > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Eliot Lear > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Ralph Droms > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Dan Romascanu > > Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : draft-ietf-op= sawg-mud-14.txt > > Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = : 56 > > Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 : 2018-01-24 > > =C2=A0 > > Abstract: > > =C2=A0=C2=A0 This memo specifies a component-based architecture for= manufacturer > > =C2=A0=C2=A0 usage descriptions (MUD).=C2=A0 The goal of MUD is to = provide a means for > > =C2=A0=C2=A0 Things to signal to the network what sort of access an= d network > > =C2=A0=C2=A0 functionality they require to properly function.=C2=A0= The initial focus > > =C2=A0=C2=A0 is on access control.=C2=A0 Later work can delve into = other aspects. > > =C2=A0 > > =C2=A0=C2=A0 This memo specifies two YANG modules, IPv4 and IPv6 DH= CP options, an > > =C2=A0=C2=A0 LLDP TLV, a URL suffix specification, an X.509 certifi= cate extension > > =C2=A0=C2=A0 and a means to sign and verify the descriptions. > > =C2=A0 > > =C2=A0 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > =C2=A0 > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-opsawg-mud-14 > > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14 > > =C2=A0 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-14 > > =C2=A0 > > =C2=A0 > > Please note that it may take a couple of minutes from the time of s= ubmission > > until the htmlized version and diff are available at tools.ietf.org= =2E > > =C2=A0 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > =C2=A0 > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > =C2=A0 > > =C2=A0 > --------------7B54044DF6B67DB68DFDC094 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Med,


On 24.01.18 10:52, mohamed.boucadair@orange.com wrote:

Hi Eliot,

=C2=A0

Some quick commen=
ts:
* Please note tha=
t "acl-type" shoul=
d be =E2=80=9Ctype=E2=80=9D and "rule-name" should be changed to =E2=80=9C=
name=E2=80=9D. This can be easily fixed in the examples.

My understanding from draft-ietf-netmod-acl-model-14 is that acl-type remains acl-type.=C2=A0 acl-name became name.=C2=A0 But you'= re right- rule-name became name as well.=C2=A0 I will adjust the text according= ly.

<=
/span>
* This sente=
nce should be carefully updated as well: =E2=80=9CWith the exceptions of "name", "acl-ty=
pe", "rule-name", and TCP and=E2=80=9D.
* I guess th=
e examples should be checked to align with the new ACL structure. For exa=
mple, 
=C2=A0- =E2=80=
=9Cipv6-acl=E2=80=9D entries should be updated to =E2=80=9Cipv6=E2=80=9D.=

Which is the text I adjusted ;-)

<=
/span>
 - add =E2=80=
=9Cl3=E2=80=9D entry before =E2=80=9Cipv4=E2=80=9D and =E2=80=9Cipv6=E2=80=
=9D.

I think this is done in the normative text but you're right- it needs to be corrected in the examples.

<=
/span>
* It would u=
seful to add a justification why it is not recommended to support 'reject=
' action.

Ok, I'll add some text.

<=
/span>
* Unless I=E2=
=80=99m mistaken, the mud use case does not require the support of interf=
aces as an attachment point. It may be useful to add something among thos=
e lines: =C2=A0

=C2=A0<= /span>

=C2=A0=C2=A0 Given= that MUD does not deal with interfaces, the

=C2=A0=C2=A0 suppo= rt of the "ietf-interfaces" module [RFC7223] is not

=C2=A0=C2=A0 requi= red. Specifically, the support of interface-related

=C2=A0=C2=A0 featu= res and branches (e.g., interface-attachment and interface-stats)

=C2=A0=C2=A0=C2=A0= of the ACL YANG module is not required.


ok.


In addition, I have received the following requests for data elements to be added to the core model:

  • Manufacturer-Name
  • Device-Type
  • Model-Number
  • Software-version

Unless I hear objections, I am disposed to add these as non-mandatory leaf-nodes as strings underneath the top-level MUD object.

Eliot

=C2=A0
Cheers,=

Med

=C2=A0

De=C2=A0: OPSAWG [mailto:opsawg-bounces@ietf.org] De la part de Eliot Lear
Envoy=C3=A9=C2=A0: mercredi 24 janvier 2018 09:3= 4
Cc=C2=A0: Mahesh Jethanandani; opsawg@ietf.org;= Mark Nottingham
Objet=C2=A0: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt

=C2=A0

This update primarily focuses on two elements that were agreed during WGLC:

  • The update to the ACL model.=C2=A0 That update has taken lo= nger than I would have liked, but it is now at least close to finished.=C2=A0 Note: the MUD model does not yet match the published ACL model, but it does match the agreed changes that will be produced in the next ACL draft.
  • Mark Nottingham had commented that it is not appropriate to have versioning information in the MUD-URL itself, but that it should be in the model.=C2=A0 We agreed on this cha= nge, as well as some wording around how HTTP is handled.

Based on these changes, I would like to move this document forward to IETF LC.

Eliot

=C2=A0

On 24.01.18 09:29, internet-drafts@ietf.org wrote:

=C2=A0
A New Internet-Draft is available from the on-line Inter=
net-Drafts directories.
This draft is a work item of the Operations and Manageme=
nt Area Working Group WG of the IETF.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0: Manufacturer Usage =
Description Specification
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Eliot Lear
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Ralph Droms
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Dan Romascanu
 Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : dr=
aft-ietf-opsawg-mud-14.txt
 Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 : 56
 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 : 2018-01-24
=C2=A0
Abstract:
=C2=A0=C2=A0 This memo specifies a component-based archi=
tecture for manufacturer
=C2=A0=C2=A0 usage descriptions (MUD).=C2=A0 The goal of=
 MUD is to provide a means for
=C2=A0=C2=A0 Things to signal to the network what sort o=
f access and network
=C2=A0=C2=A0 functionality they require to properly func=
tion.=C2=A0 The initial focus
=C2=A0=C2=A0 is on access control.=C2=A0 Later work can =
delve into other aspects.
=C2=A0
=C2=A0=C2=A0 This memo specifies two YANG modules, IPv4 =
and IPv6 DHCP options, an
=C2=A0=C2=A0 LLDP TLV, a URL suffix specification, an X.=
509 certificate extension
=C2=A0=C2=A0 and a means to sign and verify the descript=
ions.
=C2=A0
=C2=A0
The IETF datatracker status page for this draft is:=

https://datatracker.ietf.org/doc/dra=
ft-ietf-opsawg-mud/
=C2=A0
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-=
opsawg-mud-14
https://datatracker.ietf.org/=
doc/html/draft-ietf-opsawg-mud-14
=C2=A0
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?ur=
l2=3Ddraft-ietf-opsawg-mud-14
=C2=A0
=C2=A0
Please note that it may take a couple of minutes from th=
e time of submission
until the htmlized version and diff are available at too=
ls.ietf.org.
=C2=A0
Internet-Drafts are also available by anonymous FTP at:<=
o:p>
ftp://ftp.ietf.org/internet-drafts/
= 
=C2=A0
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
=C2=A0

=C2=A0


--------------7B54044DF6B67DB68DFDC094-- --6PiswfVOF2HOIjniSfAV5UKhPbjHw3Cb3-- --rHCcJw3qkTpTaIQNmQcEejxiEU4fQK812 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpoWlkACgkQh7ZrRtnS ejOPKwgAsiNabTe0l6/Qkwkr26ODqPDriNDly5VdMTr/eCMmhWTM/i3EoKL0ESUl iPCAoI/IXe2kDuOhx1Q7ut0X0Qut7GLOY6i5BAGVqeZN0R8vC18Me3MJvTMv6TKj DtPpGQONJlHoerNRLufaZqB6gRGBcC78UPLUAGdVhIjiGJR4XVX2OLNbQXF8YMtR OtGh85PwJfWSKAAeaKVh9614A21Vc93Jx98+0Uw3ajjTpeOjfai+hqm47wrolx35 InU3jF55brvwPMLdRS++UyD3bfApz0JGLlUh4iPOkAz821CZ1JjhVvKGy7qiZohn sZ7bLyzuv7ev293aqq09riAH3Lrzdg== =vKua -----END PGP SIGNATURE----- --rHCcJw3qkTpTaIQNmQcEejxiEU4fQK812-- From nobody Wed Jan 24 02:14:11 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E221812DA16 for ; Wed, 24 Jan 2018 02:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 94e2G98yvHUt for ; Wed, 24 Jan 2018 02:14:08 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F67412D964 for ; Wed, 24 Jan 2018 02:14:08 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5F2E8EAF; Wed, 24 Jan 2018 11:14:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id HjO_Hcuv2L_i; Wed, 24 Jan 2018 11:14:07 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Jan 2018 11:14:07 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 447E020149; Wed, 24 Jan 2018 11:14:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ouI2HTCj-g39; Wed, 24 Jan 2018 11:14:07 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD27920147; Wed, 24 Jan 2018 11:14:06 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9FF4042275B2; Wed, 24 Jan 2018 11:14:06 +0100 (CET) Date: Wed, 24 Jan 2018 11:14:06 +0100 From: Juergen Schoenwaelder To: Eliot Lear Cc: mohamed.boucadair@orange.com, Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham Message-ID: <20180124101406.pgzerj2ejnuyjfv6@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Eliot Lear , mohamed.boucadair@orange.com, Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 10:14:11 -0000 On Wed, Jan 24, 2018 at 11:05:13AM +0100, Eliot Lear wrote: > > In addition, I have received the following requests for data elements to > be added to the core model: > > * Manufacturer-Name > * Device-Type > * Model-Number > * Software-version > Will these definitions be aligned with definitions in 'ietf-hardware' defined in draft-ietf-netmod-entity-08.txt (which is in the state IESG Evaluation)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 24 03:01:03 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151AA12DA21 for ; Wed, 24 Jan 2018 03:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, 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 w92u1Iq4wYlh for ; Wed, 24 Jan 2018 03:01:00 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1FD12D96D for ; Wed, 24 Jan 2018 03:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2423; q=dns/txt; s=iport; t=1516791660; x=1518001260; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=ZLGOgt6TaLJgBxDY4BTgxVYVhqJ9O5uQDt+c0sH05as=; b=PLOAw9DQSVFw4oKPjjGztdtnPQ4eye5F0zNilr89P0It1Tj6Oi02uXPe G/M0ucVOTpx/ScGIAlciuRoM4jiWYl50fH5S+EwqxWBwNQgyhsOVhO/9y uMV8Y5t+5/7MnqDgr2xgY4KQGENc5/PxwuGVr4L1kPQK6L7DNh/aTpnXa w=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos; i="5.46,406,1511827200"; d="asc'?scan'208"; a="1623654" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 11:00:58 +0000 Received: from [10.61.241.55] ([10.61.241.55]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0OB0wi2011900; Wed, 24 Jan 2018 11:00:58 GMT To: mohamed.boucadair@orange.com, Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20180124101406.pgzerj2ejnuyjfv6@elstar.local> From: Eliot Lear Message-ID: <31c28b37-2bf8-2a64-cb47-44430ef104c7@cisco.com> Date: Wed, 24 Jan 2018 12:00:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180124101406.pgzerj2ejnuyjfv6@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KLuBfc8CUBWVvmgEjqNfXISsxOgLXCpl2" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 11:01:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KLuBfc8CUBWVvmgEjqNfXISsxOgLXCpl2 Content-Type: multipart/mixed; boundary="4r9pTNAdVFDHnm0u11aNnxHbjRmWiIbwp"; protected-headers="v1" From: Eliot Lear To: mohamed.boucadair@orange.com, Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham Message-ID: <31c28b37-2bf8-2a64-cb47-44430ef104c7@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20180124101406.pgzerj2ejnuyjfv6@elstar.local> In-Reply-To: <20180124101406.pgzerj2ejnuyjfv6@elstar.local> --4r9pTNAdVFDHnm0u11aNnxHbjRmWiIbwp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Yes, this makes sense. Eliot On 24.01.18 11:14, Juergen Schoenwaelder wrote: > On Wed, Jan 24, 2018 at 11:05:13AM +0100, Eliot Lear wrote: >> In addition, I have received the following requests for data elements = to >> be added to the core model: >> >> * Manufacturer-Name >> * Device-Type >> * Model-Number >> * Software-version >> > Will these definitions be aligned with definitions in 'ietf-hardware' > defined in draft-ietf-netmod-entity-08.txt (which is in the state IESG > Evaluation)? > > /js > --4r9pTNAdVFDHnm0u11aNnxHbjRmWiIbwp-- --KLuBfc8CUBWVvmgEjqNfXISsxOgLXCpl2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpoZ2kACgkQh7ZrRtnS ejM7wwgArWeeQuBrKR6QpzWF/DVQnBvbxyNkPuFAaSqmVb6SalMr95SyEdQhMqhE nSRn1AUy0odFu1r1SuRBjLwpTiCRw0TDcl8CA8Hym5LUld7SGRgBHDEPAzmLy4JF COis4H3EvyI+qSuxt9sD7IU+oxFs1EUiCNkSjUJtoTkVhmBHpOOFNM8LIGdbKoTQ LVr1YETZSSPbQrx/9x56/1w/AHPREDfwNVDkFmf4YcMJRdiqRDd8AARSP1smrREP Yxrau1OSxzZiSvTqEV11TbI4RhcWQLzl7WhwuHeRE3PudncZqh/3Roe2ecglP2dh mjpWDRKMQIsri9QE79AE7ESs5lHwhA== =jWP2 -----END PGP SIGNATURE----- --KLuBfc8CUBWVvmgEjqNfXISsxOgLXCpl2-- From nobody Wed Jan 24 03:20:31 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5A212DA29 for ; Wed, 24 Jan 2018 03:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, 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 7zSJljHBPz6G for ; Wed, 24 Jan 2018 03:20:28 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D17D12DA27 for ; Wed, 24 Jan 2018 03:20:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=795; q=dns/txt; s=iport; t=1516792828; x=1518002428; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=K7MiM3fJeDJPifbfbV1PI/9+RtOA2wMx2mq8udRTnlk=; b=SJnaBLndZ5S/qFaEaKB5cAKbbI/yigDSyrUturQyNILPRxd4sbygD6lj F8/E+Z6Fr4C18to+Pp32anfUDMDn+00eyUdhl0e+yGI1sorG1bK6MalC+ dQeMcfJ9Ye9z1DdNw3oiCA5cVt260rjlMW2lIKmnb5v8YAIKQ/CjImitV U=; X-IronPort-AV: E=Sophos;i="5.46,406,1511827200"; d="scan'208";a="1571172" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 11:20:26 +0000 Received: from [10.61.214.179] ([10.61.214.179]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0OBKPB9013341; Wed, 24 Jan 2018 11:20:25 GMT To: Eliot Lear , mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Joe Clarke Organization: Cisco Message-ID: <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> Date: Wed, 24 Jan 2018 06:20:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 11:20:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/24/18 05:05, Eliot Lear wrote: > In addition, I have received the following requests for data > elements to be added to the core model: > > * Manufacturer-Name * Device-Type * Model-Number * > Software-version > > > Unless I hear objections, I am disposed to add these as > non-mandatory leaf-nodes as strings underneath the top-level MUD > object. Is there a reason why they wouldn't be mandatory? Seems like these data would be readily available and having them would make a number of use case cases possible. Joe -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWmhr9wAKCRBvaI+K/hTP hz8+AJkBYe3doJJu8j1YkEatXt097IkX9QCgqfUdD6uzeNIjSBmV881F9JZooXI= =Kuxo -----END PGP SIGNATURE----- From nobody Wed Jan 24 03:24:38 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3503F12DA29 for ; Wed, 24 Jan 2018 03:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, 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 01k_QazMNsqW for ; Wed, 24 Jan 2018 03:24:35 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3547912DA27 for ; Wed, 24 Jan 2018 03:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2473; q=dns/txt; s=iport; t=1516793075; x=1518002675; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=vCqpvj6KqXQFsp36zu+rpy9skNRH80DNiYm+7t1k0Ds=; b=R6M/3AuqSQRMfDnvZaTKh0WhvVj1DMLT0IJoLcROTTWs3dWBkm3H+xoW eXuS9LcKkTWP/o/xbQ5P1USDXSgK+0/XQruAE5TRar9RbEkdBDT/R6Udo yvUid9f1O41RvPxh9nliU+B0gyt7/xBpuWQR0L+o7YxLdbc482+R+ZRj4 4=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos; i="5.46,406,1511827200"; d="asc'?scan'208"; a="1576371" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 11:24:33 +0000 Received: from [10.61.241.55] ([10.61.241.55]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0OBOXS9023355; Wed, 24 Jan 2018 11:24:33 GMT To: Joe Clarke , mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> From: Eliot Lear Message-ID: <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> Date: Wed, 24 Jan 2018 12:24:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="49vlMmAIIX9WGCFDpVbBKFRDqJivUxOUB" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 11:24:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --49vlMmAIIX9WGCFDpVbBKFRDqJivUxOUB Content-Type: multipart/mixed; boundary="Hbje5iBWjbgES13dWB29cdAxgUigDs7wL"; protected-headers="v1" From: Eliot Lear To: Joe Clarke , mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham Message-ID: <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> In-Reply-To: <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> --Hbje5iBWjbgES13dWB29cdAxgUigDs7wL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 24.01.18 12:20, Joe Clarke wrote: > Is there a reason why they wouldn't be mandatory?=C2=A0 Seems like thes= e > data would be readily available and having them would make a number of > use case cases possible. Yes, there is.=C2=A0 If the MUD-URL is "burned in" via 802.1AR and the software can be updated, then one oughtn't provide software information for the simple reason that it would be most likely wrong.=C2=A0 Hardware info?=C2=A0 Sure.=C2=A0 Software when using DHCP or LLDP?=C2=A0 Sure.=C2=A0= But otherwise no. Eliot --Hbje5iBWjbgES13dWB29cdAxgUigDs7wL-- --49vlMmAIIX9WGCFDpVbBKFRDqJivUxOUB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpobPAACgkQh7ZrRtnS ejMB6Qf9EECd7j+eb3Otp4uQImyVLgf0ADsIAng9cfwHHhyub+UO0jiwSE9QSURn NOOGYeienhSRLMZ3WRI+Rs157SnfiHG3b8NQzXFa+J9TBWWL4cwTJCiRvT3tlOy6 IpIZ1dZ3wLbfxwlBjR5zPxCgyo0reGRVZ0CBZOFY/c3UxjW+POcUDPsUK3GJaP44 tK66NlVyjCisCwrwrFoBQM69yUaIgZUxuMy091vpZ9+Ry/yeIacS4wOfJI+N2g4u I5b845QepWXlCONBmgAzOo1r+pmz2voDyeY2ppOKB+5VrEWkZWzaTWqTlTGUn2oQ W+h15k3v6MUkaxQhZUWAGSO+TR70yw== =S2/7 -----END PGP SIGNATURE----- --49vlMmAIIX9WGCFDpVbBKFRDqJivUxOUB-- From nobody Wed Jan 24 03:54:36 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D108D12DA2C for ; Wed, 24 Jan 2018 03:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 4ROiqnE9CJkS for ; Wed, 24 Jan 2018 03:54:31 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FC4120454 for ; Wed, 24 Jan 2018 03:54:31 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id C120D1013D3; Wed, 24 Jan 2018 12:54:29 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 8DC5240069; Wed, 24 Jan 2018 12:54:29 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0382.000; Wed, 24 Jan 2018 12:54:29 +0100 From: To: Eliot Lear CC: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham , "Saswat Praharaj (saspraha)" Thread-Topic: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt Thread-Index: AQHTlO4ijwfw7fdn00+sxY/M7KbCAqOCvqXQ///8YYCAABDhAA== Date: Wed, 24 Jan 2018 11:54:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C612A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0C612AOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 11:54:34 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0C612AOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpUaGFuayB5b3UgRWxpb3QgZm9yIHRoZSBwcm9tcHQgZm9sbG93LXVwLg0KDQpQbGVh c2Ugc2VlIHNvbWUgY29tbWVudHMgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBFbGlv dCBMZWFyIFttYWlsdG86bGVhckBjaXNjby5jb21dDQpFbnZvecOpIDogbWVyY3JlZGkgMjQgamFu dmllciAyMDE4IDExOjA1DQrDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCkNjIDogTWFo ZXNoIEpldGhhbmFuZGFuaTsgb3BzYXdnQGlldGYub3JnOyBNYXJrIE5vdHRpbmdoYW07IFNhc3dh dCBQcmFoYXJhaiAoc2FzcHJhaGEpDQpPYmpldCA6IFJlOiBbT1BTQVdHXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLW9wc2F3Zy1tdWQtMTQudHh0DQoNCg0KSGkgTWVkLA0KDQpPbiAyNC4wMS4xOCAx MDo1MiwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4gd3JvdGU6DQpIaSBFbGlvdCwNCg0KDQpTb21lIHF1aWNrIGNvbW1lbnRz Og0KDQoqIFBsZWFzZSBub3RlIHRoYXQgImFjbC10eXBlIiBzaG91bGQgYmUg4oCcdHlwZeKAnSBh bmQgInJ1bGUtbmFtZSIgc2hvdWxkIGJlIGNoYW5nZWQgdG8g4oCcbmFtZeKAnS4gVGhpcyBjYW4g YmUgZWFzaWx5IGZpeGVkIGluIHRoZSBleGFtcGxlcy4NCg0KTXkgdW5kZXJzdGFuZGluZyBmcm9t IGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xNCBpcyB0aGF0IGFjbC10eXBlIHJlbWFpbnMg YWNsLXR5cGUuICBhY2wtbmFtZSBiZWNhbWUgbmFtZS4gIEJ1dCB5b3UncmUgcmlnaHQtIHJ1bGUt bmFtZSBiZWNhbWUgbmFtZSBhcyB3ZWxsLiAgSSB3aWxsIGFkanVzdCB0aGUgdGV4dCBhY2NvcmRp bmdseS4NCltNZWRdIEkgZ3Vlc3MgeW91IG1lYW50IC0xNS4gSSBjb25maXJtIHRoYXQgYWNsLXR5 cGUgaXMgdG8gYmUgY2hhbmdlZCB0b28uIEJlbG93IGFuIGV4Y2VycHQgb2YgdGhlIGFjbCB0cmVl IHN0cnVjdHVyZToNCg0KICAgICArLS1ydyBhY2Nlc3MtbGlzdHMNCiAgICAgICAgKy0tcncgYWNs KiBbbmFtZV0NCiAgICAgICAgfCAgKy0tcncgbmFtZSAgICBzdHJpbmcNCiAgICAgICAgfCAgKy0t cncgdHlwZT8gICBhY2wtdHlwZQ0KDQoNCiogVGhpcyBzZW50ZW5jZSBzaG91bGQgYmUgY2FyZWZ1 bGx5IHVwZGF0ZWQgYXMgd2VsbDog4oCcV2l0aCB0aGUgZXhjZXB0aW9ucyBvZiAibmFtZSIsICJh Y2wtdHlwZSIsICJydWxlLW5hbWUiLCBhbmQgVENQIGFuZOKAnS4NCg0KKiBJIGd1ZXNzIHRoZSBl eGFtcGxlcyBzaG91bGQgYmUgY2hlY2tlZCB0byBhbGlnbiB3aXRoIHRoZSBuZXcgQUNMIHN0cnVj dHVyZS4gRm9yIGV4YW1wbGUsDQoNCiAtIOKAnGlwdjYtYWNs4oCdIGVudHJpZXMgc2hvdWxkIGJl IHVwZGF0ZWQgdG8g4oCcaXB2NuKAnS4NCg0KV2hpY2ggaXMgdGhlIHRleHQgSSBhZGp1c3RlZCA7 LSkNCltNZWRdIFllcy4gSSB3YXMgcmVmZXJyaW5nIHRvIHRoZSBleGFtcGxlcy4NCg0KDQogLSBh ZGQg4oCcbDPigJ0gZW50cnkgYmVmb3JlIOKAnGlwdjTigJ0gYW5kIOKAnGlwdjbigJ0uDQoNCkkg dGhpbmsgdGhpcyBpcyBkb25lIGluIHRoZSBub3JtYXRpdmUgdGV4dCBidXQgeW91J3JlIHJpZ2h0 LSBpdCBuZWVkcyB0byBiZSBjb3JyZWN0ZWQgaW4gdGhlIGV4YW1wbGVzLg0KDQoNCg0KKiBJdCB3 b3VsZCB1c2VmdWwgdG8gYWRkIGEganVzdGlmaWNhdGlvbiB3aHkgaXQgaXMgbm90IHJlY29tbWVu ZGVkIHRvIHN1cHBvcnQgJ3JlamVjdCcgYWN0aW9uLg0KDQpPaywgSSdsbCBhZGQgc29tZSB0ZXh0 Lg0KDQpbTWVkXSBUaGFuayB5b3UuIEJUVywgd291bGRu4oCZdCB5b3UgbmVlZCBhIHJhdGUtbGlt aXQgYWN0aW9uIHRvIOKAnHByb3RlY3TigJ0gYWdhaW5zdCBleGhhdXN0aW5nIFRoaW5nIHJlc291 cmNlcz8NCg0KSWYgc28sIGZlZWwgZnJlZSB0byBncmFiIGZyb20gdGhlIGZvbGxvd2luZzoNCg0K DQo9PQ0KDQogICBhdWdtZW50ICIvaWV0Zi1hY2w6YWNjZXNzLWxpc3RzL2lldGYtYWNsOmFjbC9p ZXRmLWFjbDphY2VzIiArDQogICAgICAgICAgICIvaWV0Zi1hY2w6YWNlL2lldGYtYWNsOmFjdGlv bnMiIHsNCiAgICAgZGVzY3JpcHRpb24NCiAgICAgICAiQXVnbWVudHMgQUNMIG1vZHVsZSB3aXRo IGEgcmF0ZS1saW1pdCBhY3Rpb24uIjsNCiAgICAgbGVhZiByYXRlLWxpbWl0IHsNCg0KICAgICAg IHdoZW4gImRlcml2ZWQtZnJvbS1vci1zZWxmKC9pZXRmLWFjbDphY2Nlc3MtbGlzdHMvaWV0Zi1h Y2w6YWNsL2lldGYtYWNsOmFjZXMvIiArDQogICAgICAgICAgICAiaWV0Zi1hY2w6YWNlL2lldGYt YWNsOmFjdGlvbnMvaWV0Zi1hY2w6Zm9yd2FyZGluZywgJ2lldGYtYWNsOmFjY2VwdCcpIjsNCiAg ICAgICB0eXBlIGRlY2ltYWw2NCB7DQogICAgICAgICBmcmFjdGlvbi1kaWdpdHMgMjsNCiAgICAg ICB9DQogICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAicmF0ZS1saW1pdCB0cmFmZmljLiBUaGlz IGFjdGlvbiBpcyB2YWxpZCBvbmx5IHdoZW4gYWNjZXB0IGFjdGlvbiBpcyB1c2VkLiI7DQogICAg ICB9DQogICB9DQo9PQ0KDQoNCiogVW5sZXNzIEnigJltIG1pc3Rha2VuLCB0aGUgbXVkIHVzZSBj YXNlIGRvZXMgbm90IHJlcXVpcmUgdGhlIHN1cHBvcnQgb2YgaW50ZXJmYWNlcyBhcyBhbiBhdHRh Y2htZW50IHBvaW50LiBJdCBtYXkgYmUgdXNlZnVsIHRvIGFkZCBzb21ldGhpbmcgYW1vbmcgdGhv c2UgbGluZXM6DQoNCiAgIEdpdmVuIHRoYXQgTVVEIGRvZXMgbm90IGRlYWwgd2l0aCBpbnRlcmZh Y2VzLCB0aGUNCiAgIHN1cHBvcnQgb2YgdGhlICJpZXRmLWludGVyZmFjZXMiIG1vZHVsZSBbUkZD NzIyMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIyMz5dIGlzIG5vdA0KICAgcmVx dWlyZWQuIFNwZWNpZmljYWxseSwgdGhlIHN1cHBvcnQgb2YgaW50ZXJmYWNlLXJlbGF0ZWQNCiAg IGZlYXR1cmVzIGFuZCBicmFuY2hlcyAoZS5nLiwgaW50ZXJmYWNlLWF0dGFjaG1lbnQgYW5kIGlu dGVyZmFjZS1zdGF0cykNCiAgIG9mIHRoZSBBQ0wgWUFORyBtb2R1bGUgaXMgbm90IHJlcXVpcmVk Lg0KDQpvay4NCg0KDQpJbiBhZGRpdGlvbiwgSSBoYXZlIHJlY2VpdmVkIHRoZSBmb2xsb3dpbmcg cmVxdWVzdHMgZm9yIGRhdGEgZWxlbWVudHMgdG8gYmUgYWRkZWQgdG8gdGhlIGNvcmUgbW9kZWw6 DQoNCiAgKiAgIE1hbnVmYWN0dXJlci1OYW1lDQogICogICBEZXZpY2UtVHlwZQ0KICAqICAgTW9k ZWwtTnVtYmVyDQogICogICBTb2Z0d2FyZS12ZXJzaW9uDQoNClVubGVzcyBJIGhlYXIgb2JqZWN0 aW9ucywgSSBhbSBkaXNwb3NlZCB0byBhZGQgdGhlc2UgYXMgbm9uLW1hbmRhdG9yeSBsZWFmLW5v ZGVzIGFzIHN0cmluZ3MgdW5kZXJuZWF0aCB0aGUgdG9wLWxldmVsIE1VRCBvYmplY3QuDQoNCkVs aW90DQoNCg0KDQoNCkNoZWVycywNCg0KTWVkDQoNCkRlIDogT1BTQVdHIFttYWlsdG86b3BzYXdn LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgRWxpb3QgTGVhcg0KRW52b3nDqSA6IG1l cmNyZWRpIDI0IGphbnZpZXIgMjAxOCAwOTozNA0KQ2MgOiBNYWhlc2ggSmV0aGFuYW5kYW5pOyBv cHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47IE1hcmsgTm90dGluZ2hhbQ0K T2JqZXQgOiBSZTogW09QU0FXR10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1vcHNhd2ctbXVkLTE0 LnR4dA0KDQoNClRoaXMgdXBkYXRlIHByaW1hcmlseSBmb2N1c2VzIG9uIHR3byBlbGVtZW50cyB0 aGF0IHdlcmUgYWdyZWVkIGR1cmluZyBXR0xDOg0KDQogICogICBUaGUgdXBkYXRlIHRvIHRoZSBB Q0wgbW9kZWwuICBUaGF0IHVwZGF0ZSBoYXMgdGFrZW4gbG9uZ2VyIHRoYW4gSSB3b3VsZCBoYXZl IGxpa2VkLCBidXQgaXQgaXMgbm93IGF0IGxlYXN0IGNsb3NlIHRvIGZpbmlzaGVkLiAgTm90ZTog dGhlIE1VRCBtb2RlbCBkb2VzIG5vdCB5ZXQgbWF0Y2ggdGhlIHB1Ymxpc2hlZCBBQ0wgbW9kZWws IGJ1dCBpdCBkb2VzIG1hdGNoIHRoZSBhZ3JlZWQgY2hhbmdlcyB0aGF0IHdpbGwgYmUgcHJvZHVj ZWQgaW4gdGhlIG5leHQgQUNMIGRyYWZ0Lg0KICAqICAgTWFyayBOb3R0aW5naGFtIGhhZCBjb21t ZW50ZWQgdGhhdCBpdCBpcyBub3QgYXBwcm9wcmlhdGUgdG8gaGF2ZSB2ZXJzaW9uaW5nIGluZm9y bWF0aW9uIGluIHRoZSBNVUQtVVJMIGl0c2VsZiwgYnV0IHRoYXQgaXQgc2hvdWxkIGJlIGluIHRo ZSBtb2RlbC4gIFdlIGFncmVlZCBvbiB0aGlzIGNoYW5nZSwgYXMgd2VsbCBhcyBzb21lIHdvcmRp bmcgYXJvdW5kIGhvdyBIVFRQIGlzIGhhbmRsZWQuDQoNCkJhc2VkIG9uIHRoZXNlIGNoYW5nZXMs IEkgd291bGQgbGlrZSB0byBtb3ZlIHRoaXMgZG9jdW1lbnQgZm9yd2FyZCB0byBJRVRGIExDLg0K DQpFbGlvdA0KDQpPbiAyNC4wMS4xOCAwOToyOSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCg0KQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRp cmVjdG9yaWVzLg0KDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBPcGVyYXRpb25z IGFuZCBNYW5hZ2VtZW50IEFyZWEgV29ya2luZyBHcm91cCBXRyBvZiB0aGUgSUVURi4NCg0KDQoN CiAgICAgICAgVGl0bGUgICAgICAgICAgIDogTWFudWZhY3R1cmVyIFVzYWdlIERlc2NyaXB0aW9u IFNwZWNpZmljYXRpb24NCg0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBFbGlvdCBMZWFyDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgUmFscGggRHJvbXMNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBEYW4gUm9tYXNjYW51DQoNCiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LW9wc2F3Zy1tdWQtMTQudHh0DQoNCiBQYWdlcyAgICAgICAgICAgOiA1Ng0KDQogRGF0ZSAgICAg ICAgICAgIDogMjAxOC0wMS0yNA0KDQoNCg0KQWJzdHJhY3Q6DQoNCiAgIFRoaXMgbWVtbyBzcGVj aWZpZXMgYSBjb21wb25lbnQtYmFzZWQgYXJjaGl0ZWN0dXJlIGZvciBtYW51ZmFjdHVyZXINCg0K ICAgdXNhZ2UgZGVzY3JpcHRpb25zIChNVUQpLiAgVGhlIGdvYWwgb2YgTVVEIGlzIHRvIHByb3Zp ZGUgYSBtZWFucyBmb3INCg0KICAgVGhpbmdzIHRvIHNpZ25hbCB0byB0aGUgbmV0d29yayB3aGF0 IHNvcnQgb2YgYWNjZXNzIGFuZCBuZXR3b3JrDQoNCiAgIGZ1bmN0aW9uYWxpdHkgdGhleSByZXF1 aXJlIHRvIHByb3Blcmx5IGZ1bmN0aW9uLiAgVGhlIGluaXRpYWwgZm9jdXMNCg0KICAgaXMgb24g YWNjZXNzIGNvbnRyb2wuICBMYXRlciB3b3JrIGNhbiBkZWx2ZSBpbnRvIG90aGVyIGFzcGVjdHMu DQoNCg0KDQogICBUaGlzIG1lbW8gc3BlY2lmaWVzIHR3byBZQU5HIG1vZHVsZXMsIElQdjQgYW5k IElQdjYgREhDUCBvcHRpb25zLCBhbg0KDQogICBMTERQIFRMViwgYSBVUkwgc3VmZml4IHNwZWNp ZmljYXRpb24sIGFuIFguNTA5IGNlcnRpZmljYXRlIGV4dGVuc2lvbg0KDQogICBhbmQgYSBtZWFu cyB0byBzaWduIGFuZCB2ZXJpZnkgdGhlIGRlc2NyaXB0aW9ucy4NCg0KDQoNCg0KDQpUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctbXVkLw0KDQoNCg0KVGhl cmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KDQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctbXVkLTE0DQoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctbXVkLTE0DQoNCg0K DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2F3Zy1tdWQtMTQN Cg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQoNCmZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPUFNBV0cgbWFpbGluZyBsaXN0DQoN Ck9QU0FXR0BpZXRmLm9yZzxtYWlsdG86T1BTQVdHQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KDQoNCg0KDQo= --_000_787AE7BB302AE849A7480A190F8B93300A0C612AOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ cGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ291cmllciBOZXcgXDtjb2xvclw6YmxhY2siOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAg MCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXcgXDtjb2xvclw6 d2luZG93dGV4dCI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNv bG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0Fj ZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBk ZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOp Zm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6 bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uaW5zZXJ0DQoJe21zby1zdHlsZS1u YW1lOmluc2VydDt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRl eHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj azsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcw Ljg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo1MTAyOTU3NzQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDY2MjYyNjQ4O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDoxMzYyOTc0MzMyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTI3MzYxOTg0O30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy NTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1s aXN0LWlkOjE4NTAzNzA4MTc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDUzNjk1MzQ4O30N CkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDgu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPlJlLSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5UaGFuayB5b3UgRWxpb3QgZm9yIHRoZSBwcm9tcHQgZm9sbG93LXVwLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBzZWUgc29tZSBj b21tZW50cyBpbmxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkRl Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+IEVsaW90IExlYXIgW21haWx0bzpsZWFyQGNpc2NvLmNvbV0NCjxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAyNCBqYW52aWVyIDIwMTggMTE6MDU8YnI+DQo8Yj7DgCZu YnNwOzo8L2I+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+ IE1haGVzaCBKZXRoYW5hbmRhbmk7IG9wc2F3Z0BpZXRmLm9yZzsgTWFyayBOb3R0aW5naGFtOyBT YXN3YXQgUHJhaGFyYWogKHNhc3ByYWhhKTxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtP UFNBV0ddIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb3BzYXdnLW11ZC0xNC50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cD5IaSBNZWQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiAyNC4wMS4xOCAxMDo1MiwgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4gd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNr JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IaSBFbGlvdCwNCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+U29tZSBxdWljayBjb21tZW50czo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiPiogUGxlYXNlIG5vdGUgdGhhdCA8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mcXVvdDthY2wtdHlwZSZxdW90OyBzaG91 bGQgYmUg4oCcdHlwZeKAnSBhbmQgJnF1b3Q7cnVsZS1uYW1lJnF1b3Q7IHNob3VsZCBiZSBjaGFu Z2VkIHRvIOKAnG5hbWXigJ0uIFRoaXMgY2FuIGJlIGVhc2lseSBmaXhlZCBpbiB0aGUgZXhhbXBs ZXMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KTXkgdW5kZXJzdGFuZGluZyBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLWFj bC1tb2RlbC0xNCBpcyB0aGF0IGFjbC10eXBlIHJlbWFpbnMgYWNsLXR5cGUuJm5ic3A7IGFjbC1u YW1lIGJlY2FtZSBuYW1lLiZuYnNwOyBCdXQgeW91J3JlIHJpZ2h0LSBydWxlLW5hbWUgYmVjYW1l IG5hbWUgYXMgd2VsbC4mbmJzcDsgSSB3aWxsIGFkanVzdCB0aGUgdGV4dCBhY2NvcmRpbmdseS48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gSSBn dWVzcyB5b3UgbWVhbnQgLTE1LiBJIGNvbmZpcm0gdGhhdCBhY2wtdHlwZSBpcyB0byBiZSBjaGFu Z2VkIHRvby4gQmVsb3cgYW4gZXhjZXJwdCBvZiB0aGUgYWNsIHRyZWUgc3RydWN0dXJlOg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBhY2Nlc3MtbGlzdHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICYjNDM7LS1ydyBhY2wqIFtuYW1lXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgbmFt ZSZuYnNwOyZuYnNwOyZuYnNwOyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3 IHR5cGU/Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+YWNs LXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiogVGhpcyBzZW50ZW5jZSBzaG91bGQg YmUgY2FyZWZ1bGx5IHVwZGF0ZWQgYXMgd2VsbDog4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij5XaXRoIHRoZSBleGNlcHRpb25zIG9mIDxzcGFuIGNsYXNzPSJpbnNlcnQiPiZxdW90O25hbWUm cXVvdDssPC9zcGFuPiAmcXVvdDthY2wtdHlwZSZxdW90OywgJnF1b3Q7cnVsZS1uYW1lJnF1b3Q7 LCBhbmQgVENQIGFuZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPuKAnS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiog SSBndWVzcyB0aGUgZXhhbXBsZXMgc2hvdWxkIGJlIGNoZWNrZWQgdG8gYWxpZ24gd2l0aCB0aGUg bmV3IEFDTCBzdHJ1Y3R1cmUuIEZvciBleGFtcGxlLCA8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDst IOKAnGlwdjYtYWNs4oCdIGVudHJpZXMgc2hvdWxkIGJlIHVwZGF0ZWQgdG8g4oCcaXB2NuKAnS48 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCldoaWNo IGlzIHRoZSB0ZXh0IEkgYWRqdXN0ZWQgOy0pPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFllcy4gSSB3YXMgcmVmZXJyaW5nIHRvIHRoZSBleGFt cGxlcy4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPiZuYnNwOy0gYWRkIOKAnGwz4oCdIGVudHJ5IGJlZm9yZSDigJxpcHY04oCdIGFuZCDigJxp cHY24oCdLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KSSB0aGluayB0 aGlzIGlzIGRvbmUgaW4gdGhlIG5vcm1hdGl2ZSB0ZXh0IGJ1dCB5b3UncmUgcmlnaHQtIGl0IG5l ZWRzIHRvIGJlIGNvcnJlY3RlPC9zcGFuPmQgaW4gdGhlIGV4YW1wbGVzLjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPiogSXQgd291bGQgdXNlZnVsIHRvIGFkZCBhIGp1c3RpZmljYXRpb24gd2h5 IGl0IGlzIG5vdCByZWNvbW1lbmRlZCB0byBzdXBwb3J0ICdyZWplY3QnIGFjdGlvbi48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9rLCBJJ2xsIGFk ZCBzb21lIHRleHQuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPltNZWRdIFRoYW5rIHlvdS4gQlRXLCB3b3VsZG7igJl0IHlvdSBuZWVk IGEgcmF0ZS1saW1pdCBhY3Rpb24gdG8g4oCccHJvdGVjdOKAnSBhZ2FpbnN0IGV4aGF1c3Rpbmcg VGhpbmcgcmVzb3VyY2VzPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPklmIHNvLCBmZWVsIGZyZWUgdG8gZ3JhYiBmcm9tIHRoZSBmb2xsb3dpbmc6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPj09PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+Jm5ic3A7Jm5ic3A7IGF1Z21lbnQgJnF1b3Q7L2lldGYtYWNsOmFjY2Vzcy1saXN0cy9pZXRm LWFjbDphY2wvaWV0Zi1hY2w6YWNlcyZxdW90OyAmIzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmcXVvdDsvaWV0Zi1hY2w6YWNlL2lldGYtYWNsOmFjdGlvbnMmcXVvdDsgezxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3Jp cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O0F1Z21lbnRzIEFDTCBtb2R1bGUgd2l0aCBhIHJhdGUtbGltaXQg YWN0aW9uLiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGxlYWYgcmF0ZS1saW1pdCB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGVuICZxdW90O2Rlcml2ZWQtZnJvbS1vci1zZWxmKC9p ZXRmLWFjbDphY2Nlc3MtbGlzdHMvaWV0Zi1hY2w6YWNsL2lldGYtYWNsOmFjZXMvJnF1b3Q7ICYj NDM7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lldGYtYWNs OmFjZS9pZXRmLWFjbDphY3Rpb25zL2lldGYtYWNsOmZvcndhcmRpbmcsICdpZXRmLWFjbDphY2Nl cHQnKSZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgZGVjaW1hbDY0IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZy YWN0aW9uLWRpZ2l0cyAyOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2lu ZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90 O3JhdGUtbGltaXQgdHJhZmZpYy4gVGhpcyBhY3Rpb24gaXMgdmFsaWQgb25seSB3aGVuIGFjY2Vw dCBhY3Rpb24gaXMgdXNlZC4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZu YnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj49PTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiogVW5sZXNzIEnigJltIG1pc3Rha2Vu LCB0aGUgbXVkIHVzZSBjYXNlIGRvZXMgbm90IHJlcXVpcmUgdGhlIHN1cHBvcnQgb2YgaW50ZXJm YWNlcyBhcyBhbiBhdHRhY2htZW50IHBvaW50LiBJdCBtYXkgYmUgdXNlZnVsIHRvIGFkZCBzb21l dGhpbmcgYW1vbmcgdGhvc2UgbGluZXM6ICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyBHaXZlbiB0aGF0IE1VRCBkb2VzIG5vdCBk ZWFsIHdpdGggaW50ZXJmYWNlcywgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsgc3VwcG9ydCBvZiB0aGUgJnF1b3Q7aWV0Zi1pbnRl cmZhY2VzJnF1b3Q7IG1vZHVsZSBbPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzIyMyIgdGl0bGU9IiZxdW90O0ENCiAgICAgICAgICAgICAgWUFORyBEYXRhIE1vZGVsIGZvciBJ bnRlcmZhY2UgTWFuYWdlbWVudCZxdW90OyI+PHNwYW4gbGFuZz0iRU4tVVMiPlJGQzcyMjM8L3Nw YW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPl0NCiBpcyBub3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyByZXF1aXJlZC4gU3BlY2lmaWNhbGx5LCB0aGUg c3VwcG9ydCBvZiBpbnRlcmZhY2UtcmVsYXRlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7IGZlYXR1cmVzIGFuZCBicmFuY2hlcyAoZS5n LiwgaW50ZXJmYWNlLWF0dGFjaG1lbnQgYW5kIGludGVyZmFjZS1zdGF0cykNCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6 d2luZG93dGV4dCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7b2Yg dGhlIEFDTCBZQU5HIG1vZHVsZSBpcyBub3QgcmVxdWlyZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpvay48YnI+DQo8YnI+DQo8YnI+DQpJbiBhZGRpdGlvbiwgSSBoYXZlIHJlY2VpdmVkIHRoZSBm b2xsb3dpbmcgcmVxdWVzdHMgZm9yIGRhdGEgZWxlbWVudHMgdG8gYmUgYWRkZWQgdG8gdGhlIGNv cmUgbW9kZWw6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCk1hbnVmYWN0dXJlci1OYW1lPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzEiPg0KRGV2aWNlLVR5cGU8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpNb2RlbC1OdW1iZXI8bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpTb2Z0d2FyZS12 ZXJzaW9uPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpV bmxlc3MgSSBoZWFyIG9iamVjdGlvbnMsIEkgYW0gZGlzcG9zZWQgdG8gYWRkIHRoZXNlIGFzIG5v bi1tYW5kYXRvcnkgbGVhZi1ub2RlcyBhcyBzdHJpbmdzIHVuZGVybmVhdGggdGhlIHRvcC1sZXZl bCBNVUQgb2JqZWN0Ljxicj4NCjxicj4NCkVsaW90PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Q2hlZXJzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPk1lZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBP UFNBV0cgWzxhIGhyZWY9Im1haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm9w c2F3Zy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEVsaW90IExl YXI8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMjQgamFudmllciAyMDE4IDA5 OjM0PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBNYWhlc2ggSmV0aGFuYW5kYW5pOyA8YSBocmVmPSJt YWlsdG86b3BzYXdnQGlldGYub3JnIj5vcHNhd2dAaWV0Zi5vcmc8L2E+OyBNYXJrIE5vdHRpbmdo YW08YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbT1BTQVdHXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLW9wc2F3Zy1tdWQtMTQudHh0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+VGhp cyB1cGRhdGUgcHJpbWFyaWx5IGZvY3VzZXMgb24gdHdvIGVsZW1lbnRzIHRoYXQgd2VyZSBhZ3Jl ZWQgZHVyaW5nIFdHTEM6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NClRoZSB1cGRhdGUgdG8g dGhlIEFDTCBtb2RlbC4mbmJzcDsgVGhhdCB1cGRhdGUgaGFzIHRha2VuIGxvbmdlciB0aGFuIEkg d291bGQgaGF2ZSBsaWtlZCwgYnV0IGl0IGlzIG5vdyBhdCBsZWFzdCBjbG9zZSB0byBmaW5pc2hl ZC4mbmJzcDsgTm90ZTogdGhlIE1VRCBtb2RlbCBkb2VzIG5vdCB5ZXQgbWF0Y2ggdGhlIHB1Ymxp c2hlZCBBQ0wgbW9kZWwsIGJ1dCBpdCBkb2VzIG1hdGNoIHRoZSBhZ3JlZWQgY2hhbmdlcyB0aGF0 IHdpbGwgYmUgcHJvZHVjZWQgaW4gdGhlDQogbmV4dCBBQ0wgZHJhZnQuPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPg0KTWFyayBO b3R0aW5naGFtIGhhZCBjb21tZW50ZWQgdGhhdCBpdCBpcyBub3QgYXBwcm9wcmlhdGUgdG8gaGF2 ZSB2ZXJzaW9uaW5nIGluZm9ybWF0aW9uIGluIHRoZSBNVUQtVVJMIGl0c2VsZiwgYnV0IHRoYXQg aXQgc2hvdWxkIGJlIGluIHRoZSBtb2RlbC4mbmJzcDsgV2UgYWdyZWVkIG9uIHRoaXMgY2hhbmdl LCBhcyB3ZWxsIGFzIHNvbWUgd29yZGluZyBhcm91bmQgaG93IEhUVFAgaXMgaGFuZGxlZC48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwPkJhc2VkIG9uIHRoZXNlIGNoYW5nZXMsIEkgd291bGQgbGlr ZSB0byBtb3ZlIHRoaXMgZG9jdW1lbnQgZm9yd2FyZCB0byBJRVRGIExDLjxvOnA+PC9vOnA+PC9w Pg0KPHA+RWxpb3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI0LjAxLjE4IDA5 OjI5LCA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj4NCmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZzwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPG86 cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgT3Bl cmF0aW9ucyBhbmQgTWFuYWdlbWVudCBBcmVhIFdvcmtpbmcgR3JvdXAgV0cgb2YgdGhlIElFVEYu PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOzogTWFudWZh Y3R1cmVyIFVzYWdlIERlc2NyaXB0aW9uIFNwZWNpZmljYXRpb248bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9ycyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IEVsaW90IExl YXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUmFscGggRHJvbXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRGFuIFJvbWFzY2FudTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiBGaWxlbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IGRy YWZ0LWlldGYtb3BzYXdnLW11ZC0xNC50eHQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gUGFnZXMm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgOiA1NjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBEYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjAxOC0wMS0y NDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFi c3RyYWN0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIG1lbW8gc3Bl Y2lmaWVzIGEgY29tcG9uZW50LWJhc2VkIGFyY2hpdGVjdHVyZSBmb3IgbWFudWZhY3R1cmVyPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHVzYWdlIGRlc2NyaXB0aW9ucyAoTVVE KS4mbmJzcDsgVGhlIGdvYWwgb2YgTVVEIGlzIHRvIHByb3ZpZGUgYSBtZWFucyBmb3I8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhpbmdzIHRvIHNpZ25hbCB0byB0aGUgbmV0 d29yayB3aGF0IHNvcnQgb2YgYWNjZXNzIGFuZCBuZXR3b3JrPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IGZ1bmN0aW9uYWxpdHkgdGhleSByZXF1aXJlIHRvIHByb3Blcmx5IGZ1 bmN0aW9uLiZuYnNwOyBUaGUgaW5pdGlhbCBmb2N1czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBpcyBvbiBhY2Nlc3MgY29udHJvbC4mbmJzcDsgTGF0ZXIgd29yayBjYW4gZGVs dmUgaW50byBvdGhlciBhc3BlY3RzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIG1lbW8gc3BlY2lmaWVzIHR3byBZ QU5HIG1vZHVsZXMsIElQdjQgYW5kIElQdjYgREhDUCBvcHRpb25zLCBhbjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBMTERQIFRMViwgYSBVUkwgc3VmZml4IHNwZWNpZmljYXRp b24sIGFuIFguNTA5IGNlcnRpZmljYXRlIGV4dGVuc2lvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBhbmQgYSBtZWFucyB0byBzaWduIGFuZCB2ZXJpZnkgdGhlIGRlc2NyaXB0 aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0 dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1tdWQv Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1tdWQv PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PlRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1vcHNhd2ctbXVkLTE0Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vcHNhd2ctbXVkLTE0PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctbXVkLTE0 Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdn LW11ZC0xNDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzYXdnLW11ZC0xNCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzYXdnLW11ZC0xNDwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+dW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8iPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3By ZT4NCjxwcmU+T1BTQVdHIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmciPk9QU0FXR0BpZXRmLm9yZzwvYT48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2F3ZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c8 L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93300A0C612AOPEXCLILMA3corp_-- From nobody Wed Jan 24 04:16:06 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9269C120227 for ; Wed, 24 Jan 2018 04:16:04 -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, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, 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 oRXtDKTI773j for ; Wed, 24 Jan 2018 04:16:02 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CD81200F1 for ; Wed, 24 Jan 2018 04:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20271; q=dns/txt; s=iport; t=1516796162; x=1518005762; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=cIXyd3bThnhqkSDwYGvTTOyGma+xZYT4GZYvrR1Cr38=; b=Jd4AH4Nu5XoNqRu/h4Pp+QDMXPRoFl2ECo6lu/vQdvZO+k/Kis+36pQ9 0aOykzYwPKEau0kxneAi212kOIY6CRmE+36Tm04qkGkmCk7ajwP/Dwy4b rwcnSBzbohoRltsuyw1D2R/tScMEj77RiCbzx3Rf5uKF99pV5ibzo88tS M=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.46,407,1511827200"; d="asc'?scan'208,217";a="1624089" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 12:16:00 +0000 Received: from [10.61.241.55] ([10.61.241.55]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0OCFxNK022774; Wed, 24 Jan 2018 12:15:59 GMT To: mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham , "Saswat Praharaj (saspraha)" References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0C612A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Eliot Lear Message-ID: Date: Wed, 24 Jan 2018 13:15:58 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0C612A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kbHJ2MEaQd8O8eVS6WRLTGxfmXA2CPS4h" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 12:16:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kbHJ2MEaQd8O8eVS6WRLTGxfmXA2CPS4h Content-Type: multipart/mixed; boundary="qXGRswrxwIUoaIXqn0SHUWx1kW0f1JcBA"; protected-headers="v1" From: Eliot Lear To: mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham , "Saswat Praharaj (saspraha)" Message-ID: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0C612A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0C612A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> --qXGRswrxwIUoaIXqn0SHUWx1kW0f1JcBA Content-Type: multipart/alternative; boundary="------------92A72AB52EEC13768B41EEA2" Content-Language: en-US This is a multi-part message in MIME format. --------------92A72AB52EEC13768B41EEA2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Med, Please see below: On 24.01.18 12:54, mohamed.boucadair@orange.com wrote: > > My understanding from draft-ietf-netmod-acl-model-14 is that acl-type > remains acl-type.=C2=A0 acl-name became name.=C2=A0 But you're right- r= ule-name > became name as well.=C2=A0 I will adjust the text accordingly. > > [Med] I guess you meant -15. I confirm that acl-type is to be changed > too. Below an excerpt of the acl tree structure: > > =C2=A0 > > =C2=A0=C2=A0=C2=A0=C2=A0 +--rw access-lists > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw acl* [name] > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw name=C2=A0=C2=A0= =C2=A0 string > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw type?=C2=A0=C2= =A0 acl-type > > =C2=A0 > > * This sentence should be carefully updated as well: =E2=80=9CWith the > exceptions of "name", "acl-type", "rule-name", and TCP and=E2=80=9D. > * I guess the examples should be checked to align with the new ACL > structure. For example, > =C2=A0- =E2=80=9Cipv6-acl=E2=80=9D entries should be updated to =E2=80=9C= ipv6=E2=80=9D. You're right.=C2=A0 I stand corrected.=C2=A0 And I spotted the error in t= he example.=C2=A0 Will correct. > > > Which is the text I adjusted ;-) > > [Med] Yes. I was referring to the examples. > > =C2=A0- add =E2=80=9Cl3=E2=80=9D entry before =E2=80=9Cipv4=E2=80=9D an= d =E2=80=9Cipv6=E2=80=9D. > > > I think this is done in the normative text but you're right- it needs > to be corrected in the examples. > > > * It would useful to add a justification why it is not recommended to > support 'reject' action. > > > Ok, I'll add some text. > > [Med] Thank you. BTW, wouldn=E2=80=99t you need a rate-limit action to > =E2=80=9Cprotect=E2=80=9D against exhausting Thing resources? > I don't think that's appropriate at this point.=C2=A0 For one thing, it g= oes well beyond what many implementations can actually do.=C2=A0 For another,= it may be asking a bit much of the manufacturers to predict this sort of behavior, and it will be easy to get wrong.=C2=A0 I would suggest this be= handled later as we get some additional operational experience. Eliot --------------92A72AB52EEC13768B41EEA2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Med,

Please see below:


On 24.01.18 12:54, mohamed.boucadair@orange.com wrote:


My understanding from draft-ietf-netmod-acl-model-14 is that acl-type remains acl-type.=C2=A0 acl-name became name.=C2=A0 = But you're right- rule-name became name as well.=C2=A0 I will adj= ust the text accordingly.<= /span>

[Med] I guess you meant -15. I confirm that acl-type is to be changed too. Below an excerpt of the acl tree structure:

=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0 +--rw access-lists

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--rw acl* [name]

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw name=C2=A0=C2=A0=C2=A0 string

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw type?=C2=A0=C2=A0 acl-type

=C2=A0

* This sen=
tence should be carefully updated as well: =E2=80=9CWith the exceptions of "name", "acl-=
type", "rule-name", and TCP and=E2=80=9D.
          
* I guess =
the examples should be checked to align with the new ACL structure. For e=
xample, 

          
=C2=A0- =E2=
=80=9Cipv6-acl=E2=80=9D entries should be updated to =E2=80=9Cipv6=E2=80=9D=
=2E

You're right.=C2=A0 I stand corrected.=C2=A0 And I spotted the error = in the example.=C2=A0 Will correct.


Which is the text I adjusted ;-)<= o:p>

[Med] Yes. I was referring to the examples. 

=C2=A0- ad=
d =E2=80=9Cl3=E2=80=9D entry before =E2=80=9Cipv4=E2=80=9D and =E2=80=9Ci=
pv6=E2=80=9D.


I think this is done in the normative text but you're right- it needs to be corrected in the examples.
= 

* It would=
 useful to add a justification why it is not recommended to support 'reje=
ct' action.


Ok, I'll add some text.

[Med] Thank you. BTW,= wouldn=E2=80=99t you need a rate-limit action to =E2=80=9Cp= rotect=E2=80=9D against exhausting Thing resources?


I don't think that's appropriate at this point.=C2=A0 For one thing, = it goes well beyond what many implementations can actually do.=C2=A0 For= another, it may be asking a bit much of the manufacturers to predict this sort of behavior, and it will be easy to get wrong.=C2=A0 I woul= d suggest this be handled later as we get some additional operational experience.

Eliot
--------------92A72AB52EEC13768B41EEA2-- --qXGRswrxwIUoaIXqn0SHUWx1kW0f1JcBA-- --kbHJ2MEaQd8O8eVS6WRLTGxfmXA2CPS4h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpoeP8ACgkQh7ZrRtnS ejO9Tgf/XkeTtG3nGOY9Sqw/EOwuTq0ErukjfGkiiPWqHn1cYADa+UDWWpIhwWoX qpPNqiui6bDvo6u2Fk1ztXCs7ISAgMrAQtXt1XMaQ9P+RvQKrwUSmdnJc95jAvSN zjylchkuBlAhrc0XG9H1jGyVxwEiLmT+HOjdZbPaH8JtcKhswcy9qRXeFZ+4KN+/ yCpk9tunGc9Tpt3dVvy1vYYv7pEfeVW9rCduwIHkuWFlk+DyEdn+4VF7T2OctLTa TJbTekSd1Pu3k9di+X7FVDC72ok3lhgCr9YNJtFjeySdFKBXYdM8WWGc22QuMLm6 LhcBw5hSrO3pTZ+7IV3RTV1syU2ENw== =9Eqs -----END PGP SIGNATURE----- --kbHJ2MEaQd8O8eVS6WRLTGxfmXA2CPS4h-- From nobody Wed Jan 24 04:36:09 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88F1241FC for ; Wed, 24 Jan 2018 04:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 x00VpH8zqQlw for ; Wed, 24 Jan 2018 04:36:05 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802D7120726 for ; Wed, 24 Jan 2018 04:36:04 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 2478840BFC; Wed, 24 Jan 2018 13:36:03 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 021591C007E; Wed, 24 Jan 2018 13:36:03 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0382.000; Wed, 24 Jan 2018 13:36:02 +0100 From: To: Eliot Lear CC: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham , "Saswat Praharaj (saspraha)" Thread-Topic: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt Thread-Index: AQHTlO4ijwfw7fdn00+sxY/M7KbCAqOCvqXQ///8YYCAABDhAIAAE6cAgAAV2dA= Date: Wed, 24 Jan 2018 12:36:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C61BF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0C612A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0C61BFOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 12:36:08 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0C61BFOPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBlbm91Z2guIFRoYW5rIHlvdS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogRWxpb3QgTGVh ciBbbWFpbHRvOmxlYXJAY2lzY28uY29tXQ0KRW52b3nDqSA6IG1lcmNyZWRpIDI0IGphbnZpZXIg MjAxOCAxMzoxNg0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpDYyA6IE1haGVzaCBK ZXRoYW5hbmRhbmk7IG9wc2F3Z0BpZXRmLm9yZzsgTWFyayBOb3R0aW5naGFtOyBTYXN3YXQgUHJh aGFyYWogKHNhc3ByYWhhKQ0KT2JqZXQgOiBSZTogW09QU0FXR10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1vcHNhd2ctbXVkLTE0LnR4dA0KDQoNCkhpIE1lZCwNCg0KUGxlYXNlIHNlZSBiZWxvdzoN Cg0KT24gMjQuMDEuMTggMTI6NTQsIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRv Om1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KDQoNCg0KTXkgdW5kZXJzdGFu ZGluZyBmcm9tIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xNCBpcyB0aGF0IGFjbC10eXBl IHJlbWFpbnMgYWNsLXR5cGUuICBhY2wtbmFtZSBiZWNhbWUgbmFtZS4gIEJ1dCB5b3UncmUgcmln aHQtIHJ1bGUtbmFtZSBiZWNhbWUgbmFtZSBhcyB3ZWxsLiAgSSB3aWxsIGFkanVzdCB0aGUgdGV4 dCBhY2NvcmRpbmdseS4NCltNZWRdIEkgZ3Vlc3MgeW91IG1lYW50IC0xNS4gSSBjb25maXJtIHRo YXQgYWNsLXR5cGUgaXMgdG8gYmUgY2hhbmdlZCB0b28uIEJlbG93IGFuIGV4Y2VycHQgb2YgdGhl IGFjbCB0cmVlIHN0cnVjdHVyZToNCg0KICAgICArLS1ydyBhY2Nlc3MtbGlzdHMNCiAgICAgICAg Ky0tcncgYWNsKiBbbmFtZV0NCiAgICAgICAgfCAgKy0tcncgbmFtZSAgICBzdHJpbmcNCiAgICAg ICAgfCAgKy0tcncgdHlwZT8gICBhY2wtdHlwZQ0KDQoNCiogVGhpcyBzZW50ZW5jZSBzaG91bGQg YmUgY2FyZWZ1bGx5IHVwZGF0ZWQgYXMgd2VsbDog4oCcV2l0aCB0aGUgZXhjZXB0aW9ucyBvZiAi bmFtZSIsICJhY2wtdHlwZSIsICJydWxlLW5hbWUiLCBhbmQgVENQIGFuZOKAnS4NCg0KKiBJIGd1 ZXNzIHRoZSBleGFtcGxlcyBzaG91bGQgYmUgY2hlY2tlZCB0byBhbGlnbiB3aXRoIHRoZSBuZXcg QUNMIHN0cnVjdHVyZS4gRm9yIGV4YW1wbGUsDQoNCiAtIOKAnGlwdjYtYWNs4oCdIGVudHJpZXMg c2hvdWxkIGJlIHVwZGF0ZWQgdG8g4oCcaXB2NuKAnS4NCg0KWW91J3JlIHJpZ2h0LiAgSSBzdGFu ZCBjb3JyZWN0ZWQuICBBbmQgSSBzcG90dGVkIHRoZSBlcnJvciBpbiB0aGUgZXhhbXBsZS4gIFdp bGwgY29ycmVjdC4NCg0KDQpXaGljaCBpcyB0aGUgdGV4dCBJIGFkanVzdGVkIDstKQ0KW01lZF0g WWVzLiBJIHdhcyByZWZlcnJpbmcgdG8gdGhlIGV4YW1wbGVzLg0KDQoNCg0KIC0gYWRkIOKAnGwz 4oCdIGVudHJ5IGJlZm9yZSDigJxpcHY04oCdIGFuZCDigJxpcHY24oCdLg0KDQpJIHRoaW5rIHRo aXMgaXMgZG9uZSBpbiB0aGUgbm9ybWF0aXZlIHRleHQgYnV0IHlvdSdyZSByaWdodC0gaXQgbmVl ZHMgdG8gYmUgY29ycmVjdGVkIGluIHRoZSBleGFtcGxlcy4NCg0KDQoNCg0KKiBJdCB3b3VsZCB1 c2VmdWwgdG8gYWRkIGEganVzdGlmaWNhdGlvbiB3aHkgaXQgaXMgbm90IHJlY29tbWVuZGVkIHRv IHN1cHBvcnQgJ3JlamVjdCcgYWN0aW9uLg0KDQpPaywgSSdsbCBhZGQgc29tZSB0ZXh0Lg0KDQoN CltNZWRdIFRoYW5rIHlvdS4gQlRXLCB3b3VsZG7igJl0IHlvdSBuZWVkIGEgcmF0ZS1saW1pdCBh Y3Rpb24gdG8g4oCccHJvdGVjdOKAnSBhZ2FpbnN0IGV4aGF1c3RpbmcgVGhpbmcgcmVzb3VyY2Vz Pw0KDQpJIGRvbid0IHRoaW5rIHRoYXQncyBhcHByb3ByaWF0ZSBhdCB0aGlzIHBvaW50LiAgRm9y IG9uZSB0aGluZywgaXQgZ29lcyB3ZWxsIGJleW9uZCB3aGF0IG1hbnkgaW1wbGVtZW50YXRpb25z IGNhbiBhY3R1YWxseSBkby4gIEZvciBhbm90aGVyLCBpdCBtYXkgYmUgYXNraW5nIGEgYml0IG11 Y2ggb2YgdGhlIG1hbnVmYWN0dXJlcnMgdG8gcHJlZGljdCB0aGlzIHNvcnQgb2YgYmVoYXZpb3Is IGFuZCBpdCB3aWxsIGJlIGVhc3kgdG8gZ2V0IHdyb25nLiAgSSB3b3VsZCBzdWdnZXN0IHRoaXMg YmUgaGFuZGxlZCBsYXRlciBhcyB3ZSBnZXQgc29tZSBhZGRpdGlvbmFsIG9wZXJhdGlvbmFsIGV4 cGVyaWVuY2UuDQoNCkVsaW90DQo= --_000_787AE7BB302AE849A7480A190F8B93300A0C61BFOPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFw7Y29s b3JcOmJsYWNrIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFw7Y29sb3JcOndpbmRvd3RleHQiOw0KCXBhbm9z ZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRN TCBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLlBy Zm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBI VE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLlRleHRl ZGVidWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9u dC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5pbnNlcnQNCgl7bXNvLXN0eWxlLW5hbWU6aW5zZXJ0O30N CnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0K CWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6Ymxh Y2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPkZhaXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmVub3VnaDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+VGhhbms8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPnlvdS48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5N ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5E ZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRv d3RleHQiPiBFbGlvdCBMZWFyIFttYWlsdG86bGVhckBjaXNjby5jb21dDQo8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMjQgamFudmllciAyMDE4IDEzOjE2PGJyPg0KPGI+w4Am bmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9i PiBNYWhlc2ggSmV0aGFuYW5kYW5pOyBvcHNhd2dAaWV0Zi5vcmc7IE1hcmsgTm90dGluZ2hhbTsg U2Fzd2F0IFByYWhhcmFqIChzYXNwcmFoYSk8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBb T1BTQVdHXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW9wc2F3Zy1tdWQtMTQudHh0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SGkgTWVkLDxvOnA+PC9vOnA+PC9wPg0KPHA+UGxlYXNlIHNl ZSBiZWxvdzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI0LjAxLjE4IDEyOjU0 LCA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+DQptb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHVuZGVyc3RhbmRp bmcgZnJvbSBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTQgaXMgdGhhdCBhY2wtdHlwZSBy ZW1haW5zIGFjbC10eXBlLiZuYnNwOyBhY2wtbmFtZSBiZWNhbWUgbmFtZS4mbmJzcDsgQnV0IHlv dSdyZSByaWdodC0gcnVsZS1uYW1lIGJlY2FtZSBuYW1lIGFzIHdlbGwuJm5ic3A7IEkgd2lsbCBh ZGp1c3QgdGhlIHRleHQgYWNjb3JkaW5nbHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5bTWVkXSBJIGd1ZXNzIHlvdSBtZWFudCAtMTUuIEkgY29uZmlybSB0aGF0IGFjbC10eXBl IGlzIHRvIGJlIGNoYW5nZWQgdG9vLiBCZWxvdyBhbiBleGNlcnB0IG9mIHRoZSBhY2wgdHJlZSBz dHJ1Y3R1cmU6DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWNjZXNzLWxpc3RzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0 ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGFjbCogW25hbWVdPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0 JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyBzdHJp bmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB0eXBl PyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5hY2wtdHlwZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+KiBUaGlzIHNl bnRlbmNlIHNob3VsZCBiZSBjYXJlZnVsbHkgdXBkYXRlZCBhcyB3ZWxsOiDigJw8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPldpdGggdGhlIGV4Y2VwdGlvbnMgb2YgPHNwYW4gY2xhc3M9Imluc2Vy dCI+JnF1b3Q7bmFtZSZxdW90Oyw8L3NwYW4+ICZxdW90O2FjbC10eXBlJnF1b3Q7LCAmcXVvdDty dWxlLW5hbWUmcXVvdDssIGFuZCBUQ1AgYW5kPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6d2luZG93dGV4dCI+4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiogSSBndWVzcyB0aGUg ZXhhbXBsZXMgc2hvdWxkIGJlIGNoZWNrZWQgdG8gYWxpZ24gd2l0aCB0aGUgbmV3IEFDTCBzdHJ1 Y3R1cmUuIEZvciBleGFtcGxlLCA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDstIOKAnGlwdjYtYWNs 4oCdIGVudHJpZXMgc2hvdWxkIGJlIHVwZGF0ZWQgdG8g4oCcaXB2NuKAnS48L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KWW91J3JlIHJp Z2h0LiZuYnNwOyBJIHN0YW5kIGNvcnJlY3RlZC4mbmJzcDsgQW5kIEkgc3BvdHRlZCB0aGUgZXJy b3IgaW4gdGhlIGV4YW1wbGUuJm5ic3A7IFdpbGwgY29ycmVjdC48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQpXaGljaCBpcyB0aGUgdGV4dCBJIGFkanVzdGVkIDstKTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjpibGFjayZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+W01lZF0gWWVzLiBJIHdhcyByZWZlcnJpbmcgdG8gdGhlIGV4YW1wbGVz Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dCI+Jm5ic3A7LSBhZGQg4oCcbDPigJ0gZW50cnkgYmVmb3JlIOKAnGlwdjTigJ0gYW5kIOKA nGlwdjbigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KSSB0aGluayB0aGlzIGlzIGRvbmUgaW4gdGhlIG5vcm1h dGl2ZSB0ZXh0IGJ1dCB5b3UncmUgcmlnaHQtIGl0IG5lZWRzIHRvIGJlIGNvcnJlY3RlPC9zcGFu PmQgaW4gdGhlIGV4YW1wbGVzLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiogSXQg d291bGQgdXNlZnVsIHRvIGFkZCBhIGp1c3RpZmljYXRpb24gd2h5IGl0IGlzIG5vdCByZWNvbW1l bmRlZCB0byBzdXBwb3J0ICdyZWplY3QnIGFjdGlvbi48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk9rLCBJJ2xsIGFkZCBzb21lIHRleHQuPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcgO2NvbG9yOmJsYWNrJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5bTWVkXSBUaGFu ayB5b3UuIEJUVywgd291bGRu4oCZdCB5b3UgbmVlZCBhIHJhdGUtbGltaXQgYWN0aW9uIHRvIOKA nHByb3RlY3TigJ0gYWdhaW5zdCBleGhhdXN0aW5nIFRoaW5nIHJlc291cmNlcz8NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSBkb24n dCB0aGluayB0aGF0J3MgYXBwcm9wcmlhdGUgYXQgdGhpcyBwb2ludC4mbmJzcDsgRm9yIG9uZSB0 aGluZywgaXQgZ29lcyB3ZWxsIGJleW9uZCB3aGF0IG1hbnkgaW1wbGVtZW50YXRpb25zIGNhbiBh Y3R1YWxseSBkby4mbmJzcDsgRm9yIGFub3RoZXIsIGl0IG1heSBiZSBhc2tpbmcgYSBiaXQgbXVj aCBvZiB0aGUgbWFudWZhY3R1cmVycyB0byBwcmVkaWN0IHRoaXMgc29ydCBvZiBiZWhhdmlvciwg YW5kIGl0IHdpbGwgYmUgZWFzeSB0byBnZXQgd3JvbmcuJm5ic3A7DQogSSB3b3VsZCBzdWdnZXN0 IHRoaXMgYmUgaGFuZGxlZCBsYXRlciBhcyB3ZSBnZXQgc29tZSBhZGRpdGlvbmFsIG9wZXJhdGlv bmFsIGV4cGVyaWVuY2UuPGJyPg0KPGJyPg0KRWxpb3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93300A0C61BFOPEXCLILMA3corp_-- From nobody Wed Jan 24 06:52:43 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A176124D6C; Wed, 24 Jan 2018 06:52:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, Tianran Zhou , warren@kumari.net, opsawg-chairs@ietf.org, zhoutianran@huawei.com, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151680555709.25672.9561537628046201312.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 06:52:37 -0800 Archived-At: Subject: [OPSAWG] Suresh Krishnan's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-11: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 14:52:37 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 3.2. This should be easy to resolve but I would like this to be disambiguated before publication. RFC5844 specifies *two* different options for UDP encapsulation IPv4-UDP and IPv4-UDP-TLV. Please clarify which of these modes is intended when the Tunnel-Type is 4 4: PMIPv6-UDP. This refers to the UDP tunneling encapsulation described in [RFC5844]. From nobody Wed Jan 24 10:25:27 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37C7127419 for ; Wed, 24 Jan 2018 10:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 wauzTPFA4hzo for ; Wed, 24 Jan 2018 10:25:22 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 6F41C127275 for ; Wed, 24 Jan 2018 10:25:22 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id c16so6229856itc.5 for ; Wed, 24 Jan 2018 10:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7NUG0gs3h2Qr9K75bf29LCKYCSrx1ilNX1Dpxy4rbvw=; b=Pb8qRN2nXu4oc1naSwksV4SQ7EFhoU7lu/snm2eiion6FbFUa7PjzfAlDvfu420Unw bYXBMk9TBxPGmSJ8UBuLZjBcxiD5g6iWjBbEakT+jM/71YdrJ17wdg2Z/dY8w0VRassU EML5TgctvfOV6TAN2wP6Qpvq20l0bHo0aAsmK6YxxAgI2qbh/eEpYHodu2JBEdqpyrJb tnO4pWNxZDPhulXyGHCrW15faOiOV2fH53VyodCJtF0ugN8u+Q/vdy7mgRJYexrMtPi8 wInaqgNmQacMPzEFwvLZeJxV/N83TI+FKOkwpE3HZmKvrVShdoS2rVTGthKFonE+ffLt RpTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7NUG0gs3h2Qr9K75bf29LCKYCSrx1ilNX1Dpxy4rbvw=; b=uevO8YK6UscstO0ioyz/INLX2teEeWcgw6T1iXMurkdxzoLHMPp31IkBRqUzv0dmfd cUuZ4gb3Qtci/QCsbM9bTs6byyfxndI55aty+22NL8VSmsxOXaKTbAHUDZQSXRKQ2Ol5 uuCumh2KVf4IyJMenw+obmb6fOLc1RSj3Q7eo0/A7onOe2em2aj96zqRk5JBDhhTDWpZ mtOBYxhtd9WHlgRjN+iQWVLFTrA1wmJJN2QuA1d9qf7IEXGWzMmELR6U4RUdE4BCwCpU cs1hEL/mhDYdC4dfZR1jN7nd/ZbbYC2i0vU3gXru4tgEpgsg4ActFQeCp1cbAXHfIvUU ui4g== X-Gm-Message-State: AKwxytcQ9kh41gYFXVLmCR211VIS3+e5PWMSi6oZBhP2eyw/LTV0u7MS gADgcdcixAMGaZfJGx/RBlE= X-Google-Smtp-Source: AH8x224QZeWfFCOmS4lD0EyfnDyIBs8xVlD5UA9ONU/AD39il4DuLb9efQR2TaD+/kIa1Wm/gj0tWg== X-Received: by 10.36.83.21 with SMTP id n21mr9864025itb.74.1516818321557; Wed, 24 Jan 2018 10:25:21 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:f531:c9be:3b67:558d]) by smtp.gmail.com with ESMTPSA id a4sm448512itc.13.2018.01.24.10.25.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 10:25:20 -0800 (PST) From: Mahesh Jethanandani Message-Id: <77A11041-5699-408D-90A9-0DDB0E79BF44@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_11393CC9-5192-4248-98EF-7B930AB4AF30" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 24 Jan 2018 10:25:18 -0800 In-Reply-To: <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> Cc: opsawg@ietf.org, Warren Kumari , Mark Nottingham To: Eliot Lear References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 18:25:26 -0000 --Apple-Mail=_11393CC9-5192-4248-98EF-7B930AB4AF30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 24, 2018, at 12:34 AM, Eliot Lear wrote: >=20 > This update primarily focuses on two elements that were agreed during = WGLC: >=20 > The update to the ACL model. That update has taken longer than I = would have liked, but it is now at least close to finished. Note: the = MUD model does not yet match the published ACL model, but it does match = the agreed changes that will be produced in the next ACL draft. Does it? Looking at the MUD example in Section 8 of the draft, I see that = port/range is hanging off of ipv6 IP header. Per your comment, we moved = the port under the =E2=80=98tcp=E2=80=99 header in the ACL model. Also, the container "access-list-entries" had been renamed to =E2=80=9Cace= s=E2=80=9D in an earlier version of the draft. Med has pointed out some = other discrepancies, but in general, I would scrub the entire example = one more time. Cheers. p.s. The updated ACL model tree looks like this now: module: ietf-access-control-list +--rw access-lists +--rw acl* [name] | +--rw name string | +--rw type? acl-type | +--rw aces | +--rw ace* [name] | +--rw name string | +--rw matches | | +--rw (l2)? | | | +--:(eth) | | | +--rw eth {match-on-eth}? | | | +--rw destination-mac-address? | | | | yang:mac-address | | | +--rw destination-mac-address-mask? | | | | yang:mac-address | | | +--rw source-mac-address? | | | | yang:mac-address | | | +--rw source-mac-address-mask? | | | | yang:mac-address | | | +--rw ethertype? | | | eth:ethertype | | +--rw (l3)? | | | +--:(ipv4) | | | | +--rw ipv4 {match-on-ipv4}? | | | | +--rw dscp? inet:dscp | | | | +--rw ecn? uint8 | | | | +--rw length? uint16 | | | | +--rw ttl? uint8 | | | | +--rw protocol? uint8 | | | | +--rw ihl? uint8 | | | | +--rw flags? bits | | | | +--rw offset? uint16 | | | | +--rw identification? uint16 | | | | +--rw (destination-network)? | | | | | +--:(destination-ipv4-network) | | | | | +--rw destination-ipv4-network? | | | | | inet:ipv4-prefix | | | | +--rw (source-network)? | | | | +--:(source-ipv4-network) | | | | +--rw source-ipv4-network? | | | | inet:ipv4-prefix | | | +--:(ipv6) | | | +--rw ipv6 {match-on-ipv6}? | | | +--rw dscp? inet:dscp | | | +--rw ecn? uint8 | | | +--rw length? uint16 | | | +--rw ttl? uint8 | | | +--rw protocol? uint8 | | | +--rw (destination-network)? | | | | +--:(destination-ipv6-network) | | | | +--rw destination-ipv6-network? | | | | inet:ipv6-prefix | | | +--rw (source-network)? | | | | +--:(source-ipv6-network) | | | | +--rw source-ipv6-network? | | | | inet:ipv6-prefix | | | +--rw flow-label? | | | inet:ipv6-flow-label | | +--rw (l4)? | | | +--:(tcp) | | | | +--rw tcp {match-on-tcp}? | | | | +--rw sequence-number? | | | | | uint32 | | | | +--rw acknowledgement-number? | | | | | uint32 | | | | +--rw data-offset? | | | | | uint8 | | | | +--rw reserved? | | | | | uint8 | | | | +--rw flags? | | | | | bits | | | | +--rw window-size? | | | | | uint16 | | | | +--rw urgent-pointer? | | | | | uint16 | | | | +--rw options? | | | | | uint32 | | | | +--rw (source-port)? | | | | | +--:(source-port-range-or-operator) | | | | | +--rw source-port-range-or-operator | | | | | +--rw (port-range-or-operator)? | | | | | +--:(range) | | | | | | +--rw lower-port | | | | | | | inet:port-number | | | | | | +--rw upper-port | | | | | | inet:port-number | | | | | +--:(operator) | | | | | +--rw operator? operator | | | | | +--rw port | | | | | inet:port-number | | | | +--rw (destination-port)? | | | | +--:(destination-port-range-or-operator) | | | | +--rw destination-port-range-or-opera tor | | | | +--rw (port-range-or-operator)? | | | | +--:(range) | | | | | +--rw lower-port | | | | | | inet:port-number | | | | | +--rw upper-port | | | | | inet:port-number | | | | +--:(operator) | | | | +--rw operator? operator | | | | +--rw port | | | | inet:port-number | | | +--:(udp) | | | | +--rw udp {match-on-udp}? | | | | +--rw length? | | | | | uint16 | | | | +--rw (source-port)? | | | | | +--:(source-port-range-or-operator) | | | | | +--rw source-port-range-or-operator | | | | | +--rw (port-range-or-operator)? | | | | | +--:(range) | | | | | | +--rw lower-port | | | | | | | inet:port-number | | | | | | +--rw upper-port | | | | | | inet:port-number | | | | | +--:(operator) | | | | | +--rw operator? operator | | | | | +--rw port | | | | | inet:port-number | | | | +--rw (destination-port)? | | | | +--:(destination-port-range-or-operator) | | | | +--rw destination-port-range-or-opera tor | | | | +--rw (port-range-or-operator)? | | | | +--:(range) | | | | | +--rw lower-port | | | | | | inet:port-number | | | | | +--rw upper-port | | | | | inet:port-number | | | | +--:(operator) | | | | +--rw operator? operator | | | | +--rw port | | | | inet:port-number | | | +--:(icmp) | | | +--rw icmp {match-on-icmp}? | | | +--rw type? uint8 | | | +--rw code? uint8 | | | +--rw rest-of-header? uint32 | | +--rw egress-interface? if:interface-ref | | +--rw ingress-interface? if:interface-ref | +--rw actions | | +--rw forwarding identityref | | +--rw logging? identityref | +--ro statistics {acl-aggregate-stats}? | +--ro matched-packets? yang:counter64 | +--ro matched-octets? yang:counter64 +--rw attachment-points +--rw interface* [interface-id] {interface-attachment}? +--rw interface-id if:interface-ref +--rw ingress | +--rw acl-sets | +--rw acl-set* [name] | +--rw name | | -> ../../../../../../acl/name | +--ro ace-statistics* [name] {interface-stats}? | +--ro name leafref | +--ro matched-packets? yang:counter64 | +--ro matched-octets? yang:counter64 +--rw egress +--rw acl-sets +--rw acl-set* [name] +--rw name | -> ../../../../../../acl/name +--ro ace-statistics* [name] {interface-stats}? +--ro name leafref +--ro matched-packets? yang:counter64 +--ro matched-octets? yang:counter64 > Mark Nottingham had commented that it is not appropriate to have = versioning information in the MUD-URL itself, but that it should be in = the model. We agreed on this change, as well as some wording around how = HTTP is handled. > Based on these changes, I would like to move this document forward to = IETF LC. >=20 > Eliot >=20 > On 24.01.18 09:29, internet-drafts@ietf.org = wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Operations and Management Area = Working Group WG of the IETF. >>=20 >> Title : Manufacturer Usage Description = Specification >> Authors : Eliot Lear >> Ralph Droms >> Dan Romascanu >> Filename : draft-ietf-opsawg-mud-14.txt >> Pages : 56 >> Date : 2018-01-24 >>=20 >> Abstract: >> This memo specifies a component-based architecture for = manufacturer >> usage descriptions (MUD). The goal of MUD is to provide a means = for >> Things to signal to the network what sort of access and network >> functionality they require to properly function. The initial = focus >> is on access control. Later work can delve into other aspects. >>=20 >> This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, = an >> LLDP TLV, a URL suffix specification, an X.509 certificate = extension >> and a means to sign and verify the descriptions. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-opsawg-mud-14 = >> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14 = >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-14 = >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ = >>=20 >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg = >>=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_11393CC9-5192-4248-98EF-7B930AB4AF30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 24, 2018, at 12:34 AM, Eliot Lear <lear@cisco.com> = wrote:

=20 =20

This = update primarily focuses on two elements that were agreed during WGLC:

  • The update to the ACL model.  That update has = taken longer than I would have liked, but it is now at least close to finished.  Note: the MUD model does not yet match the = published ACL model, but it does match the agreed changes that will be produced in the next ACL = draft.
Does it?

Looking at the MUD example in Section 8 of the = draft, I see that port/range is hanging off of ipv6 IP header. Per your = comment, we moved the port under the =E2=80=98tcp=E2=80=99 header in the = ACL model.

Also, the container = "access-list-entries" had been renamed to =E2=80=9Caces=E2=80=9D in an = earlier version of the draft. Med has pointed out some other = discrepancies, but in general, I would scrub the entire example one more = time.

Cheers.

p.s. The updated ACL model tree looks like this = now:

module: = ietf-access-control-list
  =   +--rw access-lists
       +--rw acl* [name]
       |  +--rw = name    string
       |  +--rw type?   = acl-type
       |  +--rw = aces
       |     +--rw ace* = [name]
       |        +--rw = name          string
       |  =       +--rw matches
       |        = |  +--rw (l2)?
       |        = |  |  +--:(eth)
       |        = |  |     +--rw eth {match-on-eth}?
       |  =       |  |        +--rw = destination-mac-address?
       |        = |  |        |       = yang:mac-address
       |        = |  |        +--rw = destination-mac-address-mask?
       |        = |  |        |       = yang:mac-address
       |        = |  |        +--rw = source-mac-address?
       |        = |  |        |       = yang:mac-address
       |        = |  |        +--rw = source-mac-address-mask?
       |        = |  |        |       = yang:mac-address
       |        = |  |        +--rw ethertype?
       |  =       |  |            =     eth:ethertype
       |        = |  +--rw (l3)?
       |        = |  |  +--:(ipv4)
       |        = |  |  |  +--rw ipv4 {match-on-ipv4}?
       |  =       |  |  |     +--rw dscp?   =                     = inet:dscp
       |        = |  |  |     +--rw ecn?        =                 = uint8
       |        = |  |  |     +--rw length?       =               uint16
       |  =       |  |  |     +--rw ttl?  =                     =   uint8
       |        = |  |  |     +--rw protocol?       =             uint8
       |  =       |  |  |     +--rw ihl?  =                     =   uint8
       |        = |  |  |     +--rw flags?        =               bits
       |  =       |  |  |     +--rw offset? =                     = uint16
       |        = |  |  |     +--rw identification?     =         uint16
       |        = |  |  |     +--rw = (destination-network)?
       |        = |  |  |     |  = +--:(destination-ipv4-network)
       |        = |  |  |     |     +--rw = destination-ipv4-network?
       |        = |  |  |     |           =   inet:ipv4-prefix
       |        = |  |  |     +--rw (source-network)?
       |  =       |  |  |        = +--:(source-ipv4-network)
       |        = |  |  |           +--rw = source-ipv4-network?
       |        = |  |  |               =     inet:ipv4-prefix
       |        = |  |  +--:(ipv6)
       |        = |  |     +--rw ipv6 {match-on-ipv6}?
       |  =       |  |        +--rw dscp? =                     =   inet:dscp
       |        = |  |        +--rw ecn?      =                   = uint8
       |        = |  |        +--rw length?       =               uint16
       |  =       |  |        +--rw = ttl?                  =       uint8
       |        = |  |        +--rw protocol?     =               uint8
       |  =       |  |        +--rw = (destination-network)?
       |        = |  |        |  = +--:(destination-ipv6-network)
       |        = |  |        |     +--rw = destination-ipv6-network?
       |        = |  |        |         =     inet:ipv6-prefix
       |        = |  |        +--rw = (source-network)?
       |        = |  |        |  = +--:(source-ipv6-network)
       |        = |  |        |     +--rw = source-ipv6-network?
       |        = |  |        |         =     inet:ipv6-prefix
       |        = |  |        +--rw flow-label?
       |  =       |  |            =     inet:ipv6-flow-label
       |        = |  +--rw (l4)?
       |        = |  |  +--:(tcp)
       |        = |  |  |  +--rw tcp {match-on-tcp}?
       |  =       |  |  |     +--rw = sequence-number?
       |        = |  |  |     |       = uint32
       |        = |  |  |     +--rw = acknowledgement-number?
       |        = |  |  |     |       = uint32
       |        = |  |  |     +--rw data-offset?
       |  =       |  |  |     |     =   uint8
       |        = |  |  |     +--rw reserved?
       |  =       |  |  |     |     =   uint8
       |        = |  |  |     +--rw flags?
       |  =       |  |  |     |     =   bits
       |        = |  |  |     +--rw window-size?
       |  =       |  |  |     |     =   uint16
       |        = |  |  |     +--rw urgent-pointer?
       |  =       |  |  |     |     =   uint16
       |        = |  |  |     +--rw options?
       |  =       |  |  |     |     =   uint32
       |        = |  |  |     +--rw (source-port)?
       |  =       |  |  |     |  = +--:(source-port-range-or-operator)
       |        = |  |  |     |     +--rw = source-port-range-or-operator
       |        = |  |  |     |        +--rw = (port-range-or-operator)?
       |        = |  |  |     |           = +--:(range)
       |        = |  |  |     |           = |  +--rw lower-port
       |        = |  |  |     |           = |  |       inet:port-number
       |  =       |  |  |     |     =       |  +--rw upper-port
       |  =       |  |  |     |     =       |          = inet:port-number
       |        = |  |  |     |           = +--:(operator)
       |        = |  |  |     |          =     +--rw operator?     operator
       |  =       |  |  |     |    =           +--rw port
       |  =       |  |  |     |    =                   = inet:port-number
       |        = |  |  |     +--rw = (destination-port)?
       |        = |  |  |        = +--:(destination-port-range-or-operator)
       |        = |  |  |           +--rw = destination-port-range-or-opera
tor
       |        = |  |  |              +--rw = (port-range-or-operator)?
       |        = |  |  |               =   +--:(range)
       |        = |  |  |               =   |  +--rw lower-port
       |        = |  |  |               =   |  |       inet:port-number
       |  =       |  |  |         =         |  +--rw upper-port
       |  =       |  |  |         =         |          = inet:port-number
       |        = |  |  |               =   +--:(operator)
       |        = |  |  |                =     +--rw operator?     operator
       |  =       |  |  |          =           +--rw port
       |  =       |  |  |          =                   = inet:port-number
       |        = |  |  +--:(udp)
       |        = |  |  |  +--rw udp {match-on-udp}?
       |  =       |  |  |     +--rw = length?
       |        = |  |  |     |       = uint16
       |        = |  |  |     +--rw (source-port)?
       |  =       |  |  |     |  = +--:(source-port-range-or-operator)
       |        = |  |  |     |     +--rw = source-port-range-or-operator
       |        = |  |  |     |        +--rw = (port-range-or-operator)?
       |        = |  |  |     |           = +--:(range)
       |        = |  |  |     |           = |  +--rw lower-port
       |        = |  |  |     |           = |  |       inet:port-number
       |  =       |  |  |     |     =       |  +--rw upper-port
       |  =       |  |  |     |     =       |          = inet:port-number
       |        = |  |  |     |           = +--:(operator)
       |        = |  |  |     |          =     +--rw operator?     operator
       |  =       |  |  |     |    =           +--rw port
       |  =       |  |  |     |    =                   = inet:port-number
       |        = |  |  |     +--rw = (destination-port)?
       |        = |  |  |        = +--:(destination-port-range-or-operator)
       |        = |  |  |           +--rw = destination-port-range-or-opera
tor
       |        = |  |  |              +--rw = (port-range-or-operator)?
       |        = |  |  |               =   +--:(range)
       |        = |  |  |               =   |  +--rw lower-port
       |        = |  |  |               =   |  |       inet:port-number
       |  =       |  |  |         =         |  +--rw upper-port
       |  =       |  |  |         =         |          = inet:port-number
       |        = |  |  |               =   +--:(operator)
       |        = |  |  |                =     +--rw operator?     operator
       |  =       |  |  |          =           +--rw port
       |  =       |  |  |          =                   = inet:port-number
       |        = |  |  +--:(icmp)
       |        = |  |     +--rw icmp {match-on-icmp}?
       |  =       |  |        +--rw type? =             uint8
       |  =       |  |        +--rw code? =             uint8
       |  =       |  |        +--rw = rest-of-header?   uint32
       |        = |  +--rw egress-interface?    = if:interface-ref
       |        = |  +--rw ingress-interface?   = if:interface-ref
       |        +--rw = actions
       |        = |  +--rw forwarding    identityref
       |  =       |  +--rw logging?      = identityref
       |        +--ro = statistics {acl-aggregate-stats}?
       |         =   +--ro matched-packets?   yang:counter64
       |   =         +--ro matched-octets?    = yang:counter64
       +--rw = attachment-points
  =         +--rw interface* [interface-id] = {interface-attachment}?
             +--rw = interface-id    if:interface-ref
           =   +--rw ingress
             |  +--rw = acl-sets
             |   =   +--rw acl-set* [name]
             |  =       +--rw name
             |  =       |       -> = ../../../../../../acl/name
             |  =       +--ro ace-statistics* [name] = {interface-stats}?
             |   =         +--ro name         =       leafref
             |   =         +--ro matched-packets?   = yang:counter64
             |   =         +--ro matched-octets?    = yang:counter64
             +--rw = egress
  =               +--rw = acl-sets
                 =   +--rw acl-set* [name]
  =                     = +--rw name
  =                     | =       -> ../../../../../../acl/name
          =             +--ro ace-statistics* [name] = {interface-stats}?
                 =         +--ro name         =       leafref
                 =         +--ro matched-packets?   = yang:counter64
                 =         +--ro matched-octets?    = yang:counter64
  • Mark Nottingham had commented that it is not = appropriate to have versioning information in the MUD-URL itself, but that it should be in the model.  We agreed on this change, as well = as some wording around how HTTP is handled.

Based on these changes, I would like to move this = document forward to IETF LC.

Eliot


On 24.01.18 09:29, internet-drafts@ietf.org = wrote:
A New Internet-Draft is available from =
the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working =
Group WG of the IETF.

        Title           : Manufacturer Usage Description Specification
        Authors         : Eliot Lear
                          Ralph Droms
                          Dan Romascanu
	Filename        : draft-ietf-opsawg-mud-14.txt
	Pages           : 56
	Date            : 2018-01-24

Abstract:
   This memo specifies a component-based architecture for manufacturer
   usage descriptions (MUD).  The goal of MUD is to provide a means for
   Things to signal to the network what sort of access and network
   functionality they require to properly function.  The initial focus
   is on access control.  Later work can delve into other aspects.

   This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
   LLDP TLV, a URL suffix specification, an X.509 certificate extension
   and a means to sign and verify the descriptions.


The IETF datatracker status page for this draft is:
https://d=
atatracker.ietf.org/doc/draft-ietf-opsawg-mud/

There are also htmlized versions available at:
https://tool=
s.ietf.org/html/draft-ietf-opsawg-mud-14
ht=
tps://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14

A diff from the previous version is available at:
http=
s://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-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-d=
rafts/

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org=
/mailman/listinfo/opsawg


Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_11393CC9-5192-4248-98EF-7B930AB4AF30-- From nobody Wed Jan 24 10:27:28 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8066F1273E2 for ; Wed, 24 Jan 2018 10:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 y5px_jDX0LNk for ; Wed, 24 Jan 2018 10:27:24 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA07127419 for ; Wed, 24 Jan 2018 10:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=105442; q=dns/txt; s=iport; t=1516818443; x=1518028043; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=GGfyEQufPGPYY0TeOf8HQWqWFNZHIOEvUIXCMkCqaxk=; b=BmnretSUcGXAEGVFy8Esy6WT+DcdMLRGXUrbWkRV1+lQhN5iY0z8BMh6 SzJJdD2s1Gv5tKpOgC4fwx6Xu8hmxRYdmrdWRwm3LZzfNJJxq8Xx3K9qT /MBCwrQtpVi+5xY5xBt4EJRgWjKlghXvANNEUfasEHS0fRTTChJOiq83M U=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAAB/z2ha/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKgV50J4NdiiR0j04niRGOL4IXBwMYAQqESU8CGoU7GAEBAQE?= =?us-ascii?q?BAQEBAmsohSMBAQEDAQEBGAkERwsQCQIOBAYgAQYDAgICHwYfAw4GDQYCAQGKG?= =?us-ascii?q?QMNCBCVDJ1xgW06JoccDYMLAQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+EUoVUKQy?= =?us-ascii?q?CeYJrRAEBAgEBF4FtFYJrgmUFim2HSodUiT49hF6CMYEFiEeFBoIbZ4U4g3GHe?= =?us-ascii?q?Yp5gmBGiTiBPA8QOYFQMxoIGxUZJIIqCYRPQDeOKgEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,408,1511827200"; d="asc'?scan'208,217";a="1632409" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 18:27:20 +0000 Received: from [10.61.84.169] (ams3-vpn-dhcp5290.cisco.com [10.61.84.169]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0OIRJAX003095; Wed, 24 Jan 2018 18:27:19 GMT To: Mahesh Jethanandani Cc: opsawg@ietf.org, Warren Kumari , Mark Nottingham References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <77A11041-5699-408D-90A9-0DDB0E79BF44@gmail.com> From: Eliot Lear Message-ID: <82486ec7-5e33-1570-a4f2-4be56c231b2d@cisco.com> Date: Wed, 24 Jan 2018 19:27:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <77A11041-5699-408D-90A9-0DDB0E79BF44@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nEDfx8d783iPWW7G7p30rHoV6MhKsQQWC" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 18:27:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nEDfx8d783iPWW7G7p30rHoV6MhKsQQWC Content-Type: multipart/mixed; boundary="u7FllT5JmIeJGjbfwxXo54sbKE1MFdrm8"; protected-headers="v1" From: Eliot Lear To: Mahesh Jethanandani Cc: opsawg@ietf.org, Warren Kumari , Mark Nottingham Message-ID: <82486ec7-5e33-1570-a4f2-4be56c231b2d@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <77A11041-5699-408D-90A9-0DDB0E79BF44@gmail.com> In-Reply-To: <77A11041-5699-408D-90A9-0DDB0E79BF44@gmail.com> --u7FllT5JmIeJGjbfwxXo54sbKE1MFdrm8 Content-Type: multipart/alternative; boundary="------------0ACDFEC61701A6FA66588B22" Content-Language: en-US This is a multi-part message in MIME format. --------------0ACDFEC61701A6FA66588B22 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CgpPbiAyNC4wMS4xOCAxOToyNSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToKPgo+Cj4+ IE9uIEphbiAyNCwgMjAxOCwgYXQgMTI6MzQgQU0sIEVsaW90IExlYXIgPGxlYXJAY2lzY28u Y29tCj4+IDxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3cm90ZToKPj4KPj4gVGhpcyB1cGRh dGUgcHJpbWFyaWx5IGZvY3VzZXMgb24gdHdvIGVsZW1lbnRzIHRoYXQgd2VyZSBhZ3JlZWQg ZHVyaW5nCj4+IFdHTEM6Cj4+Cj4+ICAgKiBUaGUgdXBkYXRlIHRvIHRoZSBBQ0wgbW9kZWwu wqAgVGhhdCB1cGRhdGUgaGFzIHRha2VuIGxvbmdlciB0aGFuIEkKPj4gICAgIHdvdWxkIGhh dmUgbGlrZWQsIGJ1dCBpdCBpcyBub3cgYXQgbGVhc3QgY2xvc2UgdG8gZmluaXNoZWQuwqAK Pj4gICAgIE5vdGU6IHRoZSBNVUQgbW9kZWwgZG9lcyBub3QgeWV0IG1hdGNoIHRoZSBwdWJs aXNoZWQgQUNMIG1vZGVsLAo+PiAgICAgYnV0IGl0IGRvZXMgbWF0Y2ggdGhlIGFncmVlZCBj aGFuZ2VzIHRoYXQgd2lsbCBiZSBwcm9kdWNlZCBpbiB0aGUKPj4gICAgIG5leHQgQUNMIGRy YWZ0Lgo+Pgo+IERvZXMgaXQ/Cj4KPiBMb29raW5nIGF0IHRoZSBNVUQgZXhhbXBsZSBpbiBT ZWN0aW9uIDggb2YgdGhlIGRyYWZ0LCBJIHNlZSB0aGF0Cj4gcG9ydC9yYW5nZSBpcyBoYW5n aW5nIG9mZiBvZiBpcHY2IElQIGhlYWRlci4gUGVyIHlvdXIgY29tbWVudCwgd2UKPiBtb3Zl ZCB0aGUgcG9ydCB1bmRlciB0aGUg4oCYdGNw4oCZIGhlYWRlciBpbiB0aGUgQUNMIG1vZGVs LgoKWWVhaCwgdGhlIGV4YW1wbGUgd2FzIGJsb3duLsKgIEZpeGVkIGluIG5leHQgcmVsZWFz ZSA7LSnCoCBTYW1lIHdpdGgKcHJvdG9jb2wuwqAgSXQgZW5kZWQgdXAgaW4gbDQgd2hlbiBp dCBzaG91bGQgYmUgbDMuCgo+Cj4gQWxzbywgdGhlIGNvbnRhaW5lciAiYWNjZXNzLWxpc3Qt ZW50cmllcyIgaGFkIGJlZW4gcmVuYW1lZCB0byDigJxhY2Vz4oCdCj4gaW4gYW4gZWFybGll ciB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gTWVkIGhhcyBwb2ludGVkIG91dCBzb21lIG90aGVy Cj4gZGlzY3JlcGFuY2llcywgYnV0IGluIGdlbmVyYWwsIEkgd291bGQgc2NydWIgdGhlIGVu dGlyZSBleGFtcGxlIG9uZQo+IG1vcmUgdGltZS4KPgo+IENoZWVycy4KPgo+IHAucy4gVGhl IHVwZGF0ZWQgQUNMIG1vZGVsIHRyZWUgbG9va3MgbGlrZSB0aGlzIG5vdzoKPgo+IG1vZHVs ZTogaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0Cj4gwqAgwqAgKy0tcncgYWNjZXNzLWxpc3Rz Cj4gwqDCoCDCoCDCoCArLS1ydyBhY2wqIFtuYW1lXQo+IMKgwqAgwqAgwqAgfMKgICstLXJ3 IG5hbWXCoCDCoCBzdHJpbmcKPiDCoMKgIMKgIMKgIHzCoCArLS1ydyB0eXBlPyDCoCBhY2wt dHlwZQo+IMKgwqAgwqAgwqAgfMKgICstLXJ3IGFjZXMKPiDCoMKgIMKgIMKgIHwgwqAgwqAg Ky0tcncgYWNlKiBbbmFtZV0KPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCArLS1ydyBuYW1l wqAgwqAgwqAgwqAgwqAgc3RyaW5nCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgKy0tcncg bWF0Y2hlcwo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCArLS1ydyAobDIpPwo+IMKg wqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgKy0tOihldGgpCj4gwqDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgfMKgIHwgwqAgwqAgKy0tcncgZXRoIHttYXRjaC1vbi1ldGh9Pwo+IMKg wqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgwqAgwqAgwqAgKy0tcncgZGVzdGluYXRp b24tbWFjLWFkZHJlc3M/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCDCoCDC oCDCoCB8IMKgIMKgIMKgIHlhbmc6bWFjLWFkZHJlc3MKPiDCoMKgIMKgIMKgIHzCoCDCoCDC oCDCoCB8wqAgfMKgIMKgIMKgIMKgICstLXJ3IGRlc3RpbmF0aW9uLW1hYy1hZGRyZXNzLW1h c2s/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCDCoCDCoCDCoCB8IMKgIMKg IMKgIHlhbmc6bWFjLWFkZHJlc3MKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKg IMKgIMKgIMKgICstLXJ3IHNvdXJjZS1tYWMtYWRkcmVzcz8KPiDCoMKgIMKgIMKgIHzCoCDC oCDCoCDCoCB8wqAgfMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgeWFuZzptYWMtYWRkcmVzcwo+ IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgwqAgwqAgwqAgKy0tcncgc291cmNl LW1hYy1hZGRyZXNzLW1hc2s/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCDC oCDCoCDCoCB8IMKgIMKgIMKgIHlhbmc6bWFjLWFkZHJlc3MKPiDCoMKgIMKgIMKgIHzCoCDC oCDCoCDCoCB8wqAgfMKgIMKgIMKgIMKgICstLXJ3IGV0aGVydHlwZT8KPiDCoMKgIMKgIMKg IHzCoCDCoCDCoCDCoCB8wqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGV0aDpldGhlcnR5 cGUKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgKy0tcncgKGwzKT8KPiDCoMKgIMKg IMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgICstLTooaXB2NCkKPiDCoMKgIMKgIMKgIHzCoCDC oCDCoCDCoCB8wqAgfMKgIHzCoCArLS1ydyBpcHY0IHttYXRjaC1vbi1pcHY0fT8KPiDCoMKg IMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgKy0tcncgZHNjcD8gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5ldDpkc2NwCj4gwqDCoCDCoCDCoCB8wqAg wqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgICstLXJ3IGVjbj/CoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCB1aW50OAo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8 wqAgfCDCoCDCoCArLS1ydyBsZW5ndGg/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IHVpbnQxNgo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCArLS1y dyB0dGw/wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdWludDgKPiDCoMKg IMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgKy0tcncgcHJvdG9jb2w/IMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQ4Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAg wqAgfMKgIHzCoCB8IMKgIMKgICstLXJ3IGlobD/CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCB1aW50OAo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDC oCDCoCArLS1ydyBmbGFncz/CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBiaXRz Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgICstLXJ3IG9mZnNl dD8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgdWludDE2Cj4gwqDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgICstLXJ3IGlkZW50aWZpY2F0aW9uPyDCoCDC oCDCoCDCoCDCoCDCoCB1aW50MTYKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKg IHwgwqAgwqAgKy0tcncgKGRlc3RpbmF0aW9uLW5ldHdvcmspPwo+IMKgwqAgwqAgwqAgfMKg IMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8wqAgKy0tOihkZXN0aW5hdGlvbi1pcHY0LW5l dHdvcmspCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIHwgwqAg wqAgKy0tcncgZGVzdGluYXRpb24taXB2NC1uZXR3b3JrPwo+IMKgwqAgwqAgwqAgfMKgIMKg IMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIGluZXQ6aXB2NC1w cmVmaXgKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgKy0tcncg KHNvdXJjZS1uZXR3b3JrKT8KPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHzC oCDCoCDCoCDCoCArLS06KHNvdXJjZS1pcHY0LW5ldHdvcmspCj4gwqDCoCDCoCDCoCB8wqAg wqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIMKgIMKgIMKgICstLXJ3IHNvdXJjZS1pcHY0LW5l dHdvcms/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGluZXQ6aXB2NC1wcmVmaXgKPiDCoMKgIMKgIMKgIHzCoCDCoCDC oCDCoCB8wqAgfMKgICstLTooaXB2NikKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAg fCDCoCDCoCArLS1ydyBpcHY2IHttYXRjaC1vbi1pcHY2fT8KPiDCoMKgIMKgIMKgIHzCoCDC oCDCoCDCoCB8wqAgfMKgIMKgIMKgIMKgICstLXJ3IGRzY3A/IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIGluZXQ6ZHNjcAo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzC oCB8wqAgwqAgwqAgwqAgKy0tcncgZWNuP8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIHVpbnQ4Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCDCoCDCoCDC oCArLS1ydyBsZW5ndGg/IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQxNgo+ IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgwqAgwqAgwqAgKy0tcncgdHRsP8Kg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHVpbnQ4Cj4gwqDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgfMKgIHzCoCDCoCDCoCDCoCArLS1ydyBwcm90b2NvbD8gwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgdWludDgKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAg fMKgIMKgIMKgIMKgICstLXJ3IChkZXN0aW5hdGlvbi1uZXR3b3JrKT8KPiDCoMKgIMKgIMKg IHzCoCDCoCDCoCDCoCB8wqAgfMKgIMKgIMKgIMKgIHzCoCArLS06KGRlc3RpbmF0aW9uLWlw djYtbmV0d29yaykKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIMKgIMKgIMKg IHwgwqAgwqAgKy0tcncgZGVzdGluYXRpb24taXB2Ni1uZXR3b3JrPwo+IMKgwqAgwqAgwqAg fMKgIMKgIMKgIMKgIHzCoCB8wqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCBpbmV0 OmlwdjYtcHJlZml4Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCDCoCDCoCDC oCArLS1ydyAoc291cmNlLW5ldHdvcmspPwo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzC oCB8wqAgwqAgwqAgwqAgfMKgICstLTooc291cmNlLWlwdjYtbmV0d29yaykKPiDCoMKgIMKg IMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIMKgIMKgIMKgIHwgwqAgwqAgKy0tcncgc291cmNl LWlwdjYtbmV0d29yaz8KPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIMKgIMKg IMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgaW5ldDppcHY2LXByZWZpeAo+IMKgwqAgwqAgwqAg fMKgIMKgIMKgIMKgIHzCoCB8wqAgwqAgwqAgwqAgKy0tcncgZmxvdy1sYWJlbD8KPiDCoMKg IMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluZXQ6 aXB2Ni1mbG93LWxhYmVsCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgICstLXJ3IChs NCk/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCArLS06KHRjcCkKPiDCoMKg IMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHzCoCArLS1ydyB0Y3Age21hdGNoLW9uLXRj cH0/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgICstLXJ3IHNl cXVlbmNlLW51bWJlcj8KPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAg wqAgfCDCoCDCoCDCoCB1aW50MzIKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKg IHwgwqAgwqAgKy0tcncgYWNrbm93bGVkZ2VtZW50LW51bWJlcj8KPiDCoMKgIMKgIMKgIHzC oCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgfCDCoCDCoCDCoCB1aW50MzIKPiDCoMKgIMKg IMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgKy0tcncgZGF0YS1vZmZzZXQ/Cj4g wqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIHwgwqAgwqAgwqAgdWlu dDgKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgKy0tcncgcmVz ZXJ2ZWQ/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIHwgwqAg wqAgwqAgdWludDgKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAg Ky0tcncgZmxhZ3M/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKg IHwgwqAgwqAgwqAgYml0cwo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDC oCDCoCArLS1ydyB3aW5kb3ctc2l6ZT8KPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAg fMKgIHwgwqAgwqAgfCDCoCDCoCDCoCB1aW50MTYKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDC oCB8wqAgfMKgIHwgwqAgwqAgKy0tcncgdXJnZW50LXBvaW50ZXI/Cj4gwqDCoCDCoCDCoCB8 wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIHwgwqAgwqAgwqAgdWludDE2Cj4gwqDCoCDC oCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgICstLXJ3IG9wdGlvbnM/Cj4gwqDC oCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIHwgwqAgwqAgwqAgdWludDMy Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgICstLXJ3IChzb3Vy Y2UtcG9ydCk/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIHzC oCArLS06KHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKQo+IMKgwqAgwqAgwqAgfMKg IMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8IMKgIMKgICstLXJ3IHNvdXJjZS1wb3J0LXJh bmdlLW9yLW9wZXJhdG9yCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKg IMKgIHzCoCDCoCDCoCDCoCArLS1ydyAocG9ydC1yYW5nZS1vci1vcGVyYXRvcik/Cj4gwqDC oCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAg Ky0tOihyYW5nZSkKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAg fCDCoCDCoCDCoCDCoCDCoCB8wqAgKy0tcncgbG93ZXItcG9ydAo+IMKgwqAgwqAgwqAgfMKg IMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIHzCoCB8IMKgIMKg IMKgIGluZXQ6cG9ydC1udW1iZXIKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKg IHwgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCB8wqAgKy0tcncgdXBwZXItcG9ydAo+IMKgwqAg wqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIHzC oCDCoCDCoCDCoCDCoCBpbmV0OnBvcnQtbnVtYmVyCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAg wqAgfMKgIHzCoCB8IMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgKy0tOihvcGVyYXRvcikKPiDC oMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgfMKgIMKgIMKgIMKgIMKg IMKgIMKgICstLXJ3IG9wZXJhdG9yPyDCoCDCoCBvcGVyYXRvcgo+IMKgwqAgwqAgwqAgfMKg IMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcncg cG9ydAo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgaW5ldDpwb3J0LW51bWJlcgo+IMKgwqAgwqAg wqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCArLS1ydyAoZGVzdGluYXRpb24tcG9y dCk/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8wqAgwqAgwqAgwqAgKy0t OihkZXN0aW5hdGlvbi1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKQo+IMKgwqAgwqAgwqAgfMKg IMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCDCoCDCoCDCoCArLS1ydyBkZXN0aW5hdGlvbi1w b3J0LXJhbmdlLW9yLW9wZXJhCj4gdG9yCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKg IHzCoCB8wqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcncgKHBvcnQtcmFuZ2Utb3Itb3BlcmF0 b3IpPwo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCArLS06KHJhbmdlKQo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8 wqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgKy0tcncgbG93ZXItcG9ydAo+IMKg wqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8wqAgfCDCoCDCoCDCoCBpbmV0OnBvcnQtbnVtYmVyCj4gwqDCoCDCoCDCoCB8wqAgwqAg wqAgwqAgfMKgIHzCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHzCoCArLS1ydyB1cHBl ci1wb3J0Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCDCoCBpbmV0OnBvcnQtbnVtYmVyCj4gwqDCoCDC oCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICst LToob3BlcmF0b3IpCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8wqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcncgb3BlcmF0b3I/IMKgIMKgIG9wZXJhdG9y Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8wqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgKy0tcncgcG9ydAo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8 wqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluZXQ6cG9y dC1udW1iZXIKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgICstLToodWRwKQo+ IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfMKgICstLXJ3IHVkcCB7bWF0Y2gt b24tdWRwfT8KPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgKy0t cncgbGVuZ3RoPwo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8 IMKgIMKgIMKgIHVpbnQxNgo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDC oCDCoCArLS1ydyAoc291cmNlLXBvcnQpPwo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzC oCB8wqAgfCDCoCDCoCB8wqAgKy0tOihzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcikK PiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgfCDCoCDCoCArLS1y dyBzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcgo+IMKgwqAgwqAgwqAgfMKgIMKgIMKg IMKgIHzCoCB8wqAgfCDCoCDCoCB8wqAgwqAgwqAgwqAgKy0tcncgKHBvcnQtcmFuZ2Utb3It b3BlcmF0b3IpPwo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8 IMKgIMKgIMKgIMKgIMKgICstLToocmFuZ2UpCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAg fMKgIHzCoCB8IMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgfMKgICstLXJ3IGxvd2VyLXBvcnQK PiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgfCDCoCDCoCDCoCDC oCDCoCB8wqAgfCDCoCDCoCDCoCBpbmV0OnBvcnQtbnVtYmVyCj4gwqDCoCDCoCDCoCB8wqAg wqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgfMKgICstLXJ3IHVw cGVyLXBvcnQKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgfCDC oCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgaW5ldDpwb3J0LW51bWJlcgo+IMKgwqAg wqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgICst LToob3BlcmF0b3IpCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHzCoCB8IMKgIMKg IHzCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ydyBvcGVyYXRvcj8gwqAgwqAgb3BlcmF0b3IK PiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgfMKgIMKgIMKgIMKg IMKgIMKgIMKgICstLXJ3IHBvcnQKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKg IHwgwqAgwqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIGluZXQ6cG9ydC1u dW1iZXIKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgKy0tcncg KGRlc3RpbmF0aW9uLXBvcnQpPwo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAg fMKgIMKgIMKgIMKgICstLTooZGVzdGluYXRpb24tcG9ydC1yYW5nZS1vci1vcGVyYXRvcikK PiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgwqAgwqAgwqAgKy0t cncgZGVzdGluYXRpb24tcG9ydC1yYW5nZS1vci1vcGVyYQo+IHRvcgo+IMKgwqAgwqAgwqAg fMKgIMKgIMKgIMKgIHzCoCB8wqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJ3IChwb3J0 LXJhbmdlLW9yLW9wZXJhdG9yKT8KPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKg IHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tOihyYW5nZSkKPiDCoMKgIMKgIMKgIHzC oCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfMKgICstLXJ3 IGxvd2VyLXBvcnQKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAgfMKgIHwgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgfMKgIHwgwqAgwqAgwqAgaW5ldDpwb3J0LW51bWJlcgo+IMKg wqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCB8wqAgKy0tcncgdXBwZXItcG9ydAo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8 wqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgwqAgaW5ldDpwb3J0 LW51bWJlcgo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCArLS06KG9wZXJhdG9yKQo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKg IHzCoCB8wqAgfMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJ3IG9wZXJhdG9y PyDCoCDCoCBvcGVyYXRvcgo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgfMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLXJ3IHBvcnQKPiDCoMKgIMKgIMKgIHzC oCDCoCDCoCDCoCB8wqAgfMKgIHzCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBpbmV0OnBvcnQtbnVtYmVyCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKg IHzCoCArLS06KGljbXApCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgIHwgwqAgwqAg Ky0tcncgaWNtcCB7bWF0Y2gtb24taWNtcH0/Cj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAg fMKgIHzCoCDCoCDCoCDCoCArLS1ydyB0eXBlPyDCoCDCoCDCoCDCoCDCoCDCoCB1aW50OAo+ IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCB8wqAgwqAgwqAgwqAgKy0tcncgY29kZT8g wqAgwqAgwqAgwqAgwqAgwqAgdWludDgKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDCoCB8wqAg fMKgIMKgIMKgIMKgICstLXJ3IHJlc3Qtb2YtaGVhZGVyPyDCoCB1aW50MzIKPiDCoMKgIMKg IMKgIHzCoCDCoCDCoCDCoCB8wqAgKy0tcncgZWdyZXNzLWludGVyZmFjZT/CoCDCoCBpZjpp bnRlcmZhY2UtcmVmCj4gwqDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfMKgICstLXJ3IGluZ3Jl c3MtaW50ZXJmYWNlPyDCoCBpZjppbnRlcmZhY2UtcmVmCj4gwqDCoCDCoCDCoCB8wqAgwqAg wqAgwqAgKy0tcncgYWN0aW9ucwo+IMKgwqAgwqAgwqAgfMKgIMKgIMKgIMKgIHzCoCArLS1y dyBmb3J3YXJkaW5nwqAgwqAgaWRlbnRpdHlyZWYKPiDCoMKgIMKgIMKgIHzCoCDCoCDCoCDC oCB8wqAgKy0tcncgbG9nZ2luZz/CoCDCoCDCoCBpZGVudGl0eXJlZgo+IMKgwqAgwqAgwqAg fMKgIMKgIMKgIMKgICstLXJvIHN0YXRpc3RpY3Mge2FjbC1hZ2dyZWdhdGUtc3RhdHN9Pwo+ IMKgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKg IHlhbmc6Y291bnRlcjY0Cj4gwqDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG1h dGNoZWQtb2N0ZXRzP8KgIMKgIHlhbmc6Y291bnRlcjY0Cj4gwqDCoCDCoCDCoCArLS1ydyBh dHRhY2htZW50LXBvaW50cwo+IMKgIMKgIMKgIMKgIMKgICstLXJ3IGludGVyZmFjZSogW2lu dGVyZmFjZS1pZF0ge2ludGVyZmFjZS1hdHRhY2htZW50fT8KPiDCoMKgIMKgIMKgIMKgIMKg IMKgICstLXJ3IGludGVyZmFjZS1pZMKgIMKgIGlmOmludGVyZmFjZS1yZWYKPiDCoMKgIMKg IMKgIMKgIMKgIMKgICstLXJ3IGluZ3Jlc3MKPiDCoMKgIMKgIMKgIMKgIMKgIMKgIHzCoCAr LS1ydyBhY2wtc2V0cwo+IMKgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCArLS1ydyBhY2wt c2V0KiBbbmFtZV0KPiDCoMKgIMKgIMKgIMKgIMKgIMKgIHzCoCDCoCDCoCDCoCArLS1ydyBu YW1lCj4gwqDCoCDCoCDCoCDCoCDCoCDCoCB8wqAgwqAgwqAgwqAgfCDCoCDCoCDCoCAtPiAu Li8uLi8uLi8uLi8uLi8uLi9hY2wvbmFtZQo+IMKgwqAgwqAgwqAgwqAgwqAgwqAgfMKgIMKg IMKgIMKgICstLXJvIGFjZS1zdGF0aXN0aWNzKiBbbmFtZV0ge2ludGVyZmFjZS1zdGF0c30/ Cj4gwqDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG5hbWUgwqAg wqAgwqAgwqAgwqAgwqAgwqAgbGVhZnJlZgo+IMKgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDC oCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLXBhY2tldHM/IMKgIHlhbmc6Y291bnRlcjY0Cj4g wqDCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgICstLXJvIG1hdGNoZWQtb2N0 ZXRzP8KgIMKgIHlhbmc6Y291bnRlcjY0Cj4gwqDCoCDCoCDCoCDCoCDCoCDCoCArLS1ydyBl Z3Jlc3MKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ydyBhY2wtc2V0cwo+IMKgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcncgYWNsLXNldCogW25hbWVdCj4gwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcncgbmFtZQo+IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgLT4gLi4vLi4vLi4vLi4vLi4vLi4vYWNs L25hbWUKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ybyBhY2Utc3Rh dGlzdGljcyogW25hbWVdIHtpbnRlcmZhY2Utc3RhdHN9Pwo+IMKgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgKy0tcm8gbmFtZSDCoCDCoCDCoCDCoCDCoCDCoCDCoCBs ZWFmcmVmCj4gwqDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ybyBt YXRjaGVkLXBhY2tldHM/IMKgIHlhbmc6Y291bnRlcjY0Cj4gwqDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCArLS1ybyBtYXRjaGVkLW9jdGV0cz/CoCDCoCB5YW5nOmNv dW50ZXI2NAo+Pgo+PiAgICogTWFyayBOb3R0aW5naGFtIGhhZCBjb21tZW50ZWQgdGhhdCBp dCBpcyBub3QgYXBwcm9wcmlhdGUgdG8gaGF2ZQo+PiAgICAgdmVyc2lvbmluZyBpbmZvcm1h dGlvbiBpbiB0aGUgTVVELVVSTCBpdHNlbGYsIGJ1dCB0aGF0IGl0IHNob3VsZAo+PiAgICAg YmUgaW4gdGhlIG1vZGVsLsKgIFdlIGFncmVlZCBvbiB0aGlzIGNoYW5nZSwgYXMgd2VsbCBh cyBzb21lCj4+ICAgICB3b3JkaW5nIGFyb3VuZCBob3cgSFRUUCBpcyBoYW5kbGVkLgo+Pgo+ PiBCYXNlZCBvbiB0aGVzZSBjaGFuZ2VzLCBJIHdvdWxkIGxpa2UgdG8gbW92ZSB0aGlzIGRv Y3VtZW50IGZvcndhcmQgdG8KPj4gSUVURiBMQy4KPj4KPj4gRWxpb3QKPj4KPj4KPj4gT24g MjQuMDEuMTggMDk6MjksIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToKPj4+IEEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4KPj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJlYSBXb3JraW5nIEdyb3VwIFdH IG9mIHRoZSBJRVRGLgo+Pj4KPj4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogTWFudWZh Y3R1cmVyIFVzYWdlIERlc2NyaXB0aW9uIFNwZWNpZmljYXRpb24KPj4+ICAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogRWxpb3QgTGVhcgo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICBSYWxwaCBEcm9tcwo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBEYW4gUm9tYXNj YW51Cj4+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1vcHNhd2ctbXVkLTE0LnR4 dAo+Pj4gCVBhZ2VzICAgICAgICAgICA6IDU2Cj4+PiAJRGF0ZSAgICAgICAgICAgIDogMjAx OC0wMS0yNAo+Pj4KPj4+IEFic3RyYWN0Ogo+Pj4gICAgVGhpcyBtZW1vIHNwZWNpZmllcyBh IGNvbXBvbmVudC1iYXNlZCBhcmNoaXRlY3R1cmUgZm9yIG1hbnVmYWN0dXJlcgo+Pj4gICAg dXNhZ2UgZGVzY3JpcHRpb25zIChNVUQpLiAgVGhlIGdvYWwgb2YgTVVEIGlzIHRvIHByb3Zp ZGUgYSBtZWFucyBmb3IKPj4+ICAgIFRoaW5ncyB0byBzaWduYWwgdG8gdGhlIG5ldHdvcmsg d2hhdCBzb3J0IG9mIGFjY2VzcyBhbmQgbmV0d29yawo+Pj4gICAgZnVuY3Rpb25hbGl0eSB0 aGV5IHJlcXVpcmUgdG8gcHJvcGVybHkgZnVuY3Rpb24uICBUaGUgaW5pdGlhbCBmb2N1cwo+ Pj4gICAgaXMgb24gYWNjZXNzIGNvbnRyb2wuICBMYXRlciB3b3JrIGNhbiBkZWx2ZSBpbnRv IG90aGVyIGFzcGVjdHMuCj4+Pgo+Pj4gICAgVGhpcyBtZW1vIHNwZWNpZmllcyB0d28gWUFO RyBtb2R1bGVzLCBJUHY0IGFuZCBJUHY2IERIQ1Agb3B0aW9ucywgYW4KPj4+ICAgIExMRFAg VExWLCBhIFVSTCBzdWZmaXggc3BlY2lmaWNhdGlvbiwgYW4gWC41MDkgY2VydGlmaWNhdGUg ZXh0ZW5zaW9uCj4+PiAgICBhbmQgYSBtZWFucyB0byBzaWduIGFuZCB2ZXJpZnkgdGhlIGRl c2NyaXB0aW9ucy4KPj4+Cj4+Pgo+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6Cj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1tdWQvCj4+Pgo+Pj4gVGhlcmUgYXJlIGFsc28gaHRt bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ogo+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLW11ZC0xNAo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1tdWQtMTQKPj4+Cj4+PiBB IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6Cj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vcHNhd2ctbXVk LTE0Cj4+Pgo+Pj4KPj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24KPj4+IHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcgPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uCj4+Pgo+Pj4gSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ogo+Pj4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8KPj4+Cj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4gT1BTQVdHIG1haWxpbmcgbGlzdAo+Pj4g T1BTQVdHQGlldGYub3JnCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2F3Zwo+Pj4KPj4KPgo+IE1haGVzaCBKZXRoYW5hbmRhbmkKPiBtamV0aGFuYW5k YW5pQGdtYWlsLmNvbSA8bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPgo+Cgo= --------------0ACDFEC61701A6FA66588B22 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 24.01.18 19:25, Mahesh Jethanandani= wrote:


On Jan 24, 2018, at 12:34 AM, Eliot Lear <lear@cisco.com> wrote:

This update primarily focuses on two elements= that were agreed during WGLC:

  • The update to the ACL model.=C2=A0 That up= date has taken longer than I would have liked, but it is now at least close to finished.=C2=A0 Note: the MUD mod= el does not yet match the published ACL model, but it does match the agreed changes that will be produced in the next ACL draft.
Does it?

Looking at the MUD example in Section 8 of the draft, I see that port/range is hanging off of ipv6 IP header. Per your comment, we moved the port under the =E2=80=98tcp=E2=80=99 header= in the ACL model.

Yeah, the example was blown.=C2=A0 Fixed in next release ;-)=C2=A0 Sa= me with protocol.=C2=A0 It ended up in l4 when it should be l3.


Also, the container "access-list-entries" had been renamed to =E2=80=9Caces=E2=80=9D in an earlier version of the draft. Med ha= s pointed out some other discrepancies, but in general, I would scrub the entire example one more time.

Cheers.

p.s. The updated ACL model tree looks like this now:

module: ietf-access-control-list
=C2=A0 =C2=A0 +--rw access-lists
=C2=A0=C2=A0 =C2=A0 =C2=A0 +--rw acl* [name]
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw name=C2=A0 =C2=A0 string
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw type? =C2=A0 acl-type
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw aces
=C2=A0=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw ace* [name]
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw matches
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw (l2)= ?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +-= -:(eth)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2= =A0 +--rw eth {match-on-eth}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw destination-mac-address?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 yang:mac-address
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw destination-mac-address-mask?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 yang:mac-address
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw source-mac-address?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 yang:mac-address
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw source-mac-address-mask?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 yang:mac-address
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw ethertype?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 eth:ethertype
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw (l3)= ?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +-= -:(ipv4)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 +--rw ipv4 {match-on-ipv4}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw dscp? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:dscp
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw ecn?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw length? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 uint16
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw ttl?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw protocol? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 uint8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw ihl?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw flags?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 bits
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw offset? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 uint16
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw identification? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 uint16
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw (destination-network)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 +--:(destination-ipv4-network)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw destination-ipv4-network?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv4-prefi= x
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw (source-network)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--:(source-ipv4-network)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw source-ipv4-network?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv4-= prefix
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +-= -:(ipv6)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2= =A0 +--rw ipv6 {match-on-ipv6}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw dscp? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:dscp
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw ecn?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw length? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint16
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw ttl?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw protocol? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw (destination-network)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 +--:(destination-ipv6-network)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw destination-ipv6-network?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv6-p= refix
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw (source-network)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 +--:(source-ipv6-network)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw source-ipv6-network?
=
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv6-p= refix
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw flow-label?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:ipv6-flow-label=
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw (l4)= ?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +-= -:(tcp)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 +--rw tcp {match-on-tcp}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw sequence-number?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw acknowledgement-number?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw data-offset?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw reserved?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 uint8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw flags?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 bits
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw window-size?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 uint16
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw urgent-pointer?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 uint16
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw options?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw (source-port)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 +--:(source-port-range-or-operator)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw source-port-range-or-operator
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw (port-range-or-operator)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(range)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw lower-po= rt
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0= =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw upper-po= rt
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(operator)<= /div>
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw ope= rator? =C2=A0 =C2=A0 operator
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw por= t
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw (destination-port)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--:(destination-port-range-or-operator)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw destination-port-range-or-opera
tor
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw (port-range-or-operator)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(range)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw low= er-port
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 = =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw upp= er-port
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(operator)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw = operator? =C2=A0 =C2=A0 operator
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw = port
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +-= -:(udp)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 +--rw udp {match-on-udp}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw length?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 uint16
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw (source-port)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 +--:(source-port-range-or-operator)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw source-port-range-or-operator
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw (port-range-or-operator)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(range)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw lower-po= rt
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2=A0= =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw upper-po= rt
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(operator)<= /div>
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw ope= rator? =C2=A0 =C2=A0 operator
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw por= t
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 +--rw (destination-port)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 +--:(destination-port-range-or-operator)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw destination-port-range-or-opera
tor
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw (port-range-or-operator)?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(range)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw low= er-port
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 = =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw upp= er-port
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--:(operator)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw = operator? =C2=A0 =C2=A0 operator
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw = port
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 inet:port-number
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +-= -:(icmp)
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 | =C2=A0 =C2= =A0 +--rw icmp {match-on-icmp}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw type? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u= int8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw code? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 u= int8
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 +--rw rest-of-header? =C2=A0 uint32
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw egre= ss-interface?=C2=A0 =C2=A0 if:interface-ref
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw ingr= ess-interface? =C2=A0 if:interface-ref
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw actions
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw forw= arding=C2=A0 =C2=A0 identityref
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw logg= ing?=C2=A0 =C2=A0 =C2=A0 identityref
=C2=A0=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro statistics {= acl-aggregate-stats}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matc= hed-packets? =C2=A0 yang:counter64
=C2=A0=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro matc= hed-octets?=C2=A0 =C2=A0 yang:counter64
=C2=A0=C2=A0 =C2=A0 =C2=A0 +--rw attachment-points
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interface* [interface-id] {interface-attachment}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interface-id=C2=A0 =C2= =A0 if:interface-ref
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw ingress
=
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--rw acl-sets
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 +--rw acl-= set* [name]
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= +--rw name
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= | =C2=A0 =C2=A0 =C2=A0 -> ../../../../../../acl/name
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= +--ro ace-statistics* [name] {interface-stats}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--ro name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 le= afref
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--ro matched-packets? =C2=A0 yang:counter64
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 +--ro matched-octets?=C2=A0 =C2=A0 yang:counter64
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw egress
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw acl-se= ts
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw= acl-set* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 +--rw name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 | =C2=A0 =C2=A0 =C2=A0 -> ../../../../../../acl/name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 +--ro ace-statistics* [name] {interface-stats}?
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +--ro name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= leafref
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +--ro matched-packets? =C2=A0 yang:counter64
=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 +--ro matched-octets?=C2=A0 =C2=A0 yang:counter64
  • Mark Nottingham had commented that it is not appropriate to have versioning information in the MUD-URL itself, but that it should be in the model.=C2=A0= We agreed on this change, as well as some wording around how HTTP is handled.

Based on these changes, I would like to move this document forward to IETF LC.

Eliot


On 24.01.18 09:29, internet-drafts@ietf.org wrote:
A New Internet-Draft is availab=
le from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working G=
roup WG of the IETF.

        Title           : Manufacturer Usage Description Specification
        Authors         : Eliot Lear
                          Ralph Droms
                          Dan Romascanu
	Filename        : draft-ietf-opsawg-mud-14.txt
	Pages           : 56
	Date            : 2018-01-24

Abstract:
   This memo specifies a component-based architecture for manufacturer
   usage descriptions (MUD).  The goal of MUD is to provide a means for
   Things to signal to the network what sort of access and network
   functionality they require to properly function.  The initial focus
   is on access control.  Later work can delve into other aspects.

   This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
   LLDP TLV, a URL suffix specification, an X.509 certificate extension
   and a means to sign and verify the descriptions.


The IETF datatracker status page for this draft is:
https://datatracker.i=
etf.org/doc/draft-ietf-opsawg-mud/

There are also htmlized versions available at:
https://tools.ietf.org/h=
tml/draft-ietf-opsawg-mud-14
https://datatr=
acker.ietf.org/doc/html/draft-ietf-opsawg-mud-14

A diff from the previous version is available at:
https://www.ietf=
=2Eorg/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-14


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

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

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/opsawg


Mahesh Jethanandani
mjethanandani@gmail.com


--------------0ACDFEC61701A6FA66588B22-- --u7FllT5JmIeJGjbfwxXo54sbKE1MFdrm8-- --nEDfx8d783iPWW7G7p30rHoV6MhKsQQWC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpo0AcACgkQh7ZrRtnS ejNE1Af+Ns7dVa8MiJ6PmPimSfbhdIIk8AjbJflEJbELADvSA8ZBT9E4AequLhhW HzAadJ2oDAF8LqaHxz3KLCKu2Zy7Xm3TV8lO02Z4u1+1nzV2pUS66/hfqTKkQj/8 fyyPrsvOMvUVNJkC4lrqOv+04es76g/vnXNrwpw1JIEO2m07T4q6wlR7xHym8cct aEWE+i43VJiCZIMfT1HauaLfaea8tuMx1WhsI5jpUU/Hdi4GnMVLuqW+JRKhgkJ3 4OGS3iampl8dIqwwrOYqyEBZEjzDUpmfHJ46Gibo28VoTtMwG9/O5wivRRkUswKf 2HBP9iz4ssKbdE8ZAqxOcv9C9LSveg== =J2ue -----END PGP SIGNATURE----- --nEDfx8d783iPWW7G7p30rHoV6MhKsQQWC-- From nobody Wed Jan 24 19:06:09 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E76C12D7EE; Wed, 24 Jan 2018 19:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 5jOOWjimqPFI; Wed, 24 Jan 2018 19:06:00 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 70D0D12D7EA; Wed, 24 Jan 2018 19:06:00 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 54C867F133C85; Thu, 25 Jan 2018 03:05:56 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 25 Jan 2018 03:05:57 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Thu, 25 Jan 2018 11:05:47 +0800 From: Duzongpeng To: Suresh Krishnan , The IESG CC: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , Tianran Zhou , "warren@kumari.net" , "opsawg-chairs@ietf.org" , Tianran Zhou , "opsawg@ietf.org" Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-11: (with DISCUSS) Thread-Index: AQHTlSL+SHQ9VAH/hE2yWXxzxBhY7KOD4zRQ Date: Thu, 25 Jan 2018 03:05:46 +0000 Message-ID: References: <151680555709.25672.9561537628046201312.idtracker@ietfa.amsl.com> In-Reply-To: <151680555709.25672.9561537628046201312.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] Suresh Krishnan's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-11: (with DISCUSS) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 03:06:02 -0000 SGksIFN1cmVzaCBLcmlzaG5hbg0KDQoJVGhhbmsgeW91IGZvciBwcm9wb3NlIHRoZSBwcm9ibGVt LiANCg0KCUkgaGF2ZSBjaGVja2VkIHRoZSBSRkNbNTg0NF0uIEl0IGRpZCBtZW50aW9uIHR3byBr aW5kcyBvZiBVRFAgRW5jYXBzdWxhdGlvbiBNb2RlcywgSVB2NC1VRFAgYW5kIElQdjQtVURQLVRM Vi4NCg0KCUhvd2V2ZXIsIGluIHRoZSBTZWN0aW9uIDQgIklQdjQgVHJhbnNwb3J0IFN1cHBvcnQi LCBpdCBzYWlkOg0KDQogICAgICAqICBJUHY0LVVEUC1UTFYgKHBheWxvYWQgcGFja2V0IGNhcnJp ZWQgaW4gYW4gSVB2NCBwYWNrZXQgd2l0aCBVRFANCiAgICAgICAgIGFuZCBUTFYgaGVhZGVyKSBh bmQgSVB2NC1HUkUgKFBheWxvYWQgcGFja2V0IGNhcnJpZWQgaW4gYW4gSVB2NA0KICAgICAgICAg cGFja2V0IHdpdGggR1JFIGhlYWRlcikuICBSZWZlciB0byBbR1JFS0VZXS4gIElmIHBheWxvYWQN CiAgICAgICAgIHByb3RlY3Rpb24gdXNpbmcgSVBzZWMgaXMgZW5hYmxlZCwgdGhlIEVTUCBoZWFk ZXIgZm9sbG93cyB0aGUNCiAgICAgICAgIG91dGVyIElQdjQgaGVhZGVyLCBhcyBleHBsYWluZWQg aW4gU2VjdGlvbiA0LjMuDQoNCglTbywgdGhlIElQdjQtVURQLVRMViBpcyBhY3R1YWxseSBkZWZp bmVkIGluIFtHUkVLRVldLCBpLmUuIFJGQyBbNTg0NV0gbmFtZWQNCglHZW5lcmljIFJvdXRpbmcg RW5jYXBzdWxhdGlvbiAoR1JFKSBLZXkgT3B0aW9uIGZvciBQcm94eSBNb2JpbGUgSVB2Ng0KDQoJ SW4gUkZDIFs1ODQ1XSwgRmlndXJlIDUgc2hvd3MgdGhlICJUTFYtSGVhZGVyIFVEUC1CYXNlZCBF bmNhcHN1bGF0aW9uIEhlYWRlciBPcmRlciIsDQoNCiAgICAgICAgIFtJUHY0IEhlYWRlcl0NCg0K ICAgICAgICAgW1VEUCBIZWFkZXJdDQoNCiAgICAgICAgIFtUTFYgSGVhZGVyXQ0KDQogICAgICAg ICBbR1JFIEhlYWRlcl0NCg0KICAgICAgICAgW1BheWxvYWQgLSBJUHY2IG9yIElQdjQgSGVhZGVy XQ0KDQogICAgICAgICBVcHBlciBMYXllciBwcm90b2NvbHMNCg0KICAgICAgICAgRmlndXJlIDU6 IFRMVi1IZWFkZXIgVURQLUJhc2VkIEVuY2Fwc3VsYXRpb24gSGVhZGVyIE9yZGVyDQoNCglIZW5j ZSwgaW4gbXkgdW5kZXJzdGFuZGluZywgVHVubmVsLVR5cGUgaXMgNCBtZWFucyB0aGUgSVB2NC1V RFAgRW5jYXBzdWxhdGlvbiBNb2RlLCBub3QgdGhlIElQdjQtVURQLVRMViBFbmNhcHN1bGF0aW9u IE1vZGUuDQoNCglUbyByZXNvbHZlIHRoZSBwcm9ibGVtLCBJIGNhbiB1cGRhdGUgdGhlIGRyYWZ0 IGlmIG5vIG9iamVjdGlvbnMuDQoJT2xkOg0KNDogUE1JUHY2LVVEUC4gIFRoaXMgcmVmZXJzIHRv IHRoZSBVRFAgdHVubmVsaW5nIGVuY2Fwc3VsYXRpb24NCiAgICAgICAgIGRlc2NyaWJlZCBpbiBb UkZDNTg0NF0uDQogICBOZXc6DQo0OiBQTUlQdjYtVURQLiAgVGhpcyByZWZlcnMgdG8gdGhlIElQ djQtVURQIHR1bm5lbGluZyBlbmNhcHN1bGF0aW9uDQogICAgICAgICBkZXNjcmliZWQgaW4gW1JG QzU4NDRdLg0KDQoJSWYgYW55IGZ1dHVyZSBwcm9ibGVtcywgcGxlYXNlIGNvbm5lY3QgbWUuIFRo YW5rcy4NCg0KQmVzdCBSZWdhcmRzDQpab25ncGVuZyBEdQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogU3VyZXNoIEtyaXNobmFuIFttYWlsdG86c3VyZXNoQGthbG9vbS5jb21d IA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI0LCAyMDE4IDEwOjUzIFBNDQpUbzogVGhlIElF U0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5u ZWxAaWV0Zi5vcmc7IFRpYW5yYW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbT47IHdhcnJl bkBrdW1hcmkubmV0OyBvcHNhd2ctY2hhaXJzQGlldGYub3JnOyBUaWFucmFuIFpob3UgPHpob3V0 aWFucmFuQGh1YXdlaS5jb20+OyBvcHNhd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFN1cmVzaCBLcmlz aG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwtMTE6 ICh3aXRoIERJU0NVU1MpDQoNClN1cmVzaCBLcmlzaG5hbiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93 aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVu bmVsLTExOiBEaXNjdXNzDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1Ympl Y3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVk IGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoN Cg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNT Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoqIFNlY3Rpb24gMy4yLg0KVGhpcyBzaG91bGQgYmUgZWFzeSB0 byByZXNvbHZlIGJ1dCBJIHdvdWxkIGxpa2UgdGhpcyB0byBiZSBkaXNhbWJpZ3VhdGVkIGJlZm9y ZQ0KcHVibGljYXRpb24uIFJGQzU4NDQgc3BlY2lmaWVzICp0d28qIGRpZmZlcmVudCBvcHRpb25z IGZvciBVRFAgZW5jYXBzdWxhdGlvbg0KSVB2NC1VRFAgYW5kIElQdjQtVURQLVRMVi4gUGxlYXNl IGNsYXJpZnkgd2hpY2ggb2YgdGhlc2UgbW9kZXMgaXMgaW50ZW5kZWQgd2hlbg0KdGhlIFR1bm5l bC1UeXBlIGlzIDQNCg0KNDogUE1JUHY2LVVEUC4gIFRoaXMgcmVmZXJzIHRvIHRoZSBVRFAgdHVu bmVsaW5nIGVuY2Fwc3VsYXRpb24NCiAgICAgICAgIGRlc2NyaWJlZCBpbiBbUkZDNTg0NF0uDQoN Cg0KDQoNCg== From nobody Wed Jan 24 22:53:43 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E62BB12D959; Wed, 24 Jan 2018 22:53:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, Tianran Zhou , warren@kumari.net, opsawg-chairs@ietf.org, zhoutianran@huawei.com, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151686322193.15916.7801462152516155573.idtracker@ietfa.amsl.com> Date: Wed, 24 Jan 2018 22:53:41 -0800 Archived-At: Subject: [OPSAWG] Adam Roach's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 06:53:42 -0000 Adam Roach has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have run out of time to fully review this document before the telechat, and it is sufficiently outside my area of expertise that I do not believe that the input I could provide is valuable enough to warrant deferring. However, I want to put a fine point on Ben's comment ("§1, 3rd paragraph after figure 1: We should avoid using lawful intercept as a justification for protocol mechanisms.") The IETF has a long-established policy in this area, summarized in RFC 2804 as: "The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards." If you can remove the mention of lawful intercept from this document and the justification for the described configuration still makes sense (as I believe it does), please do so. If you think that the removal of lawful intercept from this section tangibly changes the rationale for the design described in this document, please let me know, and I'll change my position to DISCUSS while we figure out what needs to happen. Thanks! From nobody Wed Jan 24 23:07:48 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61AD12E055; Wed, 24 Jan 2018 23:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 dvVr06-bdGJ6; Wed, 24 Jan 2018 23:07:39 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 44F8E12E042; Wed, 24 Jan 2018 23:07:39 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E315E445479A; Thu, 25 Jan 2018 07:07:35 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 25 Jan 2018 07:07:36 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Thu, 25 Jan 2018 15:07:26 +0800 From: Duzongpeng To: Ben Campbell , The IESG CC: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , Tianran Zhou , "warren@kumari.net" , "opsawg-chairs@ietf.org" , Tianran Zhou , "opsawg@ietf.org" Thread-Topic: Ben Campbell's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT) Thread-Index: AQHTlMSzoVllslzMbEi9+5EMV7DcFaOD8o+Q Date: Thu, 25 Jan 2018 07:07:26 +0000 Message-ID: References: <151676505752.24181.16152395977449682862.idtracker@ietfa.amsl.com> In-Reply-To: <151676505752.24181.16152395977449682862.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] Ben Campbell's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 07:07:42 -0000 SGksIEJlbiBDYW1wYmVsbA0KDQoJVGhhbmsgeW91IGZvciBwcm9wb3NpbmcgdGhlIHByb2JsZW1z Lg0KDQoJUGxlYXNlIHNlZSBpbmxpbmUuDQoNCglJZiBubyBvYmplY3Rpb25zLCBJIHdpbGwgdXBk YXRlIHRoZSBkcmFmdCBhY2NvcmRpbmdseS4NCg0KCUlmIGFueSBmdXR1cmUgcHJvYmxlbXMsIHBs ZWFzZSBjb25uZWN0IG1lLiBUaGFua3MuDQoNCkJlc3QgUmVnYXJkcw0KWm9uZ3BlbmcgRHUNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJl bkBub3N0cnVtLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjQsIDIwMTggMTE6Mzgg QU0NClRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLW9wc2F3Zy1j YXB3YXAtYWx0LXR1bm5lbEBpZXRmLm9yZzsgVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3 ZWkuY29tPjsgd2FycmVuQGt1bWFyaS5uZXQ7IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc7IFRpYW5y YW4gWmhvdSA8emhvdXRpYW5yYW5AaHVhd2VpLmNvbT47IG9wc2F3Z0BpZXRmLm9yZw0KU3ViamVj dDogQmVuIENhbXBiZWxsJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdh cC1hbHQtdHVubmVsLTExOiAod2l0aCBDT01NRU5UKQ0KDQpCZW4gQ2FtcGJlbGwgaGFzIGVudGVy ZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQpkcmFmdC1pZXRmLW9wc2F3Zy1j YXB3YXAtYWx0LXR1bm5lbC0xMTogTm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxl YXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBh ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj dXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVm ZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJp YS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1F TlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVubmVsLw0KDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KLTEsIDNyZCBwYXJhZ3JhcGggYWZ0 ZXIgZmlndXJlIDE6IFdlIHNob3VsZCBhdm9pZCB1c2luZyBsYXdmdWwgaW50ZXJjZXB0IGFzIGEg anVzdGlmaWNhdGlvbiBmb3IgcHJvdG9jb2wgbWVjaGFuaXNtcy4NCg0KW3pvbmdwZW5nXQ0KQWNj ZXB0LiBXZSBjYW4gZGVsZXRlIHRoZSB1bm5lY2Vzc2FyeSBleHBsYW5hdGlvbnMuDQoNCk9sZDoN CiAgIEZpZ3VyZSAxIGRlc2NyaWJlcyBhIHN5c3RlbSB3aXRoIExvY2FsIEJyaWRnaW5nLiAgVGhl IEFDIGlzIGluIGENCiAgIGNlbnRyYWxpemVkIGxvY2F0aW9uLiAgVGhlIGRhdGEgcGxhbmUgaXMg bG9jYWxseSBicmlkZ2VkIGJ5IHRoZSBXVFBzDQogICBsZWFkaW5nIHRvIGEgc3lzdGVtIHdpdGgg Y2VudHJhbGl6ZWQgY29udHJvbCBwbGFuZSB3aXRoIGRpc3RyaWJ1dGVkDQogICBkYXRhIHBsYW5l LiAgVGhpcyBzeXN0ZW0gaGFzIHR3byBiZW5lZml0czogMSkgcmVkdWNlcyB0aGUgc2NhbGUNCiAg IHJlcXVpcmVtZW50IG9uIGRhdGEgdHJhZmZpYyBoYW5kbGluZyBjYXBhYmlsaXR5IG9mIHRoZSBB QyBhbmQgMikNCiAgIGxlYWRzIHRvIG1vcmUgZWZmaWNpZW50L29wdGltYWwgcm91dGluZyBvZiBk YXRhIHRyYWZmaWMgd2hpbGUNCiAgIG1haW50YWluaW5nIGNlbnRyYWxpemVkIGNvbnRyb2wvbWFu YWdlbWVudC4NCk5ldzoNCiAgIEZpZ3VyZSAxIGRlc2NyaWJlcyBhIHN5c3RlbSB3aXRoIExvY2Fs IEJyaWRnaW5nLiAgVGhlIEFDIGlzIGluIGENCiAgIGNlbnRyYWxpemVkIGxvY2F0aW9uLiAgVGhl IGRhdGEgcGxhbmUgaXMgbG9jYWxseSBicmlkZ2VkIGJ5IHRoZSBXVFBzDQogICBsZWFkaW5nIHRv IGEgc3lzdGVtIHdpdGggY2VudHJhbGl6ZWQgY29udHJvbCBwbGFuZSB3aXRoIGRpc3RyaWJ1dGVk DQogICBkYXRhIHBsYW5lLiAgDQoNCldvdWxkIGl0IGJlIG9rID8NClsvem9uZ3BlbmddDQoNCg0K LTEuMzogU2VydmluZyBhcyBhbiAiYXJjaGl2YWwgcmVjb3JkIiBzZWVtcyBsaWtlIGFuIG9kZCB1 c2Ugb2YgImV4cGVyaW1lbnRhbCIuDQpUaGF0IHNvdW5kcyBtb3JlICJpbmZvcm1hdGlvbmFsIiB0 byBtZS4NCg0KW3pvbmdwZW5nXSANClRoZXJlIGhhdmUgYmVlbiBkaXNjdXNzaW9ucyBhYm91dCBp dCBhbW9uZyB0aGUgYXV0aG9ycywgY2hhaXJzLCBhbmQgdGhlIEFEcy4gDQpGaW5hbGx5LCB0aGUg IkV4cGVyaW1lbnRhbCIgdHlwZSBpcyBkZWNpZGVkLg0KSXQgYSBoYXJkIGRlY2lzaW9uIHRvIG1h a2Ugd2hldGhlciB0aGUgZG9jdW1lbnQgc2hvdWxkIGJlICJFeHBlcmltZW50YWwiLCAiSW5mb3Jt YXRpb25hbCIgb3IgIkhpc3RvcmljIi4NCg0KU29tZSBwZXJzb25hbGx5IHVuZGVyc3RhbmRpbmcg YWJvdXQgaXQgdG8gc2hhcmU6DQoNCkFjY29yZGluZyB0byBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMjAyNiNzZWN0aW9uLTQuMiwgdGhlIEluZm9ybWF0aW9uYWwgdHlwZSBtZWFuczoN CiAgIEFuICJJbmZvcm1hdGlvbmFsIiBzcGVjaWZpY2F0aW9uIGlzIHB1Ymxpc2hlZCBmb3IgdGhl IGdlbmVyYWwNCiAgIGluZm9ybWF0aW9uIG9mIHRoZSBJbnRlcm5ldCBjb21tdW5pdHksIGFuZCBk b2VzIG5vdCByZXByZXNlbnQgYW4NCiAgIEludGVybmV0IGNvbW11bml0eSBjb25zZW5zdXMgb3Ig cmVjb21tZW5kYXRpb24uICBUaGUgSW5mb3JtYXRpb25hbA0KICAgZGVzaWduYXRpb24gaXMgaW50 ZW5kZWQgdG8gcHJvdmlkZSBmb3IgdGhlIHRpbWVseSBwdWJsaWNhdGlvbiBvZiBhDQogICB2ZXJ5 IGJyb2FkIHJhbmdlIG9mIHJlc3BvbnNpYmxlIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzIGZyb20g bWFueQ0KICAgc291cmNlcywgc3ViamVjdCBvbmx5IHRvIGVkaXRvcmlhbCBjb25zaWRlcmF0aW9u cyBhbmQgdG8gdmVyaWZpY2F0aW9uDQogICB0aGF0IHRoZXJlIGhhcyBiZWVuIGFkZXF1YXRlIGNv b3JkaW5hdGlvbiB3aXRoIHRoZSBzdGFuZGFyZHMgcHJvY2Vzcw0KICAgKHNlZSBzZWN0aW9uIDQu Mi4zKS4NCg0KT3VyIGRvY3VtZW50IGlzIG5vdCBmb3IgYSB0aW1lbHkgcHVibGljYXRpb24gb2Yg bmV3IGluZm9ybWF0aW9uLg0KU28gaXQgaXMgbm90IHZlcnkgcHJvcGVyIGZvciB1cyB0byBkZWNs YXJlIGFuIEluZm9ybWF0aW9uYWwgdHlwZS4NCg0KQWxzbyBpbiBSRkMyMDI2LCBpdCBpcyBzYWlk IHRoYXQgIA0KICAgVGhlICJFeHBlcmltZW50YWwiIGRlc2lnbmF0aW9uIHR5cGljYWxseSBkZW5v dGVzIGEgc3BlY2lmaWNhdGlvbiB0aGF0DQogICBpcyBwYXJ0IG9mIHNvbWUgcmVzZWFyY2ggb3Ig ZGV2ZWxvcG1lbnQgZWZmb3J0LiAgU3VjaCBhIHNwZWNpZmljYXRpb24NCiAgIGlzIHB1Ymxpc2hl ZCBmb3IgdGhlIGdlbmVyYWwgaW5mb3JtYXRpb24gb2YgdGhlIEludGVybmV0IHRlY2huaWNhbA0K ICAgY29tbXVuaXR5IGFuZCBhcyBhbiBhcmNoaXZhbCByZWNvcmQgb2YgdGhlIHdvcmssIHN1Ympl Y3Qgb25seSB0bw0KICAgZWRpdG9yaWFsIGNvbnNpZGVyYXRpb25zIGFuZCB0byB2ZXJpZmljYXRp b24gdGhhdCB0aGVyZSBoYXMgYmVlbg0KICAgYWRlcXVhdGUgY29vcmRpbmF0aW9uIHdpdGggdGhl IHN0YW5kYXJkcyBwcm9jZXNzIChzZWUgYmVsb3cpLg0KDQpTbyB3ZSBjb25zaWRlciB0aGF0IHRo ZSAiRXhwZXJpbWVudGFsIiB0eXBlIGlzIG1vcmUgc3VpdGFibGUgaGVyZS4NClsvem9uZ3Blbmdd DQoNCi03OiBJIGFncmVlIHdpdGggS2F0aGxlZW4ncyBjb21tZW50cyBhYm91dCB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMuDQoNClt6b25ncGVuZ10gDQpXZSBoYXZlIGFuc3dlcmVkIHRoZSBj b21tZW50cyBmcm9tIEthdGhsZWVuLCBhbmQgbWFkZSBzb21lIGNoYW5nZXMgdG8gdGhlIHNlY3Rp b24gNy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLg0KWy96b25ncGVuZ10NCg0KRWRpdG9yaWFs IENvbW1lbnRzIGFuZCBOaXRzOg0KDQotIFRoZSBhYmJyZXZpYXRpb25zIHRoYXQgd2VyZSBleHBh bmRlZCBpbiB0aGUgYWJzdHJhY3Qgc2hvdWxkIGJlIGV4cGFuZGVkIGFnYWluIG9uIHRoZSBib2R5 Lg0KDQpbem9uZ3BlbmddDQpPbGQ6DQogICBTZXJ2aWNlIFByb3ZpZGVycyBhcmUgZGVwbG95aW5n IHZlcnkgbGFyZ2UgV2ktRmkgZGVwbG95bWVudHMgKHJhbmdpbmcNCiAgIGZyb20gaHVuZHJlZHMg b2YgdGhvdXNhbmRzIG9mIEFjY2VzcyBQb2ludHMsIEFQcyAocmVmZXJyZWQgdG8gYXMgV1RQcw0K ICAgaW4gQ0FQV0FQIHRlcm1pbm9sb2d5KSB0byBtaWxsaW9ucyBvZiBBUHMuDQpOZXc6DQoJU2Vy dmljZSBQcm92aWRlcnMgYXJlIGRlcGxveWluZyB2ZXJ5IGxhcmdlIFdpLUZpIG5ldHdvcmsgY29u dGFpbmluZyANCiAgIGh1bmRyZWRzIG9mIHRob3VzYW5kcyBvZiBBY2Nlc3MgUG9pbnRzIChBUHMp LCB3aGljaCBhcmUgcmVmZXJyZWQgdG8gYXMgDQoJV2lyZWxlc3MgVHJhbnNtaXNzaW9uIFBvaW50 cyAoV1RQcykgaW4gQ29udHJvbCBhbmQgUHJvdmlzaW9uaW5nIG9mIA0KCVdpcmVsZXNzIEFjY2Vz cyBQb2ludHMgKENBUFdBUCkgdGVybWlub2xvZ3kuDQoNCk9sZDoNCiAgIG8gIDgwMi4zIFR1bm5l bDogQWxsIGRhdGEgZnJhbWVzIGFyZSB0dW5uZWxlZCB0byB0aGUgQUMgaW4gODAyLjMNCiAgICAg IGZvcm1hdC4NCk5ldzoNCiAgIG8gIDgwMi4zIFR1bm5lbDogQWxsIGRhdGEgZnJhbWVzIGFyZSB0 dW5uZWxlZCB0byB0aGUgQWNjZXNzIENvbnRyb2xsZXIgDQogICAgICAoQUMpIGluIDgwMi4zIGZv cm1hdC4NCg0KT2xkOg0KICAgRmlndXJlIDIgc2hvd3MgYSBzeXN0ZW0gd2hlcmUgdGhlIHR1bm5l bCBtb2RlIGlzIGNvbmZpZ3VyZWQgdG8gdHVubmVsDQogICBkYXRhIGZyYW1lcyBiZXR3ZWVuIHRo ZSBXVFAgYW5kIHRoZSBBQyBlaXRoZXIgdXNpbmcgODAyLjMgVHVubmVsIG9yDQogICA4MDIuMTEg VHVubmVsIGNvbmZpZ3VyYXRpb25zLiAgT3BlcmF0b3JzIGRlcGxveSB0aGlzIGNvbmZpZ3VyYXRp b24NCiAgIHdoZW4gdGhleSBuZWVkIHRvIHR1bm5lbCB0aGUgdXNlciB0cmFmZmljLiAgVGhlIHR1 bm5lbGluZyByZXF1aXJlbWVudA0KICAgbWF5IGJlIGRyaXZlbiBieSB0aGUgbmVlZCB0byBhcHBs eSBwb2xpY3kgYXQgdGhlIEFDIG9yIGEgbGVnYWwNCiAgIHJlcXVpcmVtZW50IHRvIHN1cHBvcnQg bGF3ZnVsIGludGVyY2VwdCBvZiB1c2VyIHRyYWZmaWMuICBUaGlzDQogICByZXF1aXJlbWVudCBj b3VsZCBiZSBtZXQgaW4gdGhlIGxvY2FsbHkgYnJpZGdlZCBzeXN0ZW0gKEZpZ3VyZSAxKSBpZg0K ICAgdGhlIGFjY2VzcyByb3V0ZXIgaW1wbGVtZW50ZWQgdGhlIHJlcXVpcmVkIHBvbGljeS4NCk5l dzoNCglGaWd1cmUgMiBzaG93cyBhIHN5c3RlbSB3aGVyZSB0aGUgdHVubmVsIG1vZGUgaXMgY29u ZmlndXJlZCB0byB0dW5uZWwNCiAgIGRhdGEgZnJhbWVzIGJldHdlZW4gdGhlIFdUUCBhbmQgdGhl IEFDIGVpdGhlciB1c2luZyA4MDIuMyBUdW5uZWwgb3INCiAgIDgwMi4xMSBUdW5uZWwgY29uZmln dXJhdGlvbnMuICBPcGVyYXRvcnMgZGVwbG95IHRoaXMgY29uZmlndXJhdGlvbg0KICAgd2hlbiB0 aGV5IG5lZWQgdG8gdHVubmVsIHRoZSB1c2VyIHRyYWZmaWMuICBUaGUgdHVubmVsaW5nIHJlcXVp cmVtZW50DQogICBtYXkgYmUgZHJpdmVuIGJ5IHRoZSBuZWVkIHRvIGFwcGx5IHBvbGljeSBhdCB0 aGUgQUMgb3IgYSBsZWdhbA0KICAgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBsYXdmdWwgaW50ZXJj ZXB0IG9mIHVzZXIgdHJhZmZpYy4gIFRoaXMNCiAgIHJlcXVpcmVtZW50IGNvdWxkIGJlIG1ldCBp biB0aGUgbG9jYWxseSBicmlkZ2VkIHN5c3RlbSAoRmlndXJlIDEpIGlmDQogICB0aGUgQWNjZXNz IFJvdXRlciAoQVIpIGltcGxlbWVudGVkIHRoZSByZXF1aXJlZCBwb2xpY3kuDQoNClsvem9uZ3Bl bmddDQoNCi0xLCBwYXJhZ3JhcGggYWZ0ZXIgZmlndXJlIDE6IE1pc3NpbmcgYXJ0aWNsZSBiZWZv cmUgdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgIkNBUFdBUCIuDQoNClt6b25ncGVuZ10gDQpJIHRo aW5rIHRoZSBmaXJzdCBvbmUgb2YgdGhlIG1vZGlmaWNhdGlvbnMgYWJvdmUgY2FuIHNvbHZlIHRo ZSBwcm9ibGVtLiBJcyBpdCBPSz8NClsvem9uZ3BlbmddDQoNCi0xLjMsIGZpcnN0IHNlbnRlbmNl OiAiIFNlcnZpY2UgUHJvdmlkZXIncyAiIHNob3VsZCBlaXRoZXIgYmUgIiBTZXJ2aWNlIFByb3Zp ZGVycycgIiBvciAidGhlIFNlcnZpY2UgUHJvdmlkZXIncw0KDQoNClt6b25ncGVuZ10gDQpBZ3Jl ZS4gV2UgcHJlZmVyIHRoZSAiIFNlcnZpY2UgUHJvdmlkZXJzJyAiLiBUaGFua3MuDQpbL3pvbmdw ZW5nXQ0KDQoNCi0yLCAzcmQgcGFyYWdyYXBoIGFmdGVyIGZpZ3VyZSA1OiBNaXNzaW5nIGFydGlj bGUgYmVmb3JlIFdUUCAobXVsdGlwbGUgb2NjdXJyZW5jZXMpLg0KW3pvbmdwZW5nXSANCklmIHdl IGhhdmUgbW9kaWZpZWQgaXQgaW4gdGhlIHNlY3Rpb24gMSwgSSB0aGluayBpdCB3b3VsZCBiZSBv ayB0byB1c2UgdGhlIFdUUCBkaXJlY3RseSBoZXJlLiBDYW4geW91IGFncmVlPw0KWy96b25ncGVu Z10NCg0K From nobody Wed Jan 24 23:14:14 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEF812E042; Wed, 24 Jan 2018 23:14:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151686445360.15810.13640286159181880785@ietfa.amsl.com> Date: Wed, 24 Jan 2018 23:14:13 -0800 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-15.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 07:14:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Manufacturer Usage Description Specification Authors : Eliot Lear Ralph Droms Dan Romascanu Filename : draft-ietf-opsawg-mud-15.txt Pages : 59 Date : 2018-01-24 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix specification, an X.509 certificate extension and a means to sign and verify the descriptions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-15 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 24 23:16:06 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CB112E04A for ; Wed, 24 Jan 2018 23:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.489 X-Spam-Level: X-Spam-Status: No, score=-13.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 O8pgEVkP-Iyw for ; Wed, 24 Jan 2018 23:16:03 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F7312E042 for ; Wed, 24 Jan 2018 23:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3559; q=dns/txt; s=iport; t=1516864562; x=1518074162; h=subject:cc:references:from:message-id:date:mime-version: in-reply-to; bh=yg8tHyK+3HqsfT3gN9TOEoIl0W6g9tzM+sEgoRf7R+8=; b=jteTYp61CDMlXIwVN9D+F2v7JIMumawi5y88pQ1T12qZj+KqFKm3Z4Me ilTUktlxh/F7YOq65Cys4gSVxjB4Vd253wrjIdN+f/uz2+86vRK01qqa1 vhnoVrfhFERqwkQV8ZujQltIlR/0U5Uj6dcKbCINK593ruRMCE4wEtR8i s=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQBXg2la/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodBgPg12LGI9PJ5laBwMYC4RJTwImhTMVAQEBAQEBAQECayi?= =?us-ascii?q?FGwkBAQQBASFLCxALEgYqAgInIg4TBgIBAYVvhEIQtRGCJ4pgAQEBAQEBBAEBA?= =?us-ascii?q?QEBFA+EUYV9DIJ5gy8BAQIBAReEbRSCUQWKb5kahF+CMYEFjU2CG2eFOINxh3q?= =?us-ascii?q?NWol+gTw1I4FQMxoIGxUZJIEECIEeCYRPQDeOSwEBBQ?= X-IronPort-AV: E=Sophos; i="5.46,409,1511827200"; d="asc'?scan'208"; a="1639381" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 07:16:00 +0000 Received: from [10.61.84.169] (ams3-vpn-dhcp5290.cisco.com [10.61.84.169]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0P7G0ia029676 for ; Thu, 25 Jan 2018 07:16:00 GMT Cc: opsawg@ietf.org References: <151686445360.15810.13640286159181880785@ietfa.amsl.com> From: Eliot Lear Message-ID: Date: Thu, 25 Jan 2018 08:15:59 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <151686445360.15810.13640286159181880785@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jJcQRDpgP89MfXWEoXoLIm4CDGmXeRf9a" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-15.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 07:16:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jJcQRDpgP89MfXWEoXoLIm4CDGmXeRf9a Content-Type: multipart/mixed; boundary="accMCe8rABJ2GkSiaxTU85EUlw4gpkGgl"; protected-headers="v1" From: Eliot Lear Cc: opsawg@ietf.org Message-ID: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-15.txt References: <151686445360.15810.13640286159181880785@ietfa.amsl.com> In-Reply-To: <151686445360.15810.13640286159181880785@ietfa.amsl.com> --accMCe8rABJ2GkSiaxTU85EUlw4gpkGgl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Ok, here are the edits we discussed.=C2=A0 Also, mudmaker.org has been updated to reflect these changes. Eliot On 25.01.18 08:14, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Operations and Management Area Working= Group WG of the IETF. > > Title : Manufacturer Usage Description Specification > Authors : Eliot Lear > Ralph Droms > Dan Romascanu > Filename : draft-ietf-opsawg-mud-15.txt > Pages : 59 > Date : 2018-01-24 > > Abstract: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for= > Things to signal to the network what sort of access and network > functionality they require to properly function. The initial focus > is on access control. Later work can delve into other aspects. > > This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an= > LLDP TLV, a URL suffix specification, an X.509 certificate extension= > and a means to sign and verify the descriptions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-15 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-15 > > > Please note that it may take a couple of minutes from the time of submi= ssion > 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/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --accMCe8rABJ2GkSiaxTU85EUlw4gpkGgl-- --jJcQRDpgP89MfXWEoXoLIm4CDGmXeRf9a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpphC8ACgkQh7ZrRtnS ejOd5Af/ZrTe7AqKQmjTLeq4Rj3RDvEoOoXeIPR0k3hToyTgeesgos5jVUor9S5H g0QkWwlfMqFqwcYrGJNgYrxrJH3lv4RA1c+j7WBntaRQAJFFiS4XOzKxGgL+m2MW AlNZU7UAEiLQPgID10ZdfKeTtSkCh80MPVl9i+J/lHYOYVeNW+yRLoJgVOfvcT+z bPFZWcdznaF+Gq84cd7Wu6hw+T2dUo0/Y/bs5g9Z+O8Kt5tU/fBnMhuMNSzDiyaa 0VvU//KPDwMGLmcq9/PY5XBgFXhpT9Uj5a/9MGJbMna6m2iqeB6TW9eC5hzfJDn7 qtcs3nkSaXp5Ugqc5llMn/wAiwOhaA== =2Mrc -----END PGP SIGNATURE----- --jJcQRDpgP89MfXWEoXoLIm4CDGmXeRf9a-- From nobody Thu Jan 25 00:54:53 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EBA12D943; Thu, 25 Jan 2018 00:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 U-D8ttHGf9wm; Thu, 25 Jan 2018 00:54:45 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 249A012D868; Thu, 25 Jan 2018 00:54:45 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7D226A695599D; Thu, 25 Jan 2018 08:54:41 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 25 Jan 2018 08:54:42 +0000 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Thu, 25 Jan 2018 16:54:30 +0800 From: Duzongpeng To: Adam Roach , The IESG CC: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" , Tianran Zhou , "warren@kumari.net" , "opsawg-chairs@ietf.org" , Tianran Zhou , "opsawg@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT) Thread-Index: AQHTlalDH2rOASfYzUyGJ7cxrWLgk6OER4HA Date: Thu, 25 Jan 2018 08:54:30 +0000 Message-ID: References: <151686322193.15916.7801462152516155573.idtracker@ietfa.amsl.com> In-Reply-To: <151686322193.15916.7801462152516155573.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSAWG] Adam Roach's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-11: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 08:54:48 -0000 SGksIEFkYW0gUm9hY2ggYW5kIEJlbiBDYW1wYmVsbA0KDQoJVGhhbmsgeW91IGZvciBwcm9wb3Np bmcgdGhlIHByb2JsZW1zLg0KDQoJQWJvdXQgdGhlIGxhd2Z1bCBpbnRlcmNlcHQsIEkgaGF2ZSBt YWRlIGEgd3JvbmcgY29ycmVjdGlvbi4NCg0KCVdlIGNhbiBkZWxldGUgaXQgaW5zdGVhZCBvZiBt eSBjb3JyZWN0aW9uIGluIHRoZSBsYXN0IGVtYWlsLg0KDQpPbGQ6DQogICBUaGUgdHVubmVsaW5n IHJlcXVpcmVtZW50DQogICBtYXkgYmUgZHJpdmVuIGJ5IHRoZSBuZWVkIHRvIGFwcGx5IHBvbGlj eSBhdCB0aGUgQUMgb3IgYSBsZWdhbA0KICAgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBsYXdmdWwg aW50ZXJjZXB0IG9mIHVzZXIgdHJhZmZpYy4NCk5ldzoNCiAgIFRoZSB0dW5uZWxpbmcgcmVxdWly ZW1lbnQNCiAgIG1heSBiZSBkcml2ZW4gYnkgdGhlIG5lZWQgdG8gYXBwbHkgcG9saWN5IGF0IHRo ZSBBQy4NCg0KDQoJQW5kIEkgZG8gbm90IHRoaW5rIHJlbW92ZSBpdCBjYXVzZSBhbnkgcHJvYmxl bSB0byB0aGUgZHJhZnQuDQoNCglJZiBubyBvYmplY3Rpb25zLCBJIHdpbGwgdXBkYXRlIHRoZSBk cmFmdCBhY2NvcmRpbmdseS4NCg0KCUlmIGFueSBmdXR1cmUgcHJvYmxlbXMsIHBsZWFzZSBjb25u ZWN0IG1lLiBUaGFua3MuDQoNCkJlc3QgUmVnYXJkcw0KWm9uZ3BlbmcgRHUNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0u Y29tXSANClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI1LCAyMDE4IDI6NTQgUE0NClRvOiBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0LXR1 bm5lbEBpZXRmLm9yZzsgVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPjsgd2Fy cmVuQGt1bWFyaS5uZXQ7IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc7IFRpYW5yYW4gWmhvdSA8emhv dXRpYW5yYW5AaHVhd2VpLmNvbT47IG9wc2F3Z0BpZXRmLm9yZw0KU3ViamVjdDogQWRhbSBSb2Fj aCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtYWx0LXR1bm5lbC0x MTogKHdpdGggQ09NTUVOVCkNCg0KQWRhbSBSb2FjaCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1hbHQtdHVubmVs LTExOiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoN Cg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1vcHNhd2ctY2Fwd2FwLWFsdC10dW5uZWwvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5U Og0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpJIGhhdmUgcnVuIG91dCBvZiB0aW1lIHRvIGZ1bGx5IHJldmll dyB0aGlzIGRvY3VtZW50IGJlZm9yZSB0aGUgdGVsZWNoYXQsIGFuZCBpdCBpcyBzdWZmaWNpZW50 bHkgb3V0c2lkZSBteSBhcmVhIG9mIGV4cGVydGlzZSB0aGF0IEkgZG8gbm90IGJlbGlldmUgdGhh dCB0aGUgaW5wdXQgSSBjb3VsZCBwcm92aWRlIGlzIHZhbHVhYmxlIGVub3VnaCB0byB3YXJyYW50 IGRlZmVycmluZy4NCg0KSG93ZXZlciwgSSB3YW50IHRvIHB1dCBhIGZpbmUgcG9pbnQgb24gQmVu J3MgY29tbWVudCAoIsKnMSwgM3JkIHBhcmFncmFwaCBhZnRlciBmaWd1cmUgMTogV2Ugc2hvdWxk IGF2b2lkIHVzaW5nIGxhd2Z1bCBpbnRlcmNlcHQgYXMgYSBqdXN0aWZpY2F0aW9uIGZvciBwcm90 b2NvbCBtZWNoYW5pc21zLiIpICBUaGUgSUVURiBoYXMgYSBsb25nLWVzdGFibGlzaGVkIHBvbGlj eSBpbiB0aGlzIGFyZWEsIHN1bW1hcml6ZWQgaW4gUkZDIDI4MDQgYXM6ICJUaGUgSUVURiBoYXMg ZGVjaWRlZCBub3QgdG8gY29uc2lkZXIgcmVxdWlyZW1lbnRzIGZvciB3aXJldGFwcGluZyBhcyBw YXJ0IG9mIHRoZSBwcm9jZXNzIGZvciBjcmVhdGluZyBhbmQgbWFpbnRhaW5pbmcgSUVURiBzdGFu ZGFyZHMuIg0KDQpJZiB5b3UgY2FuIHJlbW92ZSB0aGUgbWVudGlvbiBvZiBsYXdmdWwgaW50ZXJj ZXB0IGZyb20gdGhpcyBkb2N1bWVudCBhbmQgdGhlIGp1c3RpZmljYXRpb24gZm9yIHRoZSBkZXNj cmliZWQgY29uZmlndXJhdGlvbiBzdGlsbCBtYWtlcyBzZW5zZSAoYXMgSSBiZWxpZXZlIGl0IGRv ZXMpLCBwbGVhc2UgZG8gc28uIElmIHlvdSB0aGluayB0aGF0IHRoZSByZW1vdmFsIG9mIGxhd2Z1 bCBpbnRlcmNlcHQgZnJvbSB0aGlzIHNlY3Rpb24gdGFuZ2libHkgY2hhbmdlcyB0aGUgcmF0aW9u YWxlIGZvciB0aGUgZGVzaWduIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LCBwbGVhc2UgbGV0 IG1lIGtub3csIGFuZCBJJ2xsIGNoYW5nZSBteSBwb3NpdGlvbiB0byBESVNDVVNTIHdoaWxlIHdl IGZpZ3VyZSBvdXQgd2hhdCBuZWVkcyB0byBoYXBwZW4uDQoNClRoYW5rcyENCg0KDQo= From nobody Fri Jan 26 02:05:07 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0922A12E04A for ; Fri, 26 Jan 2018 02:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, 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 UF6MKTWGmtYt for ; Fri, 26 Jan 2018 02:05:00 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A31112D849 for ; Fri, 26 Jan 2018 02:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=902; q=dns/txt; s=iport; t=1516961099; x=1518170699; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=RDensZDfaLPsHtGnfCXMfmGetsidjZ0BubVs4SSMfSk=; b=PP6Kx5SmfAZEdgMa1KqjQvJuA+30jk21PDHT5QeYfwHm3pWUMWqqPQGc hwZdGOu3g5F84XRsFt+lHHhJToMUqfusmiJ8fOWhBEbU/BjQ4BUVtpG6m MSEjVtH/k2Lyq0Uo7gU25hI1p1Tsc3WvS8oEq4bc9gmpSa1VZ269WygNL Y=; X-IronPort-AV: E=Sophos;i="5.46,415,1511827200"; d="scan'208";a="1662297" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 10:04:57 +0000 Received: from [10.61.167.172] ([10.61.167.172]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0QA4vxA013717; Fri, 26 Jan 2018 10:04:57 GMT To: Eliot Lear , mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> From: Joe Clarke Organization: Cisco Message-ID: Date: Fri, 26 Jan 2018 05:05:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 10:05:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/24/18 06:24, Eliot Lear wrote: > > > On 24.01.18 12:20, Joe Clarke wrote: >> Is there a reason why they wouldn't be mandatory? Seems like >> these data would be readily available and having them would make >> a number of use case cases possible. > > Yes, there is. If the MUD-URL is "burned in" via 802.1AR and the > software can be updated, then one oughtn't provide software > information for the simple reason that it would be most likely > wrong. Hardware info? Sure. Software when using DHCP or LLDP? > Sure. But otherwise no. Fair, but why not mandatory then for device-type, model-number, and manuf-name? Joe -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWmr9TwAKCRBvaI+K/hTP h4UhAJ9C7cFxWuDxndYipyAFnunsWUrllQCfRhK/8Gnk4t7YMM26hCsxUCt3rVY= =eEtq -----END PGP SIGNATURE----- From nobody Fri Jan 26 02:59:10 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916B112DA00 for ; Fri, 26 Jan 2018 02:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, 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 Co9KGAGN_IMx for ; Fri, 26 Jan 2018 02:59:06 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B9312D779 for ; Fri, 26 Jan 2018 02:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2549; q=dns/txt; s=iport; t=1516964346; x=1518173946; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=smWSH0D/Qnj71i8tShr7uauBFrSGOC0Ua/hdkzZWS3E=; b=TQqC0/Nw2Opd2tLwRzPgXbabyeWCrswCPB/agUwv6T+Qs1ymShw3UyU+ 1RVwGOE+OJdvl21Ujo4W8WcENILc1V5DfiP03jREKhDugvfl98i2UBsYN m78yV7sMPARTPSr1JBczcLZAQe/sRbKHS82UTCcK8J2t5ofuGAnBWCNjw I=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos; i="5.46,415,1511827200"; d="asc'?scan'208"; a="1610682" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 10:59:04 +0000 Received: from [10.61.84.169] (ams3-vpn-dhcp5290.cisco.com [10.61.84.169]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0QAx3cR032569; Fri, 26 Jan 2018 10:59:04 GMT To: Joe Clarke , mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> From: Eliot Lear Message-ID: <1ad938c9-9c07-4d22-f324-54594454db8b@cisco.com> Date: Fri, 26 Jan 2018 11:59:03 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D6IFdMv2eetNnqVf8Qj40j3oMOP50lsVK" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 10:59:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D6IFdMv2eetNnqVf8Qj40j3oMOP50lsVK Content-Type: multipart/mixed; boundary="xkHfqaTTawbFBgnnbNoIN3CNQAcXUtaQf"; protected-headers="v1" From: Eliot Lear To: Joe Clarke , mohamed.boucadair@orange.com Cc: Mahesh Jethanandani , "Saswat Praharaj (saspraha)" , "opsawg@ietf.org" , Mark Nottingham Message-ID: <1ad938c9-9c07-4d22-f324-54594454db8b@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> In-Reply-To: --xkHfqaTTawbFBgnnbNoIN3CNQAcXUtaQf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 26.01.18 11:05, Joe Clarke wrote: > > Fair, but why not mandatory then for device-type, model-number, and > manuf-name? I think the argument should be the other way around.=C2=A0 Why should the= y be mandatory?=C2=A0 Making things mandatory makes them more fragile.=C2=A0 T= o me there really has to be value in adding that fragility. Also, I've been persuaded to drop device-type because nobody can easily define such a thing, and it requires serious consideration elsewhere (like in t2trg). Eliot --xkHfqaTTawbFBgnnbNoIN3CNQAcXUtaQf-- --D6IFdMv2eetNnqVf8Qj40j3oMOP50lsVK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlprCfcACgkQh7ZrRtnS ejO4HwgAzclFX0CQuWlVBPvvrEMdaFdZO2yFfy6UmSJiiKusgQjh+4sQz/enAUyj yD1cOoEiZ/1Yq3GCuaAAaan1mJ3XV4PQvmu/EEADKLp+NkgiuIuLHk9BgwVvZgl4 R1dQN6Py3kroxdf/Pb25roT1p4JdN1YbcIxKO5ydpD3xprHeCvkCCFLuoY8ijuXg vYrXmgRk1vSvEBgiueCgXz6vsg3nGIU1Ocf/LyHSO38EoOgT2jGnHvWK7h4vOu9e WOGazyTugdwyo6YiSm6psc/XtTf1Ex5zpe+g6SKq3LIbErYPQNAu+61myIjcmJlk 7fBYXkRftYBSj5gby2UWfOfeaJCowg== =pbJv -----END PGP SIGNATURE----- --D6IFdMv2eetNnqVf8Qj40j3oMOP50lsVK-- From nobody Fri Jan 26 14:12:16 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA43128954 for ; Fri, 26 Jan 2018 14:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 pR4Tc7ssVyDH for ; Fri, 26 Jan 2018 14:12:13 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727C2128896 for ; Fri, 26 Jan 2018 14:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6168; q=dns/txt; s=iport; t=1517004732; x=1518214332; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=7T3eoxjjzuDQ9wPLoS1WhG17G5z3hgsT5FUPlfXz2lY=; b=fehWUOiSh0IkleGQD7U+WXXLrPNN8CTWPhRtOg+MDYUXw4qfLu6pwNEz YtITafU9kkR+g/xMbarbUDJl6m78xqTAlQVsXbU9JuG5me8z6Cfs0Bd0u rejosmX+iP9Iwfuq3FY07GgwAiSMfSjseJF7MApN+UdKApiuQf2yGjbbQ o=; X-Files: signature.asc : 488 X-IronPort-AV: E=Sophos;i="5.46,418,1511827200"; d="asc'?scan'208,217";a="1625640" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 22:12:10 +0000 Received: from [10.61.84.92] (ams3-vpn-dhcp5213.cisco.com [10.61.84.92]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w0QMC9In000342; Fri, 26 Jan 2018 22:12:09 GMT To: "Saswat Praharaj (saspraha)" , "Joe Clarke (jclarke)" , "mohamed.boucadair@orange.com" Cc: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> From: Eliot Lear Message-ID: <642adcf3-42e8-da68-34b0-27447ed10292@cisco.com> Date: Fri, 26 Jan 2018 23:12:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U7U6R36gtqO36AW3fjLrEU4HWqBnQ1fEb" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 22:12:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U7U6R36gtqO36AW3fjLrEU4HWqBnQ1fEb Content-Type: multipart/mixed; boundary="srTsmFD5asbQm9WuDPq4U80GQivMLBT1h"; protected-headers="v1" From: Eliot Lear To: "Saswat Praharaj (saspraha)" , "Joe Clarke (jclarke)" , "mohamed.boucadair@orange.com" Cc: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham Message-ID: <642adcf3-42e8-da68-34b0-27447ed10292@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> In-Reply-To: <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> --srTsmFD5asbQm9WuDPq4U80GQivMLBT1h Content-Type: multipart/alternative; boundary="------------22159D792ABD1E2B68F379ED" Content-Language: en-US This is a multi-part message in MIME format. --------------22159D792ABD1E2B68F379ED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Saswat, On 26.01.18 20:17, Saswat Praharaj (saspraha) wrote: > Hi Eliot, > > Adding device information (manufacture/device-type etc.) = in MUD file provides visibility in network, in addition to policy. > If visibility is not that important for MUD, we could have it as optional parameters. > > IMHO, it=E2=80=99s important because MUD will not be the = only policy for the device and if admin has to apply other policies, he/she needs to know what the device is. > Device manufacturer is the most reliable source to provide information about the device. > > Based on your comment > > > Yes, there is. If the MUD-URL is "burned in" via 802.1AR and the > > software can be updated, then one oughtn't provide software > > information for the simple reason that it would be most likely > > wrong. Hardware info? Sure. Software when using DHCP or LLDP? > > Sure. But otherwise no. > > For this, it=E2=80=99s important that we = have version number in the MUD URL =E2=80=93 Either as v1, v2 or itself. > Device description and access policy may change when software is upgraded. A newly released device with a different software version may have different access pattern compared to older version of the device= =2E That's not quite what the version did, and hardcoding the MUD-URL is the fundamental issue.=C2=A0 Remember, it's a GOOD thing to hardcode that URL= into a cert because then it is the manufacturer making the assertion and not the device itself.=C2=A0 But there are some attendant drawbacks, whic= h is why we have the other mechanisms. Eliot --------------22159D792ABD1E2B68F379ED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Saswat,

On 26.01.18 20:17, Saswat Praharaj (saspraha) wrote:
&= gt; Hi Eliot, > > Adding device information (manufacture/device-type etc.) in MUD file= provides visibility in network, in addition to policy. > If visibility is not that important for MUD, we could have it as opt= ional parameters.=20 > > IMHO, it=E2=80=99s important because MUD will not be the only policy= for the device and if admin has to apply other policies, he/she needs to= know what the device is. > Device manufacturer is the most reliable source to provide informati= on about the device. > > Based on your comment=20 > > > Yes, there is. If the MUD-URL is "burned in" via 802.1AR a= nd the=20 > > software can be updated, then one oughtn't provide software= > > information for the simple reason that it would be most lik= ely > > wrong. Hardware info? Sure. Software when using DHCP or = LLDP? > > Sure. But otherwise no. > > For this, it=E2=80=99s important that we have version number in the = MUD URL =E2=80=93 Either as v1, v2 or <software version> itself.=20 > Device description and access policy may change when software is upg= raded. A newly released device with a different software version may have= different access pattern compared to older version of the device.
That's not quite what the version did, and hardcoding the MUD-URL is the fundamental issue.=C2=A0 Remember, it's a GOOD thing to hardcode = that URL into a cert because then it is the manufacturer making the assertion and not the device itself.=C2=A0 But there are some attenda= nt drawbacks, which is why we have the other mechanisms.

Eliot

--------------22159D792ABD1E2B68F379ED-- --srTsmFD5asbQm9WuDPq4U80GQivMLBT1h-- --U7U6R36gtqO36AW3fjLrEU4HWqBnQ1fEb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlprp7gACgkQh7ZrRtnS ejNCpQgAuuZpYAmBUySZJDFJlPj0wfmbtqwAyirhjs7EanMWXeuaW+bhxl9FeMAn 0s9xH3PKmhW3hY92Devt4E5NN4VrLqRB1tJS1uMJGV2C0U89JiATo37idKnf3tSS cYaoIiDihS0rTmbyFNhOKZmvW4byGWcr7KVIWJqc57v2Om8xU27lkJ2/yGg8V0aV Nl4GjMDcWdc9hbf5Yefpy7BEsaEzvCLdcEorJifK9etuUPwYSocw6pY5hUElLe8t BmGk/NIVk3dcR87x6ImFcLMHugURoXD6e4DU225rcsq/zD7HSv+T1wFH25pN2joe lSiPCcP5aOjDi9vAfR+5mRVqJRqTGA== =kCZT -----END PGP SIGNATURE----- --U7U6R36gtqO36AW3fjLrEU4HWqBnQ1fEb-- From nobody Fri Jan 26 17:32:16 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D941112D838; Fri, 26 Jan 2018 17:32:10 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26B512D832; Fri, 26 Jan 2018 17:32:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 i2q1s579ogp7; Fri, 26 Jan 2018 17:32:08 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 AC1A312D838; Fri, 26 Jan 2018 17:32:08 -0800 (PST) X-AuditID: c618062d-8d7ff70000004288-13-5a6bd6970bc6 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 0E.F7.17032.796DB6A5; Sat, 27 Jan 2018 02:32:07 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0352.000; Fri, 26 Jan 2018 20:32:07 -0500 From: Meral Shirazipour To: "draft-mm-wg-effect-encrypt.all@ietf.org" , "gen-art@ietf.org" Thread-Topic: Gen-ART Telechat Call review of draft-mm-wg-effect-encrypt-15 Thread-Index: AdOXDUs/t32TgyX1TZWbC3M2qbO3aA== Date: Sat, 27 Jan 2018 01:32:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_ABCAA4EF18F17B4FB619EA93DEF7939A4F6938E4eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyuXSPn+70a9lRBtOvW1ksnT2N3eLqq88s DkweS5b8ZApgjOKySUnNySxLLdK3S+DKWD5xNUvBQ52K5esa2BsYP6l3MXJySAiYSKy+0sDc xcjFISRwhFGiubmDCcJZzihxceNZRpAqNgELie2/n7OCJEQEmhgljhw9DpYQFnCT2PdtL5DN AZTwlvixvxAkLCKgJ3G84zk7iM0ioCpxa+NiJhCbV8BX4nFXF1gro4CYxPdTa8DizALiEree zGeCuEhAYsme88wQtqjEy8f/WCFsJYlJS8+xQtTnSyw42csIMVNQ4uTMJywTGAVnIRk1C0nZ LCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxQU5uupHBJkZgsB+TYNPdwXh/ uuchRgEORiUe3t/7sqOEWBPLiitzDzFKcDArifCacQKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ 857x5I0SEkhPLEnNTk0tSC2CyTJxcEo1MDKIiZxLlbh8PPxfbKf14dYzWsG6G46InPJOOreY rdXU9KvNNa+OCA1j+38Hr9mLrH7b31Uru0Cyv+/pAaeEpClPtAWtF3uqym31ln9eJy/zI3n/ UYu/VxmPuk/Mtz5arHk+PewY04F5i190qNadOXVyb73VqoX7ylepiz1sVJv2wlfzecSJN0os xRmJhlrMRcWJAAVV2QFyAgAA Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180127013210.D941112D838@ietfa.amsl.com> Resent-Date: Fri, 26 Jan 2018 17:32:10 -0800 (PST) Archived-At: Subject: [OPSAWG] Gen-ART Telechat Call review of draft-mm-wg-effect-encrypt-15 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2018 01:32:11 -0000 --_000_ABCAA4EF18F17B4FB619EA93DEF7939A4F6938E4eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 t= he 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-mm-wg-effect-encrypt-15 Reviewer: Meral Shirazipour Review Date: 2018-01-26 IETF LC End Date: 2017-12-04 IESG Telechat date: 2018-02-08 Summary: This draft is ready to be published as Informational RFC . Major issues: Minor issues: Nits/editorial comments: -few occurrences: "pervassive"--->"pervasive" -[Page 6], Sec 1.1, "were were built "---->"were built " -[Page 12] , "scaleability"--->"scalability" x2 -[Page 16] , "unaccessible"--->"inaccessible" -[Page 29] ,"depening"--->"depending", "permited"--->"permitted " -[Page 31], "rasises"---->"raises", "encyption"---->"encryption", "visibilt= y"--->"visibility" Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com --_000_ABCAA4EF18F17B4FB619EA93DEF7939A4F6938E4eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART reviewer for this draft. T= he General Area Review Team (Gen-ART) reviews all IETF documents being proc= essed by the IESG for the IETF Chair. Please wait for direction from your d= ocument shepherd or AD before posting a new version of the draft.

 

For more information, please see the FAQ at <http= ://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

 

Document: draft-mm-wg-effect-en= crypt-15

Reviewer: Meral Shirazipour

Review Date: 2018-01-26

IETF LC End Date: 2017-12-04

IESG Telechat date: 2018-02-08

 

Summary: This draft is ready to be published as Info= rmational  RFC .

 

Major issues:

Minor issues:

Nits/editorial comments:

-few occurrences: "pervassive"--->"= ;pervasive"

-[Page 6], Sec 1.1, "were were built "----= >"were built "

-[Page 12] , "scaleability"--->"sc= alability" x2

-[Page 16] , "unaccessible"--->"in= accessible"

-[Page 29] ,"depening"--->"dependi= ng", "permited"--->"permitted "

-[Page 31], "rasises"= ---->"raises", "encyption"---->"encryption&q= uot;, "visibilty"--->"visibility"<= /p>

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson Research

www.ericsson.com

--_000_ABCAA4EF18F17B4FB619EA93DEF7939A4F6938E4eusaamb107erics_-- From nobody Sat Jan 27 05:48:08 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EA3CB1275C5; Sat, 27 Jan 2018 05:48:01 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DF912DA07; Sat, 27 Jan 2018 05:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 N2xoTBNFSbr2; Sat, 27 Jan 2018 05:47:59 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 5B1021275C5; Sat, 27 Jan 2018 05:47:59 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w0RDlYCq031698; Sat, 27 Jan 2018 08:47:56 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049463.ppops.net-00191d01. with ESMTP id 2frppnthcu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Jan 2018 08:47:55 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id w0RDltYQ125243; Sat, 27 Jan 2018 07:47:55 -0600 Received: from dalint01.pst.cso.att.com (dalint01.pst.cso.att.com [135.31.133.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id w0RDlplJ125226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 27 Jan 2018 07:47:51 -0600 Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [135.46.181.156]) by dalint01.pst.cso.att.com (RSA Interceptor); Sat, 27 Jan 2018 13:47:33 GMT Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [127.0.0.1]) by zlp30497.vci.att.com (Service) with ESMTP id 42BF8400039C; Sat, 27 Jan 2018 13:47:33 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30497.vci.att.com (Service) with ESMTP id 243ED40006D8; Sat, 27 Jan 2018 13:47:33 +0000 (GMT) Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id w0RDlVC4021385; Sat, 27 Jan 2018 07:47:33 -0600 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id w0RDlPnD021048; Sat, 27 Jan 2018 07:47:25 -0600 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id CBE56F0B32; Sat, 27 Jan 2018 08:47:24 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0361.001; Sat, 27 Jan 2018 08:47:24 -0500 From: "MORTON, ALFRED C (AL)" To: Meral Shirazipour , "draft-mm-wg-effect-encrypt.all@ietf.org" , "gen-art@ietf.org" Thread-Topic: Gen-ART Telechat Call review of draft-mm-wg-effect-encrypt-15 Thread-Index: AdOXDUs/t32TgyX1TZWbC3M2qbO3aAAZ/ZuA Date: Sat, 27 Jan 2018 13:47:24 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF490A6F2F@njmtexg5.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.141.203.172] Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF490A6F2Fnjmtexg5researc_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-27_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801270186 Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180127134801.EA3CB1275C5@ietfa.amsl.com> Resent-Date: Sat, 27 Jan 2018 05:48:01 -0800 (PST) Archived-At: Subject: Re: [OPSAWG] Gen-ART Telechat Call review of draft-mm-wg-effect-encrypt-15 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2018 13:48:02 -0000 --_000_4D7F4AD313D3FC43A053B309F97543CF490A6F2Fnjmtexg5researc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Meral, we'll make these edits in the working version. Kathleen and Al From: Meral Shirazipour [mailto:meral.shirazipour@ericsson.com] Sent: Friday, January 26, 2018 8:32 PM To: draft-mm-wg-effect-encrypt.all@ietf.org; gen-art@ietf.org Subject: Gen-ART Telechat Call review of draft-mm-wg-effect-encrypt-15 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 t= he 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-mm-wg-effect-encrypt-15 Reviewer: Meral Shirazipour Review Date: 2018-01-26 IETF LC End Date: 2017-12-04 IESG Telechat date: 2018-02-08 Summary: This draft is ready to be published as Informational RFC . Major issues: Minor issues: Nits/editorial comments: -few occurrences: "pervassive"--->"pervasive" -[Page 6], Sec 1.1, "were were built "---->"were built " -[Page 12] , "scaleability"--->"scalability" x2 -[Page 16] , "unaccessible"--->"inaccessible" -[Page 29] ,"depening"--->"depending", "permited"--->"permitted " -[Page 31], "rasises"---->"raises", "encyption"---->"encryption", "visibilt= y"--->"visibility" Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com --_000_4D7F4AD313D3FC43A053B309F97543CF490A6F2Fnjmtexg5researc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Meral, we’ll make these edits in the

working version.

 

Kathleen and Al

 

From: Meral Sh= irazipour [mailto:meral.shirazipour@ericsson.com]
Sent: Friday, January 26, 2018 8:32 PM
To: draft-mm-wg-effect-encrypt.all@ietf.org; gen-art@ietf.org
Subject: Gen-ART Telechat Call review of draft-mm-wg-effect-encrypt-= 15

 

I am the assigned Gen-ART reviewer for this draft. T= he General Area Review Team (Gen-ART) reviews all IETF documents being proc= essed by the IESG for the IETF Chair. Please wait for direction from your d= ocument shepherd or AD before posting a new version of the draft.

 

For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.=

 

Document: draft-mm-wg-effect-en= crypt-15

Reviewer: Meral Shirazipour

Review Date: 2018-01-26

IETF LC End Date: 2017-12-04

IESG Telechat date: 2018-02-08

 

Summary: This draft is ready to be published as Info= rmational  RFC .

 

Major issues:

Minor issues:

Nits/editorial comments:

-few occurrences: "pervassive"--->"= ;pervasive"

-[Page 6], Sec 1.1, "were were built "----= >"were built "

-[Page 12] , "scaleability"--->"sc= alability" x2

-[Page 16] , "unaccessible"--->"in= accessible"

-[Page 29] ,"depening"--->"dependi= ng", "permited"--->"permitted "

-[Page 31], "rasises"= ---->"raises", "encyption"---->"encryption&q= uot;, "visibilty"--->"visibility"<= /p>

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson Research

www.= ericsson.com

--_000_4D7F4AD313D3FC43A053B309F97543CF490A6F2Fnjmtexg5researc_-- From nobody Mon Jan 29 17:12:12 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7586E131492; Mon, 29 Jan 2018 17:12:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151727473144.27344.8624372671531680342@ietfa.amsl.com> Date: Mon, 29 Jan 2018 17:12:11 -0800 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-12.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 01:12:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : Alternate Tunnel Encapsulation for Data Frames in CAPWAP Authors : Rong Zhang Rajesh S. Pazhyannur Sri Gundavelli Zhen Cao Hui Deng Zongpeng Du Filename : draft-ietf-opsawg-capwap-alt-tunnel-12.txt Pages : 28 Date : 2018-01-29 Abstract: Control and Provisioning of Wireless Access Points (CAPWAP) defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments encapsulating data frames to an entity other than the AC (for example to an Access Router (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and the Access Router. This document defines extension to CAPWAP protocol for supporting this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process and AC may select one of the supported alternate tunnel encapsulation types while configuring the WTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-12 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-capwap-alt-tunnel-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-alt-tunnel-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 Mon Jan 29 18:26:32 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E5C1272E1; Mon, 29 Jan 2018 18:26:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, Tianran Zhou , warren@kumari.net, opsawg-chairs@ietf.org, zhoutianran@huawei.com, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151727918616.27471.3461652849370448998.idtracker@ietfa.amsl.com> Date: Mon, 29 Jan 2018 18:26:26 -0800 Archived-At: Subject: [OPSAWG] Suresh Krishnan's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-12: (with COMMENT) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 02:26:26 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. From nobody Tue Jan 30 12:54:18 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAEA12FB00 for ; Tue, 30 Jan 2018 12:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 SaD8e7YVgwsa for ; Tue, 30 Jan 2018 12:54:15 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 A76E612EA91 for ; Tue, 30 Jan 2018 12:54:15 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id l6so2685107oii.13 for ; Tue, 30 Jan 2018 12:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tqSQrKSx2EHLrhzTw6+DrQ/Ivepzer2MQIhpRCdQG0I=; b=frcbs1TyATvnTJN2/u69pHQZVnYkVfSn7iEhdp1lOEcIR8y2zOUuBdhg/6Fl0i0emf dbI22s4gRaStVkuU/Lm9vbbBNenuk7t7RwE27lIDKlYkMVCJvvnHCiqe6+VBXz1SWvE1 qdDMRTNlWrovrlTC5MSIbbuTh+eFxbc+9m3eXNdfsOyBVLfaq4YrqqaWZxrRuoWgILzh Z0rCc01WlxYZzXGG0AjAeWZIhoMqzikWVfn4AZO/MxQC2JaSOqKIduMv5ZFp5h0rSw68 pmmG61gCrpaFnxQwFpWHgYs42uFwKCkfvSfqxt6cD8eNBGU/kO1Firgtaup8UIPULeY2 oMjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tqSQrKSx2EHLrhzTw6+DrQ/Ivepzer2MQIhpRCdQG0I=; b=DVezdVhiXwndk5UnlKkCWJUm2gTB7qVnqwYpG55Y/N0XgSehjg0AiaVMJ8i9s4v3nX fig2gV8eNB1ltz50uuMroWDR2AWyeYmYy/F9hbIv7yTcZbpUPODOdUNCyjmBtx2SUfzv ZW9QGf86DEKGYChEYC0PGvm4jNzcE6HmcF0GUbXivSxHLzABs4EpOYRqFioMRJ25WEnb Pptc3h586yfqGDp/tRgOIh11Ons4mKeFzuHRfqTTRmKXhIRGQGXdsgYiRKXH5pE1ln5/ WXx3cWIWn0Li74Ansrdi+grNhLZTfAF6qaO2CYDkw8RO12sL3uwCoRLqjWSme50NQmdI h9sQ== X-Gm-Message-State: AKwxyte968KGqlCM9BUUEjh06MtR2ixdCxgt8XT1bP26jn5o2ywkEIev Jo8S0vo2U08PysNvTzfgC7CPfaPZcvME+zLshf3xGg== X-Google-Smtp-Source: AH8x225IizET9PlPtdx2tctcFH47hF6+PNNSeRhAARjjfrM3BTR/l5pGxxBmwTUR4t+LaJChEjutZp+D0bjXs1ydFaw= X-Received: by 10.202.73.11 with SMTP id w11mr2439327oia.301.1517345654290; Tue, 30 Jan 2018 12:54:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.36.201 with HTTP; Tue, 30 Jan 2018 12:53:33 -0800 (PST) From: "M. Ranganathan" Date: Tue, 30 Jan 2018 15:53:33 -0500 Message-ID: To: opsawg@ietf.org Content-Type: multipart/alternative; boundary="001a113db17ab9bcfa0564049092" Archived-At: Subject: [OPSAWG] draft-ietf-opsawg-mud-15 naming nit X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 20:54:17 -0000 --001a113db17ab9bcfa0564049092 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the acldns yang file I see augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" { description "adding abstractions to avoid need of IP addresses"; container mud { This leads to a few annoying naming conflicts when the Yang file is used to auto-generate java code. It would be convenient (although not necessary) if the container name were changed to mud-acl (the way it used to be). Sorry for nit-picking. Regards, --=20 M. Ranganathan =E2=80=9CIf debugging is the process of removing software bugs, then progra= mming must be the process of putting them in.=E2=80=9D =E2=80=93 Edsger Dijkstra --001a113db17ab9bcfa0564049092 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
In the acldns =
yang file I see

    augment "=
;/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" {
       description
         "adding abstractions to avoid need of IP addresses";
       container mud {


This leads to a few annoying nami= ng conflicts when the Yang file is used to auto-generate java code. It woul= d be convenient (although not necessary) if the container name were changed= to mud-acl (the way it used to be).

Sorry for nit-picking.
Regards,

--
M. Ranganathan

=E2=80= =9CIf debugging is the process of removing software bugs, then programming must be the process of putting them=20 in.=E2=80=9D =E2=80=93 Edsger Dijkstra

--001a113db17ab9bcfa0564049092-- From nobody Tue Jan 30 13:04:13 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C911A12FB2B for ; Tue, 30 Jan 2018 13:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, T_RP_MATCHES_RCVD=-0.01, 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 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 tZyX1IIEIJ7a for ; Tue, 30 Jan 2018 13:04:10 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741DD12FB19 for ; Tue, 30 Jan 2018 13:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6133; q=dns/txt; s=iport; t=1517346249; x=1518555849; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=kzH3QDeoLXB1JI2ZeXFP/Z7ABsg7f/5o1HLj5E7mSNA=; b=T7BoB4/kHh+EGNlhOkpLwNrXw4n8kF/qP0Qktw/coBDm9zlBrvelxJjF IPqWXuglLiitevPKmlMlhAiBK5zjIiBpclA74/hpg3/kdqmFeFd6IW1eg wcYJqXCIKkDiDOl/GkgsG1ZKS3XueTlGhaTvipiu8fntG2Ka2+AGy3FVu g=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgDO3HBa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodSiDYIsYj1MnkXGHawcDGAEKgV6Ca08CgyAUAQEBAQEBAQE?= =?us-ascii?q?CayiFJAEBBAEBIUsbCQIEFCoCAicwBgEMBgIBAYoxEIhynXGCJyaKPAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQ4KBYRXhX0MgnmDLwEBAoUGgmUFkj+RWIRhgjKOVYw?= =?us-ascii?q?th3yXZ4E8NiKBUDMaCBsVPYIqhHhAN45tAQEB?= X-IronPort-AV: E=Sophos;i="5.46,436,1511827200"; d="asc'?scan'208,217";a="1754487" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2018 21:04:05 +0000 Received: from [10.61.243.57] ([10.61.243.57]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0UL45dJ013679; Tue, 30 Jan 2018 21:04:05 GMT To: "M. Ranganathan" , opsawg@ietf.org References: From: Eliot Lear Message-ID: <6ceb9629-c578-2773-9546-5b6d4bb1918a@cisco.com> Date: Tue, 30 Jan 2018 22:04:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JATJeSf8n51IVQLmP2V6q31ckTXthJC3h" Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-15 naming nit X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 21:04:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JATJeSf8n51IVQLmP2V6q31ckTXthJC3h Content-Type: multipart/mixed; boundary="GOd8uovibw3W4a8gKO05FIL0Q5JALBSnk"; protected-headers="v1" From: Eliot Lear To: "M. Ranganathan" , opsawg@ietf.org Message-ID: <6ceb9629-c578-2773-9546-5b6d4bb1918a@cisco.com> Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-15 naming nit References: In-Reply-To: --GOd8uovibw3W4a8gKO05FIL0Q5JALBSnk Content-Type: multipart/alternative; boundary="------------A6F6F51F5A2C6582669ECAB4" Content-Language: en-US This is a multi-part message in MIME format. --------------A6F6F51F5A2C6582669ECAB4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ranga, I understand this to be a tooling issue.=C2=A0 Nevertheless, I will rever= t the change back to mud-acl as we progress the draft. Eliot On 30.01.18 21:53, M. Ranganathan wrote: > In the acldns yang file I see > augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" { > description > "adding abstractions to avoid need of IP addresses"; > container mud { > > > This leads to a few annoying naming conflicts when the Yang file is > used to auto-generate java code. It would be convenient (although not > necessary) if the container name were changed to mud-acl (the way it > used to be). > > Sorry for nit-picking. > > Regards, > > --=20 > M. Ranganathan > > =E2=80=9CIf debugging is the process of removing software bugs, then > programming must be the process of putting them in.=E2=80=9D =E2=80=93 = Edsger Dijkstra > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------A6F6F51F5A2C6582669ECAB4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Ranga,

I understand this to be a tooling issue.=C2=A0 Nevertheless, I wil= l revert the change back to mud-acl as we progress the draft.

Eliot


On 30.01.18 21:53, M. Ranganathan wrote:
In the acldns yang file I see

    augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches" {
       description
         "adding abstractions to avoid need of IP addresses";
       container mud {


This leads to a few annoying naming conflicts when the Yang file is used to auto-generate java code. It would be convenient (although not necessary) if the container name were changed to mud-acl (the way it used to be).

Sorry for nit-picking.

Regards,

--
M. Ranganathan

=E2=80=9CIf= debugging is the process of removing software bugs, then programming must be the process of putting them in.=E2=80=9D = =E2=80=93 Edsger Dijkstra



_______________________________________________
OPSAWG mailing list
OPS=
AWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------A6F6F51F5A2C6582669ECAB4-- --GOd8uovibw3W4a8gKO05FIL0Q5JALBSnk-- --JATJeSf8n51IVQLmP2V6q31ckTXthJC3h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpw3cQACgkQh7ZrRtnS ejOTtQf/dn+/Wf16DX4dZFklNbVXDei2mSRjrLXs7JLW0Eog84fRCZoeCywCwJVo xtZ4xMZ8mnOh74VkkQbTe7uow5al0gPne+xchXp3RAsRsxgWk+kI7ernYgC6yjLj 2Gv2fH7DIOOoO3LCfqJuW748TW3WCrOXjF+quFlwr2ilQkpIhqIeyS3rp8P2NMXF ShxbRMKJOvWgjsWH3CKRXVYaHtWFsv9C95W5wgWoh61a2uQokJDVXE1boxkbTzNq zCy9b7oFvT7J1RfnJiOGvU3RvTyLh0Oz9/KagAK2QVsZitCwJHEM416QcgJtoF/E JXsgMwukKJMu98sH8UK6BnJ5tj40+w== =4YEu -----END PGP SIGNATURE----- --JATJeSf8n51IVQLmP2V6q31ckTXthJC3h-- From nobody Tue Jan 30 14:33:46 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E652131452; Tue, 30 Jan 2018 14:33:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-opsawg-capwap-alt-tunnel@ietf.org, opsawg-chairs@ietf.org, Tianran Zhou , opsawg@ietf.org, zhoutianran@huawei.com, warren@kumari.net, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151735162464.7711.13477183432302714913.idtracker@ietfa.amsl.com> Date: Tue, 30 Jan 2018 14:33:44 -0800 Archived-At: Subject: [OPSAWG] Document Action: 'Alternate Tunnel Encapsulation for Data Frames in CAPWAP' to Experimental RFC (draft-ietf-opsawg-capwap-alt-tunnel-12.txt) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 22:33:44 -0000 The IESG has approved the following document: - 'Alternate Tunnel Encapsulation for Data Frames in CAPWAP' (draft-ietf-opsawg-capwap-alt-tunnel-12.txt) as Experimental RFC This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ Technical Summary CAPWAP defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC). In many deployments it is desirable to encapsulate date frames to an entity other than the AC (for example to an Access Router). This document provides a specification for this and allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types. Working Group Summary There was no drama in the WG regarding this draft. The document was originally WGLCed in 2014, and submitted for publication in early 2015. The WG then requested that the document to be returned to us, so that we could merge it with another, related draft. This has been completed, and so we are resubmitting it. Document Quality Cisco has implemented this technology. A number of operators (including CMCC and AT&T) originally indicated that they need something like this, but it is unclear if this is actually being / going to be deployed. Personnel Tianran Zhou is the document shepherd. Warren Kumari is the AD. From saspraha@cisco.com Fri Jan 26 11:17:43 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF97126D0C for ; Fri, 26 Jan 2018 11:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 EUeODxerBY6o for ; Fri, 26 Jan 2018 11:17:41 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8002C124BE8 for ; Fri, 26 Jan 2018 11:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4098; q=dns/txt; s=iport; t=1516994261; x=1518203861; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6tO/AShz2lOxetp3QctgGLpqiQ8KObmW1KyqHb2jnyQ=; b=cFYSPAPNituCjXG7vyIxBzkdc1x3L/GTIWLMOWQQdlQtiCk5aoraaQDr HxY0uJUBmR4InoqIE7Xf6n+wK7itL86VqPEXEulz5acqWU8oP8zSIpZKi X4iml5prRVGUqzPhJkZsoiRgsK3Rqi3NZGVHNZwBsYobeGAeOFvRVWQPb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgB2fWta/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNCZnQnB4NWmQ6CAplbCoIBgzoCGoIEVxUBAQEBAQEBAQJrKIU?= =?us-ascii?q?jAQEBAwEjEUUQAgEIGAICJgICAjAVEAIEAQ0Fii0IsSmCJ4pYAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYEPg0OCFYFXgWgpgwWDLwSBWQkkgwAxgjQFinKHSpFXApV?= =?us-ascii?q?kghuKN4dWlzICERkBgTsBNSOBUHAVZwGBf4JUHYFneIwrgTKBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,418,1511827200"; d="scan'208";a="346462973" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2018 19:17:40 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0QJHeF4019128 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Jan 2018 19:17:40 GMT Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 26 Jan 2018 13:17:39 -0600 Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1320.000; Fri, 26 Jan 2018 13:17:39 -0600 From: "Saswat Praharaj (saspraha)" To: "Joe Clarke (jclarke)" , Eliot Lear , "mohamed.boucadair@orange.com" CC: Mahesh Jethanandani , "opsawg@ietf.org" , Mark Nottingham Thread-Topic: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt Thread-Index: AQHTlPrWeOBu4MjTsECZsgBmlCD2raODRUiAgAABJwCAAw53gIAAmmEA Date: Fri, 26 Jan 2018 19:17:39 +0000 Message-ID: <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.85.178] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 30 Jan 2018 16:53:01 -0800 Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2018 19:49:27 -0000 SGkgRWxpb3QsDQoNCkFkZGluZyBkZXZpY2UgaW5mb3JtYXRpb24gKG1hbnVmYWN0dXJlL2Rldmlj ZS10eXBlIGV0Yy4pIGluIE1VRCBmaWxlIHByb3ZpZGVzIHZpc2liaWxpdHkgaW4gbmV0d29yaywg aW4gYWRkaXRpb24gdG8gcG9saWN5Lg0KSWYgdmlzaWJpbGl0eSBpcyBub3QgdGhhdCBpbXBvcnRh bnQgZm9yIE1VRCwgd2UgY291bGQgaGF2ZSBpdCBhcyBvcHRpb25hbCBwYXJhbWV0ZXJzLiANCg0K SU1ITywgaXTigJlzIGltcG9ydGFudCBiZWNhdXNlIE1VRCB3aWxsIG5vdCBiZSB0aGUgb25seSBw b2xpY3kgZm9yIHRoZSBkZXZpY2UgYW5kIGlmIGFkbWluIGhhcyB0byBhcHBseSBvdGhlciBwb2xp Y2llcywgaGUvc2hlIG5lZWRzIHRvIGtub3cgd2hhdCB0aGUgZGV2aWNlIGlzLg0KRGV2aWNlIG1h bnVmYWN0dXJlciBpcyB0aGUgbW9zdCByZWxpYWJsZSBzb3VyY2UgdG8gcHJvdmlkZSBpbmZvcm1h dGlvbiBhYm91dCB0aGUgZGV2aWNlLg0KDQpCYXNlZCBvbiB5b3VyIGNvbW1lbnQgDQoNCiAgICA+ IFllcywgdGhlcmUgaXMuICBJZiB0aGUgTVVELVVSTCBpcyAiYnVybmVkIGluIiB2aWEgODAyLjFB UiBhbmQgdGhlIA0KICAgID4gc29mdHdhcmUgY2FuIGJlIHVwZGF0ZWQsIHRoZW4gb25lIG91Z2h0 bid0IHByb3ZpZGUgc29mdHdhcmUNCiAgICA+IGluZm9ybWF0aW9uIGZvciB0aGUgc2ltcGxlIHJl YXNvbiB0aGF0IGl0IHdvdWxkIGJlIG1vc3QgbGlrZWx5DQogICAgPiB3cm9uZy4gIEhhcmR3YXJl IGluZm8/ICBTdXJlLiAgU29mdHdhcmUgd2hlbiB1c2luZyBESENQIG9yIExMRFA/DQogICAgPiBT dXJlLiAgQnV0IG90aGVyd2lzZSBuby4NCg0KRm9yIHRoaXMsIGl04oCZcyBpbXBvcnRhbnQgdGhh dCB3ZSBoYXZlIHZlcnNpb24gbnVtYmVyIGluIHRoZSBNVUQgVVJMIOKAkyBFaXRoZXIgYXMgdjEs IHYyIG9yIDxzb2Z0d2FyZSB2ZXJzaW9uPiBpdHNlbGYuIA0KRGV2aWNlIGRlc2NyaXB0aW9uIGFu ZCBhY2Nlc3MgcG9saWN5IG1heSBjaGFuZ2Ugd2hlbiBzb2Z0d2FyZSBpcyB1cGdyYWRlZC4gQSBu ZXdseSByZWxlYXNlZCBkZXZpY2Ugd2l0aCBhIGRpZmZlcmVudCBzb2Z0d2FyZSB2ZXJzaW9uIG1h eSBoYXZlIGRpZmZlcmVudCBhY2Nlc3MgcGF0dGVybiBjb21wYXJlZCB0byBvbGRlciB2ZXJzaW9u IG9mIHRoZSBkZXZpY2UuDQoNCk1VRCBmaWxlIGlzIGEgc3RhdGljIGZpbGUgYW5kIGluIGEgc3Rh dGljIGZpbGUgc2VydmluZyB3ZWItc2VydmVyIGxpa2UgYXBhY2hlIChvciBldmVuIGFuIG9iamVj dCBzdG9yZSBsaWtlIEFXUyBTMykgaXQgaXMgbW9zdCBsaWtlbHkgdG8gYmUgc3RvcmVkIGluIHRo ZSBkaXNrIChvbiBpbiBvYmplY3Qgc3RvcmUpIGFzIHBhdGggIDw8Ly53ZWxsLWtub3duL211ZC9t b2RlbD4+IC4NCk1VRCBmaWxlIHdvdWxkIGJlIHJlYWQgZGlyZWN0bHkgZnJvbSB0aGUgZGlzayBw YXRoIHdoZW4gdGhlIGZpbGUgaXMgc2VydmVkIHRvIHRoZSByZXF1ZXN0ZXIuDQoNCkl04oCZcyBn b2luZyB0byBiZSB2ZXJ5IGRpZmZpY3VsdCB0byBob3N0IG11bHRpcGxlIHBvbGljeSBmaWxlcyBm b3IgdGhlIHNhbWUgbW9kZWwgdW5sZXNzIHdlIGhhdmUgYSB3YXkgdG8gZGlzdGluZ3Vpc2ggdGhl bSBpbiB0aGUgVVJMIGl0c2VsZi4gDQpJZiB3ZSBoYXZlIHNvZnR3YXJlIHZlcnNpb24gaW4gdGhl IFVSTCwgd2Ugbm90IG5lZWQgdG8gaGF2ZSBpdCBpbiB0aGUgZmlsZS4gDQpUd28gZGlmZmVyZW50 IHNvZnR3YXJlIHZlcnNpb24gKHRoZXJlZm9yZSBkaWZmZXJlbnQgVVJMcykgY291bGQgcG9pbnQg dG8gdGhlIHNhbWUgTVVEIGZpbGUsIGlmIHRoZXJlIGlzIGEgbmVlZCBmb3IgdGhhdC4gDQpUaGlz IG1hcHBpbmcgY2FuIGJlIGRvbmUgZmFpcmx5IGVhc2lseSBpbnNpZGUgYSB3ZWJzZXJ2ZXIuIA0K DQpUaGFua3MsDQpTYXN3YXQNCg0KT24gMS8yNi8xOCwgMjowNSBBTSwgIkpvZSBDbGFya2UgKGpj bGFya2UpIiA8amNsYXJrZUBjaXNjby5jb20+IHdyb3RlOg0KDQogICAgLS0tLS1CRUdJTiBQR1Ag U0lHTkVEIE1FU1NBR0UtLS0tLQ0KICAgIEhhc2g6IFNIQTENCiAgICANCiAgICBPbiAxLzI0LzE4 IDA2OjI0LCBFbGlvdCBMZWFyIHdyb3RlOg0KICAgID4gDQogICAgPiANCiAgICA+IE9uIDI0LjAx LjE4IDEyOjIwLCBKb2UgQ2xhcmtlIHdyb3RlOg0KICAgID4+IElzIHRoZXJlIGEgcmVhc29uIHdo eSB0aGV5IHdvdWxkbid0IGJlIG1hbmRhdG9yeT8gIFNlZW1zIGxpa2UNCiAgICA+PiB0aGVzZSBk YXRhIHdvdWxkIGJlIHJlYWRpbHkgYXZhaWxhYmxlIGFuZCBoYXZpbmcgdGhlbSB3b3VsZCBtYWtl DQogICAgPj4gYSBudW1iZXIgb2YgdXNlIGNhc2UgY2FzZXMgcG9zc2libGUuDQogICAgPiANCiAg ICA+IFllcywgdGhlcmUgaXMuICBJZiB0aGUgTVVELVVSTCBpcyAiYnVybmVkIGluIiB2aWEgODAy LjFBUiBhbmQgdGhlIA0KICAgID4gc29mdHdhcmUgY2FuIGJlIHVwZGF0ZWQsIHRoZW4gb25lIG91 Z2h0bid0IHByb3ZpZGUgc29mdHdhcmUNCiAgICA+IGluZm9ybWF0aW9uIGZvciB0aGUgc2ltcGxl IHJlYXNvbiB0aGF0IGl0IHdvdWxkIGJlIG1vc3QgbGlrZWx5DQogICAgPiB3cm9uZy4gIEhhcmR3 YXJlIGluZm8/ICBTdXJlLiAgU29mdHdhcmUgd2hlbiB1c2luZyBESENQIG9yIExMRFA/DQogICAg PiBTdXJlLiAgQnV0IG90aGVyd2lzZSBuby4NCiAgICANCiAgICBGYWlyLCBidXQgd2h5IG5vdCBt YW5kYXRvcnkgdGhlbiBmb3IgZGV2aWNlLXR5cGUsIG1vZGVsLW51bWJlciwgYW5kDQogICAgbWFu dWYtbmFtZT8NCiAgICANCiAgICBKb2UNCiAgICAtLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0t LQ0KICAgIA0KICAgIGlGMEVBUkVDQUIwV0lRVE1pV1FIYzh3Q2hpamtyN2x2YUkrSy9oVFBod1VD V21yOVR3QUtDUkJ2YUkrSy9oVFANCiAgICBoNFVoQUo5QzdjRnhXdUR4bmRZaXB5QUZudW5zV1Vy bGxRQ2ZSaEsvOEduazR0N1lNTTI2aENzeFVDdDNyVlk9DQogICAgPWVFdHENCiAgICAtLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCiAgICANCg0K From nobody Wed Jan 31 01:11:59 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B930131625 for ; Wed, 31 Jan 2018 01:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 pJO5WGdi1qvm for ; Wed, 31 Jan 2018 01:11:55 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2C6131666 for ; Wed, 31 Jan 2018 01:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:openpgp:organization:message-id:date:user-agent:mime-version:in-reply-to:content-type:x-originating-ip:x-clientproxiedby; bh=YoTUL6VqmnVDQ4W+fOSURtNsiJRjacXJg8//caO/wFw=; b=ExkJLiUw/vR5qwIw71qBOGJ1WXVwEBSJRVHoOOCUm5+DRWUkfmRmAsrROhnQefnoDO161Iwy59eq3+Z5GsQtyeqsfHFQaYZOQB6qF527/Om+yMJxoHLHIKJ79aql6nO9y1SP0cVFJOm9UMSZ8aYC7S3T/kkIhB3BP78hcojWX03fbrSf19N3Fs4s3BFpbJhZu9IQkereSu8bDnS9xEPsJLpKNfO5ithH5BNim3MZ41GeCP+YcieI4jh0gJiZmKff2em/MvKqfaLMHuSpkbsheT7a97qVlhA5626m5I94qAmAgqVFY0OFqVdB3tdPn9Y8K9eeOkdjNNj6nURAn7iEDA== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id w0V97BQ2015606-w0V97BQ4015606 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Wed, 31 Jan 2018 10:07:11 +0100 Received: from imac2.home.forfun.net (94.198.159.130) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 31 Jan 2018 10:07:11 +0100 To: References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> From: "Marco Davids (SIDN)" Openpgp: id=AB05A4C36C4477CBA90252A3BB2857E82C0F54F3 Organization: SIDN Message-ID: Date: Wed, 31 Jan 2018 10:07:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aohU7e4lZ75H8rmttXx8BiJzSd339CoPk" X-Originating-IP: [94.198.159.130] X-ClientProxiedBy: ka-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.130, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.130 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 09:11:58 -0000 --aohU7e4lZ75H8rmttXx8BiJzSd339CoPk Content-Type: multipart/mixed; boundary="gJOZzPfDGdRKwnnfwGR7nuSVpgRoEbjjz"; protected-headers="v1" From: "Marco Davids (SIDN)" To: opsawg@ietf.org Message-ID: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> In-Reply-To: <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> --gJOZzPfDGdRKwnnfwGR7nuSVpgRoEbjjz Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Op 26-01-18 om 20:17 schreef Saswat Praharaj (saspraha): > Adding device information (manufacture/device-type etc.) in MUD file pr= ovides visibility in network, in addition to policy. Also, besides ACL's, I believe it would also make sense to convey=20 bandwidth limitation information via MUD's (my Zigbee hub does not need=20 the full available bandwidth, especially not when it is compromised) and = maybe even time constraints (only allow it to interact with the internet = during office hours, or something like that). I see several use cases for these features. -- Marco --gJOZzPfDGdRKwnnfwGR7nuSVpgRoEbjjz-- --aohU7e4lZ75H8rmttXx8BiJzSd339CoPk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEqwWkw2xEd8upAlKjuyhX6CwPVPMFAlpxhzkACgkQuyhX6CwP VPNTvBAAokXpT2ySN1IFVCft934RwqCvYN6o71t8OpiwqkmhAAknc2dmWZswC1v1 NpY0m9SO2fkP0yfSmQbn72moa+yBr6mPJgrUMguy+K+eazWc1M2CSP4NCEOExk2E 2zA3bsA0Xb/CMeL/ImxDXJxbJacn7YFRauDgBC3vPnPNSPBb7ip0eTxe0sYfgtAa JddicqR4av7ks+gFiAeEJ5Gqb9SRtO2M9a3JmuPERd+cL7rlNPu6g8+MgYD1UliE 7XMpbxwMFnSEg7VLbku3ndtlwUZCqKSULJrkf1JksouSiQwAnu5tm2xnrBG4iGZG 2TgQg05cJXDnyaW6MgUp0q8MsnWTW6f6nrx0rCbSIUNqWeeey+eZRjXg+8AKJ/6j htjOyaeo0Es/dzJxcfOvM2SNexA7essy61rkQHXn2SPUKtFWSBRWhP32VyW0Q2Rq zDMurjI58X25LPngGILjUB/4Hx3p+QexYRxPV29nkQCZE1fKorNwZhFZNbufA03S xTShSUB8LzkODUpcNJGLuHKu1SE3lJHa7kBFtlldEJgSkrbPtmtaLt42uYkI9mXB LuRmWscFyf7RxFSPQMkveC2gKR3H6Q2JWowVzjfo62LjoLxiWlIr73APBpLIdHr7 qQ07ZTeGgwXJE2h4P653wwAQM3+sogCLHsETKpxxp6RSSgkutKQ= =GKXV -----END PGP SIGNATURE----- --aohU7e4lZ75H8rmttXx8BiJzSd339CoPk-- From nobody Wed Jan 31 03:09:16 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5014712D87B for ; Wed, 31 Jan 2018 03:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, T_RP_MATCHES_RCVD=-0.01, 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 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 xHKIEbT2uf9x for ; Wed, 31 Jan 2018 03:09:08 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B168E12E047 for ; Wed, 31 Jan 2018 03:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5228; q=dns/txt; s=iport; t=1517396944; x=1518606544; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=RsxISfOWBL1+/SQzJffWBE28hhACA/C6g/xXT1lOYjI=; b=SQYrRd3pnZ4CpYHIgfe6An7INdkDdkIEVNCQYmO6H/7qJN+q96PWhXhH CaPFInP5o0PQcqdeLzWrky3Bcw0dVLKXoT4Mo2vm7PZdZUwgtmafdexiy MUlfI0G8YykEsO5MdKYwZ4wapQ6/W2LIAM3SWOsJO4GGKRorruP87CUyP U=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvAQAnonFa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodSiDYIsYj1MnfJB2h2sHAxgBCoRJTwKDIhQBAQEBAQEBAQJ?= =?us-ascii?q?rKIUkAQEEAQEhSxsLBBQqAgInMAYBDAYCAQGKMRCmaYInJoo9AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBDgoFhFt9hFcpDIJDNoMvAQEChQaCZQWkGYRhgjKOVowwh3y?= =?us-ascii?q?XaIE8NiKBUDMaCBsVPYIqhHhAN4xkAQEB?= X-IronPort-AV: E=Sophos;i="5.46,439,1511827200"; d="asc'?scan'208,217";a="1765778" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 11:09:02 +0000 Received: from [10.61.243.57] ([10.61.243.57]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0VB91Q9029525; Wed, 31 Jan 2018 11:09:02 GMT To: "Marco Davids (SIDN)" , opsawg@ietf.org References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> From: Eliot Lear Message-ID: Date: Wed, 31 Jan 2018 12:09:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M3JSeX4EkUuFdreKPEoakdTHupMRePpHM" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 11:09:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M3JSeX4EkUuFdreKPEoakdTHupMRePpHM Content-Type: multipart/mixed; boundary="F9v6ukxoup4lD448Dj6AstjpjH8q45v3F"; protected-headers="v1" From: Eliot Lear To: "Marco Davids (SIDN)" , opsawg@ietf.org Message-ID: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <49328c0f-e97e-4631-d962-3fc37497200d@cisco.com> <421f7436-c0f7-f945-25e2-fdb22c71dfbd@cisco.com> <420FC596-9CC5-4F40-AC40-0A77FD9C15CF@cisco.com> In-Reply-To: --F9v6ukxoup4lD448Dj6AstjpjH8q45v3F Content-Type: multipart/alternative; boundary="------------1CAF71EF6B2D18FBF3D39BF5" Content-Language: en-US This is a multi-part message in MIME format. --------------1CAF71EF6B2D18FBF3D39BF5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Marco, I think this is an example opportunity for an extension.=C2=A0 Let's put = that together separately.=C2=A0 happy to work with you on it. Eliot On 31.01.18 10:07, Marco Davids (SIDN) wrote: > Op 26-01-18 om 20:17 schreef Saswat Praharaj (saspraha): > >> Adding device information (manufacture/device-type etc.) in MUD file >> provides visibility in network, in addition to policy. > > Also, besides ACL's, I believe it would also make sense to convey > bandwidth limitation information via MUD's (my Zigbee hub does not > need the full available bandwidth, especially not when it is > compromised) and maybe even time constraints (only allow it to > interact with the internet during office hours, or something like that)= =2E > > I see several use cases for these features. > > --=20 > Marco > > > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------1CAF71EF6B2D18FBF3D39BF5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Marco,

I think this is an example opportunity for an extension.=C2=A0 Let= 's put that together separately.=C2=A0 happy to work with you on it.

Eliot



On 31.01.18 10:07, Marco Davids (SIDN)= wrote:
Op 26-01-18 om 20:17 schreef Saswat Praharaj (saspraha):

Adding device information (manufacture/device-type etc.) in MUD file provides visibility in network, in addition to policy.

Also, besides ACL's, I believe it would also make sense to convey bandwidth limitation information via MUD's (my Zigbee hub does not need the full available bandwidth, especially not when it is compromised) and maybe even time constraints (only allow it to interact with the internet during office hours, or something like that).

I see several use cases for these features.

--
Marco 






_______________________________________________
OPSAWG mailing list
OPS=
AWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--------------1CAF71EF6B2D18FBF3D39BF5-- --F9v6ukxoup4lD448Dj6AstjpjH8q45v3F-- --M3JSeX4EkUuFdreKPEoakdTHupMRePpHM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpxo80ACgkQh7ZrRtnS ejNWIAgAmJ+N0l3QezvGuqs2R8bRp6uSJgoIbrFEFfLCZq0ebbaeWqvMGFOO0MZd IK+qKEHBFd8Ajn7o4W0E4Trt0o/9OcvKikeZmMmNfR5ySP8sU9uJzRRhe4uNOOrv RgBiOZsBrqrIRD4oaOIYyLneqyL7RYX1cXvPIRaWglY/7nWdHRE2fSGYTHvIcVce UQ0eBsuEWMcoU5COPykU19zJnKJbfviuhPE0WPvoLx+HCQA3bVu3WKa+Qp5xli4f van9eOsPET/HtBmM+4M9wmnB2NprLKTwM5RlaRWrpVrohwp8X0odjKabnElyYA0v hxuhKHTyYWqLVRocz/BUMVGrdiQFgA== =xQ1Y -----END PGP SIGNATURE----- --M3JSeX4EkUuFdreKPEoakdTHupMRePpHM-- From nobody Wed Jan 31 11:06:00 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACD812ECA5; Wed, 31 Jan 2018 11:05:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , "Paul Hoffman" X-Test-IDTracker: no X-IETF-IDTracker: 6.71.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151742555643.25840.697219279122050688.idtracker@ietfa.amsl.com> Date: Wed, 31 Jan 2018 11:05:56 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-mm-wg-effect-encrypt-16.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 19:05:56 -0000 A new version (-16) has been submitted for draft-mm-wg-effect-encrypt: https://www.ietf.org/internet-drafts/draft-mm-wg-effect-encrypt-16.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-mm-wg-effect-encrypt-16 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Wed Jan 31 12:36:06 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DEE12D860 for ; Wed, 31 Jan 2018 12:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 3XjzLfW0tqK7 for ; Wed, 31 Jan 2018 12:36:03 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 8906112EACD for ; Wed, 31 Jan 2018 12:35:54 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id j15so8455335oii.5 for ; Wed, 31 Jan 2018 12:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iS+6KsLZOuUrI51GDrFfXwK7PwHqiC4Ma5feuJB0KXM=; b=Y8H7j1AR1sLp2s1vmN+JoDhntJduTZDTqFOwiZu1K22dk7lJ1KTRnIEevh+R2RjWKt 10bY0jMmH7FiK5q+YltjN5rbEnEhv/WSnmlwYdeBhlTLRwuxvmH6HWtjiG5mBRi43RNC Gyw4YqgKoMJq/8I4lB6ERO4qHi3D3HkNl9qV8QxbAy2RDYGx+OfOduGe2wO8E5UMH+kj h/1ChI5Q+W9OcUwQLszlGcmeBU8+XKfN9rjP/qrXwCamwdw9jMXlxhfLGFmSKn7UgXP0 gYSYWGxfEXCDPhyZrU3PmXuQKVU5U0NGuJ/1BCbM9Un4wf3TOSv9NsNxZaNP9IpgaCIo l31g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iS+6KsLZOuUrI51GDrFfXwK7PwHqiC4Ma5feuJB0KXM=; b=AoqYQuW/c6MyGVQInmis7W3YKfxTI6h3fHHi7JNRrUIYwAS+hSwosDpxej0uxJfe2q J8j5jD6RSrRk/BRXpLlj1HS2HHbaxxCDUP1JuW18eN+S7ADlQs+PCzJzSV44/f3C/hPw VW89M12JY5TUrShjpEIGkMHeeAZvP256C2WDY6655276XZIJKzRDFJjZd8Ir6s/JdD21 a4hc5/sE31zs1Lo3XtrxONteuix3vbun0D2o7Px7jGI+BxfzKhLU4QesN+ZgfQ1bx+Vh RpMpt1icolmysmAOpkyahuoYemEy6z6HI33V+KFMkdlB6q0D8mXJlDuH+V/ty6s7ifSw OrGQ== X-Gm-Message-State: AKwxytcsXi+lEzapQAtW7wAcuwNgT0m7Djqq954rfPuLy1FGMOYmcPsd wdv+MaA4liHaFPXnsVgZfw0lM1OY732eGLFPXJc= X-Google-Smtp-Source: AH8x224AEPJJBlOF9DNPaDFaV6z1u9Lys3BfZx61PnvMF+ZX6Sq+Aaw7E4g+jyTy5gR3g0xWvzHdxvIWh9x30rs6BGQ= X-Received: by 10.202.83.194 with SMTP id h185mr10974564oib.228.1517430953093; Wed, 31 Jan 2018 12:35:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.36.201 with HTTP; Wed, 31 Jan 2018 12:35:12 -0800 (PST) From: "M. Ranganathan" Date: Wed, 31 Jan 2018 15:35:12 -0500 Message-ID: To: opsawg@ietf.org Content-Type: multipart/alternative; boundary="001a113de690ee2fd30564186ca8" Archived-At: Subject: [OPSAWG] draft-ietf-opsawg-mud-15 ACL operators X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 20:36:05 -0000 --001a113de690ee2fd30564186ca8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The ACL draft has various operators for ports, including eq, lte, gte Does a compliant MUD implementation have to support all of these operators? If ONLY eq is required to be supported (I hope ) , can this be stated in the draft. Given that port ranges can be specified I wonder why the other comparison operators ( should exist but that is more a question for the ACL spec. Thanks, Ranga --=20 M. Ranganathan =E2=80=9CIf debugging is the process of removing software bugs, then progra= mming must be the process of putting them in.=E2=80=9D =E2=80=93 Edsger Dijkstra --001a113de690ee2fd30564186ca8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The ACL draft has various operators fo= r ports, including eq, lte, gte

Does a compliant MUD implement= ation have to support all of these operators? If ONLY eq is required to be = supported (I hope ) , can this be stated in the draft.

Given t= hat port ranges can be specified I wonder why the other comparison operator= s ( should exist but that is more a question for the ACL spec.

Thanks,

Ranga

--
M. Ran= ganathan

=E2=80=9CIf debugging is th= e process of removing software bugs, then programming must be the process of putting them=20 in.=E2=80=9D =E2=80=93 Edsger Dijkstra

--001a113de690ee2fd30564186ca8-- From nobody Wed Jan 31 12:36:40 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CC612EACD; Wed, 31 Jan 2018 12:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, 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 QADqTzVpofzv; Wed, 31 Jan 2018 12:36:38 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D436612E89C; Wed, 31 Jan 2018 12:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1974; q=dns/txt; s=iport; t=1517430992; x=1518640592; h=to:from:subject:message-id:date:mime-version; bh=CHkH1UEBbWU4iblsBsN749wO19YMI5N3vGKF3w5fP5Y=; b=jEvq5ykiepsFPQFgcjn9tDg9QOc/DR1USmYFDwAyOrxCdIFZ/vo4CcWy gyX9ZMLRqEOtkig05rNrY+t1E0tDDxrBcugezT2WriQahYDW0GBVAYgUA 6BntCLvU6Qn5srzFt75nD4QAuagGQhIWl1KI/iSxfBbpSfPmYyGCFIwGo A=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQBZKHJa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUdhAiLGKcVggIHA4hkFAEBAQEBAQEBAmsohU2BMwJfAQwIAQG?= =?us-ascii?q?KMagVgieKagEBAQcBAQEBFQ+EW4V9gwWBMIM6g0+CZQWkHoRhgjKOWYIEGYYig?= =?us-ascii?q?3GHfZdpgTw2IoFQMxoIGxWCaIR3QIxdAQEB?= X-IronPort-AV: E=Sophos; i="5.46,441,1511827200"; d="asc'?scan'208"; a="1724900" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 20:36:29 +0000 Received: from [10.61.243.57] ([10.61.243.57]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0VKaTGD001190; Wed, 31 Jan 2018 20:36:29 GMT To: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" From: Eliot Lear Message-ID: <70da5ead-f28a-580a-d1b0-943dd676c5c8@cisco.com> Date: Wed, 31 Jan 2018 21:36:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q3At9XFLB9RfG1EnR0IlRAqEocPNuIg1q" Archived-At: Subject: [OPSAWG] request slot for 10 minutes X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 20:36:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q3At9XFLB9RfG1EnR0IlRAqEocPNuIg1q Content-Type: multipart/mixed; boundary="ubovnasTh76DBSaq3BcEJO84GbFMukXv0"; protected-headers="v1" From: Eliot Lear To: "opsawg@ietf.org" , "opsawg-chairs@ietf.org" Message-ID: <70da5ead-f28a-580a-d1b0-943dd676c5c8@cisco.com> Subject: request slot for 10 minutes --ubovnasTh76DBSaq3BcEJO84GbFMukXv0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Dear OPSAWG chairs, Can I please have 10 minutes to talk about- AfterMUD, or those next MUDdy steps, or the like? Abstract as follows: We anticipate the IETF LC to have completed on the base MUD draft.=C2=A0 = We have other work that we may wish to look to, in terms of next steps.=C2=A0= As we have seen during last call, some have called for what amount to QoS profiles.=C2=A0 Others have discussed leveraging the MUD file for other informational elements.=C2=A0 I propose to start a discussion on both; ot= hers are encouraged to share their thoughts. Thanks, Eliot --ubovnasTh76DBSaq3BcEJO84GbFMukXv0-- --q3At9XFLB9RfG1EnR0IlRAqEocPNuIg1q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpyKMwACgkQh7ZrRtnS ejObdwf/YeJQRJv0P/AWU1DIzagkRrvTiqD9XmrR6hNvMbwfnt9xpUo8GLpvw9kk MKP0DAffrMLLpX5J6XkgNl+tBp1c0t+ABL7Oqaj4XCCZueWQIPU9rE0MY5va3G6c 53v1nDAaSyiEySdH/M+AMOnKo12iDaVeh0DCRwmtYd2BGGH2zYCVIz6QfvxY+Sgu pAapcJNCniS3GtYPXVmoEWYG+uxtzCK76tgIqfKyi4Tyc6TLupMOtn2xG2psThmN UtF6DI+WATjDxpl9JXqaqcdYPHpP9cBzvLTz8EUhqRh99tD0pY2e0dyuFdA9Ciac hyg4dbXIV44tcJaWkOguog30MribKA== =4iMN -----END PGP SIGNATURE----- --q3At9XFLB9RfG1EnR0IlRAqEocPNuIg1q-- From nobody Wed Jan 31 12:37:51 2018 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45FC12D860 for ; Wed, 31 Jan 2018 12:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, 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 2gl6ZYMQfjXl for ; Wed, 31 Jan 2018 12:37:48 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E1312D94C for ; Wed, 31 Jan 2018 12:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1972; q=dns/txt; s=iport; t=1517431068; x=1518640668; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=903RVfRYMmK1vn0xb8q5w9UYhEt4AYN8tHB/5Yqsijc=; b=E+iTW6odi9/8uz4IimcQX+vZmDM17SrQ3/4m146WXLp21xakYGIZUH9A ZM06U1sNAscZMAD7eChJklURMDEDWL6nFI19URAAHeJt4sMFZtxX7RP3D fdJkUXhLzMGLlcGlHp06Xn7YNSNV4/I18ADJHQIGJ4cahhR/foKjKDOdU E=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQBZKHJa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUdhAiLGI86mV0HA4U7AoMnFAEBAQEBAQEBAmsohSQBBSNmCxg?= =?us-ascii?q?qAgJXBgEMCAEBijGoFYInimoBAQEBAQEBAwEBAQEBAQESD4RbhX2DBYg5gmUFp?= =?us-ascii?q?B6EYYIyjlmCBAGKK4d9l2mBPDYigVAzGggbFYJohHdAjF0BAQE?= X-IronPort-AV: E=Sophos; i="5.46,441,1511827200"; d="asc'?scan'208"; a="1730345" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 20:37:44 +0000 Received: from [10.61.243.57] ([10.61.243.57]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0VKbh34013948; Wed, 31 Jan 2018 20:37:44 GMT To: "M. Ranganathan" , opsawg@ietf.org References: From: Eliot Lear Message-ID: <6d2e50c4-62ab-c0e6-f5a1-c86e714dd7db@cisco.com> Date: Wed, 31 Jan 2018 21:37:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wUnSel6QlOqB7F7fDQBKU4KWc9jFDpxBC" Archived-At: Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-15 ACL operators X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 20:37:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wUnSel6QlOqB7F7fDQBKU4KWc9jFDpxBC Content-Type: multipart/mixed; boundary="k8LkEv04IRtWoIDs3qA1hcShStfMsJQwf"; protected-headers="v1" From: Eliot Lear To: "M. Ranganathan" , opsawg@ietf.org Message-ID: <6d2e50c4-62ab-c0e6-f5a1-c86e714dd7db@cisco.com> Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-15 ACL operators References: In-Reply-To: --k8LkEv04IRtWoIDs3qA1hcShStfMsJQwf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 31.01.18 21:35, M. Ranganathan wrote: > The ACL draft has various operators for ports, including eq, lte, gte > > Does a compliant MUD implementation have to support all of these > operators? If ONLY eq is required to be supported (I hope ) , can this > be stated in the draft. All.=C2=A0 The MUD file augments the acl-model.=C2=A0 We are not varying = off the model in this aspect, nor do we really have a good way to do so. --k8LkEv04IRtWoIDs3qA1hcShStfMsJQwf-- --wUnSel6QlOqB7F7fDQBKU4KWc9jFDpxBC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpyKRcACgkQh7ZrRtnS ejOMDAf+JSLWfRUX3JlzBPtcnY7fuJKQIjYHnvwbefiM5OwdHKrvzLVTgQxLpMSX 1mR8p98HBazm+rhD9EQG4oJRoLs9EFr8z+07rGsFgauVfOsEj7oXug6zkk32Ashe yADdkL36kNtj8BGV7/HFiMXkGFdIkCblGj/sUNtnmRdDwTxjk7Nyufs4W0dNeqln nsqkWfammBQtuYEc7guJrdRuH/MfCkcE6R2w/m+yuFJFIoaiZDkx2esJ9Lcmwe1l MVkjSfT2AMX5xbpB5YOeTGK0tvLhC3tNUvU8n1nd8miNj+fD/Mu3UITAQ5IjCP90 9oyYeQY/pfdWMLlml9RovjWUktiI6w== =Nq7w -----END PGP SIGNATURE----- --wUnSel6QlOqB7F7fDQBKU4KWc9jFDpxBC-- From nobody Wed Jan 31 14:20:32 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3293612FB2D; Wed, 31 Jan 2018 14:20:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , "Paul Hoffman" X-Test-IDTracker: no X-IETF-IDTracker: 6.71.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151743722620.7924.18140748465790347905.idtracker@ietfa.amsl.com> Date: Wed, 31 Jan 2018 14:20:26 -0800 Archived-At: Subject: [OPSAWG] New Version Notification - draft-mm-wg-effect-encrypt-17.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 22:20:26 -0000 A new version (-17) has been submitted for draft-mm-wg-effect-encrypt: https://www.ietf.org/internet-drafts/draft-mm-wg-effect-encrypt-17.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-mm-wg-effect-encrypt-17 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Wed Jan 31 16:59:55 2018 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CA3131463; Wed, 31 Jan 2018 16:59:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, opsawg@ietf.org, zhoutianran@huawei.com, opsawg-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151744679375.7858.8264388378086000070.idtracker@ietfa.amsl.com> Date: Wed, 31 Jan 2018 16:59:53 -0800 Archived-At: Subject: [OPSAWG] opsawg - New Meeting Session Request for IETF 101 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 00:59:54 -0000 A new meeting session request has just been submitted by Tianran Zhou, a Chair of the opsawg working group. --------------------------------------------------------- Working Group Name: Operations and Management Area Working Group Area Name: Operations and Management Area Session Requester: Tianran Zhou Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: nvo3 ippm rtgwg Second Priority: idr detnet People who must be present: Benoit Claise Warren Kumari Joe Clarke Tianran Zhou Ignas Bagdonas Resources Requested: Special Requests: PLEASE NOTE: Combined OpsAWG / OpsAREA --------------------------------------------------------- From nobody Wed Jan 31 17:50:25 2018 Return-Path: X-Original-To: expand-draft-mm-wg-effect-encrypt.all@virtual.ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CF1CC1316A6; Wed, 31 Jan 2018 17:50:19 -0800 (PST) X-Original-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Delivered-To: xfilter-draft-mm-wg-effect-encrypt.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C41B1316F4 for ; Wed, 31 Jan 2018 17:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 hjlL5-fmvaS6 for ; Wed, 31 Jan 2018 17:50:13 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 C4B7A1316A6 for ; Wed, 31 Jan 2018 17:50:12 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx1.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1eh40o-0003hD-V1 for draft-mm-wg-effect-encrypt.all@ietf.org; Thu, 01 Feb 2018 02:50:11 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eh40g-0004Zt-RD for draft-mm-wg-effect-encrypt.all@ietf.org; Wed, 31 Jan 2018 20:50:00 -0500 Received: (qmail 13768 invoked from network); 1 Feb 2018 01:49:52 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Feb 2018 01:49:51 -0000 From: Christian Huitema To: Kathleen Moriarty References: <1ecac9b1-685b-8114-780a-a43425fb167d@huitema.net> Cc: IETF Discussion Mailing List , draft-mm-wg-effect-encrypt.all@ietf.org Message-ID: <74e8271a-39cb-ff24-1823-ba9b84689585@huitema.net> Date: Wed, 31 Jan 2018 15:49:51 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F03E892CE902D46714587DAC" X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.46) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5q7p5o4FS2ioYTYBaXgdWl4Xv9krsgRhBn0ayn6qsUc7InBZ12RzAnfB ETrOZYNjIXKaajk3XDi+BsF1NYTF5nIFtwJEKaklq458dUTNtx6IlGOm10uPm8p0YIObGHqkFeKV se1sVhWabI0/+PN3sIJV0oqgDt6uIMJQLNWWX/KRuBkp/QMJeqpYCNgR0H0cYL5jlatt7W0MNi2d 0V/iMmZqbSw0FVRJK9H3d0zNEAUTOthv1Ou3CmmtB22h9g/KPA2e3QJODyA5SR2vbuhrBKvynvLP LrRh0/EOaSVotjFa+xL2pvLWAu8MmUOH8wfPvnFaPc0PnFRbqEtbatkSOSrjKiXZ6WyzC708Oxxz g1wN5Oj564+e6R2rCFo8ZeVUGoQTehXIN8sVozy06XZAec9bkKHNkJb4Y+D0fBYZ0C4t+QmxyYwW Tu+AkpEP/xGNwycC359BPtk4NdYFkImQjwM+PyfpdAljEJHtH65Ir9noASJFC/49WOPBr5nlEUI4 xKC0Gwz4mxnIO2RVVg0I2xLfHxHE6f8Csev12WGkSqB8hkP1k+v1eo9EPvR1Jfz2bspQO0agDhCF 1ta8ddnNHAjM7mUzdb03l8iCSg5Ku1+7dAgm3g3kMsor6aO2K1AiFoE2iN9q8RQcZhq1Jey+ljJt OYomraazl8PRW2YPU2FP6VM0yPyRx6Mjk9yr6Ks4vf1I1FRF+NtenQjbUczcs8WyC2YeTDG3GrvP tS8iItY29dq4bCQrb0cNRUEOy+wokKoNpL7PRmmTib7l1mO88Ek+JJdoGohgYTe5+REmdg1rLncO VVE/v5wv/lrRaL2cDz8cjU6U2l87CuBLP05pgs+lJIw5BwMa9h2lISB9gcW9a8Mrc8quJ4btPpt/ 2FLuFH7wheKV/ZDkCKWxBeZV7ESuy/c92R6t/xTsX66F8SShYd/jKzjiuDYHz/0WYr1rUwYRNVxw njRYXuwZOqqCMck= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Resent-From: Resent-To: Kathleen.Moriarty@dell.com, acmorton@att.com, Kathleen.Moriarty.ietf@gmail.com, warren@kumari.net, ekr@rtfm.com, kaduk@mit.edu, Paul Hoffman , opsawg@ietf.org, paul.hoffman@vpnc.org Resent-Message-Id: <20180201015019.CF1CC1316A6@ietfa.amsl.com> Resent-Date: Wed, 31 Jan 2018 17:50:19 -0800 (PST) Archived-At: Subject: Re: [OPSAWG] Christian's review of draft-mm-wg-effect-encrypt-13 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 01:50:20 -0000 This is a multi-part message in MIME format. --------------F03E892CE902D46714587DAC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am using the side by side feature to review the differences between draft-13 and draft-15. I am commenting here on Kathleen's message, to check whether various points are addressed. On 1/5/2018 6:07 AM, Kathleen Moriarty wrote: > Christian, > > Thanks for your review. I'll respond inline to make sure we hit each > point raised. The next version posted may not address your points, > but the subsequent update should and I expect to have that out soon. > > On Fri, Dec 8, 2017 at 11:25 AM, Kathleen Moriarty > wrote: >> Thank you, Christain and others for your reviews. Our running draft >> has addressed most comments received by mid-IETF week. We are working= >> on the others. We also received some comments from Kyle Rose and >> Brandon Williams and are working to address those as well. >> >> We'll respond on list when we get to this set of comments. >> >> Best regards, >> Kathleen >> >> On Mon, Dec 4, 2017 at 11:23 AM, Christian Huitema wrote: >>> The high level summary is that draft-mm-wg-effect-encrypt version 13 = is >>> significantly improved from previous versions, but that the document >>> would benefit a lot from additional work. I am not convinced that the= >>> sections on data center and enterprises belong in this specific docum= ent >>> - they seem too high level to bring serious information to readers. >>> Maybe stage a separate document to survey enterprise issues in some >>> depth? I also feel that section 7 is way too speculative for a survey= >>> document. > Section 7 was previously an appendix and maybe belongs back as an > appendix, we need to figure that out. There is one particular case > that a commenter saw the value of access (where he didn't in most > places) that we may need to figure out how to keep that in the body as > helpful text. OK, waiting for the next draft then. > > Since the comments on data center and enterprises is opinion, I'll > leave the text in for now. Thanks. > > ... >>> 2. Network Service Provider Monitoring >>> >>> Section 2, "Network Service Provider Monitoring", has been reorganize= d >>> to focus on management goals rather than simply provide a list of >>> existing management tools. The description of the trouble shooting ta= sks >>> in section 2.2 is useful. It makes the point that "application server= >>> operators using increased encryption should expect to be called upon >>> more frequently to assist with debugging and troubleshooting", and th= at >>> could lead to some interesting work in the IETF. >>> >>> There is paragraph at the end of section 2.1.2, Troubleshooting, that= >>> states that "the push for encryption by application providers has bee= n >>> motivated by the application of the described techniques." I think th= at >>> paragraph is misplaced. As far as I can tell, the application provide= rs >>> are first concerned with "content management" techniques that modify >>> the data stream. Any change of content has the potential to generate >>> bugs that are difficult for the application provider to fix. The seco= nd >>> concern is "ossification", when traffic characterization based on >>> inferred features of the application traffic leads to adverse >>> consequences when the application or transport protocols evolve. Neit= her >>> of those is directly relevant to the "troubleshooting" task. Maybe mo= ve >>> that paragraph higher in the document, e.g. in the introduction of >>> section 2? If not that, then maybe move it to section 2.2.2, since on= e >>> purpose of application encryption is indeed to defeat differential >>> treatment in the network. > I see your point, but am hesitant to move the text up since there is > no other general description text in that section heading and this > just covers applications. I want to comb through all of section 2 > again after this sweep of comments, so we may do a bit more to improve > this as well within a wider scope of organizational changes. A new paragraph got inserted at the end of section 2.1: "Vendors must be aware that in order for operators to better troubleshoot and manage networks with increasing amounts of encrypted traffic, ...". That paragraph appears to use normative text, "must be enhanced", and loose keywords like "reveal cleartext network parameters". I don't much like the idea of a "diagnostic" document making specific recommendations about the actual remedy. Also, "vendors" is a strange word there, as it normally implies a customer-vendor relation. AFAIK, there is no such relation between application service providers like Netflix or Google and the managers of specific networks. I get the idea that troubleshooting is a distributed task, that application providers could help network troubleshooting by providing better tools, and that doing so would be in everybody's best interest. But that can be said in a much simpler way than this additional paragraph, without implying non-existing contractual relations, and without mandating any specific outcome to the future discussions. =20 >>> I find the discussion of load balancers in section 2.2.1 somewhat >>> confusing. It seems to cover three functions: load balancers in data >>> centers, load balancers integrated with the network, and a network >>> management function that tries to maintain proper connectivity to >>> anycast addresses services in the presence of mobility. It might be >>> useful to move the discussion of "classic" load balancers to section = 3, >>> and to discuss the problem of anycast continuity in a separate >>> subsection. The anycast discussion seems to assume that the network >>> operator alone has to deal with the supposed inadequacies of the >>> application providers. It seems obvious that this problem would be mu= ch >>> better solved by improved handling of mobility in content distributio= n >>> networks, rather than by some complex machinery in the network itself= =2E >>> This might need to be stated. I am reading draft-15, and this section is still very confusing. For example, the text says that "Mobile operators deploy integrated load balancers to assist with maintaining connection state as devices migrate. With the proliferation of mobile connected devices, there is an acute need for connection-oriented protocols that maintain connections after a network migration by an endpoint." Yet the definition at the beginning of the section mentions "integrated load balancers" as "integral part of the service provided by the server pool behind that load balancer". To me, "integral part of the service" implies that the load balancer and the server pool as managed by the same entity, which is providing the application service. Yet, the discussion after that seems to imply something rather different -- a middlebox deployed by the network provider without coordination with the application service provider. I would really like to see that text rewritten. And I stand by my original comment regarding use of anycast by CDN providers. The current text assumes some unilateral action by the network provider. It would be much more productive to explain why anycast can be problematic in high mobility environments, and suggest a future discussion on how to resolve the problem. For example, TCPM and QUIC provide support for connection migration, which would probably yield much better results than guesswork in the middle of the network. >>> Section 2.2.2 on Deep Packet Inspection could state that it is very >>> often possible to classify traffic based on analysis of the encrypted= >>> data.=20 And now it does. Thanks. >>> Audio stream, video streams and web traffic have very different >>> signatures, even when encrypted. At the same time, it should also not= e >>> that many application providers are actively working to defeat the >>> "unilateral" traffic classification enabled by these techniques, >>> complementing encryption with various techniques like multiplexing or= >>> padding. We could well observe an arms race between more powerful >>> network based analysis and smarter application hiding. >>> >>> The discussion of performance enhancing proxies in section 2.2.3 stat= es >>> that "This optimization at network edges measurably improves real-tim= e >>> transmission over long delay Internet paths or networks with large >>> capacity-variation (such as mobile/cellular networks)." This is not a= >>> consensual statement. Operators do indeed hope that deploying such >>> proxies will improve performance, but independent measurements have >>> shown that such proxies often in fact degrade performance. The studie= s >>> that show improvement tend to be based on old network technologies, o= r >>> on ancient TCP stacks. If the authors want to keep a statement like >>> that, they should add references to actual measurements. At a minimum= , >>> the text should note that many application providers disagree with th= e >>> assessment presented here, and that the development of encrypted >>> transports such as QUIC is largely motivated by the desire to mitigat= e >>> the negative effects of such "performance-dehancing" proxies. > Do you have references to the studies you are referring to as that > would be helpful. Thanks. I am searching for references. But I can propose text: Not everybody agrees that "performance enhancing proxies" actually enhance performance in the long term. Proxies are typically measured against a nominal version of the transport protocol, and may fix issues encountered in that protocol version in a specific environment. On the other hand, by "taking responsibility" for the transport protocol, proxies eschew the future benefits of transport protocol improvement in the endpoints. For example, there is active research on better congestion protocols, or better error recovery algorithms, including algorithms better adapted to wireless networks. The resulting improvements can be quickly deployed by means of system updates, or even application updates in the case of transport protocols like QUIC. Experience shows that network devices are not updated with the same frequency. An up-to-date endpoint would have benefited from the protocol updates, but would be stuck with the legacy performance if it must still use the legacy "optimizer". >>> The discussion of caching in section 2.2.5 correctly states the tensi= on >>> between network usage and application control. It could also state th= e >>> inherent privacy risk associated with network based caches: they will= >>> provide a log of which users accessed what cached content. There is a= >>> reference to draft-thomson-http-bc-01, but as far as I know the autho= rs >>> have abandoned it, in part because they could not solve the related >>> privacy issues. In any case, that draft expired several month ago, an= d >>> the reference is probably not appropriate. > Other comments led to that text being updated for the next version. > The comments received took this as one of many examples, perhaps there > is a better example that could be used instead of this draft? > > Alternate approaches such as blind caches target=3D"I-D.thomson-http-bc"/> are being explored to allow = caching > of encrypted content; however, they still require cooperation= between > the content owners or CDNs and blind caches and fall outside = the scope > of what is covered in this document. Content delegation solv= es a data > visibility problem with the delegated cache, the impact remai= ns for > the use case where HTTPS encryption limits visibility to offl= oad from > congested links. This was addressed in a separate thread, thanks. But now, we get additional text in section 2.2.6 on content compression, and a new section 2.2.7 on service function chaining. The text in 2.2.6 basically says that when the network sees the same segments used on multiple connections, it can compress them efficiently. That's plausible, but just like in section 2.2.5 we have to note that there is an explicit trade-off between compression and privacy. The "segments" that could be compressed in 2.2.6 are pretty much the same as the segments that could be cached in 2.2.5. Exposing them to the network for compression has pretty much the same effect on privacy as exposing them to the network for caching. The same caveats should apply. The new section 2.2.7 describes "service function chaining", which is an architecture for distributed implementation of services. We should separate there the management function proper, which would distribute functions already provided by the network provider, and a future expansion of the network that would provide services currently offered by application providers. Encryption actually marks a nice delimitation between these two notions. Network providers may well convince some application providers to make greater use of their "service functions", but that's a business negotiation, not an architecture discussion. If and when application providers decide to subscribe to the function provided by the network, these application providers would devise ways to expose the required data. Or then, maybe not. I would suggest writing the section 2.2.7 in a rather different way. Section 2.2 already discusses various functions that could be provided by the network, or by the application providers, or by third parties like CDN. We can not the trend to organize these functions under the "service function chaining" architecture, and the general limitation that if the functions are impacted by encryption in the current architecture, they will remain similarly impacted after the network provider adopts a "service function chaining" architecture. And leave it at that. >>> In section 2.3.3, Application Layer Gateways, I was wishing it would = say >>> something about IPv6. But then of course most IPv6 deployments today >>> involve a form of NAT64... > If you have text to suggest, we'd be happy to incorporate it. "The deployment of IPv6 may well reduce the need for NAT, and the corresponding requirement for Application Layer Gateways." > >>> Section 2.3.4 documents the "HTTP Header Insertion" technique. The >>> relation between that technique and "Network Service Provider >>> Monitoring" is unclear -- header insertion is certainly not a network= >>> monitoring tool. It is also a highly controversial tool, as documente= d >>> for example in >>> https://www.theverge.com/2016/3/7/11173010/verizon-supercookie-fine-1= -3-million-fcc. >>> I wonder whether it is appropriate to describe this at all in a docum= ent >>> dedicated to network management, and my simple suggestion would be to= >>> just remove that section altogether. Failing that, the text needs to = be >>> modified to note the controversial nature of the process, and its imp= act >>> on privacy. The authors could also note that the function could be >>> trivially implemented in the client's browsers if it was really neede= d >>> and approved by the users. There is no technical need to have anythin= g >>> like that "in the network". > I see your point, but operators wanted this text in, so how about a > modification to the last sentence to try to balance it out more? As I > read the text, it describes invasive uses, so I thought that it was > clearly something the was not without controversy. > > When HTTP connections are encrypted to protect users privacy, > mobile network service > providers cannot insert headers to accomplish the, sometimes > considered controversial, functions > above. s/sometimes/often/? >>> 3. Encryption in Hosting SP Environments >>> >>> After examining network monitoring in section 2, the draft continues >>> with an analysis of "Hosting SP Environments" in section 3, and secti= on >>> 4 describes "Encryption for Enterprises". I assume that the initials = SP >>> stand for "Service Provider" -- spelling it out would not hurt. I rea= lly >>> wonder whether these sections belong in the document at all, rather t= han >>> being published in separate documents. "Hosting Service Provider >>> Environments" appears to be a subset of the general "Data Center" >>> problem. It is true that some network providers also provide data cen= ter >>> services for their customers, but these network providers represent o= nly >>> a small fraction of the service hosting industry. Similarly, some >>> network providers provide services to enterprises, but there is a wid= e >>> variety of enterprises. It is hard to believe that the authors of an >>> individual draft have authority to speak at the same time about netwo= rk >>> services, data centers, and enterprises. In my opinion, it would be >>> simpler to just excise section 3 and 4 from this draft, and use the >>> content as input for specific drafts describing issues in data center= s >>> and enterprises. >>> > I'd prefer to keep these sections separate and think others feel the > same way. Hosted data centers can occur in several layers as well. I > work for a very large company that provides hosted infrastructure as a > service, where others offer hybrid cloud options and other outsourcing > options (application service providers, etc.) on top of this layer. > It seems you may be thinking of this as a higher level of data center > offerings than what is deployed in industry. I'd prefer not to get > into listing them out as we would certainly miss some and it could be > a confusing list that doesn't help the point of the draft. 4 may not > be just for enterprise outsourcing options as in the IAAS example > provided. I think these sections are weak, and do not bring much to the readers. But I said that already. > >>> In any case, I am puzzled by the reference to Data Loss Prevention (D= LP) >>> in the introduction of section 3.1. Data exfiltration is indeed a >>> security issue, but I knew it primarily as an issue in enterprise >>> networks. It does indeed become an issue in data centers when an >>> enterprise application is hosted outside the data center, but it is a= >>> bit strange to see the first reference there. I already suggested to >>> move section 3 and 4 out to a different document. Failing that, I wou= ld >>> suggest reversing the order of section 3 and 4, i.e., discuss enterpr= ise >>> issues first and data center issues next. > I think it was contributed there as a result of offerings to > customers. Before removing it, we'd have to get confirmation that it > isn't a service provided to many enterprises with outsourced > solutions. I am pretty sure I had confirmed this point previously as > RSA offers multiple DLP solutions at several layers. With a quick > glance, RSA has cloud and data center buzz words in their product > offering descriptions in addition to network and endpoint. The new text is somewhat better. I wonder whether DLP would merit a separate subsection. Of course the really bad opponents started using encryption long ago, well before the IETF's push for privacy. This is not exactly a new problem. Also, I would expect them to use a variety of techniques to disguise and hide their data streams. Hacking routers comes to mind. >>> The discussion of Customer Access Monitoring in section 3.1.1 is a bi= t >>> strange. Most applications control customer access based on the custo= mer >>> identity, not based on the IP addresses of the customer -- the whole >>> point of the "cloud" is that applications can be accessed from anywhe= re. >>> Some applications do perform additional checks, mainly as a defense >>> against stolen credentials, and would attempt to block access if the >>> network location does not look plausible for this specific user. Thes= e >>> are useful techniques, but the relation with encryption of data is >>> somewhat thin. It seems to reinforce my point that data center issues= >>> would best be discussed in a separate document. >>> > There are certainly access restrictions based on IP and protocol > information, which a 5-tuple and a 2-tuple are often adequate. If you > are an administrator from a company who outsourced for infrastructure > and some application support, management access of your customer > application might be a simple example where this is still used. Sure, > users are mobile, but they could VPN to their company network and > connect from an approved IP. I think some of the use cases described > are examples that are fine and encryption is a very small shift. In > some of the examples, they serve as possible ways forward for the > other use cases that haven't adapted yet. Boiling down the details > and showing that log improvements and transaction monitoring > improvements in the application or changes in protocols could ease > this transition is important IMO. It's been a helpful process for > some of the participants and I hope it helps for future protocol > development to engage in these tough discussions understanding the > perspectives on either end of this debate better. > >>> The reminder of section 3 appears to be a high level tutorial on the >>> operation of data centers. It is not clear that there is a particular= >>> problem with encryption there. Indeed, I note that a lot of operators= of >>> big data centers, such as for example AWS, Azure or Google, have >>> voluntarily pushed for increased used of encryption. I don't learn mu= ch >>> by reading these sections, and I question whether they belong in the = draft. > I'll read through it again in a final sweep. We haven't gotten > complaints about this text, but I'll note your concern in my sweep. In 3.2.1, you could be a bit more explicit about application logging, and application manageability in general. Also, maybe not say that "Application logging currently lacks detail..." Is that true of every application? In general, I agree that it would be a good thing to delineate the type of information that data center managers would like to find in logs. Of course, logging too much has its own issues, such as exposures to breaches of privacy or to lawsuits. It seems we need to have a robust discussion leading to some kind of best practice document. =20 >>> 4. Encryption for Enterprises >>> >>> The discussion on encryption in enterprises would probably benefit fr= om >>> input by a variety of enterprise network managers. I found the >>> discussion somewhat hard to read. It seems that the authors want to >>> tackle three issues: the enterprise as a target for security attacks,= >>> the enterprise as an application provider, and the enterprise as a >>> network provider. These are discussed in sections 4.1.1, 4.1.2, and >>> 4.1.3. >>> >>> The description of attacks in 4.1.1 is somewhat high level. It starts= >>> from the statement that "A significant portion of malware hides its >>> activity within TLS or other encrypted protocols" to draw a requireme= nt >>> to monitor encrypted traffic, when in practice there are many other >>> monitoring points, from endpoint monitoring to data base activity log= s >>> to logs at network authentication servers -- as stated in the last >>> paragraph of the section. >>> >>> The monitoring of application performance in enterprises appears >>> strangely focused on the "IPv6 Destination Option Header (DOH) >>> implementation of Performance and Diagnostic Metrics (PDM)". I >>> understand that most big applications solve their monitoring need by >>> implementing some form of telemetry, which is not affected at all by >>> encryption, yet I see no mention of this telemetry approach in the >>> discussion. > Different data centers operate with different architectures and > approaches. We'd be happy to get text from other network operators. > I'll also do a sweep of this section and see if I can update it a bit > more to help along these points. It may come in an update following > the next one. In 4.1.1 there is a discussion relative to BYOD and exfiltration. Seriously? I mean, if I want to exfiltrate data with my phone, I can simply copy the data on the phone, and then wait until I am outside the enterprise network to exfiltrate it. The solutions that I have seen working involve personalized watermarks in downloaded content and post facto retribution against the leakers. That is, solutions designed specifically for the problem, rather than massive fishing expeditions through encrypted data... >>> I had a hard time reading section 4.1.3, Enterprise Network Diagnosti= cs >>> and Troubleshooting. It seems to cover a variety of techniques meant = to >>> monitor application services without actually instrumenting the >>> application, and as such is not very convincing. > Yes, the problem conveyed to us is that there are way too many > applications that do a poor job of providing troubleshooting data, > that it is hard to get this to an improved state. Since this was > discussed a few years ago, I started putting comments on drafts to > request text on logging to help in the long term. The organizations > with these issues have also started reaching out to offending > application developers, but it a long road. It is recognized that > it's a better long term option. I'll see what we can do with the text > on this front. OK. What don't you just say so? Proper monitoring of application behavior requires proper instrumentation of the application. When applications do not have an adequate instrumentation, managers often resort to network-based monitoring. This is problematic when the traffic is encrypted." My concern is that if an application needs to be updated to allow monitoring, it is much more beneficial in the long term to do that by better logging, rather than by somehow weakening the encryption. We should find a way to say that. >>> The meat of section 4 appears to be in section 4.2, which is covering= >>> the issue of data loss prevention, and generally detection of data >>> exfiltration. Again, this is an issue that would be worth a specializ= ed >>> draft. >>> >>> 5. Security Monitoring for Specific Attack Types >>> >>> Looks fine, and this review is already very long. > Ack, thanks. > >>> 6. Application-based Flow Information Visible to a Network >>> >>> Do we need this section at all? It seems that most of the information= >>> could be captured by adding a small subsection to 2.1. Passive Monito= ring. > IPFIX was added at the request of Benoit to more fully cover network > management protocols in the document. Brian Trammell provided that > text, so the next version will have an improved section 6. > >>> 7. Impact on Mobility Network Optimizations and New Services >>> >>> This section appears to be a mix of replication of statements already= >>> made in section 2, and some speculation on the effect of transport >>> header encryption, such as deployed in Web RTC (SCTP over DTLS) or >>> planned in QUIC. There are active discussions in the QUIC WG to provi= de >>> alternative to transport header inspection for RTT monitoring, and >>> possibly also for packet loss monitoring. >>> >>> Contrarily to the rest of the document, this section seems speculativ= e >>> in nature. It discusses the possible effects of transport header >>> encryption on the possible deployment of new services, which do not >>> appear to be based on any IETF standard. I think the document would b= e >>> stronger if some of the content of section 7 was moved to the >>> appropriate part of section 2, and if the speculative statements were= >>> published as a separate document. > We need to look at section 7 closer and will do so either in the next > version or one that follows shortly there after. It is much shorter now, and that's good. > >>> 8. Response to Increased Encryption and Looking Forward >>> >>> Looks reasonable. > Thanks for your review and helpful comments! Would you be okay with > an ack for your review and comments in the draft? > OK, as long as I am not presented as endorsing the weakening of encryption... -- Christian Huitema --------------F03E892CE902D46714587DAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I am using the side by side feature to review the differences between draft-13 and draft-15.

I am commenting here on Kathleen's message, to check whether various points are addressed.


On 1/5/2018 6:07 AM, Kathleen Moriarty wrote:
Christian,

Thanks for your review.  I'll respond inline to make sure we hit each
point raised.  The next version posted may not address your points,
but the subsequent update should and I expect to have that out soon.

On Fri, Dec 8, 2017 at 11:25 AM, Kathleen Moriarty
<kathleen.moriarty.ietf@gmail.com> wrote:

Thank you, Christain and others for your reviews.  Our running draft
has addressed most comments received by mid-IETF week.  We are working
on the others.  We also received some comments from Kyle Rose and
Brandon Williams and are working to address those as well.

We'll respond on list when we get to this set of comments.

Best regards,
Kathleen

On Mon, Dec 4, 2017 at 11:23 AM, Christian Huitema <huitema@huitema.net> wrote:

The high level summary is that draft-mm-wg-effect-encrypt version 13 is
significantly improved from previous versions, but that the document
would benefit a lot from additional work. I am not convinced that the
sections on data center and enterprises belong in this specific document
- they seem too high level to bring serious information to readers.
Maybe stage a separate document to survey enterprise issues in some
depth? I also feel that section 7 is way too speculative for a survey
document.

Section 7 was previously an appendix and maybe belongs back as an
appendix, we need to figure that out.  There is one particular case
that a commenter saw the value of access (where he didn't in most
places) that we may need to figure out how to keep that in the body as
helpful text.
OK, waiting for the next draft then.

Since the comments on data center and enterprises is opinion, I'll
leave the text in for now.  Thanks.
... 
2.  Network Service Provider Monitoring

Section 2, "Network Service Provider Monitoring", has been reorganized
to focus on management goals rather than simply provide a list of
existing management tools. The description of the trouble shooting tasks
in section 2.2 is useful. It makes the point that "application server
operators using increased encryption should expect to be called upon
more frequently to assist with debugging and troubleshooting", and that
could lead to some interesting work in the IETF.

There is paragraph at the end of section 2.1.2, Troubleshooting, that
states that "the push for encryption by application providers has been
motivated by the application of the described techniques." I think that
paragraph is misplaced. As far as I can tell, the application providers
are first concerned with "content management" techniques that modify
the data stream. Any change of content has the potential to generate
bugs that are difficult for the application provider to fix. The second
concern is "ossification", when traffic characterization based on
inferred features of the application traffic leads to adverse
consequences when the application or transport protocols evolve. Neither
of those is directly relevant to the "troubleshooting" task. Maybe move
that paragraph higher in the document, e.g. in the introduction of
section 2? If not that, then maybe move it to section 2.2.2, since one
purpose of application encryption is indeed to defeat differential
treatment in the network.

I see your point, but am hesitant to move the text up since there is
no other general description text in that section heading and this
just covers applications.  I want to comb through all of section 2
again after this sweep of comments, so we may do a bit more to improve
this as well within a wider scope of organizational changes.

A new paragraph got inserted at the end of section 2.1: "Vendors must be aware that in order for operators to better troubleshoot and manage networks with increasing amounts of encrypted traffic, ...". That paragraph appears to use normative text, "must be enhanced", and loose keywords like "reveal cleartext network parameters". I don't much like the idea of a "diagnostic" document making specific recommendations about the actual remedy.

Also, "vendors" is a strange word there, as it normally implies a customer-vendor relation. AFAIK, there is no such relation between application service providers like Netflix or Google and the managers of specific networks.

I get the idea that troubleshooting is a distributed task, that application providers could help network troubleshooting by providing better tools, and that doing so would be in everybody's best interest. But that can be said in a much simpler way than this additional paragraph, without implying non-existing contractual relations, and without mandating any specific outcome to the future discussions.
 

      

        

          
I find the discussion of load balancers in section 2.2.1 somewhat
confusing. It seems to cover three functions: load balancers in data
centers, load balancers integrated with the network, and a network
management function that tries to maintain proper connectivity to
anycast addresses services in the presence of mobility. It might be
useful to move the discussion of "classic" load balancers to section 3,
and to discuss the problem of anycast continuity in a separate
subsection. The anycast discussion seems to assume that the network
operator alone has to deal with the supposed inadequacies of the
application providers. It seems obvious that this problem would be much
better solved by improved handling of mobility in content distribution
networks, rather than by some complex machinery in the network itself.
This might need to be stated.

        

      

    

    I am reading draft-15, and this section is still very confusing. For
    example, the text says that "Mobile operators deploy integrated load
    balancers to assist with maintaining connection state as devices
    migrate.  With the proliferation of mobile connected devices, there
    is an acute need for connection-oriented protocols that maintain
    connections after a network migration by an endpoint." Yet the
    definition at the beginning of the section mentions "integrated load
    balancers" as "integral part of the service provided by the server
    pool behind that load balancer". To me, "integral part of the
    service" implies that the load balancer and the server pool as
    managed by the same entity, which is providing the application
    service. Yet, the discussion after that seems to imply something
    rather different -- a middlebox deployed by the network provider
    without coordination with the application service provider.

    

    I would really like to see that text rewritten.

    

    And I stand by my original comment regarding use of anycast by CDN
    providers. The current text assumes some unilateral action by the
    network provider. It would be much more productive to explain why
    anycast can be problematic in high mobility environments, and
    suggest a future discussion on how to resolve the problem. For
    example, TCPM and QUIC provide support for connection migration,
    which would probably yield much better results than guesswork in the
    middle of the network.

    

    

      

        

          
Section 2.2.2 on Deep Packet Inspection could state that it is very
often possible to classify traffic based on analysis of the encrypted
data. 

        

      

    

    And now it does. Thanks.

    

      

        

          
Audio stream, video streams and web traffic have very different
signatures, even when encrypted. At the same time, it should also note
that many application providers are actively working to defeat the
"unilateral" traffic classification enabled by these techniques,
complementing encryption with various techniques like multiplexing or
padding. We could well observe an arms race between more powerful
network based analysis and smarter application hiding.

The discussion of performance enhancing proxies in section 2.2.3 states
that "This optimization at network edges measurably improves real-time
transmission over long delay Internet paths or networks with large
capacity-variation (such as mobile/cellular networks)." This is not a
consensual statement. Operators do indeed hope that deploying such
proxies will improve performance, but independent measurements have
shown that such proxies often in fact degrade performance. The studies
that show improvement tend to be based on old network technologies, or
on ancient TCP stacks. If the authors want to keep a statement like
that, they should add references to actual measurements. At a minimum,
the text should note that many application providers disagree with the
assessment presented here, and that the development of encrypted
transports such as QUIC is largely motivated by the desire to mitigate
the negative effects of such "performance-dehancing" proxies.


        

      

      
 Do you have references to the studies you are referring to as that
would be helpful.  Thanks.

    

    

    I am searching for references. But I can propose text:

    

    Not everybody agrees that "performance enhancing proxies" actually
    enhance performance in the long term. Proxies are typically measured
    against a nominal version of the transport protocol, and may fix
    issues encountered in that protocol version in a specific
    environment. On the other hand, by "taking responsibility" for the
    transport protocol, proxies eschew the future benefits of transport
    protocol improvement in the endpoints. For example, there is active
    research on better congestion protocols, or better error recovery
    algorithms, including algorithms better adapted to wireless
    networks. The resulting improvements can be quickly deployed by
    means of system updates, or even application updates in the case of
    transport protocols like QUIC. Experience shows that network devices
    are not updated with the same frequency. An up-to-date endpoint
    would have benefited from the protocol updates, but would be stuck
    with the legacy performance if it must still use the legacy
    "optimizer".

    

    

      

        

          
The discussion of caching in section 2.2.5 correctly states the tension
between network usage and application control. It could also state the
inherent privacy risk associated with network based caches: they will
provide a log of which users accessed what cached content. There is a
reference to draft-thomson-http-bc-01, but as far as I know the authors
have abandoned it, in part because they could not solve the related
privacy issues. In any case, that draft expired several month ago, and
the reference is probably not appropriate.


        

      

      
Other comments led to that text being updated for the next version.
The comments received took this as one of many examples, perhaps there
is a better example that could be used instead of this draft?

          Alternate approaches such as blind caches <xref
          target="I-D.thomson-http-bc"/> are being explored to allow caching
          of encrypted content; however, they still require cooperation between
          the content owners or CDNs and blind caches and fall outside the scope
          of what is covered in this document.  Content delegation solves a data
          visibility problem with the delegated cache, the impact remains for
          the use case where HTTPS encryption limits visibility to offload from
          congested links.


    

    

    This was addressed in a separate thread, thanks.

    

    But now, we get additional text in section 2.2.6 on content
    compression, and a new section 2.2.7 on service function chaining.

    

    The text in 2.2.6 basically says that when the network sees the same
    segments used on multiple connections, it can compress them
    efficiently. That's plausible, but just like in section 2.2.5 we
    have to note that there is an explicit trade-off between compression
    and privacy. The "segments" that could be compressed in 2.2.6 are
    pretty much the same as the segments that could be cached in 2.2.5.
    Exposing them to the network for compression has pretty much the
    same effect on privacy as exposing them to the network for caching.
    The same caveats should apply.

    

    The new section 2.2.7 describes "service function chaining", which
    is an architecture for distributed implementation of services. We
    should separate there the management function proper, which would
    distribute functions already provided by the network provider, and a
    future expansion of the network that would provide services
    currently offered by application providers. Encryption actually
    marks a nice delimitation between these two notions. Network
    providers may well convince some application providers to make
    greater use of their "service functions", but that's a business
    negotiation, not an architecture discussion. If and when application
    providers decide to subscribe to the function provided by the
    network, these application providers would devise ways to expose the
    required data. Or then, maybe not.

    

    I would suggest writing the section 2.2.7 in a rather different way.
    Section 2.2 already discusses various functions that could be
    provided by the network, or by the application providers, or by
    third parties like CDN. We can not the trend to organize these
    functions under the "service function chaining" architecture, and
    the general limitation that if the functions are impacted by
    encryption in the current architecture, they will remain similarly
    impacted after the network provider adopts a "service function
    chaining" architecture. And leave it at that.

    

    

      

        

          
In section 2.3.3, Application Layer Gateways, I was wishing it would say
something about IPv6. But then of course most IPv6 deployments today
involve a form of NAT64...


        

      

      
If you have text to suggest, we'd be happy to incorporate it.

    

    "The deployment of IPv6 may well reduce the need for NAT, and the
    corresponding requirement for Application Layer Gateways."

    

    

      



      

        

          
Section 2.3.4 documents the "HTTP Header Insertion" technique. The
relation between that technique and "Network Service Provider
Monitoring" is unclear -- header insertion is certainly not a network
monitoring tool. It is also a highly controversial tool, as documented
for example in
https://www.theverge.com/2016/3/7/11173010/verizon-supercookie-fine-1-3-million-fcc.
I wonder whether it is appropriate to describe this at all in a document
dedicated to network management, and my simple suggestion would be to
just remove that section altogether. Failing that, the text needs to be
modified to note the controversial nature of the process, and its impact
on privacy. The authors could also note that the function could be
trivially implemented in the client's browsers if it was really needed
and approved by the users. There is no technical need to have anything
like that "in the network".


        

      

      
I see your point, but operators wanted this text in, so how about a
modification to the last sentence to try to balance it out more?  As I
read the text, it describes invasive uses, so I thought that it was
clearly something the was not without controversy.

         When HTTP connections are encrypted to protect users privacy,
mobile network service
          providers cannot insert headers to accomplish the, sometimes
considered controversial, functions
          above.

    

    s/sometimes/often/?

    

    

      

      

        

          
3.  Encryption in Hosting SP Environments

After examining network monitoring in section 2, the draft continues
with an analysis of "Hosting SP Environments" in section 3, and section
4 describes "Encryption for Enterprises". I assume that the initials SP
stand for "Service Provider" -- spelling it out would not hurt. I really
wonder whether these sections belong in the document at all, rather than
being published in separate documents. "Hosting Service Provider
Environments" appears to be a subset of the general "Data Center"
problem. It is true that some network providers also provide data center
services for their customers, but these network providers represent only
a small fraction of the service hosting industry. Similarly, some
network providers provide services to enterprises, but there is a wide
variety of enterprises. It is hard to believe that the authors of an
individual draft have authority to speak at the same time about network
services, data centers, and enterprises. In my opinion, it would be
simpler to just excise section 3 and 4 from this draft, and use the
content as input for specific drafts describing issues in data centers
and enterprises.



        

      

      
I'd prefer to keep these sections separate and think others feel the
same way.  Hosted data centers can occur in several layers as well.  I
work for a very large company that provides hosted infrastructure as a
service, where others offer hybrid cloud options and other outsourcing
options (application service providers, etc.) on top of this layer.
It seems you may be thinking of this as a higher level of data center
offerings than what is deployed in industry.  I'd prefer not to get
into listing them out as we would certainly miss some and it could be
a confusing list that doesn't help the point of the draft.  4 may not
be just for enterprise outsourcing options as in the IAAS example
provided.


    

    I think these sections are weak, and do not bring much to the
    readers. But I said that already.

    

    

    

      



      

        

          
In any case, I am puzzled by the reference to Data Loss Prevention (DLP)
in the introduction of section 3.1. Data exfiltration is indeed a
security issue, but I knew it primarily as an issue in enterprise
networks. It does indeed become an issue in data centers when an
enterprise application is hosted outside the data center, but it is a
bit strange to see the first reference there. I already suggested to
move section 3 and 4 out to a different document. Failing that, I would
suggest reversing the order of section 3 and 4, i.e., discuss enterprise
issues first and data center issues next.


        

      

      
I think it was contributed there as a result of offerings to
customers.  Before removing it, we'd have to get confirmation that it
isn't a service provided to many enterprises with outsourced
solutions.  I am pretty sure I had confirmed this point previously as
RSA offers multiple DLP solutions at several layers.  With a quick
glance, RSA has cloud and data center buzz words in their product
offering descriptions in addition to network and endpoint.

    

    

    The new text is somewhat better. I wonder whether DLP would merit a
    separate subsection.

    

    Of course the really bad opponents started using encryption long
    ago, well before the IETF's push for privacy. This is not exactly a
    new problem. Also, I would expect them to use a variety of
    techniques to disguise and hide their data streams. Hacking routers
    comes to mind.

    

    

      

        

          
The discussion of Customer Access Monitoring in section 3.1.1 is a bit
strange. Most applications control customer access based on the customer
identity, not based on the IP addresses of the customer -- the whole
point of the "cloud" is that applications can be accessed from anywhere.
Some applications do perform additional checks, mainly as a defense
against stolen credentials, and would attempt to block access if the
network location does not look plausible for this specific user. These
are useful techniques, but the relation with encryption of data is
somewhat thin. It seems to reinforce my point that data center issues
would best be discussed in a separate document.



        

      

      
There are certainly access restrictions based on IP and protocol
information, which a 5-tuple and a 2-tuple are often adequate.  If you
are an administrator from a company who outsourced for infrastructure
and some application support, management access of your customer
application might be a simple example where this is still used.  Sure,
users are mobile, but they could VPN to their company network and
connect from an approved IP.  I think some of the use cases described
are examples that are fine and encryption is a very small shift.  In
some of the examples, they serve as possible ways forward for the
other use cases that haven't adapted yet.  Boiling down the details
and showing that log improvements and transaction monitoring
improvements in the application or changes in protocols could ease
this transition is important IMO.  It's been a helpful process for
some of the participants and I hope it helps for future protocol
development to engage in these tough discussions understanding the
perspectives on either end of this debate better.



      

        

          
The reminder of section 3 appears to be a high level tutorial on the
operation of data centers. It is not clear that there is a particular
problem with encryption there. Indeed, I note that a lot of operators of
big data centers, such as for example AWS, Azure or Google, have
voluntarily pushed for increased used of encryption. I don't learn much
by reading these sections, and I question whether they belong in the draft.


        

      

      
I'll read through it again in a final sweep.  We haven't gotten
complaints about this text, but I'll note your concern in my sweep.

    

    

    In 3.2.1, you could be a bit more explicit about application
    logging, and application manageability in general. Also, maybe not
    say that "Application logging currently lacks detail..." Is that true of every
      application? In general, I agree that it would be a good thing to
      delineate the type of information that data center managers would
      like to find in logs. Of course, logging too much has its own
      issues, such as exposures to breaches of privacy or to lawsuits.
      It seems we need to have a robust discussion leading to some kind
      of best practice document.

       
    
    

      

        

          
4.  Encryption for Enterprises

The discussion on encryption in enterprises would probably benefit from
input by a variety of enterprise network managers. I found the
discussion somewhat hard to read. It seems that the authors want to
tackle three issues: the enterprise as a target for security attacks,
the enterprise as an application provider, and the enterprise as a
network provider. These are discussed in sections 4.1.1, 4.1.2, and
4.1.3.

The description of attacks in 4.1.1 is somewhat high level. It starts
from the statement that "A significant portion of malware hides its
activity within TLS or other encrypted protocols" to draw a requirement
to monitor encrypted traffic, when in practice there are many other
monitoring points, from endpoint monitoring to data base activity logs
to logs at network authentication servers -- as stated in the last
paragraph of the section.

The monitoring of application performance in enterprises appears
strangely focused on the "IPv6 Destination Option Header (DOH)
implementation of Performance and Diagnostic Metrics (PDM)". I
understand that most big applications solve their monitoring need by
implementing some form of telemetry, which is not affected at all by
encryption, yet I see no mention of this telemetry approach in the
discussion.


        

      

      
Different data centers operate with different architectures and
approaches. We'd be happy to get text from other network operators.
I'll also do a sweep of this section and see if I can update it a bit
more to help along these points. It may come in an update following
the next one.

    

    

    In 4.1.1 there is a discussion relative to BYOD and exfiltration.
    Seriously? I mean, if I want to exfiltrate data with my phone, I can
    simply copy the data on the phone, and then wait until I am outside
    the enterprise network to exfiltrate it. The solutions that I have
    seen working involve personalized watermarks in downloaded content
    and post facto retribution against the leakers. That is, solutions
    designed specifically for the problem, rather than massive fishing
    expeditions through encrypted data...

    

      

        

          
I had a hard time reading section 4.1.3, Enterprise Network Diagnostics
and Troubleshooting. It seems to cover a variety of techniques meant to
monitor application services without actually instrumenting the
application, and as such is not very convincing.


        

      

      
Yes, the problem conveyed to us is that there are way too many
applications that do a poor job of providing troubleshooting data,
that it is hard to get this to an improved state.  Since this was
discussed a few years ago, I started putting comments on drafts to
request text on logging to help in the long term.  The organizations
with these issues have also started reaching out to offending
application developers, but it a long road.  It is recognized that
it's a better long term option.  I'll see what we can do with the text
on this front.

    

    

    OK. What don't you just say so? Proper monitoring of application
    behavior requires proper instrumentation of the application. When
    applications do not have an adequate instrumentation, managers often
    resort to network-based monitoring. This is problematic when the
    traffic is encrypted."

    

    My concern is that if an application needs to be updated to allow
    monitoring, it is much more beneficial in the long term to do that
    by better logging, rather than by somehow weakening the encryption.
    We should find a way to say that.

    

    

      

        

          
The meat of section 4 appears to be in section 4.2, which is covering
the issue of data loss prevention, and generally detection of data
exfiltration. Again, this is an issue that would be worth a specialized
draft.

5.  Security Monitoring for Specific Attack Types

Looks fine, and this review is already very long.


        

      

      
Ack, thanks.



      

        

          
6.  Application-based Flow Information Visible to a Network

Do we need this section at all? It seems that most of the information
could be captured by adding a small subsection to 2.1. Passive Monitoring.


        

      

      
IPFIX was added at the request of Benoit to more fully cover network
management protocols in the document.  Brian Trammell provided that
text, so the next version will have an improved section 6.



      

        

          
7.  Impact on Mobility Network Optimizations and New Services

This section appears to be a mix of replication of statements already
made in section 2, and some speculation on the effect of transport
header encryption, such as deployed in Web RTC (SCTP over DTLS) or
planned in QUIC. There are active discussions in the QUIC WG to provide
alternative to transport header inspection for RTT monitoring, and
possibly also for packet loss monitoring.

Contrarily to the rest of the document, this section seems speculative
in nature. It discusses the possible effects of transport header
encryption on the possible deployment of new services, which do not
appear to be based on any IETF standard. I think the document would be
stronger if some of the content of section 7 was moved to the
appropriate part of section 2, and if the speculative statements were
published as a separate document.


        

      

      
We need to look at section 7 closer and will do so either in the next
version or one that follows shortly there after.

    

    

    It is much shorter now, and that's good.

    

      



      

        

          
8.  Response to Increased Encryption and Looking Forward

Looks reasonable.


        

      

      
Thanks for your review and helpful comments!  Would you be okay with
an ack for your review and comments in the draft?



    

    OK, as long as I am not presented as endorsing the weakening of
    encryption...

    

    -- Christian Huitema

  


--------------F03E892CE902D46714587DAC--