From nobody Tue Aug 1 01:46:39 2017 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 CC265132C23; Tue, 1 Aug 2017 01:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xSO3mvBN-JD; Tue, 1 Aug 2017 01:46:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A978512EC13; Tue, 1 Aug 2017 01:46:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLR56844; Tue, 01 Aug 2017 08:46:27 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 1 Aug 2017 09:45:30 +0100 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.0235.001; Tue, 1 Aug 2017 16:45:27 +0800 From: Tianran Zhou To: "netmod@ietf.org" CC: "opsawg@ietf.org" Thread-Topic: Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained Thread-Index: AQHTCqKFiijio3W/uUKZZPsDSn27pQ== Date: Tue, 1 Aug 2017 08:45:27 +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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59803FE3.0064, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4009a9bac0d8de1dd2390f4b5f6e353e Archived-At: Subject: [OPSAWG] Cross-post to Netmod for LC comments//FW: WG LC for 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: Tue, 01 Aug 2017 08:46:31 -0000 Hi NETMOD WG, This is a cross post for the ongoing WGLC in OPSAWG.=20 Service Models Explained https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ Please send your comments by August 18, 2017. If you do not feel this docu= ment should advance, please state your reasons why. Regards, Tianran, OPSAWG co-chair -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Friday, July 28, 2017 11:06 AM To: opsawg@ietf.org Cc: opsawg-chairs@ietf.org Subject: [OPSAWG] WG LC for Service Models Explained Dear OPSAWG, This is a notice to start a three-week OPSAWG WG last call for the document= : Service Models Explained https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ Please read the above draft and send any issues, comments, or corrections t= o this mailing list. Please indicate your support or concerns by Friday August 18, 2017. Authors:=20 Although this is an informational document, please indicate with an email o= n the mailing list explicitly whether you are aware or you are not aware of= any IPRs related to the drafts. Thanks, Tianran, as co-chair _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Aug 1 03:31:13 2017 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 E060E131FFC; Tue, 1 Aug 2017 03:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxFTZ33r2Q4N; Tue, 1 Aug 2017 03:31:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F484131FF9; Tue, 1 Aug 2017 03:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6146; q=dns/txt; s=iport; t=1501583464; x=1502793064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sjTptGgs8sF4U4LIzzHh4/1CuwcBuW0fG3zTl93bvs0=; b=fckrIcCpigErQY9m6Cs6VCKIZ9VZx7JujyFAoRmcj+wtLSB0fYbN7Pso fTf9CmCGxyUPkW/J/pjuN5vCz/CrQfubjHsqZbvZKFhEfirFM7CAluRxI cM6TsePAt+bp54IpvUpRQW0q64p4bPx6KXF42Mhz5RP97Lw1nQrya1ZH6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAAABV4BZ/4kNJK1TBAYZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDWmRtJweOB498gWyWDQ6CBCENhEpPAhqEAj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBGwYROgsFBwQCAQgRBAEBAQICIwMCAgIlCxQBCAgCBA4DA?= =?us-ascii?q?hSKEwgQrjKCJotOAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4IdggKBTIFhK4J?= =?us-ascii?q?7hD0DAQcLARENGIJ8MIIxBYlZlhsCh06HG4U9gg0ZhTuDeIZokSSEUgEfOH8Ld?= =?us-ascii?q?xVJEgGCcYITHBmBTkQyh36BI4EOAQEB?= X-IronPort-AV: E=Sophos;i="5.41,305,1498521600"; d="scan'208";a="277164236" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2017 10:31:03 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v71AV3H2015866 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2017 10:31:03 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Aug 2017 05:31:02 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Tue, 1 Aug 2017 05:31:02 -0500 From: "Carl Moberg (camoberg)" To: Tianran Zhou CC: "netmod@ietf.org" , "opsawg@ietf.org" Thread-Topic: [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained Thread-Index: AQHTCqKFiijio3W/uUKZZPsDSn27paJvoT+A Date: Tue, 1 Aug 2017 10:31:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.95] Content-Type: text/plain; charset="utf-8" Content-ID: <701748482D71A140AAA69391FA2DDAA8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] [netmod] Cross-post to Netmod for LC comments//FW: WG LC for 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: Tue, 01 Aug 2017 10:31:08 -0000 VGlhbnJhbiwgT1BTQVdHLA0KDQogTm93IHRoYXQgUkZDODE5OSBpcyBwdWJsaXNoZWQsIEkgaGF2 ZSB0d28gKHNvbWV3aGF0IGFzc29jaWF0ZWQpIHBvaW50cyBvZg0KIGhpZ2gtbGV2ZWwgZmVlZGJh Y2sgb24gZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQ6DQoNCiAgLSBU aGUgdGVybSDigJxOZXR3b3JrIFNlcnZpY2UgTW9kZWzigJ0gaW4gUkZDIDgxOTkgaXMgaW50ZW5k ZWQgdG8gY292ZXIgYm90aA0KICAgICJDdXN0b21lciBTZXJ2aWNlIE1vZGVs4oCdIGFzIHdlbGwg YXMg4oCcU2VydmljZSBEZWxpdmVyeSBNb2RlbOKAnSBhcyBkZWZpbmVkDQogICAgaW4gZHJhZnQt aWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQuIEF0IHRoZSB0aW1lIG9mIHRoZSBm aXJzdA0KICAgIHJldmlzaW9uIG9mIHdoYXQgd2FzIGRyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLXlh bmctbW9kZWwtY2xhc3NpZmljYXRpb24NCiAgICB3ZSBkaXNjdXNzZWQgZnVydGhlciBzcGxpdHRp bmcgIk5ldHdvcmsgU2VydmljZSBNb2RlbOKAnSBpbnRvIHNtYWxsZXINCiAgICBjb21wb25lbnRz LCBidXQgZGVjaWRlZCBhZ2FpbnN0IGl0IHNpbmNlIHdlIGRpZCBub3Qgc2VlIGEgY29uc2Vuc3Vz IG9uDQogICAgd2hhdCB0aGF0IHNwbGl0IHdvdWxkIGxvb2sgbGlrZS4gSSBiZWxpZXZlIHRoZSBh dXRob3JzIGhlcmUgaXMNCiAgICBzdWdnZXN0aW5nIHN1Y2ggYSBmdXJ0aGVyIHNwbGl0Lg0KDQog ICAgVGhlcmUgaXMgb25lIHNwZWNpZmljIHBhc3NhZ2UgaW4gdGhpcyBkcmFmdCB0aGF0IEkgd291 bGQgc3VnZ2VzdCBjb3VsZA0KICAgIHVzZSByZXBocmFzaW5nIGlmIHRoZSBhdXRob3JzIGFncmVl IHRvIHRoZSBhYm92ZToNCg0KIiIiDQogICBBcyBwcmV2aW91c2x5IG5vdGVkLCBbSS1ELmlldGYt bmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb25dDQogICBwcm92aWRlcyBhIGNsYXNzaWZp Y2F0aW9uIG9mIFlBTkcgZGF0YSBtb2RlbHMuICBJdCBpbnRyb2R1Y2VzIHRoZQ0KICAgdGVybSAi TmV0d29yayBTZXJ2aWNlIFlBTkcgTW9kdWxlIiB0byBpZGVudGlmeSB0aGUgdHlwZSBvZiBtb2Rl bCB1c2VkDQogICB0byAiZGVzY3JpYmUgdGhlIGNvbmZpZ3VyYXRpb24sIHN0YXRlIGRhdGEsIG9w ZXJhdGlvbnMgYW5kDQogICBub3RpZmljYXRpb25zIG9mIGFic3RyYWN0IHJlcHJlc2VudGF0aW9u cyBvZiBzZXJ2aWNlcyBpbXBsZW1lbnRlZCBvbg0KICAgb25lIG9yIG11bHRpcGxlIG5ldHdvcmsg ZWxlbWVudHMuIiAgVGhlc2UgYXJlIHNlcnZpY2UgZGVsaXZlcnkgbW9kZWxzDQogICBhcyBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCwgdGhhdCBpcywgdGhleSBhcmUgdGhlIG1vZGVscyB1c2Vk IG9uDQogICB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIFNlcnZpY2UgT3JjaGVzdHJhdG9yIG9y IE9TUy9CU1MgYW5kIHRoZQ0KICAgTmV0d29yayBPcmNoZXN0cmF0b3IgYXMgc2hvd24gaW4gRmln dXJlIDMuDQoiIiINCg0KIC0gQW5kIHRoaXMgZ2V0cyB0byBteSBzZWNvbmQgcG9pbnQgb2YgZmVl ZGJhY2suIEZpZ3VyZSA0LiBpbiB0aGUgZHJhZnQgc2VlbXMNCiAgIHRvIHN1Z2dlc3QgdGhhdCB0 aGUgIlNlcnZpY2UgT3JjaGVzdHJhdG9yIiBpcyBhbiBlbnRpdHkgc2VwYXJhdGUgZnJvbSB0aGUN CiAgICJPcGVyYXRpb25zIGFuZCBCdXNpbmVzcyBTdXBwb3J0IFN5c3RlbXMgKE9TUy9CU1MpIi4g QW5kIGFsc28gdGhhdA0KICAgQ3VzdG9tZXJzIChhcyBkZWZpbmVkKSBpbiBTZWN0aW9uIDIgaW50 ZXJmYWNlIGRpcmVjdGx5IHdpdGggdGhhdCBlbnRpdHkuDQogICBUaGlzIGlzIGEgdmVyeSB1bnVz dWFsIGNvbnN0cnVjdCwgaW4gdGhlIHNlbnNlIHRoYXQ6DQogICAgbyBUaGUgY29tbW9uIHRheG9u b21vbXkgZnJvbSBlLmcuIFRNRm9ydW0gd291bGQgY2xhc3NpZnkgYSBzZXJ2aWNlDQogICAgICBv cmNoZXN0cmF0b3IgYXMgYSBwYXJ0IG9mIHRoZSBPU1MvQlNTIHN0YWNrLCBzaW5jZS4uLg0KICAg IG8gVGhlIHN1Y2Nlc3NmdWwgYWN0aXZhdGlvbiBvZiBhIHNlcnZpY2UgaW5jbHVkZXMgbWFueSBw YXJ0cyBvZiB0aGUNCiAgICAgIE9TUy9CU1Mtc3RhY2sgaW5jbHVkaW5nIG9wZXJhdGlvbmFsIHJl YWRpbmVzcyAoYXJlIHRoZXJlIHBoeXNpY2FsIHBvcnRzDQogICAgICBhdmFpbGFibGUpLCBiaWxs aW5nIG1hbmFnZW1lbnQgKGlzIHRoZSBjdXN0b21lciBhbGxvd2VkIHRvIHBlcmZvcm0gZS5nLg0K ICAgICAgdGhpcyByZXNvdXJjZSBleHBhbnNpb24pLCBhbmQgYXNzdXJhbmNlIChjaGFuZ2VkIHNl cnZpY2VzIHJlcXVpcmUgbmV3DQogICAgICBhc3N1cmFuY2UgcGFyYW1ldGVycykuIFRoaXMgbWFr ZXMgaXQgaGFyZCB0byBzZXBhcmF0ZSBvdXQgYSBDdXN0b21lcg0KICAgICAgaW50ZXJmYWNlIHRv IHNlcnZpY2Ugb3JjaGVzdHJhdGlvbiBvbmx5LCBzZXBhcmF0ZSBmcm9tIHRoZSBPU1MvQlNTDQog ICAgICBzdGFjay4NCg0KIFRoaXMgYW4gaW5mb3JtYXRpb25hbCBkcmFmdCBhbmQgYXMgc3VjaCBp cyBmb3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiwgYW5kIG5vdA0KIG5lY2Vzc2FyaWx5IGludGVuZGVk IHRvIHJlcHJlc2VudCBjb21tdW5pdHkgY29uc2Vuc3VzIG9yIHJlY29tbWVuZGF0aW9uLCBqdXN0 DQogbGlrZSA4MTE5LiBCdXQgSSB3b3VsZCBzdWdnZXN0IHRoZSBkb2N1bWVudCBjb3VsZCBiZSBp bXByb3ZlZCBieSBlbGFib3JhdGluZw0KIHRoZSBwb2ludCBvZiB0aGUgc2VwYXJhdGlvbiBvZiB0 aGUgb3JjaGVzdHJhdG9yIGFuZCB0aGUgQlNTL09TUyBhbmQgdGhlDQogcmVzdWx0aW5nIGRpZmZl cmVuY2UgaW4gbW9kdWxlIHR5cGVzLg0KDQotLQ0KQ2FybCBNb2JlcmcNCmNhbW9iZXJnQGNpc2Nv LmNvbQ0KDQo+IE9uIEF1ZyAxLCAyMDE3LCBhdCAxMDo0NSBBTSwgVGlhbnJhbiBaaG91IDx6aG91 dGlhbnJhbkBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIE5FVE1PRCBXRywNCj4gDQo+IFRo aXMgaXMgYSBjcm9zcyBwb3N0IGZvciB0aGUgb25nb2luZyBXR0xDIGluIE9QU0FXRy4gDQo+IA0K PiBTZXJ2aWNlIE1vZGVscyBFeHBsYWluZWQNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQvDQo+IA0KPiBQ bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIGJ5IEF1Z3VzdCAxOCwgMjAxNy4gSWYgeW91IGRvIG5v dCBmZWVsIHRoaXMgIGRvY3VtZW50IHNob3VsZCBhZHZhbmNlLCBwbGVhc2Ugc3RhdGUgeW91ciBy ZWFzb25zIHdoeS4NCj4gDQo+IFJlZ2FyZHMsDQo+IFRpYW5yYW4sIE9QU0FXRyBjby1jaGFpcg0K PiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogT1BTQVdHIFttYWlsdG86 b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaWFucmFuIFpob3UNCj4gU2Vu dDogRnJpZGF5LCBKdWx5IDI4LCAyMDE3IDExOjA2IEFNDQo+IFRvOiBvcHNhd2dAaWV0Zi5vcmcN Cj4gQ2M6IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW09QU0FXR10gV0cgTEMg Zm9yIFNlcnZpY2UgTW9kZWxzIEV4cGxhaW5lZA0KPiANCj4gRGVhciBPUFNBV0csDQo+IA0KPiBU aGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0IGEgdGhyZWUtd2VlayBPUFNBV0cgV0cgbGFzdCBjYWxs IGZvciB0aGUgZG9jdW1lbnQ6DQo+IA0KPiBTZXJ2aWNlIE1vZGVscyBFeHBsYWluZWQNCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1t b2RlbC1leHBsYWluZWQvDQo+IA0KPiBQbGVhc2UgcmVhZCB0aGUgYWJvdmUgZHJhZnQgYW5kIHNl bmQgYW55IGlzc3VlcywgY29tbWVudHMsIG9yIGNvcnJlY3Rpb25zIHRvIHRoaXMgbWFpbGluZyBs aXN0Lg0KPiBQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IG9yIGNvbmNlcm5zIGJ5IEZyaWRh eSBBdWd1c3QgMTgsIDIwMTcuDQo+IA0KPiBBdXRob3JzOiANCj4gQWx0aG91Z2ggdGhpcyBpcyBh biBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LCBwbGVhc2UgaW5kaWNhdGUgd2l0aCBhbiBlbWFpbCBv biB0aGUgbWFpbGluZyBsaXN0IGV4cGxpY2l0bHkgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9yIHlv dSBhcmUgbm90IGF3YXJlIG9mIGFueSBJUFJzIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0cy4NCj4gDQo+ IA0KPiBUaGFua3MsDQo+IFRpYW5yYW4sIGFzIGNvLWNoYWlyDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPUFNBV0cgbWFpbGluZyBsaXN0 DQo+IE9QU0FXR0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2F3Zw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Tue Aug 1 07:15:34 2017 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 1738B13217F; Tue, 1 Aug 2017 07:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 PIHtiMeWQ7rs; Tue, 1 Aug 2017 07:15:32 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD7613217D; Tue, 1 Aug 2017 07:15:31 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v71EFMgD029076; Tue, 1 Aug 2017 15:15:22 +0100 Received: from 950129200 ([210.160.37.27]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v71EFFA4029060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Aug 2017 15:15:19 +0100 Reply-To: From: "Adrian Farrel" To: , "'Tianran Zhou'" , Cc: References: <787AE7BB302AE849A7480A190F8B93300A014245@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A014245@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 1 Aug 2017 15:15:14 +0100 Message-ID: <00b101d30ad0$9b842380$d28c6a80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH3xPK8SnNx+dJdxeKTifN90yR7aQIsSZSpohS0rRA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23230.007 X-TM-AS-Result: No--32.951-10.0-31-10 X-imss-scan-details: No--32.951-10.0-31-10 X-TMASE-MatchedRID: u6ojmU07PKynykMun0J1wiTvxLEspKGgJCrNy6AbUJVaW2Ktn+I8/nkv YGlzSDgVTWLw2jvbfpwoGF6uLtKGsvnVY0DWsTq3kkRQ7aojOUtBE9kJF1f1wtJgDNnoqapaDYX q2a0NnVVOPREOfdCh4irjRM2tKUbNvu2VsndWvkV1+T1nEN2yFqX1XMd/SqvuGtRDsD0yuYYP65 UmIJNL5MAr8OnIIfRkMblbAAttHSO3DZqopyKYuI6MisxJraxHbd6rGhWOAwStj24Xqh0yXLgdV RJvMmASUAFcfB2J+2x03QnUDorIqMsivWKuyGdycfsdX+Y7hRPWme/MypByxjCmUYns3FLTeOGd mwAPhlzJ//Qj80fwjoSVLfmsEwmIwD7Q+k3oMXgTRDzcDa8P677VXHusOfivV6KWY8jugmVkwPN Ptwx5z2fUZZk1xBvtcw/ECt57W+hocr5vRHCIahK6EFc0lvV0I0JEbeNIWJZhe8qthb7Ntz+2wa /V3o/KnoADjwBFsGo47xy8aeoZ4ZBI/XkYMjIOrA6HcPclJMahQhstwJ9G4EfNMvadhydiOkiGG idO7I9sLB7XmhY/zrybQaZfYheYa05J4KDryhKZroPNdqiG81HB9PagRph0mLey3mPjJ/lJQ0OQ UGYtfUa/WALu00cEHDnwvr6B+jQYB2fOueQzjxM0JxSxHjFJ/W9MYGK5mu3UZxEAlFPo846HM5r qDwqtlExlQIQeRG0= Archived-At: Subject: Re: [OPSAWG] WG LC for 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: Tue, 01 Aug 2017 14:15:34 -0000 Med, thanks! All of this looks tractable. I think nearly 100% is just stuff we can = take. There are one or two items for clarification where we'll respond at the = time of the edits. Cheers, Adrian > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 28 July 2017 09:23 > To: Tianran Zhou; opsawg@ietf.org > Cc: opsawg-chairs@ietf.org > Subject: Re: [OPSAWG] WG LC for Service Models Explained >=20 > Hi all, >=20 > I support advancing this document. >=20 > Below some comments that can be easily fixed by the authors. >=20 > - Remove RFC7426 and RFC8049 from the normative references. Those are = cited > as examples. >=20 > - Simplify the text in the abstract as follows: >=20 > OLD : >=20 > The IETF has produced a considerable number of data modules in the > YANG modelling language. The majority of these modules are used to > construct data models to model devices or monolithic functions and > ^^^^^^^^^^^^^^ > they allow access for configuration and to read operational = status.^ >=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^ >=20 > NEW: > The IETF has produced a considerable number of data modules in the > YANG modelling language. The majority of these modules are used to > construct data models for devices or monolithic functions. >=20 > - Introduction: >=20 > * Please cite RFC7149 in addition to [RFC7426] to have both IETF and = IRTF > perspectives. > * Please update this text as follows: >=20 > OLD: > Within the context of Software Defined Networking (SDN) [RFC7426] > YANG data models may be used on Southbound Interfaces (SBIs) = between > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > a controller and network devices, and between network orchestrators > and controllers. >=20 > NEW: > Within the context of Software Defined Networking (SDN) [RFC7426] > YANG data models may be used on the interface between > a controller and network devices, and between network orchestrators > and controllers. >=20 > SBI is introduced, but not used in the text. > I'm not sure introducing geo-coordinate interfaces adds clarity to the = text. >=20 > * Update this text as follows: >=20 > OLD: > Recently there has been interest in using YANG to define and = document > ^^^^^^^^ > data models that describe services in a portable way that is > independent of which network operator uses the model. >=20 > NEW: > There has been interest in using YANG to define and document > data models that describe services in a portable way that is > independent of which network operator uses the model. >=20 > Or change s/Recently/Recently (as per 2017) >=20 > * s/ Customer- Provider Interface/Customer-Provider Interface >=20 > - Section 2: > s/i.e., routers or switches/e.g., routers or switches >=20 > - Section 3: >=20 > * Fix the following: >=20 > OLD: > This is shown simply in Figure 1 >=20 > NEW: > This is shown simply in Figure 1. >=20 > * Fix the following: >=20 > OLD: > The IETF uses the YANG data modeling language defined in [RFC6020] >=20 > NEW: > The IETF uses the YANG data modeling language defined in [RFC6020]. >=20 > - Section 4: Update this text as follows (the introduction text is = about "many > figures") >=20 > OLD: > [RFC7491] describes an interface between... >=20 > NEW: > Figure 1 of [RFC7491] shows an interface between... >=20 > - Section 5: I don't understand what is meant by "standard feature" in = this text: >=20 > "but these are not > standard features of the service as described in the customer > service model" >=20 > Do you mean: those are not mandatory features to be included in a = service > model? >=20 > - Section 6: I would shorten this text because L3WG is already = introduced and > stated many times in the document: >=20 > Several initiatives within the IETF are developing customer service > models. The most advanced presents the Layer Three Virtual Private > Network (L3VPN) service as described by a network operator to a > customer. This L3VPN service model (L3SM) is documented in = [RFC8049] > where its usage is described as in Figure 5 which is reproduced = from > that document. As can be seen, the L3SM is a customer service = model > as described in this document. >=20 > Many thanks to the authors for writing this draft. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: OPSAWG [mailto:opsawg-bounces@ietf.org] De la part de Tianran = Zhou > > Envoy=E9=A0: vendredi 28 juillet 2017 05:06 > > =C0=A0: opsawg@ietf.org > > Cc=A0: opsawg-chairs@ietf.org > > Objet=A0: [OPSAWG] WG LC for Service Models Explained > > > > Dear OPSAWG, > > > > This is a notice to start a three-week OPSAWG WG last call for the > > document: > > > > Service Models Explained > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model- > > explained/ > > > > Please read the above draft and send any issues, comments, or = corrections > > to this mailing list. > > Please indicate your support or concerns by Friday August 18, 2017. > > > > Authors: > > Although this is an informational document, please indicate with an = email > > on the mailing list explicitly whether you are aware or you are not = aware > > of any IPRs related to the drafts. > > > > > > Thanks, > > Tianran, as 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 Tue Aug 1 18:37:31 2017 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 D56D9126BF3; Tue, 1 Aug 2017 18:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 b8amOlDOp1eU; Tue, 1 Aug 2017 18:37:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E8E12426E; Tue, 1 Aug 2017 18:37:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSN29179; Wed, 02 Aug 2017 01:37:24 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 2 Aug 2017 02:37:24 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 2 Aug 2017 09:37:17 +0800 From: Tianran Zhou To: "Carl Moberg (camoberg)" CC: "netmod@ietf.org" , "opsawg@ietf.org" Thread-Topic: [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained Thread-Index: AQHTCqKFiijio3W/uUKZZPsDSn27paJvoT+AgACm82A= Date: Wed, 2 Aug 2017 01:37:16 +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.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59812CD5.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5be9eb8e6bcf74f25c11aa298e0331df Archived-At: Subject: Re: [OPSAWG] [netmod] Cross-post to Netmod for LC comments//FW: WG LC for 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: Wed, 02 Aug 2017 01:37:30 -0000 SGkgQ2FybCwNCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIEl0J3MgYSB2YWx1YWJsZSBm ZWVkYmFjayBmcm9tIHRoZSBhdXRob3Igb2YgdGhlIGFzc29jaWF0ZWQgUkZDLiANCkFsdGhvdWdo IGluZm9ybWF0aW9uYWwsIGFzIGEgd29ya2luZyBncm91cCBhY3Rpb24sIEkgaG9wZSB0aGUgZG9j dW1lbnQgY2FuIHJlcHJlc2VudCB0aGUgY29tbXVuaXR5IGNvbnNlbnN1cy4NCg0KQ2hlZXJzLA0K VGlhbnJhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENhcmwgTW9i ZXJnIChjYW1vYmVyZykgW21haWx0bzpjYW1vYmVyZ0BjaXNjby5jb21dDQo+IFNlbnQ6IFR1ZXNk YXksIEF1Z3VzdCAwMSwgMjAxNyA2OjMxIFBNDQo+IFRvOiBUaWFucmFuIFpob3UNCj4gQ2M6IG5l dG1vZEBpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBD cm9zcy1wb3N0IHRvIE5ldG1vZCBmb3IgTEMgY29tbWVudHMvL0ZXOiBXRyBMQyBmb3INCj4gU2Vy dmljZSBNb2RlbHMgRXhwbGFpbmVkDQo+IA0KPiBUaWFucmFuLCBPUFNBV0csDQo+IA0KPiAgTm93 IHRoYXQgUkZDODE5OSBpcyBwdWJsaXNoZWQsIEkgaGF2ZSB0d28gKHNvbWV3aGF0IGFzc29jaWF0 ZWQpIHBvaW50cw0KPiBvZiAgaGlnaC1sZXZlbCBmZWVkYmFjayBvbiBkcmFmdC1pZXRmLW9wc2F3 Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZDoNCj4gDQo+ICAgLSBUaGUgdGVybSDigJxOZXR3b3Jr IFNlcnZpY2UgTW9kZWzigJ0gaW4gUkZDIDgxOTkgaXMgaW50ZW5kZWQgdG8gY292ZXIgYm90aA0K PiAgICAgIkN1c3RvbWVyIFNlcnZpY2UgTW9kZWzigJ0gYXMgd2VsbCBhcyDigJxTZXJ2aWNlIERl bGl2ZXJ5IE1vZGVs4oCdIGFzIGRlZmluZWQNCj4gICAgIGluIGRyYWZ0LWlldGYtb3BzYXdnLXNl cnZpY2UtbW9kZWwtZXhwbGFpbmVkLiBBdCB0aGUgdGltZSBvZiB0aGUgZmlyc3QNCj4gICAgIHJl dmlzaW9uIG9mIHdoYXQgd2FzDQo+IGRyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLXlhbmctbW9kZWwt Y2xhc3NpZmljYXRpb24NCj4gICAgIHdlIGRpc2N1c3NlZCBmdXJ0aGVyIHNwbGl0dGluZyAiTmV0 d29yayBTZXJ2aWNlIE1vZGVs4oCdIGludG8gc21hbGxlcg0KPiAgICAgY29tcG9uZW50cywgYnV0 IGRlY2lkZWQgYWdhaW5zdCBpdCBzaW5jZSB3ZSBkaWQgbm90IHNlZSBhIGNvbnNlbnN1cyBvbg0K PiAgICAgd2hhdCB0aGF0IHNwbGl0IHdvdWxkIGxvb2sgbGlrZS4gSSBiZWxpZXZlIHRoZSBhdXRo b3JzIGhlcmUgaXMNCj4gICAgIHN1Z2dlc3Rpbmcgc3VjaCBhIGZ1cnRoZXIgc3BsaXQuDQo+IA0K PiAgICAgVGhlcmUgaXMgb25lIHNwZWNpZmljIHBhc3NhZ2UgaW4gdGhpcyBkcmFmdCB0aGF0IEkg d291bGQgc3VnZ2VzdCBjb3VsZA0KPiAgICAgdXNlIHJlcGhyYXNpbmcgaWYgdGhlIGF1dGhvcnMg YWdyZWUgdG8gdGhlIGFib3ZlOg0KPiANCj4gIiIiDQo+ICAgIEFzIHByZXZpb3VzbHkgbm90ZWQs IFtJLUQuaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbl0NCj4gICAgcHJvdmlk ZXMgYSBjbGFzc2lmaWNhdGlvbiBvZiBZQU5HIGRhdGEgbW9kZWxzLiAgSXQgaW50cm9kdWNlcyB0 aGUNCj4gICAgdGVybSAiTmV0d29yayBTZXJ2aWNlIFlBTkcgTW9kdWxlIiB0byBpZGVudGlmeSB0 aGUgdHlwZSBvZiBtb2RlbCB1c2VkDQo+ICAgIHRvICJkZXNjcmliZSB0aGUgY29uZmlndXJhdGlv biwgc3RhdGUgZGF0YSwgb3BlcmF0aW9ucyBhbmQNCj4gICAgbm90aWZpY2F0aW9ucyBvZiBhYnN0 cmFjdCByZXByZXNlbnRhdGlvbnMgb2Ygc2VydmljZXMgaW1wbGVtZW50ZWQgb24NCj4gICAgb25l IG9yIG11bHRpcGxlIG5ldHdvcmsgZWxlbWVudHMuIiAgVGhlc2UgYXJlIHNlcnZpY2UgZGVsaXZl cnkgbW9kZWxzDQo+ICAgIGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LCB0aGF0IGlzLCB0 aGV5IGFyZSB0aGUgbW9kZWxzIHVzZWQgb24NCj4gICAgdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRo ZSBTZXJ2aWNlIE9yY2hlc3RyYXRvciBvciBPU1MvQlNTIGFuZCB0aGUNCj4gICAgTmV0d29yayBP cmNoZXN0cmF0b3IgYXMgc2hvd24gaW4gRmlndXJlIDMuDQo+ICIiIg0KPiANCj4gIC0gQW5kIHRo aXMgZ2V0cyB0byBteSBzZWNvbmQgcG9pbnQgb2YgZmVlZGJhY2suIEZpZ3VyZSA0LiBpbiB0aGUg ZHJhZnQNCj4gc2VlbXMNCj4gICAgdG8gc3VnZ2VzdCB0aGF0IHRoZSAiU2VydmljZSBPcmNoZXN0 cmF0b3IiIGlzIGFuIGVudGl0eSBzZXBhcmF0ZSBmcm9tDQo+IHRoZQ0KPiAgICAiT3BlcmF0aW9u cyBhbmQgQnVzaW5lc3MgU3VwcG9ydCBTeXN0ZW1zIChPU1MvQlNTKSIuIEFuZCBhbHNvIHRoYXQN Cj4gICAgQ3VzdG9tZXJzIChhcyBkZWZpbmVkKSBpbiBTZWN0aW9uIDIgaW50ZXJmYWNlIGRpcmVj dGx5IHdpdGggdGhhdCBlbnRpdHkuDQo+ICAgIFRoaXMgaXMgYSB2ZXJ5IHVudXN1YWwgY29uc3Ry dWN0LCBpbiB0aGUgc2Vuc2UgdGhhdDoNCj4gICAgIG8gVGhlIGNvbW1vbiB0YXhvbm9tb215IGZy b20gZS5nLiBUTUZvcnVtIHdvdWxkIGNsYXNzaWZ5IGEgc2VydmljZQ0KPiAgICAgICBvcmNoZXN0 cmF0b3IgYXMgYSBwYXJ0IG9mIHRoZSBPU1MvQlNTIHN0YWNrLCBzaW5jZS4uLg0KPiAgICAgbyBU aGUgc3VjY2Vzc2Z1bCBhY3RpdmF0aW9uIG9mIGEgc2VydmljZSBpbmNsdWRlcyBtYW55IHBhcnRz IG9mIHRoZQ0KPiAgICAgICBPU1MvQlNTLXN0YWNrIGluY2x1ZGluZyBvcGVyYXRpb25hbCByZWFk aW5lc3MgKGFyZSB0aGVyZSBwaHlzaWNhbA0KPiBwb3J0cw0KPiAgICAgICBhdmFpbGFibGUpLCBi aWxsaW5nIG1hbmFnZW1lbnQgKGlzIHRoZSBjdXN0b21lciBhbGxvd2VkIHRvIHBlcmZvcm0NCj4g ZS5nLg0KPiAgICAgICB0aGlzIHJlc291cmNlIGV4cGFuc2lvbiksIGFuZCBhc3N1cmFuY2UgKGNo YW5nZWQgc2VydmljZXMgcmVxdWlyZSBuZXcNCj4gICAgICAgYXNzdXJhbmNlIHBhcmFtZXRlcnMp LiBUaGlzIG1ha2VzIGl0IGhhcmQgdG8gc2VwYXJhdGUgb3V0IGEgQ3VzdG9tZXINCj4gICAgICAg aW50ZXJmYWNlIHRvIHNlcnZpY2Ugb3JjaGVzdHJhdGlvbiBvbmx5LCBzZXBhcmF0ZSBmcm9tIHRo ZSBPU1MvQlNTDQo+ICAgICAgIHN0YWNrLg0KPiANCj4gIFRoaXMgYW4gaW5mb3JtYXRpb25hbCBk cmFmdCBhbmQgYXMgc3VjaCBpcyBmb3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiwgYW5kDQo+IG5vdCAg bmVjZXNzYXJpbHkgaW50ZW5kZWQgdG8gcmVwcmVzZW50IGNvbW11bml0eSBjb25zZW5zdXMgb3IN Cj4gcmVjb21tZW5kYXRpb24sIGp1c3QgIGxpa2UgODExOS4gQnV0IEkgd291bGQgc3VnZ2VzdCB0 aGUgZG9jdW1lbnQgY291bGQgYmUNCj4gaW1wcm92ZWQgYnkgZWxhYm9yYXRpbmcgIHRoZSBwb2lu dCBvZiB0aGUgc2VwYXJhdGlvbiBvZiB0aGUgb3JjaGVzdHJhdG9yDQo+IGFuZCB0aGUgQlNTL09T UyBhbmQgdGhlICByZXN1bHRpbmcgZGlmZmVyZW5jZSBpbiBtb2R1bGUgdHlwZXMuDQo+IA0KPiAt LQ0KPiBDYXJsIE1vYmVyZw0KPiBjYW1vYmVyZ0BjaXNjby5jb20NCj4gDQo+ID4gT24gQXVnIDEs IDIwMTcsIGF0IDEwOjQ1IEFNLCBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb20+ IHdyb3RlOg0KPiA+DQo+ID4gSGkgTkVUTU9EIFdHLA0KPiA+DQo+ID4gVGhpcyBpcyBhIGNyb3Nz IHBvc3QgZm9yIHRoZSBvbmdvaW5nIFdHTEMgaW4gT1BTQVdHLg0KPiA+DQo+ID4gU2VydmljZSBN b2RlbHMgRXhwbGFpbmVkDQo+ID4NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYQ0KPiA+IGluZWQvDQo+ID4NCj4g PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIGJ5IEF1Z3VzdCAxOCwgMjAxNy4gSWYgeW91IGRv IG5vdCBmZWVsIHRoaXMNCj4gZG9jdW1lbnQgc2hvdWxkIGFkdmFuY2UsIHBsZWFzZSBzdGF0ZSB5 b3VyIHJlYXNvbnMgd2h5Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBUaWFucmFuLCBPUFNBV0cg Y28tY2hhaXINCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog T1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaWFu cmFuDQo+ID4gWmhvdQ0KPiA+IFNlbnQ6IEZyaWRheSwgSnVseSAyOCwgMjAxNyAxMTowNiBBTQ0K PiA+IFRvOiBvcHNhd2dAaWV0Zi5vcmcNCj4gPiBDYzogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZw0K PiA+IFN1YmplY3Q6IFtPUFNBV0ddIFdHIExDIGZvciBTZXJ2aWNlIE1vZGVscyBFeHBsYWluZWQN Cj4gPg0KPiA+IERlYXIgT1BTQVdHLA0KPiA+DQo+ID4gVGhpcyBpcyBhIG5vdGljZSB0byBzdGFy dCBhIHRocmVlLXdlZWsgT1BTQVdHIFdHIGxhc3QgY2FsbCBmb3IgdGhlIGRvY3VtZW50Og0KPiA+ DQo+ID4gU2VydmljZSBNb2RlbHMgRXhwbGFpbmVkDQo+ID4NCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYQ0KPiA+ IGluZWQvDQo+ID4NCj4gPiBQbGVhc2UgcmVhZCB0aGUgYWJvdmUgZHJhZnQgYW5kIHNlbmQgYW55 IGlzc3VlcywgY29tbWVudHMsIG9yIGNvcnJlY3Rpb25zDQo+IHRvIHRoaXMgbWFpbGluZyBsaXN0 Lg0KPiA+IFBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3IgY29uY2VybnMgYnkgRnJpZGF5 IEF1Z3VzdCAxOCwgMjAxNy4NCj4gPg0KPiA+IEF1dGhvcnM6DQo+ID4gQWx0aG91Z2ggdGhpcyBp cyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LCBwbGVhc2UgaW5kaWNhdGUgd2l0aCBhbiBlbWFp bA0KPiBvbiB0aGUgbWFpbGluZyBsaXN0IGV4cGxpY2l0bHkgd2hldGhlciB5b3UgYXJlIGF3YXJl IG9yIHlvdSBhcmUgbm90IGF3YXJlDQo+IG9mIGFueSBJUFJzIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0 cy4NCj4gPg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IFRpYW5yYW4sIGFzIGNvLWNoYWlyDQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IE9QU0FXRyBtYWlsaW5nIGxpc3QNCj4gPiBPUFNBV0dAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBs aXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Wed Aug 2 03:29:05 2017 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 9A46C129B3A for ; Wed, 2 Aug 2017 03:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 7REkz1_T7Kr6 for ; Wed, 2 Aug 2017 03:29:01 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087DC126C23 for ; Wed, 2 Aug 2017 03:29:00 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v72ASr0v005732; Wed, 2 Aug 2017 11:28:53 +0100 Received: from 950129200 (25.70.114.87.dyn.plus.net [87.114.70.25]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v72ASmmW005678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2017 11:28:52 +0100 Reply-To: From: "Adrian Farrel" To: , References: <010301d30968$186c8410$49458c30$@olddog.co.uk> In-Reply-To: <010301d30968$186c8410$49458c30$@olddog.co.uk> Date: Wed, 2 Aug 2017 11:28:47 +0100 Message-ID: <01c601d30b7a$23af8f20$6b0ead60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFqyy8irvd3/FbyVkKh1BMxk4t9NKNBE7Dg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23232.006 X-TM-AS-Result: No--21.469-10.0-31-10 X-imss-scan-details: No--21.469-10.0-31-10 X-TMASE-MatchedRID: rYpa/RC+czHD66A+AisN3eYAh37ZsBDCC/ExpXrHizxBDVeC8J7uwaGn 6ctNCqSXJN3ib+XNKT1wUgcoQqXK/jGHdB2zquuCkkRQ7aojOUuagpdUd+IwzyJ8zskw0dbrq8M 1tdFZKo+EmmFz+RIbZmTfvaWtCHRxNgyelB4Yx0ISWCj0fkOcnN2+i8ybXdyVmoTc4HKMT4fTv2 PUTA1slBCtjkyn83/3p7T5Ug4GlA0dj9vNGYhpkY6MisxJraxHbd6rGhWOAwStj24Xqh0yXESQr bj050MmGlG/OzFL2GylkZPX5MkERqz6N/B4RSnBu99+WGQIeAtVhXyPY4BCZSsWLoSqLlJh10dp xFjKl74k7FhZLnoFUwzRvCJRF+bJXaB/chJb3tMspRlTLgXy/U+4kuSJytt6mHy7uaiMrL7fwNl 0bw7C1dYNtY4AtMpWlW3VqMhw7wWqOU7PhR32fvjQkA7rdCuFQjyw/h+P5m1lm/0lbZGpmK9axn 5UWC0vu5h9co4nGEMYimZuKBGzdjW+K/PcvqBrngIgpj8eDcC063Wh9WVqgqbyPFGTn+O41GcRA JRT6POOhzOa6g8KrZRMZUCEHkRt Archived-At: Subject: Re: [OPSAWG] WG LC for 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: Wed, 02 Aug 2017 10:29:04 -0000 Dan, thanks! > Comment #1 - The current abstract could be simmered down to: > > The IETF has produced a number of data modules in the YANG modelling > 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 Three Virtual Private Network Service Model produced by > the L3SM working group and documented in RFC 8049). > > This document describes the role of an IETF service model, and 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 > engineered and delivered to the customer; details of how network protocols > and devices are engineered to deliver a service are captured in other models > that are not exposed through the Customer-Provider Interface. OK. Appreciate reducing the Abstract. Most changes good. Some "not far enough". But I would like to keep the mention of config and operational status. So... The IETF has produced a number of data modules in the YANG modelling language. The majority of these are used to construct data models to model devices or monolithic functions and they allow access for configuration and to read operational status. A small number of YANG modules have been defined to model services (for example, the Layer Three Virtual Private Network Service Model documented in RFC 8049). This document describes the role of an IETF service model, and shows where a service model fits into a Software Defined Networking architecture. Note that service models do not make any assumption of how a service is engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other models that are not exposed through the Customer-Provider Interface. > Comment #2 - A mix of "modelling" and "modeling" usage in the document. > British or American is fine, but maybe not both. Oh, yes. Fixing. > Comment #3 - Section 1. Introduction, second paragraph, last sentence: > ""There may also be a hierarchy of such components with super-controllers, > domain controllers, and device controllers all exchanging information and > instructions using YANG models" > > The only reference to "super-controller" I found (using a popular search > engine) was an accessory for the Nintendo Entertainment System video game > console. Maybe the authors might want to use the term "super controller". Isn't the Super Controller a character in Guardians of the Galaxy? > Comment #4 - Section 1. Introduction, third paragraph, last sentence: > "Ultimately they could be used in online, software-driven dynamic systems." > > Why not use the term "software defined networks" or "SDN systems", instead > of "online, software-driven dynamic systems". You use the term "software > defined networks" in the abstract and earlier in the introductory text, and > again in section 4. Yes. Actually we should say both since "online, software-driven dynamic systems" is only a step on the path to SDN. Hence... Such models may be used in manual and even paper-driven service request processes with a gradual transition to IT-based mechanisms. Ultimately they could be used in online, software-driven dynamic systems, and eventually as part of an SDN system. > Comment #5 - Section 3. Using Service Models, third paragraph, last > sentence: > > "However, co-located software components might use an API, while systems > with more direct human interactions might use web pages or even paper > forms." > > Indeed RFC6241 and RFC8040 are data-model/schema-driven APIs. Should the > sentence read ("internal API" or "private API"), as in: > > "However, co-located software components might use an internal API, while > systems with more direct human interactions might use web pages or even > paper forms." O tempera, o mores. Once upon a time there were APIs and remote APIs (which weren't really APIs at all but rather a communications library accessed via an API and delivering remotely via another API). But language is a living medium :-) I don't object to "internal API". > Comment #6 - The document uses capitalised and non-capitalised instances of > "Control Plane". Ack > Comment #9 - Section 9. Manageability Considerations > > You use the term "Service Orchestration" in this section but I found no > reference, or previous definition, in the document. Figure 3 introduces the "Service Orchestrator". Do you think we should add more text to explain its function? > Overall, really minor NITs. Good job with the document. Thanks. All nits are good nits. Adrian From nobody Wed Aug 2 03:29:25 2017 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 56C08131EAA; Wed, 2 Aug 2017 03:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 C3SFrzHp_yyr; Wed, 2 Aug 2017 03:29:05 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F04126C23; Wed, 2 Aug 2017 03:29:04 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v72ASsC3005760; Wed, 2 Aug 2017 11:28:54 +0100 Received: from 950129200 (25.70.114.87.dyn.plus.net [87.114.70.25]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v72ASmmX005678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2017 11:28:53 +0100 Reply-To: From: "Adrian Farrel" To: "'Tianran Zhou'" , "'Carl Moberg \(camoberg\)'" Cc: , References: In-Reply-To: Date: Wed, 2 Aug 2017 11:28:47 +0100 Message-ID: <01ca01d30b7a$24525ed0$6cf71c70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbAW31o9HwWBByTtTCkleEadoDZAGGyjiIAVq6DN+iSYZtgA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23232.006 X-TM-AS-Result: No--13.096-10.0-31-10 X-imss-scan-details: No--13.096-10.0-31-10 X-TMASE-MatchedRID: qsaWi0FWcYs4HKI/yaqRm8WUKBjERoYToUj+E6Ep7aJZps+y1VXzqeoP UWMnzVTmhl8BhrTenAn+5Tu3wgSyXHKzRQDC+n78j2FGM19l45fRahuPwaQ1Wmnf+v+Bv9DlWki Dtk1XHnVq4rFfCHYg9gzLDqEyu1hQkfLugziW86ezI1v7J4hECiFq4bKNOR/1PcFkClcmQNs+mZ LuHsKcOhQw4NetPOmNgXAwpNBCV1nmYx6DxF+ydUYmcTlfI8c1fkuZtv/FS5oahchoz+8vwvPxq 4CDAAaNg9gsQPN4r+3DRpsDfF9TvZ+/3E8wlr+DuIwLnB3Aqp2b/LTS0T1K1t02EDYL8YqmUS35 4uMGPVEqBq00VTznlULvrzj8lAWotemwkGxPacZMcRwauwQkhEbbuL7Y47c0Rxay6zLLCxgtjYL FZ2xmSlRHcqR3jRqp2xd9EQ8Wt0643QBcEf+g8X7siEtWY367UXlp1FHYSPVMpKclxGaCEdiz8u jSyOkYrTKkwsUc4lekn61ttGqIDY39U4x946BX+mHRL3uzOiJA8JZETQujwkYX5kyNXpCIp83IW P6+nSaeTJ2KWImGZ8NXbe00kNLgi8ICQO6ibxRx+x1f5juFEwvWQayvnHh3ClyrX4tOmxSjxYyR Ba/qJaEwgORH8p/AjaPj0W1qn0Q7AFczfjr/7Ay/OSZuzy1aOJkGXgCZnPLeq5Xw5DFhKvPiRVT 7GOosaahJTKV0sNo= Archived-At: Subject: Re: [OPSAWG] [netmod] Cross-post to Netmod for LC comments//FW: WG LC for 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: Wed, 02 Aug 2017 10:29:06 -0000 Hi Carl, > - The term =E2=80=9CNetwork Service Model=E2=80=9D in RFC 8199 is = intended to cover both > "Customer Service Model=E2=80=9D as well as =E2=80=9CService = Delivery Model=E2=80=9D as defined > in draft-ietf-opsawg-service-model-explained. At the time of the = first > revision of what was > draft-bogdanovic-netmod-yang-model-classification > we discussed further splitting "Network Service Model=E2=80=9D = into smaller > components, but decided against it since we did not see a = consensus on > what that split would look like. I believe the authors here is > suggesting such a further split. I think that an "issue" with RFC 8199 is that is appears to imply that = the "Network Service Module" (sic) it defines is used on a specific = interface rather than simply being the classification of "all modules = used north of this point". This our draft is doing slightly more than = partitioning the classification. The last couple of rounds of edits to = what became 8199 were working with Dean to slightly soften thee language = used to make this more consistent. But see below... > There is one specific passage in this draft that I would suggest = could > use rephrasing if the authors agree to the above: > > """ > As previously noted, [I-D.ietf-netmod-yang-model-classification] > provides a classification of YANG data models. It introduces the > term "Network Service YANG Module" to identify the type of model = used > to "describe the configuration, state data, operations and > notifications of abstract representations of services implemented = on > one or multiple network elements." These are service delivery = models > as described in this document, that is, they are the models used on > the interface between the Service Orchestrator or OSS/BSS and the > Network Orchestrator as shown in Figure 3. > """ You suggest this could be rephrased, but don't suggest how:-) I just checked 8199 and I see that the quote we have is still accurate. I am wondering what it is specifically about this text that worries you. = Again, this may come back to the use of a module on a functional = interface. I read 8199 as saying that the "Network Service YANG Modules = are used by the OSS/BSS in talking to the network elements (o perhaps = Controllers?) to configure the network to deliver the service. Am I = wrong? If I'm right in my reading we are not "splitting" the classification, = but introducing a new class that lives further north (where the = atmosphere is thinner and the temperature colder) > - And this gets to my second point of feedback. Figure 4. in the = draft > seems to suggest that the "Service Orchestrator" is an entity = separate > from the "Operations and Business Support Systems (OSS/BSS)". I want to jump into this paragraph at once just to say "no, no, no!" This figure (like most I draw in ASCII these days) displays functional = components not physical entities. How you choose to implement is entirely up to you. It seems likely (to me) that the interface between customer and operator = is externally exposed (but not necessarily realised using RESTconf). It does not seem obvious to me that the Service Orchestrator and the = OSS/BSS are separate blobs, except to note that the OSS/BSS deployed = today does not support the Customer Service YANG Modules and so the = extent to which it provides "service orchestration" is limited. I might also claim that an OSS/BSS possibly operates on a single network = where the orchestration of a service *might* involve the coordination of = more than one network. > And also that > Customers (as defined) in Section 2 interface directly with that = entity. > This is a very unusual construct, in the sense that: > o The common taxonomomy from e.g. TMForum would classify a service > orchestrator as a part of the OSS/BSS stack, since... > o The successful activation of a service includes many parts of = the > OSS/BSS-stack including operational readiness (are there = physical > ports available), billing management (is the customer allowed to = > perform e.g. this resource expansion), and assurance (changed > services require new assurance parameters). This makes it hard > to separate out a Customer interface to service orchestration > only, separate from the OSS/BSS stack. I am not (overly) familiar with the TMF work, however, your text = "TMForum would classify a service orchestrator as a part of the OSS/BSS = stack" suggests the acceptance of service orchestration as "a thing". If = you were writing code, you *might* write a separate module (even = library) to handle service orchestration, and maintain that as a = separate module from billing management, etc. That does not make them = completely separate, but does result in them showing as separate = functional components in the "OSS/BSS stack." > This an informational draft and as such is for general information, = and > not necessarily intended to represent community consensus or > recommendation, just like 8119. I choose to disagree! 8199 had WG and IETF last call. It has community = consensus. The intention of this draft is that it, too, will have IETF community = consensus. But be aware that we are neither trying to force that consensus, nor = dictate the terminology. What we are doing is trying to answer the = (often repeated) question: "Where do L2SM and L3SM fit into the picture = since they don't seem to be intended to talk to network devices or = controllers?" > But I would suggest the document could be > improved by elaborating the point of the separation of the = orchestrator > and the BSS/OSS and the resulting difference in module types. I could certainly add text around Figure 4 to say "...this illustrates a = functional architecture and an implementation might not choose to make = the distinctions shown such that separations and interfaces illustrated = might fall within a single implementation." Would that help? Many thanks, Adrian From nobody Wed Aug 2 04:34:30 2017 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 AE81413202C for ; Wed, 2 Aug 2017 04:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielking-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLi_8kkBWAxY for ; Wed, 2 Aug 2017 04:34:27 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 ABA5412EC13 for ; Wed, 2 Aug 2017 04:34:26 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t201so38858785wmt.1 for ; Wed, 02 Aug 2017 04:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=+6q2ywqtrFJ6Do6MxaFL8nJ+gOqAj252jUZsxU7Vxdo=; b=0hXPcXppN/ExycJ8Z8lGyVL2CBYxR0b5OOBr0FS/EH6gK4DZSfK9t4rbkFJIaqIwVG GKXLJFcVBCzfZrKaQju8VlHKRKLpEe0/yHrLFgyR3c8zz2Rl5Rj7Lp6b6njNJVCU/LAz rrmeH6zWi2nrpuShjkdV1VdrmWMdElyWs0tqAmTrqvg1QsijxvM9aD2ZapsH6D1myEgd TWDm708z0OjvIalgvSqTlq/PjlROkoNw4KYt0DOm/ujEVpFmO8E0K4/PY1DXnX3JLs5h z6XpaqSOosgtVSzaOaeIKpsNpGEJtbstQbF7Y50eWnn9/IFnfdpK9tanjcIkRnpy+1De M5mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=+6q2ywqtrFJ6Do6MxaFL8nJ+gOqAj252jUZsxU7Vxdo=; b=p4nVGzdIH3FuoAPggiJYqpehW+Qor2OIuisluS+dR1DmBcaHqho9SwLuneF2cfVr2V RIaeDGGaqy8kMjqAUndYDVg7J/C9HdvqPAs/1zA6kwdyNoU+duunauJ1whUSQJTOD2rF pvVM96a+mdK0L1WzzFKJqUw/kT7+QJDXo0azAkaOWbyUCVnjyRnQ4AsY/Yjzl2ODl220 jIy8l6dAR6BhfjYvO5IqwEI+y5UNqIGfgkrxnPZXNNdkpt+i+c3XK23JDNnnN33Hzd1W hA+YRAR9pqCa49j5uz5x5lqGOhezVH6hPAcBm4T308vFXDfveVejkB9wqgEjVvXHGnkO OKlw== X-Gm-Message-State: AIVw1114VZ7YOf3b18lmrH2GEiC0j2dX2fx7hjUiWPb7sFMtqVeuqwkT GVeTcKDyCQMxSFTU X-Received: by 10.28.30.14 with SMTP id e14mr3404147wme.10.1501673665120; Wed, 02 Aug 2017 04:34:25 -0700 (PDT) Received: from INARA ([87.101.243.155]) by smtp.gmail.com with ESMTPSA id y35sm12893146wrd.60.2017.08.02.04.34.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 04:34:24 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: , References: <010301d30968$186c8410$49458c30$@olddog.co.uk> <01c601d30b7a$23af8f20$6b0ead60$@olddog.co.uk> In-Reply-To: <01c601d30b7a$23af8f20$6b0ead60$@olddog.co.uk> Date: Wed, 2 Aug 2017 14:34:15 +0300 Message-ID: <004f01d30b83$4a6990d0$df3cb270$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFqyy8irvd3/FbyVkKh1BMxk4t9NAMfxVMpoyhuUOA= Content-Language: en-gb Archived-At: Subject: Re: [OPSAWG] WG LC for 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: Wed, 02 Aug 2017 11:34:29 -0000 Thanks Adrian, all good. BR, Dan. -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 02 August 2017 13:29 To: daniel@olddog.co.uk; opsawg@ietf.org Subject: RE: [OPSAWG] WG LC for Service Models Explained Dan, thanks! > Comment #1 - The current abstract could be simmered down to: > > The IETF has produced a number of data modules in the YANG modelling > 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 Three Virtual Private Network Service Model > produced by the L3SM working group and documented in RFC 8049). > > This document describes the role of an IETF service model, and 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 engineered and delivered to the customer; details of how network > protocols and devices are engineered to deliver a service are captured > in other models that are not exposed through the Customer-Provider Interface. OK. Appreciate reducing the Abstract. Most changes good. Some "not far enough". But I would like to keep the mention of config and operational status. So... The IETF has produced a number of data modules in the YANG modelling language. The majority of these are used to construct data models to model devices or monolithic functions and they allow access for configuration and to read operational status. A small number of YANG modules have been defined to model services (for example, the Layer Three Virtual Private Network Service Model documented in RFC 8049). This document describes the role of an IETF service model, and shows where a service model fits into a Software Defined Networking architecture. Note that service models do not make any assumption of how a service is engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other models that are not exposed through the Customer-Provider Interface. > Comment #2 - A mix of "modelling" and "modeling" usage in the document. > British or American is fine, but maybe not both. Oh, yes. Fixing. > Comment #3 - Section 1. Introduction, second paragraph, last sentence: > ""There may also be a hierarchy of such components with > super-controllers, domain controllers, and device controllers all > exchanging information and instructions using YANG models" > > The only reference to "super-controller" I found (using a popular > search > engine) was an accessory for the Nintendo Entertainment System video > game console. Maybe the authors might want to use the term "super controller". Isn't the Super Controller a character in Guardians of the Galaxy? > Comment #4 - Section 1. Introduction, third paragraph, last sentence: > "Ultimately they could be used in online, software-driven dynamic systems." > > Why not use the term "software defined networks" or "SDN systems", > instead of "online, software-driven dynamic systems". You use the term > "software defined networks" in the abstract and earlier in the > introductory text, and again in section 4. Yes. Actually we should say both since "online, software-driven dynamic systems" is only a step on the path to SDN. Hence... Such models may be used in manual and even paper-driven service request processes with a gradual transition to IT-based mechanisms. Ultimately they could be used in online, software-driven dynamic systems, and eventually as part of an SDN system. > Comment #5 - Section 3. Using Service Models, third paragraph, last > sentence: > > "However, co-located software components might use an API, while > systems with more direct human interactions might use web pages or > even paper forms." > > Indeed RFC6241 and RFC8040 are data-model/schema-driven APIs. Should > the sentence read ("internal API" or "private API"), as in: > > "However, co-located software components might use an internal API, > while systems with more direct human interactions might use web pages > or even paper forms." O tempera, o mores. Once upon a time there were APIs and remote APIs (which weren't really APIs at all but rather a communications library accessed via an API and delivering remotely via another API). But language is a living medium :-) I don't object to "internal API". > Comment #6 - The document uses capitalised and non-capitalised > instances of "Control Plane". Ack > Comment #9 - Section 9. Manageability Considerations > > You use the term "Service Orchestration" in this section but I found > no reference, or previous definition, in the document. Figure 3 introduces the "Service Orchestrator". Do you think we should add more text to explain its function? > Overall, really minor NITs. Good job with the document. Thanks. All nits are good nits. Adrian From nobody Wed Aug 2 04:36:02 2017 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 79792131EBA; Wed, 2 Aug 2017 04:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 opnMBebqRpSG; Wed, 2 Aug 2017 04:35:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5B8120227; Wed, 2 Aug 2017 04:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13962; q=dns/txt; s=iport; t=1501673753; x=1502883353; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RrzjLABJDCs+tT98jK1Jwf2ghCuybqx0aF0aVLP+N4g=; b=lHYo6gWEoK97Dtrxt4EqVZZ6CKU+2D14D2Yu7RkhZmDzQouMeOjh7DYU XaIRqmxEV0+B9pazEE4X8X+rK+0c7z2v4OUOzj41gWi2aFlLiQN7g6Lok xE47otQcHZflAAtxg1FJb7HgmabS16C2TF0ZslqqUXS/D/yHwxgRxADsr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAACMuIFZ/5hdJa1TBAYZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDWoFRJweOB5ACgW6WEA6CBIVHAhqEGT8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRgBAQEBAgEjEUUFCwIBCBIGAgImAgICMBUCDgIEDgMCFIoTCK1MgiaLTQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEfgQuCHYICgUyBYyuCfIQ/AQEHBAcBEQ2DFDCCMQW?= =?us-ascii?q?JWRMFlgsCiF6CP4kNgg2JToZpkSgVhD0BHzh/C3cVWwGCcYITHBmBTkQyhywPF?= =?us-ascii?q?4EMgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,311,1498521600"; d="scan'208";a="277661254" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2017 11:35:52 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v72BZqH2030846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2017 11:35:52 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 06:35:51 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 06:35:51 -0500 From: "Carl Moberg (camoberg)" To: "adrian@olddog.co.uk" CC: Tianran Zhou , "opsawg@ietf.org" , "netmod@ietf.org" Thread-Topic: [OPSAWG] [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained Thread-Index: AQHTCqKFiijio3W/uUKZZPsDSn27paJvoT+AgACm82CAAOqagIAAEr2A Date: Wed, 2 Aug 2017 11:35:51 +0000 Message-ID: <3AF5CE83-3B4C-4C5C-A79C-C54589F95A58@cisco.com> References: <01ca01d30b7a$24525ed0$6cf71c70$@olddog.co.uk> In-Reply-To: <01ca01d30b7a$24525ed0$6cf71c70$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.84] Content-Type: text/plain; charset="utf-8" Content-ID: <762885144285274EA4396A9DDC2BDCDC@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] [netmod] Cross-post to Netmod for LC comments//FW: WG LC for 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: Wed, 02 Aug 2017 11:35:55 -0000 QWRyaWFuLA0KDQo+IE9uIEF1ZyAyLCAyMDE3LCBhdCAxMjoyOCBQTSwgQWRyaWFuIEZhcnJlbCA8 YWRyaWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQo+IA0KPiBIaSBDYXJsLA0KPiANCj4+ICAtIFRo ZSB0ZXJtIOKAnE5ldHdvcmsgU2VydmljZSBNb2RlbOKAnSBpbiBSRkMgODE5OSBpcyBpbnRlbmRl ZCB0byBjb3ZlciBib3RoDQo+PiAgICAiQ3VzdG9tZXIgU2VydmljZSBNb2RlbOKAnSBhcyB3ZWxs IGFzIOKAnFNlcnZpY2UgRGVsaXZlcnkgTW9kZWzigJ0gYXMgZGVmaW5lZA0KPj4gICAgaW4gZHJh ZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQuIEF0IHRoZSB0aW1lIG9mIHRo ZSBmaXJzdA0KPj4gICAgcmV2aXNpb24gb2Ygd2hhdCB3YXMNCj4+IGRyYWZ0LWJvZ2Rhbm92aWMt bmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24NCj4+ICAgIHdlIGRpc2N1c3NlZCBmdXJ0 aGVyIHNwbGl0dGluZyAiTmV0d29yayBTZXJ2aWNlIE1vZGVs4oCdIGludG8gc21hbGxlcg0KPj4g ICAgY29tcG9uZW50cywgYnV0IGRlY2lkZWQgYWdhaW5zdCBpdCBzaW5jZSB3ZSBkaWQgbm90IHNl ZSBhIGNvbnNlbnN1cyBvbg0KPj4gICAgd2hhdCB0aGF0IHNwbGl0IHdvdWxkIGxvb2sgbGlrZS4g SSBiZWxpZXZlIHRoZSBhdXRob3JzIGhlcmUgaXMNCj4+ICAgIHN1Z2dlc3Rpbmcgc3VjaCBhIGZ1 cnRoZXIgc3BsaXQuDQo+IA0KPiBJIHRoaW5rIHRoYXQgYW4gImlzc3VlIiB3aXRoIFJGQyA4MTk5 IGlzIHRoYXQgaXMgYXBwZWFycyB0byBpbXBseSB0aGF0IHRoZSAiTmV0d29yayBTZXJ2aWNlIE1v ZHVsZSIgKHNpYykgaXQgZGVmaW5lcyBpcyB1c2VkIG9uIGEgc3BlY2lmaWMgaW50ZXJmYWNlIHJh dGhlciB0aGFuIHNpbXBseSBiZWluZyB0aGUgY2xhc3NpZmljYXRpb24gb2YgImFsbCBtb2R1bGVz IHVzZWQgbm9ydGggb2YgdGhpcyBwb2ludCIuIFRoaXMgb3VyIGRyYWZ0IGlzIGRvaW5nIHNsaWdo dGx5IG1vcmUgdGhhbiBwYXJ0aXRpb25pbmcgdGhlIGNsYXNzaWZpY2F0aW9uLiBUaGUgbGFzdCBj b3VwbGUgb2Ygcm91bmRzIG9mIGVkaXRzIHRvIHdoYXQgYmVjYW1lIDgxOTkgd2VyZSB3b3JraW5n IHdpdGggRGVhbiB0byBzbGlnaHRseSBzb2Z0ZW4gdGhlZSBsYW5ndWFnZSB1c2VkIHRvIG1ha2Ug dGhpcyBtb3JlIGNvbnNpc3RlbnQuDQoNCiBSaWdodCwgYW5kIHRoZSByZWFzb24gd2h5IHdlIHRv b2sgdGhlICJhbGwgbW9kdWxlcyB1c2VkIG5vcnRoIG9mIHRoaXMgcG9pbnTigJ0gaXMgdGhhdCB3 ZSBoYXZlIG5vdCBzZWVuIGFueSBzaWduIG9mIGNvbnZlcmdlbmNlIGFyb3VuZCBhYnN0cmFjdGlv bnMgaW50byBzbWFsbGVyIGNvbXBvbmVudHMuIEluIHNob3J0OiBpbXBsZW1lbnRhdGlvbnMgb2Yg 4oCcWUFORyBmb3Igc2VydmljZXPigJ0gaXMgY3VycmVudGx5IGFsbCBvdmVyIHRoZSBtYXAuDQoN Cj4gQnV0IHNlZSBiZWxvdy4uLg0KPiANCj4+ICAgIFRoZXJlIGlzIG9uZSBzcGVjaWZpYyBwYXNz YWdlIGluIHRoaXMgZHJhZnQgdGhhdCBJIHdvdWxkIHN1Z2dlc3QgY291bGQNCj4+ICAgIHVzZSBy ZXBocmFzaW5nIGlmIHRoZSBhdXRob3JzIGFncmVlIHRvIHRoZSBhYm92ZToNCj4+IA0KPj4gIiIi DQo+PiAgIEFzIHByZXZpb3VzbHkgbm90ZWQsIFtJLUQuaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1j bGFzc2lmaWNhdGlvbl0NCj4+ICAgcHJvdmlkZXMgYSBjbGFzc2lmaWNhdGlvbiBvZiBZQU5HIGRh dGEgbW9kZWxzLiAgSXQgaW50cm9kdWNlcyB0aGUNCj4+ICAgdGVybSAiTmV0d29yayBTZXJ2aWNl IFlBTkcgTW9kdWxlIiB0byBpZGVudGlmeSB0aGUgdHlwZSBvZiBtb2RlbCB1c2VkDQo+PiAgIHRv ICJkZXNjcmliZSB0aGUgY29uZmlndXJhdGlvbiwgc3RhdGUgZGF0YSwgb3BlcmF0aW9ucyBhbmQN Cj4+ICAgbm90aWZpY2F0aW9ucyBvZiBhYnN0cmFjdCByZXByZXNlbnRhdGlvbnMgb2Ygc2Vydmlj ZXMgaW1wbGVtZW50ZWQgb24NCj4+ICAgb25lIG9yIG11bHRpcGxlIG5ldHdvcmsgZWxlbWVudHMu IiAgVGhlc2UgYXJlIHNlcnZpY2UgZGVsaXZlcnkgbW9kZWxzDQo+PiAgIGFzIGRlc2NyaWJlZCBp biB0aGlzIGRvY3VtZW50LCB0aGF0IGlzLCB0aGV5IGFyZSB0aGUgbW9kZWxzIHVzZWQgb24NCj4+ ICAgdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBTZXJ2aWNlIE9yY2hlc3RyYXRvciBvciBPU1Mv QlNTIGFuZCB0aGUNCj4+ICAgTmV0d29yayBPcmNoZXN0cmF0b3IgYXMgc2hvd24gaW4gRmlndXJl IDMuDQo+PiAiIiINCj4gDQo+IFlvdSBzdWdnZXN0IHRoaXMgY291bGQgYmUgcmVwaHJhc2VkLCBi dXQgZG9uJ3Qgc3VnZ2VzdCBob3c6LSkNCj4gSSBqdXN0IGNoZWNrZWQgODE5OSBhbmQgSSBzZWUg dGhhdCB0aGUgcXVvdGUgd2UgaGF2ZSBpcyBzdGlsbCBhY2N1cmF0ZS4NCj4gDQo+IEkgYW0gd29u ZGVyaW5nIHdoYXQgaXQgaXMgc3BlY2lmaWNhbGx5IGFib3V0IHRoaXMgdGV4dCB0aGF0IHdvcnJp ZXMgeW91LiBBZ2FpbiwgdGhpcyBtYXkgY29tZSBiYWNrIHRvIHRoZSB1c2Ugb2YgYSBtb2R1bGUg b24gYSBmdW5jdGlvbmFsIGludGVyZmFjZS4gSSByZWFkIDgxOTkgYXMgc2F5aW5nIHRoYXQgdGhl ICJOZXR3b3JrIFNlcnZpY2UgWUFORyBNb2R1bGVzIGFyZSB1c2VkIGJ5IHRoZSBPU1MvQlNTIGlu IHRhbGtpbmcgdG8gdGhlIG5ldHdvcmsgZWxlbWVudHMgKG8gcGVyaGFwcyBDb250cm9sbGVycz8p IHRvIGNvbmZpZ3VyZSB0aGUgbmV0d29yayB0byBkZWxpdmVyIHRoZSBzZXJ2aWNlLiBBbSBJIHdy b25nPw0KPiANCj4gSWYgSSdtIHJpZ2h0IGluIG15IHJlYWRpbmcgd2UgYXJlIG5vdCAic3BsaXR0 aW5nIiB0aGUgY2xhc3NpZmljYXRpb24sIGJ1dCBpbnRyb2R1Y2luZyBhIG5ldyBjbGFzcyB0aGF0 IGxpdmVzIGZ1cnRoZXIgbm9ydGggKHdoZXJlIHRoZSBhdG1vc3BoZXJlIGlzIHRoaW5uZXIgYW5k IHRoZSB0ZW1wZXJhdHVyZSBjb2xkZXIpDQoNCiBJIHRoaW5rIGF0IHRoZSBjb3JlIG9mIHRoZSBm ZWVkYmFjayAoYW5kIHNvcnJ5IHRoYXQgaXQgdG9vayB0d28gcm91bmRzIG9mIGVtYWlsIHRvIG1h a2UgaXQgc2hvcnRlciA6LSkgaXMgdGhhdCBpbiA4MTk5IHRoZSBTZXJ2aWNlIE9yY2hlc3RyYXRv ciBpcyBhc3N1bWVkIHRvIGJlIGFuIGludGVncmFsIHBhcnQgb2YgT1NTL0JTUy4gTW9yZSBiZWxv dy4NCg0KPj4gLSBBbmQgdGhpcyBnZXRzIHRvIG15IHNlY29uZCBwb2ludCBvZiBmZWVkYmFjay4g RmlndXJlIDQuIGluIHRoZSBkcmFmdA0KPj4gICBzZWVtcyB0byBzdWdnZXN0IHRoYXQgdGhlICJT ZXJ2aWNlIE9yY2hlc3RyYXRvciIgaXMgYW4gZW50aXR5IHNlcGFyYXRlDQo+PiAgIGZyb20gdGhl ICJPcGVyYXRpb25zIGFuZCBCdXNpbmVzcyBTdXBwb3J0IFN5c3RlbXMgKE9TUy9CU1MpIi4NCj4g DQo+IEkgd2FudCB0byBqdW1wIGludG8gdGhpcyBwYXJhZ3JhcGggYXQgb25jZSBqdXN0IHRvIHNh eSAibm8sIG5vLCBubyEiDQo+IFRoaXMgZmlndXJlIChsaWtlIG1vc3QgSSBkcmF3IGluIEFTQ0lJ IHRoZXNlIGRheXMpIGRpc3BsYXlzIGZ1bmN0aW9uYWwgY29tcG9uZW50cyBub3QgcGh5c2ljYWwg ZW50aXRpZXMuDQo+IEhvdyB5b3UgY2hvb3NlIHRvIGltcGxlbWVudCBpcyBlbnRpcmVseSB1cCB0 byB5b3UuDQo+IEl0IHNlZW1zIGxpa2VseSAodG8gbWUpIHRoYXQgdGhlIGludGVyZmFjZSBiZXR3 ZWVuIGN1c3RvbWVyIGFuZCBvcGVyYXRvciBpcyBleHRlcm5hbGx5IGV4cG9zZWQgKGJ1dCBub3Qg bmVjZXNzYXJpbHkgcmVhbGlzZWQgdXNpbmcgUkVTVGNvbmYpLg0KDQogVGhpcyBpcyBwZXJoYXBz IGFsc28gYXQgdGhlIGNvcmUgb2YgdGhlIGZlZWRiYWNrLiBJIGhhdmUgbmV2ZXIgc2VlbiBhbiBp bXBsZW1lbnRhdGlvbi9hcmNoaXRlY3R1cmUgd2l0aCBhIGZ1bmN0aW9uYWxseSBkaXN0aW5jdCBT ZXJ2aWNlIE9yY2hlc3RyYXRvciAob3V0c2lkZSBvZiBPU1MvQlNTKSBleHBvc2VkIGRpcmVjdGx5 IHRvIGN1c3RvbWVycy4gVGhlcmUgaXMgdXN1YWxseSBhdCBsZWFzdCBzb21ldGhpbmcgbGlrZSBh biBvcmRlciBtYW5hZ2VyIChhcyBwYXJ0IG9mIHRoZSBPU1MvQlNTKSBiZXR3ZWVuIHRoZSBjdXN0 b21lciBhbmQgdGhlIHNlcnZpY2Ugb3JjaGVzdHJhdG9yLiBFdmVuIGluIHRoZSBpbnN0YW5jZXMg b2Ygc2VsZi1zZXJ2aWNlIHBvcnRhbHMgKHdoaWNoIGFyZSBuYXR1cmFsbHkgbG9jYXRlZCB2ZXJ5 IGNsb3NlIHRvIHRoZSBuZXR3b3JrKSB0aGVyZSBpcyBhdCBsZWFzdCBzb21lIG5vdGlvbiBvZiBw cmljaW5nIGFuZCBiaWxsaW5nIGludm9sdmVkLg0KDQo+IEl0IGRvZXMgbm90IHNlZW0gb2J2aW91 cyB0byBtZSB0aGF0IHRoZSBTZXJ2aWNlIE9yY2hlc3RyYXRvciBhbmQgdGhlIE9TUy9CU1MgYXJl IHNlcGFyYXRlIGJsb2JzLCBleGNlcHQgdG8gbm90ZSB0aGF0IHRoZSBPU1MvQlNTIGRlcGxveWVk IHRvZGF5IGRvZXMgbm90IHN1cHBvcnQgdGhlIEN1c3RvbWVyIFNlcnZpY2UgWUFORyBNb2R1bGVz IGFuZCBzbyB0aGUgZXh0ZW50IHRvIHdoaWNoIGl0IHByb3ZpZGVzICJzZXJ2aWNlIG9yY2hlc3Ry YXRpb24iIGlzIGxpbWl0ZWQuDQoNCiBXZWxsLCBhIGNvbW1vbiBwYXR0ZXJuIGlzIHRvIGhhdmUg dGhlIG9yZGVyIG1hbmFnZXIgcHV0IGluIG9yZGVycyBmb3IgdGVjaG5pY2FsIHNlcnZpY2UgYWN0 aXZhdGlvbiBmcm9tIGEgc2VydmljZSBvcmNoZXN0cmF0b3IuIFRoZSB1cHRha2Ugb2YgWUFORyBz ZWVtcyB0byBiZSBtb3N0bHkgaW4gdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBvcmRlciBtYW5h Z2VyIChhbiBpbnRlZ3JhbCBwYXJ0IG9mIE9TUy9CU1MpIGFuZCB0aGUgc2VydmljZSBvcmNoZXN0 cmF0b3IuDQoNCj4gSSBtaWdodCBhbHNvIGNsYWltIHRoYXQgYW4gT1NTL0JTUyBwb3NzaWJseSBv cGVyYXRlcyBvbiBhIHNpbmdsZSBuZXR3b3JrIHdoZXJlIHRoZSBvcmNoZXN0cmF0aW9uIG9mIGEg c2VydmljZSAqbWlnaHQqIGludm9sdmUgdGhlIGNvb3JkaW5hdGlvbiBvZiBtb3JlIHRoYW4gb25l IG5ldHdvcmsuDQoNCiBIbW0sIHNpbmNlIHRoZSBhY3R1YWwgYnVzaW5lc3MgaXMgYWNjb3VudGVk IGZvciBpbiB0aGUgT1NTL0JTUyAoaW5jbHVkaW5nIHJhdGluZywgY2hhcmdpbmcsIGJpbGxpbmcp IEnigJltIG5vdCBzdXJlIGhvdyBhIG11bHRpLW5ldHdvcmsgc2VydmljZSBvcmNoZXN0cmF0b3Ig b3V0c2lkZSBvZiBhbiBPU1MvQlNTIGNvbnRleHQgd291bGQgd29yay4NCg0KPj4gQW5kIGFsc28g dGhhdA0KPj4gICBDdXN0b21lcnMgKGFzIGRlZmluZWQpIGluIFNlY3Rpb24gMiBpbnRlcmZhY2Ug ZGlyZWN0bHkgd2l0aCB0aGF0IGVudGl0eS4NCj4+ICAgVGhpcyBpcyBhIHZlcnkgdW51c3VhbCBj b25zdHJ1Y3QsIGluIHRoZSBzZW5zZSB0aGF0Og0KPj4gICAgbyBUaGUgY29tbW9uIHRheG9ub21v bXkgZnJvbSBlLmcuIFRNRm9ydW0gd291bGQgY2xhc3NpZnkgYSBzZXJ2aWNlDQo+PiAgICAgIG9y Y2hlc3RyYXRvciBhcyBhIHBhcnQgb2YgdGhlIE9TUy9CU1Mgc3RhY2ssIHNpbmNlLi4uDQo+PiAg ICBvIFRoZSBzdWNjZXNzZnVsIGFjdGl2YXRpb24gb2YgYSBzZXJ2aWNlIGluY2x1ZGVzIG1hbnkg cGFydHMgb2YgdGhlDQo+PiAgICAgIE9TUy9CU1Mtc3RhY2sgaW5jbHVkaW5nIG9wZXJhdGlvbmFs IHJlYWRpbmVzcyAoYXJlIHRoZXJlIHBoeXNpY2FsDQo+PiAgICAgIHBvcnRzIGF2YWlsYWJsZSks IGJpbGxpbmcgbWFuYWdlbWVudCAoaXMgdGhlIGN1c3RvbWVyIGFsbG93ZWQgdG8gDQo+PiAgICAg IHBlcmZvcm0gZS5nLiB0aGlzIHJlc291cmNlIGV4cGFuc2lvbiksIGFuZCBhc3N1cmFuY2UgKGNo YW5nZWQNCj4+ICAgICAgc2VydmljZXMgcmVxdWlyZSBuZXcgYXNzdXJhbmNlIHBhcmFtZXRlcnMp LiBUaGlzIG1ha2VzIGl0IGhhcmQNCj4+ICAgICAgdG8gc2VwYXJhdGUgb3V0IGEgQ3VzdG9tZXIg aW50ZXJmYWNlIHRvIHNlcnZpY2Ugb3JjaGVzdHJhdGlvbg0KPj4gICAgICBvbmx5LCBzZXBhcmF0 ZSBmcm9tIHRoZSBPU1MvQlNTIHN0YWNrLg0KPiANCj4gSSBhbSBub3QgKG92ZXJseSkgZmFtaWxp YXIgd2l0aCB0aGUgVE1GIHdvcmssIGhvd2V2ZXIsIHlvdXIgdGV4dCAiVE1Gb3J1bSB3b3VsZCBj bGFzc2lmeSBhIHNlcnZpY2Ugb3JjaGVzdHJhdG9yIGFzIGEgcGFydCBvZiB0aGUgT1NTL0JTUyBz dGFjayIgc3VnZ2VzdHMgdGhlIGFjY2VwdGFuY2Ugb2Ygc2VydmljZSBvcmNoZXN0cmF0aW9uIGFz ICJhIHRoaW5nIi4gSWYgeW91IHdlcmUgd3JpdGluZyBjb2RlLCB5b3UgKm1pZ2h0KiB3cml0ZSBh IHNlcGFyYXRlIG1vZHVsZSAoZXZlbiBsaWJyYXJ5KSB0byBoYW5kbGUgc2VydmljZSBvcmNoZXN0 cmF0aW9uLCBhbmQgbWFpbnRhaW4gdGhhdCBhcyBhIHNlcGFyYXRlIG1vZHVsZSBmcm9tIGJpbGxp bmcgbWFuYWdlbWVudCwgZXRjLiBUaGF0IGRvZXMgbm90IG1ha2UgdGhlbSBjb21wbGV0ZWx5IHNl cGFyYXRlLCBidXQgZG9lcyByZXN1bHQgaW4gdGhlbSBzaG93aW5nIGFzIHNlcGFyYXRlIGZ1bmN0 aW9uYWwgY29tcG9uZW50cyBpbiB0aGUgIk9TUy9CU1Mgc3RhY2su4oCdDQoNCiBFeGFjdGx5IHJp Z2h0LiBUaGUgdGVybSDigJxPU1MvQlNT4oCdIGl0c2VsZiBhcyBJ4oCZbSB1c2VkIHRvIGhlYXJp bmcgaXQgaXMgYSBtZWFucyBvZiBncm91cGluZyBhIChodWdlKSBzZXQgb2YgZnVuY3Rpb25zIHVu ZGVyIGEgY29tbW9uIGxhYmVsLg0KDQo+PiBUaGlzIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgYW5k IGFzIHN1Y2ggaXMgZm9yIGdlbmVyYWwgaW5mb3JtYXRpb24sIGFuZA0KPj4gbm90ICBuZWNlc3Nh cmlseSBpbnRlbmRlZCB0byByZXByZXNlbnQgY29tbXVuaXR5IGNvbnNlbnN1cyBvcg0KPj4gcmVj b21tZW5kYXRpb24sIGp1c3QgbGlrZSA4MTE5Lg0KPiANCj4gSSBjaG9vc2UgdG8gZGlzYWdyZWUh IDgxOTkgaGFkIFdHIGFuZCBJRVRGIGxhc3QgY2FsbC4gSXQgaGFzIGNvbW11bml0eSBjb25zZW5z dXMuDQoNCiBUcnVlLiBJdCB3YXMgYSBoZWF2eS1oYW5kZWQgYXR0ZW1wdCBhdCBwdXNoaW5nIG9u IHRoZSBmYWN0IHRoYXQgd2XigJlyZSBub3Qgd3JpdGluZyBzdGFuZGFyZHMgaGVyZSwgYnV0IG1l cmVseSB3b3JraW5nIHRvIGluZm9ybS4gQnV0IHlvdeKAmXJlIGFic29sdXRlbHkgcmlnaHQgdGhh dCBXRyB3b3JrIGl0ZW1zIHJlZmxlY3QgY29uc2Vuc3VzLg0KDQo+IFRoZSBpbnRlbnRpb24gb2Yg dGhpcyBkcmFmdCBpcyB0aGF0IGl0LCB0b28sIHdpbGwgaGF2ZSBJRVRGIGNvbW11bml0eSBjb25z ZW5zdXMuDQo+IEJ1dCBiZSBhd2FyZSB0aGF0IHdlIGFyZSBuZWl0aGVyIHRyeWluZyB0byBmb3Jj ZSB0aGF0IGNvbnNlbnN1cywgbm9yIGRpY3RhdGUgdGhlIHRlcm1pbm9sb2d5LiBXaGF0IHdlIGFy ZSBkb2luZyBpcyB0cnlpbmcgdG8gYW5zd2VyIHRoZSAob2Z0ZW4gcmVwZWF0ZWQpIHF1ZXN0aW9u OiAiV2hlcmUgZG8gTDJTTSBhbmQgTDNTTSBmaXQgaW50byB0aGUgcGljdHVyZSBzaW5jZSB0aGV5 IGRvbid0IHNlZW0gdG8gYmUgaW50ZW5kZWQgdG8gdGFsayB0byBuZXR3b3JrIGRldmljZXMgb3Ig Y29udHJvbGxlcnM/4oCdDQoNCiBNYWtlcyBzZW5zZS4gQW5kIGluIG15IHNpbXBsaXN0aWMgKDgx OTktaW5mdXNlZCkgbWluZCwgZS5nLiBpZXRmLWwydnBuLXN2Y0AyMDE2LTA4LTE5LnlhbmcgaXMg YSBncmVhdCBleGFtcGxlIG9mIGEgTmV0d29yayBTZXJ2aWNlIE1vZHVsZS4gU28gZmFyIHNvIGdv b2QgOy0pIFdoZXRoZXIgd2UgY2FuIGNvbWUgdXAgd2l0aCBmdXJ0aGVyIGNsYXNzaWZpY2F0aW9u IHRvIHJvYnVzdGx5IGNhcHR1cmUgdGhlICJzY29wZSBvZiBhbmQgcHVycG9zZSBvZiBhbiBJRVRG IHNlcnZpY2UgbW9kZWzigJ0gaXMgbmV4dC4NCg0KPj4gQnV0IEkgd291bGQgc3VnZ2VzdCB0aGUg ZG9jdW1lbnQgY291bGQgYmUNCj4+IGltcHJvdmVkIGJ5IGVsYWJvcmF0aW5nICB0aGUgcG9pbnQg b2YgdGhlIHNlcGFyYXRpb24gb2YgdGhlIG9yY2hlc3RyYXRvcg0KPj4gYW5kIHRoZSBCU1MvT1NT IGFuZCB0aGUgcmVzdWx0aW5nIGRpZmZlcmVuY2UgaW4gbW9kdWxlIHR5cGVzLg0KPiANCj4gSSBj b3VsZCBjZXJ0YWlubHkgYWRkIHRleHQgYXJvdW5kIEZpZ3VyZSA0IHRvIHNheSAiLi4udGhpcyBp bGx1c3RyYXRlcyBhIGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJlIGFuZCBhbiBpbXBsZW1lbnRhdGlv biBtaWdodCBub3QgY2hvb3NlIHRvIG1ha2UgdGhlIGRpc3RpbmN0aW9ucyBzaG93biBzdWNoIHRo YXQgc2VwYXJhdGlvbnMgYW5kIGludGVyZmFjZXMgaWxsdXN0cmF0ZWQgbWlnaHQgZmFsbCB3aXRo aW4gYSBzaW5nbGUgaW1wbGVtZW50YXRpb24uIiBXb3VsZCB0aGF0IGhlbHA/DQoNCiBXaXRoIHRo ZSBmdXJ0aGVyIGVsYWJvcmF0aW9uIGFib3ZlLCB3b3VsZCB0aGlzIG1ha2Ugc2Vuc2U/DQoNCg0K ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgfCAgICAgICAgICAgICAgIHwN CiAgICAgICAgICB8ICAgQ3VzdG9tZXJzICAgfA0KICAgICAgICAgIHwgICAgICAgICAgICAgICB8 DQogICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtDQogICAgIEN1c3RvbWVyIFNlcnZpY2UgWUFORyBNb2R1bGVzDQoNCiAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KICAgICAgfCAgICAgT3BlcmF0aW9ucyBhbmQgQnVzaW5lc3MgU3VwcG9ydCBTeXN0ZW0g KE9TUy9CU1MpICAgICAgICB8DQogICAgICB8ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgIHwNCiAgICAgIHwgICAgICAgICAgICAgIHwg ICBTZXJ2aWNlIE9yY2hlc3RyYXRvciAgIHwgICAgICAgICAgICAgICAgICAgfA0KICAgICAgfCAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAg ICB8DQogICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0NCiAgICAgTmV0d29yayBTZXJ2aWNlIFlB TkcgTW9kdWxlcw0KDQogICAgKy0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLSsgICArLS0t LS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLSsNCiAgICB8ICAgICAgICAgICAgfCAgIHwgICAg ICAgICAgICAgfCAgIHwgICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgfA0KICAgIHwgIC0g TDJWUE4gICB8ICAgfCAgIC0gTDJWUE4gICB8ICAgfCAgICBFVlBOICAgICB8ICAgfCAgICBMM1ZQ TiAgICB8DQogICAgfCAgLSBWUFdTICAgIHwgICB8ICAgLSBWUExTICAgIHwgICB8ICAgICAgICAg ICAgIHwgICB8ICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgfCAgIHwgICAgICAgICAg ICAgfCAgIHwgICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgfA0KICAgICstLS0tLS0tLS0t LS0rICAgKy0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0r DQoNCiAgICAgLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtDQogICAgIE5ldHdvcmsgRWxlbWVudCBZQU5HIE1vZHVsZXMNCg0KICAg ICArLS0tLS0tLS0tLS0tKyAgKy0tLS0tLS0tLS0tLSsgICstLS0tLS0tLS0tLS0tKyAgKy0tLS0t LS0tLS0tLSsNCiAgICAgfCAgICAgICAgICAgIHwgIHwgICAgICAgICAgICB8ICB8ICAgICAgICAg ICAgIHwgIHwgICAgICAgICAgICB8DQogICAgIHwgICAgTVBMUyAgICB8ICB8ICAgIEJHUCAgICAg fCAgfCBJUHY0IC8gSVB2NiB8ICB8ICBFdGhlcm5ldCAgfA0KICAgICB8ICAgICAgICAgICAgfCAg fCAgICAgICAgICAgIHwgIHwgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgIHwNCiAgICAgKy0t LS0tLS0tLS0tLSsgICstLS0tLS0tLS0tLS0rICArLS0tLS0tLS0tLS0tLSsgICstLS0tLS0tLS0t LS0rDQoNCiAgICAgICBMMlZQTjogTGF5ZXIgMiBWaXJ0dWFsIFByaXZhdGUgTmV0d29yaw0KICAg ICAgIEwzVlBOOiBMYXllciAzIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrDQogICAgICAgVlBXUzog VmlydHVhbCBQcml2YXRlIFdpcmUgU2VydmljZQ0KICAgICAgIFZQTFM6IFZpcnR1YWwgUHJpdmF0 ZSBMQU4gU2VydmljZQ0KDQoNCg0KPiBNYW55IHRoYW5rcywNCj4gDQo+IEFkcmlhbg0KPiANCg0K From nobody Thu Aug 3 04:27:44 2017 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 C367C131EA6 for ; Thu, 3 Aug 2017 04:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 Lswu3dm7p2vL for ; Thu, 3 Aug 2017 04:27:39 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 A70A9131EAA for ; Thu, 3 Aug 2017 04:27:38 -0700 (PDT) Received: from [192.168.1.129] ([80.159.240.8]) by mail.gmx.com (mrgmx001 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MCtNr-1dlF1p0Gep-009gsY; Thu, 03 Aug 2017 13:27:34 +0200 From: Ian Farrer Content-Type: multipart/alternative; boundary="Apple-Mail=_E96EA3DA-AA12-4C79-A1C8-8BFDBF3D3C45" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <4E314FA5-C5AF-4EAB-87E8-256254F95142@gmx.com> Date: Thu, 3 Aug 2017 13:27:33 +0200 To: jclarke@cisco.com, opsawg@ietf.org X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:uNXidiTKRGy2gKr01aTPB76NMrluQnJ1qij75hcMC1WhcLsPMQH tynIIjfTHeG3RWofyToXwH3Y5NOtX8WW0zbjf47zJRfIuhaO07xxioiP3oPc1hdtWBzj7pk 3cTVPcYfC3T8eNeLjlbsGPiohOWc8+N7DAxXcJTIZi8zp2EEy6fJoWnsiI2gcw+f1zcNWLH bWTvA37ddnJO9LUQQURvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:WGa7VasgUoI=:QewRf9zKM/KH62lBccgFUG VsUVbiOQutAQGjOGvPU5Bbf3hIwhNpsejnQf07aG4p27Jyw4nr/20LRpFOm7j3+h6daXz7OGa rvpYWBnhAzr2CDVsV2g5mkKwUWcXjsdYv/B2hi8qAqji9RO7JDAsn73qgCXGvpNNuOFcBCkdr jXsG0eLyJJq3Db9qZ+mAWb3ToGO8MCggcS6q99kkTmg1zarQS5bWiK0rHNM19gNYs7yxm3Dfz /hK+vdNoda/UM/wjcoBl2Zq7IFCTjwGozcLyoAwp9QWfIExfzCJkLHqtD/ZeqHFWAYga+SgX4 dl2B+GWRL2uBWo1iMLjFE62CdOWliaONZ/za/7Pu4wUKUf9LmIq5v9880a0fj2Fc1nhzWa+9A v2cdnZ2ksKBpUImxQLMY+s/gcIWZQTUVoB+3cLZTXSC0+nDPtWHnNP93UDvSkGBjkcYc4CxZx U1te71gOQpUABk6kFjRlblwFUxqSEcK22b1CRsX925mdocNhB33ckZtLd5IVhNSeLT5NLwTGT GR528LBBR95zQiVG4s7D7G6iZBGGuu16eaiNOPGzWxqn8WsI01P+3URKy41keFXi8InK46uI3 ycsH2YT6bScSRXuA5DLsVSWFV5EEmxIygUNmj5X4cetePmSFya5I5b+qBJAcbbp/tlpFPCWcX eFcbuJNxv6ojiIxsiwfkf5ARlNpBXuD0T68+gnFdp57ksMAGZQoJiTigXssdDYWoRNG2oGF3C +g4YJMzlUY1rqHnfO3c5/1UUEQ7m/qHkXSGoEsPTDOBQX8dfqd5xEXyeMI4CgeNUBG2j1oh/C LEIhXEICXC+eL3Wpt2htsIM0G4I/oi6SUXnU+hpdbTvWf8KnyM= Archived-At: Subject: Re: [OPSAWG] WG adoption poll for draft-sivakumar-yang-nat-07 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, 03 Aug 2017 11:27:41 -0000 --Apple-Mail=_E96EA3DA-AA12-4C79-A1C8-8BFDBF3D3C45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I support this being adopted.=20 We have two additional yang model drafts in Softwire that will make use = of the NAT model in this draft, so it is important work. Thanks, Ian Greetings OPSAWG, After this draft was presented in Prague, it was stated that we would do=20= a call for adoption on the list. There seemed to be general support for=20= the work. Therefore, this will serve as the chairs=E2=80=99 formal = adoption=20 poll for this document into OPSAWG. YANG Data Model for Network Address Translation (NAT) https://datatracker.ietf.org/doc/draft-sivakumar-yang-nat/ = This poll request will go for three weeks to allow for the summer=20 vacation time. Please get your feedback (and initial reviews) in by=20 August 17, 2017. In addition to simply supporting the adoption, please also let us know=20= if you are willing to review the work as it progresses. Thank you. Joe (for the co-chairs) --Apple-Mail=_E96EA3DA-AA12-4C79-A1C8-8BFDBF3D3C45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 
Hi,
I support this being adopted. 
We have two additional yang model drafts in =
Softwire that will make use of the NAT model in this draft, so it is =
important work.
Thanks,
Ian

Greetings =
OPSAWG,

After this draft was presented in Prague, it was stated that we would do=20=

a call for adoption on the list.  There seemed to be general support for=20=

the work.  Therefore, this will serve as the chairs=E2=80=99 formal =
adoption=20
poll for this document into OPSAWG.

YANG Data Model for Network Address Translation (NAT)
https://datatracker.ietf.org/doc/draft-sivakumar-yang-nat/

This poll request will go for three weeks to allow for the summer=20
vacation time.  Please get your feedback (and initial reviews) in by=20
August 17, 2017.

In addition to simply supporting the adoption, please also let us know=20=

if you are willing to review the work as it progresses.

Thank you.

Joe (for the co-chairs)

= --Apple-Mail=_E96EA3DA-AA12-4C79-A1C8-8BFDBF3D3C45-- From nobody Thu Aug 3 05:51:52 2017 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 76084128961 for ; Thu, 3 Aug 2017 05:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6NPHGkDLT8c for ; Thu, 3 Aug 2017 05:51:49 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AD812EBF9 for ; Thu, 3 Aug 2017 05:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1220; q=dns/txt; s=iport; t=1501764709; x=1502974309; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=xa3ErZFgxxX9LhDQ8GDT+hrB0ilqAW/2kOUkk6gJMtU=; b=FPVSf4jYUbMkBKZF60Mkcu10rhlxsf4fvj8JRtS5A6/7o2fO16UDhph+ xGCWzyume5D109kR2sIZ4nwP6cEn8VxxJFAtEcCQdZN8GG0fsZzKdn5p1 AEp/qBDMWEOSJ8EHgIYw3sgMPRIkcBe2YZobfmRfLcthR2730M1YbfULF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgAKG4NZ/49dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkbZ49gW6WFYISLIUbAoQ9QBcBAgEBAQEBAQFrKIUYAQEBAQIBHQY?= =?us-ascii?q?PAVYLGAICJgICVwYBDAgBAYojCBCsX4Imi04BAQEBAQEBAQEBAQEBAQEBAQEbB?= =?us-ascii?q?YELgh2CAoFMgg6CfIgGgmEBBJ99h1ODA4lXgg+FWINVhwyWASABNoEKUyQVSYc?= =?us-ascii?q?2JIoMAQEB?= X-IronPort-AV: E=Sophos;i="5.41,316,1498521600"; d="scan'208";a="466015598" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2017 12:51:48 +0000 Received: from [10.150.54.144] (dhcp-10-150-54-144.cisco.com [10.150.54.144]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v73CplxV009464; Thu, 3 Aug 2017 12:51:48 GMT To: Ian Farrer , opsawg@ietf.org References: <4E314FA5-C5AF-4EAB-87E8-256254F95142@gmx.com> From: Joe Clarke Organization: Cisco Message-ID: Date: Thu, 3 Aug 2017 08:51:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <4E314FA5-C5AF-4EAB-87E8-256254F95142@gmx.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSAWG] WG adoption poll for draft-sivakumar-yang-nat-07 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, 03 Aug 2017 12:51:50 -0000 On 8/3/17 07:27, Ian Farrer wrote: > Hi, > > I support this being adopted. > > We have two additional yang model drafts in Softwire that will make use of the NAT model in this draft, so it is important work. Thanks for the support and comment, Ian. Given that SW will have dependent work, are you or others involved with that work signing up to review the NAT draft as it progresses? Joe > > Thanks, > > Ian > > > Greetings OPSAWG, > > After this draft was presented in Prague, it was stated that we would do > a call for adoption on the list. There seemed to be general support for > the work. Therefore, this will serve as the chairs’ formal adoption > poll for this document into OPSAWG. > > YANG Data Model for Network Address Translation (NAT) > https://datatracker.ietf.org/doc/draft-sivakumar-yang-nat/ > > This poll request will go for three weeks to allow for the summer > vacation time. Please get your feedback (and initial reviews) in by > August 17, 2017. > > In addition to simply supporting the adoption, please also let us know > if you are willing to review the work as it progresses. > > Thank you. > > Joe (for the co-chairs) > > From nobody Wed Aug 9 02:39:03 2017 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 4A3F2132055; Wed, 9 Aug 2017 02:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 ClGU89Qu1WSV; Wed, 9 Aug 2017 02:38:58 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10091.outbound.protection.outlook.com [40.107.1.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56F9124B0A; Wed, 9 Aug 2017 02:38:57 -0700 (PDT) Received: from VI1PR0602MB2942.eurprd06.prod.outlook.com (10.175.25.15) by VI1PR0602MB2941.eurprd06.prod.outlook.com (10.175.25.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Wed, 9 Aug 2017 09:38:54 +0000 Received: from VI1PR0602MB2942.eurprd06.prod.outlook.com ([fe80::ada1:e082:40d:a6fc]) by VI1PR0602MB2942.eurprd06.prod.outlook.com ([fe80::ada1:e082:40d:a6fc%13]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 09:38:54 +0000 From: LUIS MIGUEL CONTRERAS MURILLO To: "adrian@olddog.co.uk" , 'Tianran Zhou' , "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06 Thread-Index: AdLdnqvxxHWykNpkRwaeTXVzD7sXxAJDN94ACo/UplA= Date: Wed, 9 Aug 2017 09:38:54 +0000 Message-ID: References: <028e01d2e6ab$8cb9ab20$a62d0160$@olddog.co.uk> In-Reply-To: <028e01d2e6ab$8cb9ab20$a62d0160$@olddog.co.uk> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=luismiguel.contrerasmurillo@telefonica.com; x-originating-ip: [195.235.92.36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0602MB2941; 6:Q7MT78eq2Q5XmaAXwuUfo2+hXcd9jYTWhunA1LzXCpiu3ft6/cufrVdupZeBkrVVfjlG3sMsWdZYUKVVv3Ig1K4dN7Q5m7lUzmy70QYYCxaiP329RB6LdoT7xknRQqGKLvOMs+RtoL3OqypfdsXWlv1M84ARstjIZ2iZbqFvuvihXMQUXjnaphKyxYkZpNqEGjlp5TSnPcJo/+yegMwfRpgCypSyc1FP6AABdJfXZtoAFDjDZBhDIvZDJKL8yLRSf3JS7qPb6zb5NKKSUDhUC7SsW6zz2jhXT5/6YAROJ38lAnzVTlsM4z9zTsXQAVmxtMBnaZsU3nyl+EkDOMmQzA==; 5:mAYajinlL2fRecKIljQIQxMLtlpWUeVhmCdspYYvQscrU0ZscW0hFJDIZUaKRRhZEVbTemXh3kl0f5gt5Qcqq0wQcVaP5YuR2D/TDgXZvePrWr7vBziEUqZMsfvImJ7L1wu3aaRIOjSetZFm1ApZcw==; 24:1fNc7xCn48uScjAMFfgbwDU8uNbC+FqhwbMei7Qp9PGKC3FR2ZYpUfrA+ostkmaLZe49CDkKAPwp1eAaR8qpLnUxobzWUMoz3ovXRvhj0Qo=; 7:/pnluu3HhPSsBRuHhbgOPdjQSRfiRIX+MxdZO5H6AxiHJ8kYVPkJeYb2lsBqkCwt2cUL4a+DLLQ/MBLGKo2v4XziYniQ+oOQBOAaV3THVtHIKNYbnMuewjIHXxnly3JxGQ2pLgBZj/wjsN1i7fQDqAweu8VV9oh9s+XvBxQrOYNFsathalB0z3kPcmm50f7DfBSmKRia+0xpySAfe4k2y0tqW/c6cZk+21a6MITYNII= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9f443652-bc47-4831-70d2-08d4df0a7383 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0602MB2941; x-ms-traffictypediagnostic: VI1PR0602MB2941: x-exchange-antispam-report-test: UriScan:(40392960112811)(120809045254105)(192374486261705)(131327999870524)(50582790962513)(211171220733660)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0602MB2941; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0602MB2941; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39450400003)(39840400002)(39410400002)(39400400002)(13464003)(40134004)(189002)(25724002)(199003)(59124004)(51444003)(14454004)(55016002)(8676002)(2950100002)(229853002)(3280700002)(7736002)(966005)(305945005)(99286003)(5660300001)(8936002)(25786009)(2906002)(86362001)(189998001)(101416001)(66066001)(4326008)(74316002)(53936002)(54356999)(76176999)(3660700001)(68736007)(230783001)(105586002)(6436002)(97736004)(102836003)(6116002)(53546010)(50986999)(3846002)(478600001)(2501003)(106356001)(6506006)(81156014)(33656002)(5250100002)(38730400002)(81166006)(2900100001)(53346004)(9686003)(6246003)(7696004)(6306002)(9010500006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0602MB2941; H:VI1PR0602MB2942.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 09:38:54.5805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0602MB2941 Archived-At: Subject: Re: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06 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, 09 Aug 2017 09:39:02 -0000 Hi Adrian, all, I have been able to work on the review after holidays. Apologies for the de= lay in providing it. Please, find here below my comments and suggestions. I= f something is not clear ta all, please, let me know. *Specific comments* - There are several sentences along the document trying to define the scope= of service model in the context of IETF. These are: (1) in Terms and Conce= pts, for Service, "... A service in the context of this document (sometimes= called a Network Service) is some form of connectivity between customer si= tes and the Internet, or between customer sites across the network operator= 's network and across the Internet"; (2) section 5, first bullet, "The serv= ices we are discussing are services provided by network operators to custom= ers ... network operators may offer value-added services as well as network= connection services to their customers."; (3) section 6.4, "The IETF's wo= rk on service models is typically smaller offering a simple, self-contained= service YANG module". Since in the abstract it is stated that "This document briefly sets out the= scope of and purpose of an IETF service model", probably the best would be= to include at the very beginning a clear sentence with such definition, in= order to focus the reader. - In abstract: "... details of how network protocols and devices are engine= ered to deliver a service are captured in other models that are not exposed= through the Customer-Provider Interface" <-- Thinking on recursiveness, th= e Customer-Provide Interface can require low-level details or models. In ot= her words, when a Network Operator is Customer of another Network Operator,= what kind of interface would you consider for that relationship? - Figure 2: in contrast with Figure 3, where would be positioned here the S= ervice Delivery models? Should it be assumed a collapse of functionality in= the Orchestrator of Fig. 2 including both Service and Network Orchestrator= ? Would be those models internal? Maybe it could be convenient to reflect a= lso in Fig. 2 both Service Delivery and Network Configuration models, for c= onsistency. - In section 4, below Fig. 2: "This means that the service request must be = mapped to the orchestrator's view, and this mapping may include a choice of= which networks and technologies to use depending on which service features= have been requested." < -- Such mapping is performed by the Orchestrator i= tself, right? So maybe the sentence can be rephrased (e.g., ... the service= request must be mapped by the orchestrator ...). - Figure 3. The Customer Service model in segment (a) would be probably som= ething else than a connectivity/transport service, even though parts of suc= h service request are out of scope of IETF. I mean, e.g. a Network Service = Descriptor in NFV. So the Service Orchestrator purpose can be broader than = what is the scope of IETF. This can be maybe clarified. - Figure 3. As part of the figure or in the text description, it would be n= ice to have hints about how recursiveness or east/west relationships (for m= ultiple administrative domains) are mapped to model categories here. - Section 5, bullets about Commercial terms and SLAs. Maybe it can be conve= nient to explicitly say that they are out of the scope. It is mentioned tha= t is hard to standardize this, but no assertive indication if both are out = of the scope. - Section 6: "... interface between the Service Orchestrator or OSS/BSS ...= ". Does it apply as well to Fig. 3? If so, maybe it would be nice also to i= nclude in Fig. 3 for consistency. - Figure 4. I think that the figure it is not clear at all. There is a mix = of functional elements (e.g. Service Orchestrator, OSS/BSS) with models. Pr= obably a more homogeneous figure could be better. - Section 6.2: it would be nice to make clear what of the sample models can= be categorized as Service Delivery model, and what of them can be categori= zed as network Element (or device) models. - MEF work is mentioned in section 6.4. I think it would be necessary to co= ver/describe some other initiatives like the one of ETSI NFV with respect t= o Network Service Descriptors. - Section 6.4: "This does not invalidate either approach, but only observes= that they are different." More than different, MEF as described here is br= oader in scope. Maybe the sentence can be rephrased in this sense. - Section 7.2: it is not clear if policies are considered or not as part of= the scope of the customer service models. Difficulties on identifying comm= on policies for the operators are mentioned. But similar situation is also = mentioned in section 7.3 with the result of identifying common parametrizat= ion after working on it. So maybe it can be mentioned that such kind of wor= k is required, instead of not covering policies at all. - Section 8: the interface between Service Orchestrator and Network Orchest= rator can be also external, and then security measures should be applied. - Section 9, last paragraph: Reporting is essential for SLAs (monitoring) a= nd accounting / billing (resource usage). But it seems (as mentioned before= in the document) that commercial terms and SLAs are not part of the custom= er service models. Then, if reporting is included as part of the customer s= ervice model, as suggested by this paragraph, it is apparently inconsistent= with the fact of not having the ways of requesting SLAs and billing, but h= aving the necessary information for that being reported (in other words, ho= w can I express what information is of interest for me if I cannot express = SLAs or commercial terms?). *Editorial comments* - In abstract: RFC 8049 should be included between brackets. - In section 2, Terms and concepts: for Network Operator -> it is mentioned= that "The term is also used to refer to an individual who performs operati= ons and management on those networks." <-- Since it is not used with this m= eaning in the text, I would remove that clarification to avoid ambiguity. - In section 2, Terms and concepts: for Data Model -> the following sentenc= e seems to be editorial, maybe it can be removed: "so it may be helpful to = quote some text to give context within this document." - Section 6.2 < -- Probably it would be better to separate Service Delivery= from Network Element models in different sections, with sample models refe= rred - Same section. Network Element model is introduced here for 1st time. In f= igure 3 it is referred as device configuration model. It would be better to= have an homogeneous naming. - Section 9, first sentence: "... related to network management." -> "... r= elated to network management and control." Best regards Luis __________________________________ Luis M. Contreras Technology and Planning Transport, IP and Interconnection Networks Telef=F3nica I+D / Global CTO unit / Telef=F3nica Distrito Telef=F3nica, Edificio Sur 3, Planta 3 28050 Madrid Espa=F1a / Spain Skype (Lync): +34 91 312 9084 Mobile: +34 680 947 650 luismiguel.contrerasmurillo@telefonica.com -----Mensaje original----- De: OPSAWG [mailto:opsawg-bounces@ietf.org] En nombre de Adrian Farrel Enviado el: viernes, 16 de junio de 2017 16:19 Para: 'Tianran Zhou' ; opsawg@ietf.org CC: opsawg-chairs@ietf.org Asunto: Re: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-exp= lained-06 Of course, I support the WG working on this :-) The offer of a review from Luis is gratefully accepted. That will make for = a nice first revision inside the WG. Joe. Yes, I'd be interested to hear what other's think about your point, an= d to add text to clarify the issue. Cheers, Adrian > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran > Zhou > Sent: 05 June 2017 02:55 > To: opsawg@ietf.org > Cc: opsawg-chairs@ietf.org > Subject: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model- > explained-06 > > Dear OPSAWG, > > In Seoul, we got enough interest and positive response on this service > models explained draft. > By the authors' request, this email starts a formal poll. The chairs > would like to > know if the WG participants agree that the following document should > be adopted as a WG document in OPSAWG. > > Service Models Explained > https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explain > ed/ > > The adoption poll will take two weeks. Please let us know your opinion > by June 19. It would also be good to hear who is willing to review this d= ocument. > > Since we already found that the majority of the f2f participants at > our IETF97 session like this idea, please do speak up now if you do > not agree or have serious > objections (with explanation of course). > > Regards, > Tianran, OPSAWG Co-Chair > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Wed Aug 9 05:34:11 2017 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 AD5B11323C7; Wed, 9 Aug 2017 05:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 OtSIpudJmwC0; Wed, 9 Aug 2017 05:34:07 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084B41323B5; Wed, 9 Aug 2017 05:33:58 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v79CXnac021020; Wed, 9 Aug 2017 13:33:49 +0100 Received: from 950129200 ([96.47.153.2]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v79CXk4w020970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Aug 2017 13:33:48 +0100 Reply-To: From: "Adrian Farrel" To: "'LUIS MIGUEL CONTRERAS MURILLO'" , "'Tianran Zhou'" , Cc: References: <028e01d2e6ab$8cb9ab20$a62d0160$@olddog.co.uk> In-Reply-To: Date: Wed, 9 Aug 2017 13:33:43 +0100 Message-ID: <00b001d3110b$c0226b70$40674250$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHTPawIDXDMTslJzeQqpAnPR3LeKAFNC4xVAPxshNmiaU/aQA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23246.006 X-TM-AS-Result: No--22.818-10.0-31-10 X-imss-scan-details: No--22.818-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wjDfgfM3Zc/RIHYIZed9zXVJg8sTT3RzF9oJ bLBq7ybGoz8HTl+z1fZ/Lx6iMAc0GFQeeXZETLPMQr2qXCJMSV8gIlfZcIw7oB2MqMQkpb/vaRn uwdqIKHv+JciIkC3M9vFPDHhQkgxyXKzTiz0xAeCVUcz8XpiS9OnyXFanZ6WWInzOyTDR1utyZ4 bLJyy0n8hbo7VYichQOOjWlZAQN6m1zIiTDWBbO0hEDfw/93Bubv16+gil4jdPtLhlThdPEFpNb XTsWM8cxdMDEDSgbA/QYszg5zwOGX8b147nSU7WMCg3EkpGtWvS+VqQO/GHvP5PMwphTQFKjzro MRry5yIHnm6aYFp1bLX1Kd5A3Ra5ej+lfNCDL2+GwT67eecJ8LzWODqZvEk5iGWrzccRsv4n357 avcH0+wlNTOh1ZlxvyU3TZOaWRvELVz2hLJE7uXV895e/Bd2JcK8qHvdFHLCCsBeCv8CM/YRp0u V6Yx1jc3XzZqLTk6zz8SuI8XssnQIDy0k6N7pnypeMiaCPnxuimsR6hkcJAn1Dn+DKecbWCf2h9 A2gFAVf58NTALKPeStTyad5t0PaSOSNhk9WmWFzaTZqCdc3fKO7Nt6iP+dXFhtZRxCBI9hLzIAq tC0PPgxkiPHh9EVXJGvIodm8AYiEQtdzMrOJAnXuAcDIAWvTmyqQJWNsuklrMbakJN8OeZHZY1M 4VObvFZRSPe8XO0sKMVwUnzYRRYNq8Tt0UzjvqeBupNgLgYcxXH/dlhvLv6drpTvh7T6opfQfeo vBjyhDatNlARhKq++7eYCcDqzZd3WlHgjh+h2eAiCmPx4NwGNn8XPiALIb+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Subject: Re: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06 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, 09 Aug 2017 12:34:11 -0000 Luis thanks very much indeed for such a thorough and thoughtful review. We'll come back to you with detailed responses SOON. Cheers, Adrian -- Support an author and your imagination Tales from the Wood - Eighteen new fairy tales More Tales from the Wood - Eighteen MORE new fairy tales Coming soon - Tales from Beyond the Wood https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: LUIS MIGUEL CONTRERAS MURILLO > [mailto:luismiguel.contrerasmurillo@telefonica.com] > Sent: 09 August 2017 10:39 > To: adrian@olddog.co.uk; 'Tianran Zhou'; opsawg@ietf.org > Cc: opsawg-chairs@ietf.org > Subject: RE: [OPSAWG] WG adoption poll for = draft-wu-opsawg-service-model- > explained-06 >=20 > Hi Adrian, all, >=20 > I have been able to work on the review after holidays. Apologies for = the delay in > providing it. Please, find here below my comments and suggestions. If something > is not clear ta all, please, let me know. >=20 > *Specific comments* >=20 > - There are several sentences along the document trying to define the = scope of > service model in the context of IETF. These are: (1) in Terms and = Concepts, for > Service, "... A service in the context of this document (sometimes = called a > Network Service) is some form of connectivity between customer sites = and the > Internet, or between customer sites across the network operator's = network and > across the Internet"; (2) section 5, first bullet, "The services we = are discussing are > services provided by network operators to customers ... network = operators may > offer value-added services as well as network connection services to = their > customers."; (3) section 6.4, "The IETF's work on service models is = typically > smaller offering a simple, self-contained service YANG module". > Since in the abstract it is stated that "This document briefly sets = out the scope of > and purpose of an IETF service model", probably the best would be to = include at > the very beginning a clear sentence with such definition, in order to = focus the > reader. >=20 > - In abstract: "... details of how network protocols and devices are engineered to > deliver a service are captured in other models that are not exposed = through the > Customer-Provider Interface" <-- Thinking on recursiveness, the = Customer- > Provide Interface can require low-level details or models. In other = words, when a > Network Operator is Customer of another Network Operator, what kind of > interface would you consider for that relationship? >=20 > - Figure 2: in contrast with Figure 3, where would be positioned here = the Service > Delivery models? Should it be assumed a collapse of functionality in = the > Orchestrator of Fig. 2 including both Service and Network = Orchestrator? Would > be those models internal? Maybe it could be convenient to reflect also = in Fig. 2 > both Service Delivery and Network Configuration models, for = consistency. >=20 > - In section 4, below Fig. 2: "This means that the service request = must be mapped > to the orchestrator's view, and this mapping may include a choice of = which > networks and technologies to use depending on which service features = have > been requested." < -- Such mapping is performed by the Orchestrator = itself, > right? So maybe the sentence can be rephrased (e.g., ... the service = request must > be mapped by the orchestrator ...). >=20 > - Figure 3. The Customer Service model in segment (a) would be = probably > something else than a connectivity/transport service, even though = parts of such > service request are out of scope of IETF. I mean, e.g. a Network = Service > Descriptor in NFV. So the Service Orchestrator purpose can be broader = than what > is the scope of IETF. This can be maybe clarified. >=20 > - Figure 3. As part of the figure or in the text description, it would = be nice to have > hints about how recursiveness or east/west relationships (for multiple > administrative domains) are mapped to model categories here. >=20 > - Section 5, bullets about Commercial terms and SLAs. Maybe it can be > convenient to explicitly say that they are out of the scope. It is = mentioned that is > hard to standardize this, but no assertive indication if both are out = of the scope. >=20 > - Section 6: "... interface between the Service Orchestrator or = OSS/BSS ...". Does > it apply as well to Fig. 3? If so, maybe it would be nice also to = include in Fig. 3 for > consistency. >=20 > - Figure 4. I think that the figure it is not clear at all. There is a = mix of functional > elements (e.g. Service Orchestrator, OSS/BSS) with models. Probably a = more > homogeneous figure could be better. >=20 > - Section 6.2: it would be nice to make clear what of the sample = models can be > categorized as Service Delivery model, and what of them can be = categorized as > network Element (or device) models. >=20 > - MEF work is mentioned in section 6.4. I think it would be necessary = to > cover/describe some other initiatives like the one of ETSI NFV with = respect to > Network Service Descriptors. >=20 > - Section 6.4: "This does not invalidate either approach, but only = observes that > they are different." More than different, MEF as described here is = broader in > scope. Maybe the sentence can be rephrased in this sense. >=20 > - Section 7.2: it is not clear if policies are considered or not as = part of the scope of > the customer service models. Difficulties on identifying common = policies for the > operators are mentioned. But similar situation is also mentioned in = section 7.3 > with the result of identifying common parametrization after working on = it. So > maybe it can be mentioned that such kind of work is required, instead = of not > covering policies at all. >=20 > - Section 8: the interface between Service Orchestrator and Network > Orchestrator can be also external, and then security measures should = be applied. >=20 > - Section 9, last paragraph: Reporting is essential for SLAs = (monitoring) and > accounting / billing (resource usage). But it seems (as mentioned = before in the > document) that commercial terms and SLAs are not part of the customer = service > models. Then, if reporting is included as part of the customer service = model, as > suggested by this paragraph, it is apparently inconsistent with the = fact of not > having the ways of requesting SLAs and billing, but having the = necessary > information for that being reported (in other words, how can I express = what > information is of interest for me if I cannot express SLAs or = commercial terms?). >=20 > *Editorial comments* >=20 > - In abstract: RFC 8049 should be included between brackets. >=20 > - In section 2, Terms and concepts: for Network Operator -> it is = mentioned that > "The term is also used to refer to an individual who performs = operations and > management on those networks." <-- Since it is not used with this = meaning in the > text, I would remove that clarification to avoid ambiguity. >=20 > - In section 2, Terms and concepts: for Data Model -> the following = sentence > seems to be editorial, maybe it can be removed: "so it may be helpful = to quote > some text to give context within this document." >=20 > - Section 6.2 < -- Probably it would be better to separate Service = Delivery from > Network Element models in different sections, with sample models = referred >=20 > - Same section. Network Element model is introduced here for 1st time. = In figure > 3 it is referred as device configuration model. It would be better to = have an > homogeneous naming. >=20 > - Section 9, first sentence: "... related to network management." -> = "... related to > network management and control." >=20 >=20 > Best regards >=20 > Luis >=20 > __________________________________ > Luis M. Contreras >=20 > Technology and Planning > Transport, IP and Interconnection Networks > Telef=F3nica I+D / Global CTO unit / Telef=F3nica >=20 > Distrito Telef=F3nica, Edificio Sur 3, Planta 3 > 28050 Madrid > Espa=F1a / Spain >=20 > Skype (Lync): +34 91 312 9084 > Mobile: +34 680 947 650 > luismiguel.contrerasmurillo@telefonica.com >=20 >=20 > -----Mensaje original----- > De: OPSAWG [mailto:opsawg-bounces@ietf.org] En nombre de Adrian Farrel > Enviado el: viernes, 16 de junio de 2017 16:19 > Para: 'Tianran Zhou' ; opsawg@ietf.org > CC: opsawg-chairs@ietf.org > Asunto: Re: [OPSAWG] WG adoption poll for = draft-wu-opsawg-service-model- > explained-06 >=20 > Of course, I support the WG working on this :-) >=20 > The offer of a review from Luis is gratefully accepted. That will make = for a nice > first revision inside the WG. >=20 > Joe. Yes, I'd be interested to hear what other's think about your = point, and to add > text to clarify the issue. >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran > > Zhou > > Sent: 05 June 2017 02:55 > > To: opsawg@ietf.org > > Cc: opsawg-chairs@ietf.org > > Subject: [OPSAWG] WG adoption poll for = draft-wu-opsawg-service-model- > > explained-06 > > > > Dear OPSAWG, > > > > In Seoul, we got enough interest and positive response on this = service > > models explained draft. > > By the authors' request, this email starts a formal poll. The chairs > > would > like to > > know if the WG participants agree that the following document should > > be adopted as a WG document in OPSAWG. > > > > Service Models Explained > > = https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explain > > ed/ > > > > The adoption poll will take two weeks. Please let us know your = opinion > > by June 19. It would also be good to hear who is willing to review = this > document. > > > > Since we already found that the majority of the f2f participants at > > our IETF97 session like this idea, please do speak up now if you do > > not agree or have > serious > > objections (with explanation of course). > > > > Regards, > > Tianran, 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 >=20 > ________________________________ >=20 > Este mensaje y sus adjuntos se dirigen exclusivamente a su = destinatario, puede > contener informaci=F3n privilegiada o confidencial y es para uso = exclusivo de la > persona o entidad de destino. Si no es usted. el destinatario = indicado, queda > notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia = sin autorizaci=F3n > puede estar prohibida en virtud de la legislaci=F3n vigente. Si ha = recibido este > mensaje por error, le rogamos que nos lo comunique inmediatamente por = esta > misma v=EDa y proceda a su destrucci=F3n. >=20 > The information contained in this transmission is privileged and = confidential > information intended only for the use of the individual or entity = named above. If > the reader of this message is not the intended recipient, you are = hereby notified > that any dissemination, distribution or copying of this communication = is strictly > prohibited. If you have received this transmission in error, do not = read it. Please > immediately reply to the sender that you have received this = communication in > error and then delete it. >=20 > Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=E1rio, > pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso = exclusivo da > pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o = destinat=E1rio indicado, > fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou = c=F3pia sem autoriza=E7=E3o > pode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu = esta mensagem > por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma = via > e proceda a sua destrui=E7=E3o From nobody Fri Aug 11 13:02:44 2017 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 4EE7A127058; Fri, 11 Aug 2017 13:02:37 -0700 (PDT) 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.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150248175729.24498.16927681607334663849@ietfa.amsl.com> Date: Fri, 11 Aug 2017 13:02:37 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.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, 11 Aug 2017 20:02:37 -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-08.txt Pages : 48 Date : 2017-08-11 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). This includes 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 11 13:11:04 2017 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 65B161325DD for ; Fri, 11 Aug 2017 13:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.986 X-Spam-Level: X-Spam-Status: No, score=-11.986 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, 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 uabPJz3D0cg3 for ; Fri, 11 Aug 2017 13:11:00 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EAC132530 for ; Fri, 11 Aug 2017 13:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3705; q=dns/txt; s=iport; t=1502482260; x=1503691860; h=subject:cc:references:from:message-id:date:mime-version: in-reply-to; bh=w9r0lvQF1GUHpR8oLw8axIwj1YqfLOqT900nTbkBK5Y=; b=Izo/8u1tTzQC3JIzn4Ugl8p2TvZZxsjVZaAwKp+vPY56YhIAG6e6W1TS R7nD5z6CDshaFwejYOq17rdOlIdMStB8Ys7YxN6WWwCXH/GD8K33LodHG CawoKtlDoFL6m+DAQ5Vd0fQpOcYTsujmX0xIsHYchtlTrDSD6K4ryRQQZ U=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAADpDY5Z/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgQUPjhGQDIFulheCEgcaC4RMTwImhFA/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRAJAQEBAwEBIUsLEAsSBioCAiciDhMGAgEBhW6EPRCrZIImi2ABAQEBAQUBA?= =?us-ascii?q?QEBAQETD4MoggKDWoJ8gyaEYBOCTgWKBIgPjhOEMYIhgQGMZ4IPWYUEg1eHEYl?= =?us-ascii?q?kjC8fOIEKMiEIHBUfKnYPhjUgNoovAQEF?= X-IronPort-AV: E=Sophos;i="5.41,359,1498521600"; d="asc'?scan'208";a="279445355" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Aug 2017 20:10:59 +0000 Received: from [10.41.34.92] ([10.41.34.92]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7BKAxti000492 for ; Fri, 11 Aug 2017 20:10:59 GMT Cc: opsawg@ietf.org References: <150248175729.24498.16927681607334663849@ietfa.amsl.com> From: Eliot Lear Message-ID: <9956db24-0a43-c739-d729-c580ff037cc7@cisco.com> Date: Fri, 11 Aug 2017 13:10:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150248175729.24498.16927681607334663849@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BdDXKBofUJlrPc9OmkVpDUKVWdBV5PRlw" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.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, 11 Aug 2017 20:11:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BdDXKBofUJlrPc9OmkVpDUKVWdBV5PRlw Content-Type: multipart/mixed; boundary="Ne7cu7frffGdfRaWFX9XC4NXC60n7bXdB"; protected-headers="v1" From: Eliot Lear Cc: opsawg@ietf.org Message-ID: <9956db24-0a43-c739-d729-c580ff037cc7@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.txt References: <150248175729.24498.16927681607334663849@ietfa.amsl.com> In-Reply-To: <150248175729.24498.16927681607334663849@ietfa.amsl.com> --Ne7cu7frffGdfRaWFX9XC4NXC60n7bXdB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi everyone, As promised, this update corrects all examples (we just didn't have time to do that for the IETF) and adds a bit more wording around the abstractions so as to give some guidance on how to translate abstractions. In addition, some guidance is given relating to how to instantiate the ACL model, given the use of features. Finally, the MUD file maker has been updated, and can now be reached at mudmaker.org. With this, I would ask that we start the various YANG doctor and other directorate reviews. Eliot On 8/11/17 1:02 PM, 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-08.txt > Pages : 48 > Date : 2017-08-11 > > Abstract: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). This includes 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-08 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-08 > > > 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 > --Ne7cu7frffGdfRaWFX9XC4NXC60n7bXdB-- --BdDXKBofUJlrPc9OmkVpDUKVWdBV5PRlw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZjg9TAAoJEIe2a0bZ0nozlXgIAJsVV8s4cSJYB359eRSDjGh8 A8w66n7JWHQ3LPEbKCOgXa1/QgJY2iNsprmy0zlW1G3PV6irI9VThgl35Y4b7cQn Dtl+Pj2nCSIcuOJEchWBOY4hv6sDroPV3l5s/YLw2yNcoo9Zi/pd2TZqNiUADqIf 41FP8TxkhJ2Zg0PbvKs8UWcSYySyDrY09fHhQeEIHA8Y9u42FozrbNOdYFUI39cW 1c8phESiSo5oiUcp7OZoYDmghjihDb8MslkL8U9aWTAri0hapwyu2JhKPgsIEPBl BGURtzIsDe+SMDRzVNqJ2bm8NxrB6RCZvq0wbp+j5xxnR5Zl5yYjQUQRhBryc5c= =BZhU -----END PGP SIGNATURE----- --BdDXKBofUJlrPc9OmkVpDUKVWdBV5PRlw-- From nobody Mon Aug 14 11:41:12 2017 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 931CE1323B5 for ; Mon, 14 Aug 2017 11:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.987 X-Spam-Level: X-Spam-Status: No, score=-12.987 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, URIBL_RHS_DOB=1.514, 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 CtCbkrrW5WI4 for ; Mon, 14 Aug 2017 11:41:08 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F893132399 for ; Mon, 14 Aug 2017 11:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5817; q=dns/txt; s=iport; t=1502736068; x=1503945668; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=seUPlaZMRVnJ4tvdNYRobRk0Yl7qR0REvidYLFKDjzI=; b=fZaL1SlImkUT973zys88ZYrSRxox6ReuNxmQ6JWgExjxruic9PLXvhtl wSUi6IGDkkTAQrqkJ/4Z4fYpQuG1jmnVD72aBn2wDkMoZC3Dbb1FaTGNq zfUMj7MYXeVD/EaG0K8phjaIONyfVRrjHG4soUJ+OzjX8UyOVx27EroNV w=; X-IronPort-AV: E=Sophos;i="5.41,374,1498521600"; d="scan'208";a="443029657" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2017 18:41:07 +0000 Received: from [10.118.87.86] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7EIf7OL017036; Mon, 14 Aug 2017 18:41:07 GMT To: Eliot Lear Cc: opsawg@ietf.org References: <150248175729.24498.16927681607334663849@ietfa.amsl.com> <9956db24-0a43-c739-d729-c580ff037cc7@cisco.com> From: Joe Clarke Organization: Cisco Message-ID: <0994d0ba-714d-3b5c-8542-06ee19dceef1@cisco.com> Date: Mon, 14 Aug 2017 14:41:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9956db24-0a43-c739-d729-c580ff037cc7@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.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: Mon, 14 Aug 2017 18:41:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Eliot and MUD authors. I first want to chime in as a working group member and provide a review of this latest revision. Please see below. Section 1: OLD: In this specification we specify each of these building blocks and how they are intended to be used together NEW: In this specification we describe each of these building blocks and how they are intended to be used together It's a nit, but specification and specify sound awkward together. So I chose a different word. === Section 1.2: I love the readability of this in general, but maybe replace "Facebook" with "social network" or something a bit more generic. === Section 1.4: You state that the memo describes three ways to emit a MUD URL. You ultimately list three, but this reads strangely: The other method defined is an X.509 constraint... This is the second method (the first being DHCP). So maybe you should state, "An other method" or "The second method". === Section 1.6: A MUD file is more than just a behavior. It lists details about a Thing such as whether or not it's supported, details about it from a reference URL, etc. Perhaps the definition of a MUD file should be "...JSON that describes a Thing and its required network behavior." === Section 1.7: You mix the use of URL and URI. While a URL is a URI, I think it would be good to keep the use of URL as that is what you define in section 1.6. === Section 1.8: While you call out a reputation system check, would an important step here be to verify the overall veracity of the MUD file itself? That is, verify the MUD files signature. You talk about this below, but I think it's worth calling out here as well. === Section 2: You state that "Devices parsing MUD files..." I think you should refer to your terminology here and say "MUD controllers parsing MUD files..." Additionally, you say that upon seeing "other" elements in the MUD file, the controller should cease processing. What exactly happens, then, to the data already parsed? Does that get applied, or must the controller reject the entire file? IMHO, the controller should disregard a file that violates the spec. But in any case, I think you should be explicit here in the text. === Section 6: Should the timers for last-update and cache-validity be mandatory? As it stands now, nothing in metainfo is mandatory, and I think some things (like the timers) should be. I also think is-supported is key. === Section 7: Typo: replicated across IPv4 and IPv6 to allow MUD file autjors the ability I think you mean "authors". === Sections 7.1 and 7.2: I would imagine at some level these names would have to be resolved. Perhaps what you mean as to when they are resolved is left to the implementation? That is to say, some vendors may resolve at the time of configuration whereas others may resolve more dynamically. === Appendix B and Section 8: These are out of date with the current schema. For example, you have lastUpdate instead of last-update, cacheValidity instead of cache-validity. Joe On 8/11/17 16:10, Eliot Lear wrote: > Hi everyone, > > As promised, this update corrects all examples (we just didn't have > time to do that for the IETF) and adds a bit more wording around > the abstractions so as to give some guidance on how to translate > abstractions. In addition, some guidance is given relating to how > to instantiate the ACL model, given the use of features. > > Finally, the MUD file maker has been updated, and can now be > reached at mudmaker.org. > > With this, I would ask that we start the various YANG doctor and > other directorate reviews. > > Eliot > > > On 8/11/17 1:02 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 >> 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-08.txt Pages : 48 Date >> : 2017-08-11 >> >> Abstract: This memo specifies a component-based architecture for >> manufacturer usage descriptions (MUD). This includes 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-08 >> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-08 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-08 >> >> >> 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/ >> >> _______________________________________________ OPSAWG mailing >> list OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > > > _______________________________________________ OPSAWG mailing > list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg > -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWZHuvgAKCRBvaI+K/hTP h2xLAKCrdGolZdv0x/47tywrINlsT4XcowCfUCBThZqwYuO/+ZmyDl4G641Q1xs= =cVEQ -----END PGP SIGNATURE----- From nobody Mon Aug 14 13:07:20 2017 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 D4685132391 for ; Mon, 14 Aug 2017 13:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.986 X-Spam-Level: X-Spam-Status: No, score=-12.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, 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 GjmYsoHMXtb1 for ; Mon, 14 Aug 2017 13:07:17 -0700 (PDT) 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 5990B126E64 for ; Mon, 14 Aug 2017 13:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20812; q=dns/txt; s=iport; t=1502741236; x=1503950836; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=q4i5V/i2X4yDEuxTXv0K5tInMnJoGMqkOGsrSauRr94=; b=GUbkSRBji5YpUEieuP5knaRn+l1x77VU/jFH7tS1ySimt9WMASkzdKaO P3ej0YuK2By+1QGy6BC1enTRikgQUUoaa5yM1bG8toWZ19QpsEugQQsPR gDGP9Hxw0mmk/CkWthjf0OABZT4A7Oq0vG0xCZIu7yYL8rST28lsNQCol E=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.41,374,1498521600"; d="asc'?scan'208,217";a="656776351" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2017 20:07:14 +0000 Received: from [10.61.167.177] ([10.61.167.177]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7EK7Ebh027765; Mon, 14 Aug 2017 20:07:14 GMT To: Joe Clarke Cc: opsawg@ietf.org References: <150248175729.24498.16927681607334663849@ietfa.amsl.com> <9956db24-0a43-c739-d729-c580ff037cc7@cisco.com> <0994d0ba-714d-3b5c-8542-06ee19dceef1@cisco.com> From: Eliot Lear Message-ID: Date: Mon, 14 Aug 2017 21:07:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0994d0ba-714d-3b5c-8542-06ee19dceef1@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t1bO8cRX6GXK9IbLkoPmq4qIvc5Ro3xLu" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.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: Mon, 14 Aug 2017 20:07:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t1bO8cRX6GXK9IbLkoPmq4qIvc5Ro3xLu Content-Type: multipart/mixed; boundary="gq0JpN6JnJNoknI2H5WAlodob5teEmuKd"; protected-headers="v1" From: Eliot Lear To: Joe Clarke Cc: opsawg@ietf.org Message-ID: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.txt References: <150248175729.24498.16927681607334663849@ietfa.amsl.com> <9956db24-0a43-c739-d729-c580ff037cc7@cisco.com> <0994d0ba-714d-3b5c-8542-06ee19dceef1@cisco.com> In-Reply-To: <0994d0ba-714d-3b5c-8542-06ee19dceef1@cisco.com> --gq0JpN6JnJNoknI2H5WAlodob5teEmuKd Content-Type: multipart/alternative; boundary="------------6832122971E909CF28877836" Content-Language: en-US This is a multi-part message in MIME format. --------------6832122971E909CF28877836 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joe, Thanks for your thoughtful review. Please now see below. On 8/14/17 7:41 PM, Joe Clarke wrote: > Hello, Eliot and MUD authors. I first want to chime in as a working > group member and provide a review of this latest revision. Please see > below. > > Section 1: > > OLD: > > In this specification we specify each of these building blocks and > how they are intended to be used together > > NEW: > > In this specification we describe each of these building blocks and > how they are intended to be used together > > It's a nit, but specification and specify sound awkward together. So > I chose a different word. +1. Nice catch. > > =3D=3D=3D > > Section 1.2: > > I love the readability of this in general, but maybe replace > "Facebook" with "social network" or something a bit more generic. Ok. > > =3D=3D=3D > > Section 1.4: > > You state that the memo describes three ways to emit a MUD URL. You > ultimately list three, but this reads strangely: > > The other method defined is an X.509 constraint... > > This is the second method (the first being DHCP). So maybe you should > state, "An other method" or "The second method". Right. > > =3D=3D=3D > > Section 1.6: > > A MUD file is more than just a behavior. It lists details about a > Thing such as whether or not it's supported, details about it from a > reference URL, etc. Perhaps the definition of a MUD file should be > "...JSON that describes a Thing and its required network behavior." I would prefer to run with "suggested" than "required". The analogy has always been an indications label that comes with medicine. You can go off label if you want, Mme. Administrator, even if it isn't recommended. > > =3D=3D=3D > > Section 1.7: > > You mix the use of URL and URI. While a URL is a URI, I think it > would be good to keep the use of URL as that is what you define in > section 1.6. Righto. There are a handful of places where URI is still appropriate (registrations, internationalization). > > =3D=3D=3D > > Section 1.8: > > While you call out a reputation system check, would an important step > here be to verify the overall veracity of the MUD file itself? That > is, verify the MUD files signature. You talk about this below, but I > think it's worth calling out here as well. Good point. > > =3D=3D=3D > > Section 2: > > You state that "Devices parsing MUD files..." I think you should > refer to your terminology here and say "MUD controllers parsing MUD > files..." > Right. > Additionally, you say that upon seeing "other" elements in the MUD > file, the controller should cease processing. What exactly happens, > then, to the data already parsed? Does that get applied, or must the > controller reject the entire file? IMHO, the controller should > disregard a file that violates the spec. But in any case, I think you > should be explicit here in the text. Made explicit. > > =3D=3D=3D > > Section 6: > > Should the timers for last-update and cache-validity be mandatory? As > it stands now, nothing in metainfo is mandatory, and I think some > things (like the timers) should be. I also think is-supported is key. That's a good question and I like the list that you identified. I think this requires some additional discussion, though, just to confirm model structure. I'll come back to you on this. > > =3D=3D=3D > > Section 7: > > Typo: replicated across IPv4 and IPv6 to allow MUD file autjors the > ability > > I think you mean "authors". > Corrected. > =3D=3D=3D > > Sections 7.1 and 7.2: > > I would imagine at some level these names would have to be resolved. > Perhaps what you mean as to when they are resolved is left to the > implementation? That is to say, some vendors may resolve at the time > of configuration whereas others may resolve more dynamically. I think I want to say more than that. What I'm thinking about is as follows: > A number of means may be used to resolve hosts. What is > important is that such resolutions be consistent with ACLs required by > devices to properly operate. > > =3D=3D=3D > > Appendix B and Section 8: > > These are out of date with the current schema. For example, you have > lastUpdate instead of last-update, cacheValidity instead of > cache-validity. > Oh nertz! That's a mudmaker bug. Fixed! Thanks! Eliot=20 > Joe > > On 8/11/17 16:10, Eliot Lear wrote: > > Hi everyone, > > > As promised, this update corrects all examples (we just didn't have > > time to do that for the IETF) and adds a bit more wording around > > the abstractions so as to give some guidance on how to translate > > abstractions. In addition, some guidance is given relating to how > > to instantiate the ACL model, given the use of features. > > > Finally, the MUD file maker has been updated, and can now be > > reached at mudmaker.org. > > > With this, I would ask that we start the various YANG doctor and > > other directorate reviews. > > > Eliot > > > > On 8/11/17 1:02 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 > >> 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-08.txt Pages : 48 Date > >> : 2017-08-11 > >> > >> Abstract: This memo specifies a component-based architecture for > >> manufacturer usage descriptions (MUD). This includes 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-08 > >> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-08 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-08 > >> > >> > >> 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/ > >> > >> _______________________________________________ OPSAWG mailing > >> list OPSAWG@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsawg > >> > > > > > > _______________________________________________ OPSAWG mailing > > list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg > > > --------------6832122971E909CF28877836 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joe,

Thanks for your thoughtful review.=C2=A0 Please now see below.

<individual-not-editor-or author>


On 8/14/17 7:41 PM, Joe Clarke wrote:
Hello, Eliot and MUD authors.=C2=A0 I first= want to chime in as a working
group member and provide a review of this latest revision.=C2=A0 Pl= ease see
below.

Section 1:

OLD:

In this specification we specify each of these building blocks and<= br> how they are intended to be used together

NEW:

In this specification we describe each of these building blocks and
how they are intended to be used together

It's a nit, but specification and specify sound awkward together.=C2= =A0 So
I chose a different word.

+1.=C2=A0 Nice catch.


=3D=3D=3D

Section 1.2:

I love the readability of this in general, but maybe replace
"Facebook" with "social network" or something a bit more generic.

Ok.


=3D=3D=3D

Section 1.4:

You state that the memo describes three ways to emit a MUD URL.=C2=A0= You
ultimately list three, but this reads strangely:

The other method defined is an X.509 constraint...

This is the second method (the first being DHCP).=C2=A0 So maybe yo= u should
state, "An other method" or "The second method".

Right.


=3D=3D=3D

Section 1.6:

A MUD file is more than just a behavior.=C2=A0 It lists details abo= ut a
Thing such as whether or not it's supported, details about it from a
reference URL, etc.=C2=A0 Perhaps the definition of a MUD file shou= ld be
"...JSON that describes a Thing and its required network behavior."

I would prefer to run with "suggested" than "required".=C2=A0 The ana= logy has always been an indications label that comes with medicine.=C2=A0 = You can go off label if you want, Mme. Administrator, even if it isn't recommended.



=3D=3D=3D

Section 1.7:

You mix the use of URL and URI.=C2=A0 While a URL is a URI, I think= it
would be good to keep the use of URL as that is what you define in<= br> section 1.6.

Righto.=C2=A0 There are a handful of places where URI is still appropriate (registrations, internationalization).

=3D=3D=3D

Section 1.8:

While you call out a reputation system check, would an important step
here be to verify the overall veracity of the MUD file itself?=C2=A0= That
is, verify the MUD files signature.=C2=A0 You talk about this below= , but I
think it's worth calling out here as well.

Good point.

=3D=3D=3D

Section 2:

You state that "Devices parsing MUD files..."=C2=A0 I think you sho= uld
refer to your terminology here and say "MUD controllers parsing MUD
files..."

Right.

Additionally, you say that upon seeing "other" elements in the MUD
file, the controller should cease processing.=C2=A0 What exactly happens,
then, to the data already parsed?=C2=A0 Does that get applied, or m= ust the
controller reject the entire file?=C2=A0 IMHO, the controller shoul= d
disregard a file that violates the spec.=C2=A0 But in any case, I t= hink you
should be explicit here in the text.

Made explicit.


=3D=3D=3D

Section 6:

Should the timers for last-update and cache-validity be mandatory?=C2=A0 As
it stands now, nothing in metainfo is mandatory, and I think some things (like the timers) should be.=C2=A0 I also think is-supported= is key.

That's a good question and I like the list that you identified.=C2=A0= I think this requires some additional discussion, though, just to confirm model structure.=C2=A0 I'll come back to you on this.



=3D=3D=3D

Section 7:

Typo: replicated across IPv4 and IPv6 to allow MUD file autjors the
ability

I think you mean "authors".

Corrected.

=3D=3D=3D

Sections 7.1 and 7.2:

I would imagine at some level these names would have to be resolved.
Perhaps what you mean as to when they are resolved is left to the implementation?=C2=A0 That is to say, some vendors may resolve at t= he time
of configuration whereas others may resolve more dynamically.

I think I want to say more than that.

What I'm thinking about is as follows:

A number of=C2=A0=C2=A0 =C2=A0means may be = used to resolve hosts.=C2=A0 What is
important is that such resolutions be consistent with ACLs required by
devices=C2=A0 to properly operate.


=3D=3D=3D

Appendix B and Section 8:

These are out of date with the current schema.=C2=A0 For example, y= ou have
lastUpdate instead of last-update, cacheValidity instead of
cache-validity.

Oh nertz!=C2=A0 That's a mudmaker bug.=C2=A0 Fixed!

Thanks!

Eliot=C2=A0

Joe


On 8/11/17 16:10, Eliot Lear wrote:
> Hi everyone,

> As promised, this update corrects all examples (we just didn't have
> time to do that for the IETF) and adds a bit more wording around
> the abstractions so as to give some guidance on how to translate
> abstractions.=C2=A0 In addition, some guidance is given relati= ng to how
> to instantiate the ACL model, given the use of features.

> Finally, the MUD file maker has been updated, and can now be > reached at mudmaker.org.

> With this, I would ask that we start=C2=A0 the various YANG do= ctor and
> other directorate reviews.

> Eliot


> On 8/11/17 1:02 PM, internet-drafts@ietf.org wrote:<= br> >> 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : Manufacturer Usage Description Specification
>> Authors=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = Eliot Lear Ralph Droms Dan Romascanu Filename
>> : draft-ietf-opsawg-mud-08.txt Pages=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 48 Date
>> : 2017-08-11
>>
>> Abstract: This memo specifies a component-based architecture for
>> manufacturer usage descriptions (MUD).=C2=A0 This includes= 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/do= c/draft-ietf-opsawg-mud/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-= ietf-opsawg-mud-08
>> https://datatracker.ietf.org/do= c/html/draft-ietf-opsawg-mud-08
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-opsawg-mud-08
>>
>>
>> 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/
>>
>> _______________________________________________ OPSAWG mailing
>> list OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsa= wg
>>




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

&= gt;

--------------6832122971E909CF28877836-- --gq0JpN6JnJNoknI2H5WAlodob5teEmuKd-- --t1bO8cRX6GXK9IbLkoPmq4qIvc5Ro3xLu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZkgLzAAoJEIe2a0bZ0nozgLgIAIUoe5diAr13sIqcaXoHsqU9 jZVNh/bzGKxTDiQVy86AhiMrfuiMy8mbOx/hMgJ5kB+yHaKeaA+GDpF85Mj8rO1J 7nzTb6+ODQlTUmQp6aHV8fvWh35NYNqdiH4BKdZzypKKZRGrgPj0ksp/yIXjrJRc 0TieUNbb6NOqdsZKO6LaLaCBkPU4KonYHwO9z5fLb4NbhLFUvcpQxGIkGKtQMEMm vH5oQtmrm3SmRA1N0/jJEMNkyNwsalJAa9xke59Af5fiQ11x+NvH8Tsx5Up9rRKU 9znYP6YmH5wzLU8IFAEBlSpgOzu0o79LrrM1iu64H5JsAmWEYXOpyaJdbj2rWZw= =edCb -----END PGP SIGNATURE----- --t1bO8cRX6GXK9IbLkoPmq4qIvc5Ro3xLu-- From nobody Mon Aug 14 13:41:26 2017 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 BB977132425 for ; Mon, 14 Aug 2017 13:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 MYzOrgVlCkRz for ; Mon, 14 Aug 2017 13:41:23 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E104D126E64 for ; Mon, 14 Aug 2017 13:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2954; q=dns/txt; s=iport; t=1502743282; x=1503952882; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=VGFXvLBvymxvN537vYSanMmN349RPnCrQOidTZ49H40=; b=QrbyhtbAuo6ZQtjPc5kXt0NNRh8oC/FP4M7EikExkatdioUlqfIrwSPM INsqfSA7PjLEB7cOk07FICxzLtHK5gqJyOtj0f2KcsercuGBCYU/cu5jX 5IdYOKh6CufEFyLzc4N2qa3W+fBC42PjtIBOlZr/pxfj2bjF7sMJ8HQ/J E=; X-IronPort-AV: E=Sophos;i="5.41,374,1498521600"; d="scan'208";a="280428494" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Aug 2017 20:41:22 +0000 Received: from [10.118.87.86] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7EKfMig022465; Mon, 14 Aug 2017 20:41:22 GMT To: Eliot Lear Cc: opsawg@ietf.org References: <150248175729.24498.16927681607334663849@ietfa.amsl.com> <9956db24-0a43-c739-d729-c580ff037cc7@cisco.com> <0994d0ba-714d-3b5c-8542-06ee19dceef1@cisco.com> From: Joe Clarke Organization: Cisco Message-ID: Date: Mon, 14 Aug 2017 16:41:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-08.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: Mon, 14 Aug 2017 20:41:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/14/17 16:07, Eliot Lear wrote: >> Section 1.6: >> >> A MUD file is more than just a behavior. It lists details about >> a Thing such as whether or not it's supported, details about it >> from a reference URL, etc. Perhaps the definition of a MUD file >> should be "...JSON that describes a Thing and its required >> network behavior." > > I would prefer to run with "suggested" than "required". The > analogy has always been an indications label that comes with > medicine. You can go off label if you want, Mme. Administrator, > even if it isn't recommended. Yes, I agree. Very good distinction. >> Section 6: >> >> Should the timers for last-update and cache-validity be >> mandatory? As it stands now, nothing in metainfo is mandatory, >> and I think some things (like the timers) should be. I also >> think is-supported is key. > > That's a good question and I like the list that you identified. I > think this requires some additional discussion, though, just to > confirm model structure. I'll come back to you on this. Count me in. I thought about this section for a little bit before writing this, and I got really comfortable with the notation of the timers and is-supported being the only mandatory elements. >> >> Sections 7.1 and 7.2: >> >> I would imagine at some level these names would have to be >> resolved. Perhaps what you mean as to when they are resolved is >> left to the implementation? That is to say, some vendors may >> resolve at the time of configuration whereas others may resolve >> more dynamically. > > I think I want to say more than that. > > What I'm thinking about is as follows: > >> A number of means may be used to resolve hosts. What is >> important is that such resolutions be consistent with ACLs >> required by devices to properly operate. I like this text. I would only add some element of time to this to indicate that hosts may be resolved at different points in the packet processing path, and attention should be paid to how this is done to ensure any changes that may occur in resolution. Ugh, that just made me think. Maybe there should be a manufacturer considerations blurb that says that different vendors may do resolution differently, and if a manufacturer uses DNS with a round-robin set of addresses, it may cause discrepancies in what ACLs will allow (based on the controller/network device that does the resolution). I feel this kind of thing should be made more explicit to ensure that The Right Thing gets done on the network. Thanks for your attention, Eliot. Like I said, I continue to enjoy the readability of this document. Joe -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWZIK7gAKCRBvaI+K/hTP h1ZTAJ95fS/ntTC/niRALDNy350krVo8wACfZbPg7SPWTFHCXHrS62UeAnzJFyg= =Bhr7 -----END PGP SIGNATURE----- From nobody Tue Aug 15 05:58:09 2017 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 7F96513257B for ; Tue, 15 Aug 2017 05:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.006 X-Spam-Level: X-Spam-Status: No, score=-13.006 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, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514, 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 gMU3qsScp3NT for ; Tue, 15 Aug 2017 05:58:05 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADDD1324C4 for ; Tue, 15 Aug 2017 05:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2855; q=dns/txt; s=iport; t=1502801885; x=1504011485; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ACVKIuyxV//hTwwQOLoQP1clBS2Sh6j0aEWfuvDuj0U=; b=ZdOa9T/TIKK5K/BmEXdsnHzqtamAWgwySl3EkClK3DUit9W3w9vLHUTj /BTMI6d/hOllxU5SUmt1294fWeLQa4ta8KHo52rWIRMLJ0JStGYSwGYbx hT/9CXB5JBd8PAPPKKXc4lsmwG73CWmFIkEhaVzTiKwR+KjJ/EohQ+f8i w=; X-IronPort-AV: E=Sophos;i="5.41,377,1498521600"; d="scan'208";a="471855929" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2017 12:58:04 +0000 Received: from [10.150.76.117] ([10.150.76.117]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v7FCw4V1002218; Tue, 15 Aug 2017 12:58:04 GMT To: Eliot Lear Cc: opsawg@ietf.org References: <150248175729.24498.16927681607334663849@ietfa.amsl.com> <9956db24-0a43-c739-d729-c580ff037cc7@cisco.com> From: Joe Clarke Organization: Cisco Message-ID: Date: Tue, 15 Aug 2017 08:58:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9956db24-0a43-c739-d729-c580ff037cc7@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-08.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, 15 Aug 2017 12:58:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/11/17 16:10, Eliot Lear wrote: > Hi everyone, > > As promised, this update corrects all examples (we just didn't have > time to do that for the IETF) and adds a bit more wording around > the abstractions so as to give some guidance on how to translate > abstractions. In addition, some guidance is given relating to how > to instantiate the ACL model, given the use of features. > > Finally, the MUD file maker has been updated, and can now be > reached at mudmaker.org. > > With this, I would ask that we start the various YANG doctor and > other directorate reviews. Eliot, as co-chair, I have requested an early review for this draft (and revision) from YANG Doc, IOTDIR, SECDIR, and GENART. I have given the reviews a two-week deadline (for August 29). Joe > > Eliot > > > On 8/11/17 1:02 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 >> 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-08.txt Pages : 48 Date >> : 2017-08-11 >> >> Abstract: This memo specifies a component-based architecture for >> manufacturer usage descriptions (MUD). This includes 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-08 >> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-08 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-08 >> >> >> 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/ >> >> _______________________________________________ OPSAWG mailing >> list OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > > > _______________________________________________ OPSAWG mailing > list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg > -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWZLv2QAKCRBvaI+K/hTP hxhqAJ9gDHum03Oa295/Nem6ZLohcA9VFACglOu5wiAzfZM0834qModnxfvjZLc= =bJWh -----END PGP SIGNATURE----- From nobody Thu Aug 17 18:06:19 2017 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 1A6E31243F6; Thu, 17 Aug 2017 18:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 q5rr6Sa5pgS3; Thu, 17 Aug 2017 18:06:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D13132677; Thu, 17 Aug 2017 18:06:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMV67168; Fri, 18 Aug 2017 01:06:13 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 18 Aug 2017 02:06:12 +0100 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.0235.001; Fri, 18 Aug 2017 09:06:03 +0800 From: Tianran Zhou To: Tianran Zhou , "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for Service Models Explained Thread-Index: AdMHTnDHrV1ZgIm0T/Wx+jEZsCaBuAQb10BQ Date: Fri, 18 Aug 2017 01:06:02 +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.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59963D85.00B6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4f45b32973ec4e0348108d0cf00f05e3 Archived-At: Subject: Re: [OPSAWG] WG LC for 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, 18 Aug 2017 01:06:18 -0000 Hi Authors, We got pretty good suggestions and comments during the LC. Could you please improve the document and send to the community? Cheers, Tianran > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran Zhou > Sent: Friday, July 28, 2017 11:06 AM > To: opsawg@ietf.org > Cc: opsawg-chairs@ietf.org > Subject: [OPSAWG] WG LC for Service Models Explained >=20 > Dear OPSAWG, >=20 > This is a notice to start a three-week OPSAWG WG last call for the docume= nt: >=20 > Service Models Explained > https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-expla > ined/ >=20 > Please read the above draft and send any issues, comments, or corrections > to this mailing list. > Please indicate your support or concerns by Friday August 18, 2017. >=20 > Authors: > Although this is an informational document, please indicate with an email > on the mailing list explicitly whether you are aware or you are not aware > of any IPRs related to the drafts. >=20 >=20 > Thanks, > Tianran, as co-chair >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Aug 17 18:15:02 2017 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 0106D132677; Thu, 17 Aug 2017 18:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sNiLzI-CHT-2; Thu, 17 Aug 2017 18:14:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE73132143; Thu, 17 Aug 2017 18:14:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMV67895; Fri, 18 Aug 2017 01:14:57 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 18 Aug 2017 02:14:56 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.219]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 18 Aug 2017 09:14:45 +0800 From: Qin Wu To: Tianran Zhou , "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: WG LC for Service Models Explained Thread-Index: AdMHTnDHrV1ZgIm0T/Wx+jEZsCaBuAQcHyAQ Date: Fri, 18 Aug 2017 01:14:44 +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.136.79.163] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59963F91.0096, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.219, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4f45b32973ec4e0348108d0cf00f05e3 Archived-At: Subject: Re: [OPSAWG] WG LC for 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, 18 Aug 2017 01:15:01 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIFRpYW5yYW4gWmhvdQ0Kt6LLzcqxvOQ6IDIwMTfE6jfUwjI4yNUgMTE6 MDYNCsrVvP7Iyzogb3BzYXdnQGlldGYub3JnDQqzrcvNOiBvcHNhd2ctY2hhaXJzQGlldGYub3Jn DQrW98ziOiBbT1BTQVdHXSBXRyBMQyBmb3IgU2VydmljZSBNb2RlbHMgRXhwbGFpbmVkDQoNCkRl YXIgT1BTQVdHLA0KDQpUaGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0IGEgdGhyZWUtd2VlayBPUFNB V0cgV0cgbGFzdCBjYWxsIGZvciB0aGUgZG9jdW1lbnQ6DQoNClNlcnZpY2UgTW9kZWxzIEV4cGxh aW5lZA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ct c2VydmljZS1tb2RlbC1leHBsYWluZWQvDQoNClBsZWFzZSByZWFkIHRoZSBhYm92ZSBkcmFmdCBh bmQgc2VuZCBhbnkgaXNzdWVzLCBjb21tZW50cywgb3IgY29ycmVjdGlvbnMgdG8gdGhpcyBtYWls aW5nIGxpc3QuDQpQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IG9yIGNvbmNlcm5zIGJ5IEZy aWRheSBBdWd1c3QgMTgsIDIwMTcuDQoNCkF1dGhvcnM6IA0KQWx0aG91Z2ggdGhpcyBpcyBhbiBp bmZvcm1hdGlvbmFsIGRvY3VtZW50LCBwbGVhc2UgaW5kaWNhdGUgd2l0aCBhbiBlbWFpbCBvbiB0 aGUgbWFpbGluZyBsaXN0IGV4cGxpY2l0bHkgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9yIHlvdSBh cmUgbm90IGF3YXJlIG9mIGFueSBJUFJzIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0cy4NCg0KW1Fpbl06 IFJlY2VpdmUga2luZGx5IHJlbWluZGVyIGZyb20gY2hhaXJzIHJlY2VudGx5LCB0aGFua3MuIGhl cmUgSSBjb25maXJtIHRoYXQgd2UgaGF2ZSBubyBJUFIgYW5kIGFsc28gd2UgYXJlIG5vdCBhd2Fy ZSBvZiBhbnkgSVBScyByZWxhdGVkIHRvIHRoaXMgZHJhZnQuDQoNClRoYW5rcywNClRpYW5yYW4s IGFzIGNvLWNoYWlyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPUFNBV0cgbWFpbGluZyBsaXN0DQpPUFNBV0dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQo= From nobody Fri Aug 18 01:32:54 2017 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 3CBAB13291F; Fri, 18 Aug 2017 01:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 Q-4Upd1yQHVt; Fri, 18 Aug 2017 01:32:50 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4015413291C; Fri, 18 Aug 2017 01:32:49 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7I8WdgY009537; Fri, 18 Aug 2017 09:32:39 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7I8WZg7009521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Aug 2017 09:32:35 +0100 Reply-To: From: "Adrian Farrel" To: "'Qin Wu'" , "'Tianran Zhou'" , Cc: References: In-Reply-To: Date: Fri, 18 Aug 2017 09:32:32 +0100 Message-ID: <073201d317fc$8abd5e20$a0381a60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH3xPK8SnNx+dJdxeKTifN90yR7aQI+IkxDoi59p/A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23266.006 X-TM-AS-Result: No--9.666-10.0-31-10 X-imss-scan-details: No--9.666-10.0-31-10 X-TMASE-MatchedRID: +c13yJDs9004HKI/yaqRm1aOpp/sV5nVCAruoteJOhz530JsOyx4RZTr bO9zUOWjuD9ES7ZgSoec6RAXSnppiwt3e7z0WipR9Ib/6w+1lWRNJPe8wtHB72tEzrC9eANpnba z4C25kZbv3FN3B39MyZcZ0icLp7DqTX7PJ/OU3vL+xOhjarOnHmrz/G/ZSbVq+gtHj7OwNO2J8Y JgRrgXFwjwiD4RuA0gyQVgU5dmdV7fbW9Abs3UR/QetEwQrZXd Archived-At: Subject: Re: [OPSAWG] WG LC for 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, 18 Aug 2017 08:32:52 -0000 > Authors: > Although this is an informational document, please indicate with an email on the > mailing list explicitly whether you are aware or you are not aware of any IPRs > related to the drafts. > > [Qin]: Receive kindly reminder from chairs recently, thanks. here I confirm that > we have no IPR and also we are not aware of any IPRs related to this draft. Not sure whether I responded. Anyway... No, I am not aware of any IPR related to this draft. Thanks, Adrian From nobody Fri Aug 18 06:09:13 2017 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 42F4A132199; Fri, 18 Aug 2017 06:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, 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 lEnMvvzd27T4; Fri, 18 Aug 2017 06:09:09 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872D11204DA; Fri, 18 Aug 2017 06:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1352; q=dns/txt; s=iport; t=1503061749; x=1504271349; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=MxSn4FAJqlN/Um+AVZC6+uZFNdaunW69FsPyCEYCoAY=; b=jlY348rv81WI/abM9CA2M5Cy3KvAMUW/SWdxeXhRsKfrDFsAF6pTk7Dc +H9VPKM1xs4LzyM8BhiEOVzUscbNdpkjIqnYyfHcgUf/Z4a9/eOub8H8U c2dOzRdjV8CZxmsDfrGjGC6xvnMLd5IZ1tSRS1slk+bAVQkeuJzuUw6ka E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgDn5ZZZ/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pknzqBTCKYLiyFGwKDbEIVAQIBAQEBAQEBax0LhRkBBR0GDwF?= =?us-ascii?q?GEAsYAgImAgJXBg0IAQGKLBCrc4Imi2YBAQEBAQEBAQEBAQEBAQEBAQEbBYELg?= =?us-ascii?q?h2CAoFMgg4LgnGIBoJhBaBNh1SMboIQhWGDWIcViWiMNjUigQpTJBVJhzYkim0?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.41,393,1498521600"; d="scan'208";a="473608264" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2017 13:09:08 +0000 Received: from [10.118.87.86] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v7ID97J7008811; Fri, 18 Aug 2017 13:09:08 GMT From: Joe Clarke To: "opsawg@ietf.org" Cc: "opsawg-chairs@ietf.org" References: <45D770E1-8CB4-4288-8437-BC32773A4E5B@cisco.com> Organization: Cisco Message-ID: Date: Fri, 18 Aug 2017 09:09:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <45D770E1-8CB4-4288-8437-BC32773A4E5B@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSAWG] WG adoption poll for draft-sivakumar-yang-nat-07 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, 18 Aug 2017 13:09:12 -0000 Hello opsawg, We are at the end of our call for adoption, and based on discussion on this list, there seems to be enough support to adopt this work for the opsawg. In addition to simple replies of support, this work is being leveraged in other working groups. I would ask the authors to keep in contact with the softwire work at least to make sure there aren't any bottlenecks, as well as to get additional reviews. Additionally, authors, can you please update the draft and resubmit as a WG document? Joe for the opsawg chairs On 7/27/17 10:09, Joe Clarke wrote: > Greetings OPSAWG, > > After this draft was presented in Prague, it was stated that we would do > a call for adoption on the list.  There seemed to be general support for > the work.  Therefore, this will serve as the chairs’ formal adoption > poll for this document into OPSAWG. > > YANG Data Model for Network Address Translation (NAT) > https://datatracker.ietf.org/doc/draft-sivakumar-yang-nat/ > > This poll request will go for three weeks to allow for the summer > vacation time.  Please get your feedback (and initial reviews) in by > August 17, 2017. > > In addition to simply supporting the adoption, please also let us know > if you are willing to review the work as it progresses. > > Thank you. > > Joe (for the co-chairs) From nobody Fri Aug 18 06:30:51 2017 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 6F7BB13235E; Fri, 18 Aug 2017 06:30:42 -0700 (PDT) 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.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150306304237.14107.4196398089737507728@ietfa.amsl.com> Date: Fri, 18 Aug 2017 06:30:42 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-00.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, 18 Aug 2017 13:30:42 -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-00.txt Pages : 67 Date : 2017-08-18 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 data model for the NAT function. NAT44, NAT64, and NPTv6 are covered in this document. 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-00 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 18 06:46:21 2017 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 CC4EB1323C9 for ; Fri, 18 Aug 2017 06:46:19 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 35pz8GLOLS7w for ; Fri, 18 Aug 2017 06:46:17 -0700 (PDT) Received: from relais-inet.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 9A9451323FB for ; Fri, 18 Aug 2017 06:46:14 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 066F7C014F; Fri, 18 Aug 2017 15:46:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id D279F80062; Fri, 18 Aug 2017 15:46:12 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0361.001; Fri, 18 Aug 2017 15:46:09 +0200 From: To: "opsawg@ietf.org" CC: JACQUENET Christian IMT/OLN , "Senthil Sivakumar (ssenthil)" , Qin Wu , "sureshk@juniper.net" Thread-Topic: New Version Notification for draft-ietf-opsawg-nat-yang-00.txt Thread-Index: AQHTGCYxFTBAjXjWbk+rPM0P5RoFsqKKHPCg Date: Fri, 18 Aug 2017 13:46:08 +0000 Message-ID: References: <150306304258.14107.7355173713892326702.idtracker@ietfa.amsl.com> In-Reply-To: <150306304258.14107.7355173713892326702.idtracker@ietfa.amsl.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.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OPSAWG] TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.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, 18 Aug 2017 13:46:20 -0000 RGVhciBhbGwsIA0KDQpUaGUgLTAwIHZlcnNpb24gaW50ZWdyYXRlcyB0aGUgY29tbWVudHMgcmVj ZWl2ZWQgZHVyaW5nIHRoZSBDYWxsIGZvciBBZG9wdGlvbjoNCg0KLSBDbGFyaWZ5IGhvdyBEZXN0 aW5hdGlvbiBOQVQgaXMgY292ZXJlZCAoVGlhbnJhbikNCi0gRm9sbG93IHRoZSBOTURBIGd1aWRl bGluZXMgKEp1ZXJnZW4gYW5kIFFpbikNCi0gSW5jbHVkZSBhIGdlbmVyaWMgc3RydWN0dXJlIGZv ciBBTEdzIGluc3RlYWQgb2YgbGlzdGluZyBzdXBwb3J0ZWQgb25lcyAoSnVlcmdlbikNCi0gSW5j bHVkZSBhIGRpc2N1c3Npb24gYWJvdXQgaG93IG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbHMgYXJl L2NhbiBiZSBzdXBwb3J0ZWQgKEp1ZXJnZW4pDQotIEluY2x1ZGUgYSBjb21wcmVoZW5zaXZlIGxp c3Qgb2YgZXhhbXBsZXMgIChKdWVyZ2VuKQ0KLSBNb3ZlIHRoZSBleGFtcGxlIHRvIGFuIGFwcGVu ZGl4IChKdWVyZ2VuKQ0KDQpXZSBkbyBzdGlsbCBoYXZlIG9uZSBwZW5kaW5nIGNvbW1lbnQgdGhh dCB3YXMgcmFpc2VkIGJ5IExlZSBIb3dhcmQgd2hlbiBJIHByZXNlbnRlZCBpbiBQcmFndWU6IGFk ZCBDTEFUIHRvIHRoZSBsaXN0LiANCg0KQ29tbWVudHMgYXJlIG1vcmUgdGhhbiB3ZWxjb21lLiBQ bGVhc2UgcmV2aWV3LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+IERlwqA6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxOCBhb8O7dCAyMDE3IDE1 OjMxDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IFNlbnRoaWwgU2l2YWt1bWFy OyBKQUNRVUVORVQgQ2hyaXN0aWFuDQo+IElNVC9PTE47IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc7 IFFpbiBXdQ0KPiBPYmpldMKgOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWll dGYtb3BzYXdnLW5hdC15YW5nLTAwLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBNb2hhbWVkIEJvdWNhZGFpciBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJ RVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmcN Cj4gUmV2aXNpb246CTAwDQo+IFRpdGxlOgkJQSBZQU5HIERhdGEgTW9kZWwgZm9yIE5ldHdvcmsg QWRkcmVzcyBUcmFuc2xhdGlvbiAoTkFUKSBhbmQNCj4gTmV0d29yayBQcmVmaXggVHJhbnNsYXRp b24gKE5QVCkNCj4gRG9jdW1lbnQgZGF0ZToJMjAxNy0wOC0xOA0KPiBHcm91cDoJCW9wc2F3Zw0K PiBQYWdlczoJCTY3DQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vcHNhd2ctDQo+IG5hdC15YW5nLTAwLnR4dA0KPiBTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1v cHNhd2ctbmF0LQ0KPiB5YW5nLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLTAwDQo+IEh0bWxpemVkOiAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdn LQ0KPiBuYXQteWFuZy0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBGb3IgdGhlIHNha2Ug b2YgbmV0d29yayBhdXRvbWF0aW9uIGFuZCB0aGUgbmVlZCBmb3IgcHJvZ3JhbW1pbmcNCj4gICAg TmV0d29yayBBZGRyZXNzIFRyYW5zbGF0aW9uIChOQVQpIGZ1bmN0aW9uIGluIHBhcnRpY3VsYXIs IGEgZGF0YQ0KPiAgICBtb2RlbCBmb3IgY29uZmlndXJpbmcgYW5kIG1hbmFnaW5nIHRoZSBOQVQg aXMgZXNzZW50aWFsLiAgVGhpcw0KPiAgICBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1v ZGVsIGZvciB0aGUgTkFUIGZ1bmN0aW9uLiAgTkFUNDQsDQo+ICAgIE5BVDY0LCBhbmQgTlBUdjYg YXJlIGNvdmVyZWQgaW4gdGhpcyBkb2N1bWVudC4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m DQo+IHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Fri Aug 18 07:35:55 2017 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 27BAA13218C for ; Fri, 18 Aug 2017 07:35:54 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 mJUBXVoJ_1CX for ; Fri, 18 Aug 2017 07:35:51 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0B21323BA for ; Fri, 18 Aug 2017 07:35:49 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id B8A226056B; Fri, 18 Aug 2017 16:35:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 7D5CF180061; Fri, 18 Aug 2017 16:35:47 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0361.001; Fri, 18 Aug 2017 16:35:45 +0200 From: To: Lee Howard , "jordi.palet@consulintel.es" CC: "opsawg@ietf.org" , JACQUENET Christian IMT/OLN , "Senthil Sivakumar (ssenthil)" , Qin Wu , "sureshk@juniper.net" Thread-Topic: CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.txt) Thread-Index: AdMYLPDNz1ZKlJbMRqCG7OBhszrdBAAAjECQ Date: Fri, 18 Aug 2017 14:35:45 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.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, 18 Aug 2017 14:35:54 -0000 UmUtLA0KDQpGb3J3YXJkZWQgdG8gdGhlIE9QU0FXRyBsaXN0LiANCg0KUGxlYXNlIHVzZSB0aGlz IG1lc3NhZ2VzIHdoZW4gcmVwbHlpbmcuIA0KDQpBcG9sb2dpZXMgZm9yIHRoZSBpbmNvbnZlbmll bmNlLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ IERlwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAx OCBhb8O7dCAyMDE3IDE2OjE5DQo+IMOAwqA6ICdMZWUgSG93YXJkJzsgam9yZGkucGFsZXRAY29u c3VsaW50ZWwuZXMNCj4gQ2PCoDogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZzsgSkFDUVVFTkVUIENo cmlzdGlhbiBJTVQvT0xOOyBTZW50aGlsDQo+IFNpdmFrdW1hciAoc3NlbnRoaWwpOyAnUWluIFd1 Jzsgc3VyZXNoa0BqdW5pcGVyLm5ldA0KPiBPYmpldMKgOiBDTEFUICh3YXMgVFI6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LQ0KPiB5YW5nLTAwLnR4 dCkNCj4gDQo+IEhpIExlZSwNCj4gDQo+IChJJ20gYWRkaW5nIEpvcmRpIHRvIHRoZSBkaXNjdXNz aW9uIHNpbmNlIGhlIGlzIGZhbWlsaWFyIHdpdGggQ0xBVCBpbiBhDQo+IENQRSkNCj4gDQo+IFlv dSBzdWdnZXN0ZWQgaW4gUHJhZ3VlIHRvIGFkZCBDTEFUIHRvIHRoZSBOQVQgWUFORyBtb2R1bGUu DQo+IA0KPiBQbGVhc2UgZmluZCBiZWxvdyBob3cgd2UgYXJlIHBsYW5uaW5nIHRvIGNvdmVyIGl0 IGluIHRoZSBuZXh0IGl0ZXJhdGlvbiBvZg0KPiB0aGUgZHJhZnQ6DQo+IA0KPiAoMSkgSWYgYSBk ZWRpY2F0ZWQgcHJlZml4IGlzIGNvbmZpZ3VyZWQgZm9yIENMQVQsIHRoZW4gb25seSBhIHN0YXRl bGVzcw0KPiBYTEFUIHdpbGwgYmUgcmVxdWlyZWQuIFRoYXQgaXMsIG5vIG1hcHBpbmcgdGFibGUg d2lsbCBiZSBtYWludGFpbmVkIGF0DQo+IGFsbC4gU2luY2UgdGhlIG1vZHVsZSBhbHJlYWR5IGlu Y2x1ZGVzIE5BVDY0IHByZWZpeChlcyksIHRoZSBDTEFUIElQdjYNCj4gcHJlZml4IHdpbGwgYmUg bWlzc2luZy4gVGhlIHRyZWUgc3RydWN0dXJlIGNhbiBiZSB1cGRhdGVkIGFzIGZvbGxvd3M6DQo+ IA0KPiBPTEQ6DQo+ICAgICAgICAgICAgICArLS1ydyBuYXQ2NC1wcmVmaXhlcyogW25hdDY0LXBy ZWZpeF0NCj4gICAgICAgICAgICAgIHwgICstLXJ3IG5hdDY0LXByZWZpeCAgICAgICAgICAgICAg IGluZXQ6aXB2Ni1wcmVmaXgNCj4gICAgICAgICAgICAgIHwgICstLXJ3IGRlc3RpbmF0aW9uLWlw djQtcHJlZml4KiBbaXB2NC1wcmVmaXhdDQo+ICAgICAgICAgICAgICB8ICAgICArLS1ydyBpcHY0 LXByZWZpeCAgICBpbmV0OmlwdjQtcHJlZml4DQo+IA0KPiBORVc6DQo+IA0KPiAgICAgICAgICAg ICAgKy0tcncgbmF0NjQtcHJlZml4ZXMqIFtuYXQ2NC1wcmVmaXhdDQo+ICAgICAgICAgICAgICB8 ICArLS1ydyBuYXQ2NC1wcmVmaXggICAgICAgICAgICAgICBpbmV0OmlwdjYtcHJlZml4DQo+ICAg ICAgICAgICAgICB8ICArLS1ydyBkZXN0aW5hdGlvbi1pcHY0LXByZWZpeCogW2lwdjQtcHJlZml4 XQ0KPiAgICAgICAgICAgICAgfCAgICAgKy0tcncgaXB2NC1wcmVmaXggICAgaW5ldDppcHY0LXBy ZWZpeA0KPiAgICAgICAgICAgICAgKy0tcncgY2xhdC1pcHY2LXByZWZpeD8gICAgICAgICAgICAg aW5ldDppcHY2LXByZWZpeA0KPiANCj4gKDIpIElmIG5vIGRlZGljYXRlZCAvNjQgcHJlZml4IGlz IHByb3ZpZGVkLCBhIE5BVDQ0IHdpbGwgYmUgcmVxdWlyZWQuIEENCj4gc3RhdGVsZXNzIFhMQVQg d2lsbCBiZSB0aGVuIGFwcGxpZWQgb24gTkFUZWQgcGFja2V0cy4gVGhpcyBjYXNlIGlzDQo+IG5h dGl2ZWx5IHN1cHBvcnRlZCBieSB0aGUgY3VycmVudCBZQU5HIG1vZGVsLg0KPiANCj4gQSBDTEFU IG1vZHVsZSBjYW4gYXV0b21hdGljYWxseSBzZWxlY3QgYW4gSVB2NCBhZGRyZXNzIGZyb20gMTky LjAuMC4wLzI5DQo+IChSRkM3MzM1KS4gVGhpcyBhZGRyZXNzIGNhbiBhbHNvIGJlIHNldC4gVG8g ZG8gc28sIHRoZSB0cmVlIHN0cnVjdHVyZSBjYW4NCj4gYmUgdXBkYXRlZCB3aXRoOg0KPiANCj4g TkVXOg0KPiAgICAgICAgICAgICAgLi4uDQo+ICAgICAgICAgICAgICArLS1ydyBjbGF0LWlwdjQt YWRkcmVzcz8gICAgICAgICAgICBpbmV0OmlwdjQtYWRkcmVzcw0KPiAgICAgICAgICAgICAgLi4u DQo+IA0KPiBUaGUgQ0xBVCBJUHY0IGFkZHJlc3Mgd2lsbCBiZSB0YWtlbiBieSBkZWZhdWx0IGZy b20gMTkyLjAuMC4wLzI5LiBPdGhlcg0KPiBhZGRyZXNzZXMgY2FuIGJlIHVzZWQuDQo+IA0KPiBM ZWUvSm9yZGksIGFyZSB0aGVyZSBhbnkgb3RoZXIgcmVxdWlyZWQgY2hhbmdlcz8NCj4gDQo+IFRo YW5rIHlvdS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPiA+IERlwqA6IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlDQo+ID4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ IEVudm95w6nCoDogdmVuZHJlZGkgMTggYW/Du3QgMjAxNyAxNTo0Ng0KPiA+IMOAwqA6IG9wc2F3 Z0BpZXRmLm9yZw0KPiA+IENjwqA6IHN1cmVzaGtAanVuaXBlci5uZXQ7IEpBQ1FVRU5FVCBDaHJp c3RpYW4gSU1UL09MTg0KPiA+IE9iamV0wqA6IFtPUFNBV0ddIFRSOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb3BzYXdnLW5hdC0NCj4gPiB5YW5nLTAwLnR4dA0KPiA+ DQo+ID4gRGVhciBhbGwsDQo+ID4NCj4gPiBUaGUgLTAwIHZlcnNpb24gaW50ZWdyYXRlcyB0aGUg Y29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBDYWxsIGZvcg0KPiA+IEFkb3B0aW9uOg0KPiA+ DQo+ID4gLSBDbGFyaWZ5IGhvdyBEZXN0aW5hdGlvbiBOQVQgaXMgY292ZXJlZCAoVGlhbnJhbikN Cj4gPiAtIEZvbGxvdyB0aGUgTk1EQSBndWlkZWxpbmVzIChKdWVyZ2VuIGFuZCBRaW4pDQo+ID4g LSBJbmNsdWRlIGEgZ2VuZXJpYyBzdHJ1Y3R1cmUgZm9yIEFMR3MgaW5zdGVhZCBvZiBsaXN0aW5n IHN1cHBvcnRlZCBvbmVzDQo+ID4gKEp1ZXJnZW4pDQo+ID4gLSBJbmNsdWRlIGEgZGlzY3Vzc2lv biBhYm91dCBob3cgb3RoZXIgdHJhbnNwb3J0IHByb3RvY29scyBhcmUvY2FuIGJlDQo+ID4gc3Vw cG9ydGVkIChKdWVyZ2VuKQ0KPiA+IC0gSW5jbHVkZSBhIGNvbXByZWhlbnNpdmUgbGlzdCBvZiBl eGFtcGxlcyAgKEp1ZXJnZW4pDQo+ID4gLSBNb3ZlIHRoZSBleGFtcGxlIHRvIGFuIGFwcGVuZGl4 IChKdWVyZ2VuKQ0KPiA+DQo+ID4gV2UgZG8gc3RpbGwgaGF2ZSBvbmUgcGVuZGluZyBjb21tZW50 IHRoYXQgd2FzIHJhaXNlZCBieSBMZWUgSG93YXJkIHdoZW4NCj4gSQ0KPiA+IHByZXNlbnRlZCBp biBQcmFndWU6IGFkZCBDTEFUIHRvIHRoZSBsaXN0Lg0KPiA+DQo+ID4gQ29tbWVudHMgYXJlIG1v cmUgdGhhbiB3ZWxjb21lLiBQbGVhc2UgcmV2aWV3Lg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1l ZA0KPiA+DQo+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERlwqA6IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10N Cj4gPiA+IEVudm95w6nCoDogdmVuZHJlZGkgMTggYW/Du3QgMjAxNyAxNTozMQ0KPiA+ID4gw4DC oDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgU2VudGhpbCBTaXZha3VtYXI7IEpBQ1FVRU5F VCBDaHJpc3RpYW4NCj4gPiA+IElNVC9PTE47IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc7IFFpbiBX dQ0KPiA+ID4gT2JqZXTCoDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRm LW9wc2F3Zy1uYXQteWFuZy0wMC50eHQNCj4gPiA+DQo+ID4gPg0KPiA+ID4gQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLTAwLnR4dA0KPiA+ID4gaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNb2hhbWVkIEJvdWNhZGFpciBhbmQgcG9zdGVk IHRvIHRoZQ0KPiA+ID4gSUVURiByZXBvc2l0b3J5Lg0KPiA+ID4NCj4gPiA+IE5hbWU6CQlkcmFm dC1pZXRmLW9wc2F3Zy1uYXQteWFuZw0KPiA+ID4gUmV2aXNpb246CTAwDQo+ID4gPiBUaXRsZToJ CUEgWUFORyBEYXRhIE1vZGVsIGZvciBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRpb24gKE5BVCkN Cj4gYW5kDQo+ID4gPiBOZXR3b3JrIFByZWZpeCBUcmFuc2xhdGlvbiAoTlBUKQ0KPiA+ID4gRG9j dW1lbnQgZGF0ZToJMjAxNy0wOC0xOA0KPiA+ID4gR3JvdXA6CQlvcHNhd2cNCj4gPiA+IFBhZ2Vz OgkJNjcNCj4gPiA+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi0NCj4gb3BzYXdnLQ0KPiA+ID4gbmF0LXlhbmctMDAudHh0DQo+ ID4gPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1vcHNhd2ctDQo+IG5hdC0NCj4gPiA+IHlhbmcvDQo+ID4gPiBIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLW5hdC0NCj4g eWFuZy0NCj4gPiAwMA0KPiA+ID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi0NCj4gb3BzYXdnLQ0KPiA+ID4gbmF0LXlhbmct MDANCj4gPiA+DQo+ID4gPg0KPiA+ID4gQWJzdHJhY3Q6DQo+ID4gPiAgICBGb3IgdGhlIHNha2Ug b2YgbmV0d29yayBhdXRvbWF0aW9uIGFuZCB0aGUgbmVlZCBmb3IgcHJvZ3JhbW1pbmcNCj4gPiA+ ICAgIE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdGlvbiAoTkFUKSBmdW5jdGlvbiBpbiBwYXJ0aWN1 bGFyLCBhIGRhdGENCj4gPiA+ICAgIG1vZGVsIGZvciBjb25maWd1cmluZyBhbmQgbWFuYWdpbmcg dGhlIE5BVCBpcyBlc3NlbnRpYWwuICBUaGlzDQo+ID4gPiAgICBkb2N1bWVudCBkZWZpbmVzIGEg WUFORyBkYXRhIG1vZGVsIGZvciB0aGUgTkFUIGZ1bmN0aW9uLiAgTkFUNDQsDQo+ID4gPiAgICBO QVQ2NCwgYW5kIE5QVHY2IGFyZSBjb3ZlcmVkIGluIHRoaXMgZG9jdW1lbnQuDQo+ID4gPg0KPiA+ ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiA+IHN1Ym1pc3Npb24NCj4gPiA+ IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQo+ID4gPg0KPiA+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPg0KPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT1BT QVdHIG1haWxpbmcgbGlzdA0KPiA+IE9QU0FXR0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQo= From nobody Fri Aug 18 08:18:29 2017 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 8946E13295C for ; Fri, 18 Aug 2017 08:18:27 -0700 (PDT) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qva6FVbK-MXD for ; Fri, 18 Aug 2017 08:18:25 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01D613219B for ; Fri, 18 Aug 2017 08:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1503069502; x=1503674302; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=q6pbLqO8tR6BqvtG9CQT8z+G1 cjejj9CM8rRSAC/s+Q=; b=c6RD7+DCuMUujtKQyKIN6b65kq8joWjQIIkY+h5W6 JhJbi16VZ+FPZSL0yq1o3gZ1FgbMuUV+yWBQTD2hHTOKcjMXhepcbVCfTKSszs8j 1DFzhzE73iQfL6YicWoY5wTGMWfKSMGfIblnTjtf1pkf2epyefo7ldDoHE6EcUQU y8= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=roZU8ICXV3RiUAPD8AW3YOSI6b/BVGfUSQfO1mML3ZSegg3mf8NJhNZPD4+n L4sVcJVRNtKKs7Wus1DYez3vEWDoSsXN31uMZWj9bHHhSq5tBZoq3LMad AcHPaWvWkn4JcECO3FSHaLU0D3GfJXv7XVzgZkFCl3Qg9iIdJf3rIg=; X-MDAV-Processed: mail.consulintel.es, Fri, 18 Aug 2017 17:18:22 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 18 Aug 2017 17:18:21 +0200 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005510404.msg for ; Fri, 18 Aug 2017 17:18:20 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170818:md50005510404::K5RmAIrKGtHnQ1vI:00009gLs X-Return-Path: prvs=140398b0bb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: opsawg@ietf.org User-Agent: Microsoft-MacOutlook/f.25.0.170815 Date: Fri, 18 Aug 2017 17:18:18 +0200 From: JORDI PALET MARTINEZ To: , Lee Howard CC: , JACQUENET Christian IMT/OLN , "Senthil Sivakumar (ssenthil)" , Qin Wu , "sureshk@juniper.net" Message-ID: <292AA9DC-F011-4585-8424-C6323F2FC769@consulintel.es> Thread-Topic: CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.txt) In-Reply-To: <7e5cb648-16a8-43c9-8ac9-d869c170447c@OPEXCLILMA2.corporate.adroot.infra.ftgroup> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [OPSAWG] CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.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, 18 Aug 2017 15:18:27 -0000 Hi Med, Looks good to me, and I think it covers all the possible options, which one= exception: +--rw clat-ipv4-address? inet:ipv4-address You may want to use a prefix, not an address. If you have a CLAT serving a = =E2=80=9Cbig=E2=80=9D network, instead of a small CE, you may need to use a= pool of several IP addresses. For example, in a recent testing, I used for= the stateless CLAT (NAT46) the following EAMT (Explicit Address Mappings T= able, RFC7757): Pool IPv4/NAT46: 100.64.0.0/10 Pool IPv6: 2001:470:68ee:30::/106 (I was a bit exaggerated here, with so big pool, but is only an example) So may be something like: +--rw clat-ipv4-address? inet:ipv4-address +--rw clat-ipv4-mask? inet:ipv4-mask Note that I=E2=80=99m NOT expert in YANG, but I just read thru all your ID = and looks ok. Some other details that you may want to consider: 1) Say something about CLAT/NAT46/464XLAT in the abstract. 2) Same for the intro. 3) Same in section 2.2. 4) You may need to add also something in 2.8, at paragraph: In order to cover both NAT64 and NAT44 flavors in particular, the NAT mapping structure allows to include an IPv4 or an IPv6 address as an internal IP address. Remaining fields are common to both NAT schemes. 5) Also I think in 2.8 =E2=80=9CNote that a mapping table is maintained onl= y for stateless NAT=E2=80=9D you actually mean stateful NAT ? 6) You could also rewrite (2.8) =E2=80=9CObviously, no mapping table is mai= ntained for NPTv6 given that it is stateless and transport-agnostic=E2=80= =9D as =E2=80=9CObviously, no mapping table is maintained for any stateless= NAT (such as NAT46), neither for NPTv6 given that it is stateless and tran= sport-agnostic=E2=80=9D 7) Instead of +--rw subscriber-mask-v6?, should mask be prefix-length? 8) In section 3, I see you have some =E2=80=9Ccode=E2=80=9D for each NAT ty= pe, so you may need also for NAT46? 9) And of course, you may want to add a CLAT example at the appendix ;-) Hope it helps! Saludos, Jordi =20 -----Mensaje original----- De: Responder a: Fecha: viernes, 18 de agosto de 2017, 16:19 Para: Lee Howard , "jordi.palet@consulintel.es" CC: "opsawg-chairs@ietf.org" , JACQUENET Christian = IMT/OLN , "Senthil Sivakumar (ssenthil)" , Qin Wu , "sureshk@juniper.net" Asunto: CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-ya= ng-00.txt) Hi Lee, =20 (I'm adding Jordi to the discussion since he is familiar with CLAT in a= CPE) =20 You suggested in Prague to add CLAT to the NAT YANG module.=20 =20 Please find below how we are planning to cover it in the next iteration= of the draft: =20 (1) If a dedicated prefix is configured for CLAT, then only a stateless= XLAT will be required. That is, no mapping table will be maintained at all= . Since the module already includes NAT64 prefix(es), the CLAT IPv6 prefix = will be missing. The tree structure can be updated as follows: =20 OLD: +--rw nat64-prefixes* [nat64-prefix] | +--rw nat64-prefix inet:ipv6-prefix | +--rw destination-ipv4-prefix* [ipv4-prefix] | +--rw ipv4-prefix inet:ipv4-prefix =20 NEW: =20 +--rw nat64-prefixes* [nat64-prefix] | +--rw nat64-prefix inet:ipv6-prefix | +--rw destination-ipv4-prefix* [ipv4-prefix] | +--rw ipv4-prefix inet:ipv4-prefix +--rw clat-ipv6-prefix? inet:ipv6-prefix =20 (2) If no dedicated /64 prefix is provided, a NAT44 will be required. A= stateless XLAT will be then applied on NATed packets. This case is nativel= y supported by the current YANG model.=20 =20 A CLAT module can automatically select an IPv4 address from 192.0.0.0/2= 9 (RFC7335). This address can also be set. To do so, the tree structure can= be updated with: =20 =20 NEW: ... =20 +--rw clat-ipv4-address? inet:ipv4-address=20 ... =20 The CLAT IPv4 address will be taken by default from 192.0.0.0/29. Other= addresses can be used. =20 Lee/Jordi, are there any other required changes? =20 Thank you. =20 Cheers, Med =20 > -----Message d'origine----- > De : OPSAWG [mailto:opsawg-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=C3=A9 : vendredi 18 ao=C3=BBt 2017 15:46 > =C3=80 : opsawg@ietf.org > Cc : sureshk@juniper.net; JACQUENET Christian IMT/OLN > Objet : [OPSAWG] TR: New Version Notification for draft-ietf-opsawg-n= at- > yang-00.txt >=20 > Dear all, >=20 > The -00 version integrates the comments received during the Call for > Adoption: >=20 > - Clarify how Destination NAT is covered (Tianran) > - Follow the NMDA guidelines (Juergen and Qin) > - Include a generic structure for ALGs instead of listing supported o= nes > (Juergen) > - Include a discussion about how other transport protocols are/can be > supported (Juergen) > - Include a comprehensive list of examples (Juergen) > - Move the example to an appendix (Juergen) >=20 > We do still have one pending comment that was raised by Lee Howard wh= en I > presented in Prague: add CLAT to the list. >=20 > Comments are more than welcome. Please review. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Envoy=C3=A9 : vendredi 18 ao=C3=BBt 2017 15:31 > > =C3=80 : BOUCADAIR Mohamed IMT/OLN; Senthil Sivakumar; JACQUENET Ch= ristian > > IMT/OLN; opsawg-chairs@ietf.org; Qin Wu > > Objet : New Version Notification for draft-ietf-opsawg-nat-yang-00.= txt > > > > > > A new version of I-D, draft-ietf-opsawg-nat-yang-00.txt > > has been successfully submitted by Mohamed Boucadair and posted to = the > > IETF repository. > > > > Name: draft-ietf-opsawg-nat-yang > > Revision: 00 > > Title: A YANG Data Model for Network Address Translation (NAT) and > > Network Prefix Translation (NPT) > > Document date: 2017-08-18 > > Group: opsawg > > Pages: 67 > > URL: https://www.ietf.org/internet-drafts/draft-ietf-ops= awg- > > nat-yang-00.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-= nat- > > yang/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-nat-y= ang- > 00 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-op= sawg- > > nat-yang-00 > > > > > > 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 data model for the NAT function. NAT44, > > NAT64, and NPTv6 are covered in this document. > > > > > > > > > > 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= . > > > > The IETF Secretariat >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the use of the individual(= s) named above. If you are not the intended recipient be aware that any dis= closure, copying, distribution or use of the contents of this information, = including attached files, is prohibited. From nobody Sun Aug 20 14:36:09 2017 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 3308E1320BB for ; Sun, 20 Aug 2017 14:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-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 UhlUSacfD_ZC for ; Sun, 20 Aug 2017 14:36:04 -0700 (PDT) Received: from atl4mhob02.registeredsite.com (atl4mhob02.registeredsite.com [209.17.115.40]) (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 8D79A120724 for ; Sun, 20 Aug 2017 14:36:04 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob02.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7KLa109006401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 20 Aug 2017 17:36:01 -0400 Received: (qmail 18575 invoked by uid 0); 20 Aug 2017 21:36:00 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 20 Aug 2017 21:35:59 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Sun, 20 Aug 2017 17:35:52 -0400 From: Lee Howard To: , "jordi.palet@consulintel.es" CC: "opsawg@ietf.org" , JACQUENET Christian IMT/OLN , "Senthil Sivakumar (ssenthil)" , Qin Wu , "sureshk@juniper.net" Message-ID: Thread-Topic: CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.txt) References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [OPSAWG] CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.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: Sun, 20 Aug 2017 21:36:07 -0000 Thank you! Lee On 8/18/17, 10:35 AM, "mohamed.boucadair@orange.com" wrote: >Re-, > >Forwarded to the OPSAWG list. > >Please use this messages when replying. > >Apologies for the inconvenience. > >Cheers, >Med > >> -----Message d'origine----- >> De : BOUCADAIR Mohamed IMT/OLN >> Envoy=C3=A9 : vendredi 18 ao=C3=BBt 2017 16:19 >> =C3=80 : 'Lee Howard'; jordi.palet@consulintel.es >> Cc : opsawg-chairs@ietf.org; JACQUENET Christian IMT/OLN; Senthil >> Sivakumar (ssenthil); 'Qin Wu'; sureshk@juniper.net >> Objet : CLAT (was TR: New Version Notification for >>draft-ietf-opsawg-nat- >> yang-00.txt) >>=20 >> Hi Lee, >>=20 >> (I'm adding Jordi to the discussion since he is familiar with CLAT in a >> CPE) >>=20 >> You suggested in Prague to add CLAT to the NAT YANG module. >>=20 >> Please find below how we are planning to cover it in the next iteration >>of >> the draft: >>=20 >> (1) If a dedicated prefix is configured for CLAT, then only a stateless >> XLAT will be required. That is, no mapping table will be maintained at >> all. Since the module already includes NAT64 prefix(es), the CLAT IPv6 >> prefix will be missing. The tree structure can be updated as follows: >>=20 >> OLD: >> +--rw nat64-prefixes* [nat64-prefix] >> | +--rw nat64-prefix inet:ipv6-prefix >> | +--rw destination-ipv4-prefix* [ipv4-prefix] >> | +--rw ipv4-prefix inet:ipv4-prefix >>=20 >> NEW: >>=20 >> +--rw nat64-prefixes* [nat64-prefix] >> | +--rw nat64-prefix inet:ipv6-prefix >> | +--rw destination-ipv4-prefix* [ipv4-prefix] >> | +--rw ipv4-prefix inet:ipv4-prefix >> +--rw clat-ipv6-prefix? inet:ipv6-prefix >>=20 >> (2) If no dedicated /64 prefix is provided, a NAT44 will be required. A >> stateless XLAT will be then applied on NATed packets. This case is >> natively supported by the current YANG model. >>=20 >> A CLAT module can automatically select an IPv4 address from 192.0.0.0/29 >> (RFC7335). This address can also be set. To do so, the tree structure >>can >> be updated with: >>=20 >> NEW: >> ... >> +--rw clat-ipv4-address? inet:ipv4-address >> ... >>=20 >> The CLAT IPv4 address will be taken by default from 192.0.0.0/29. Other >> addresses can be used. >>=20 >> Lee/Jordi, are there any other required changes? >>=20 >> Thank you. >>=20 >> Cheers, >> Med >>=20 >> > -----Message d'origine----- >> > De : OPSAWG [mailto:opsawg-bounces@ietf.org] De la part de >> > mohamed.boucadair@orange.com >> > Envoy=C3=A9 : vendredi 18 ao=C3=BBt 2017 15:46 >> > =C3=80 : opsawg@ietf.org >> > Cc : sureshk@juniper.net; JACQUENET Christian IMT/OLN >> > Objet : [OPSAWG] TR: New Version Notification for >>draft-ietf-opsawg-nat- >> > yang-00.txt >> > >> > Dear all, >> > >> > The -00 version integrates the comments received during the Call for >> > Adoption: >> > >> > - Clarify how Destination NAT is covered (Tianran) >> > - Follow the NMDA guidelines (Juergen and Qin) >> > - Include a generic structure for ALGs instead of listing supported >>ones >> > (Juergen) >> > - Include a discussion about how other transport protocols are/can be >> > supported (Juergen) >> > - Include a comprehensive list of examples (Juergen) >> > - Move the example to an appendix (Juergen) >> > >> > We do still have one pending comment that was raised by Lee Howard >>when >> I >> > presented in Prague: add CLAT to the list. >> > >> > Comments are more than welcome. Please review. >> > >> > Cheers, >> > Med >> > >> > > -----Message d'origine----- >> > > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> > > Envoy=C3=A9 : vendredi 18 ao=C3=BBt 2017 15:31 >> > > =C3=80 : BOUCADAIR Mohamed IMT/OLN; Senthil Sivakumar; JACQUENET >>Christian >> > > IMT/OLN; opsawg-chairs@ietf.org; Qin Wu >> > > Objet : New Version Notification for >>draft-ietf-opsawg-nat-yang-00.txt >> > > >> > > >> > > A new version of I-D, draft-ietf-opsawg-nat-yang-00.txt >> > > has been successfully submitted by Mohamed Boucadair and posted to >>the >> > > IETF repository. >> > > >> > > Name: draft-ietf-opsawg-nat-yang >> > > Revision: 00 >> > > Title: A YANG Data Model for Network Address Translation (NAT) >> and >> > > Network Prefix Translation (NPT) >> > > Document date: 2017-08-18 >> > > Group: opsawg >> > > Pages: 67 >> > > URL: https://www.ietf.org/internet-drafts/draft-ietf- >> opsawg- >> > > nat-yang-00.txt >> > > Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg- >> nat- >> > > yang/ >> > > Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-nat- >> yang- >> > 00 >> > > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf- >> opsawg- >> > > nat-yang-00 >> > > >> > > >> > > 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 data model for the NAT function. NAT44, >> > > NAT64, and NPTv6 are covered in this document. >> > > >> > > >> > > >> > > >> > > 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. >> > > >> > > The IETF Secretariat >> > >> > _______________________________________________ >> > OPSAWG mailing list >> > OPSAWG@ietf.org >> > https://www.ietf.org/mailman/listinfo/opsawg From nobody Mon Aug 21 02:09:52 2017 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 49DE91329A7; Mon, 21 Aug 2017 02:09:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150330659115.6534.18215569185742496206@ietfa.amsl.com> Date: Mon, 21 Aug 2017 02:09:51 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-01.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: Mon, 21 Aug 2017 09:09:52 -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-01.txt Pages : 73 Date : 2017-08-21 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 data model for the NAT function. NAT44, Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit Address Mappings for Stateless IP/ICMP Translation (SIIT EIM), and IPv6 Network Prefix Translation (NPTv6) are covered in this document. 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat-yang-01 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 Aug 21 02:21:11 2017 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 4B29D1329AF for ; Mon, 21 Aug 2017 02:21:09 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 MdYxCyu6nFau for ; Mon, 21 Aug 2017 02:21:06 -0700 (PDT) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70990126C7A for ; Mon, 21 Aug 2017 02:21:06 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id C0BC9C015F; Mon, 21 Aug 2017 11:21:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 9AA2218008E; Mon, 21 Aug 2017 11:21:04 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0361.001; Mon, 21 Aug 2017 11:20:59 +0200 From: To: "jordi.palet@consulintel.es" , Lee Howard CC: "opsawg@ietf.org" , JACQUENET Christian IMT/OLN , "Senthil Sivakumar (ssenthil)" , Qin Wu , "sureshk@juniper.net" Thread-Topic: CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.txt) Thread-Index: AQHTGDU4z1ZKlJbMRqCG7OBhszrdBKKOiusw Date: Mon, 21 Aug 2017 09:20:59 +0000 Message-ID: <1a980b9c-0c6f-42c1-b0c1-f2f4f0decdbb@OPEXCLILM24.corporate.adroot.infra.ftgroup> References: <7e5cb648-16a8-43c9-8ac9-d869c170447c@OPEXCLILMA2.corporate.adroot.infra.ftgroup> <292AA9DC-F011-4585-8424-C6323F2FC769@consulintel.es> In-Reply-To: <292AA9DC-F011-4585-8424-C6323F2FC769@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.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: Mon, 21 Aug 2017 09:21:09 -0000 SGkgSm9yZGksIGFsbCwNCg0KVGhhbmsgeW91IGZvciB0aGUgZmVlZGJhY2suIA0KDQpBIG5ldyB2 ZXJzaW9uIHRoYXQgdGFrZXMgaW50byBhY2NvdW50IHlvdXIgc3VnZ2VzdGlvbnMgaXMgYXZhaWxh YmxlIG9ubGluZS4gUGxlYXNlIGNoZWNrOiANCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wMS50 eHQgDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmcvIA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wMSANCkh0bWxpemVkOiAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3Bz YXdnLW5hdC15YW5nLTAxIA0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wMQ0KDQpDaGVlcnMsDQpNZWQN Cg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogSk9SREkgUEFMRVQgTUFS VElORVogW21haWx0bzpqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lc10NCj4gRW52b3nDqcKgOiB2 ZW5kcmVkaSAxOCBhb8O7dCAyMDE3IDE3OjE4DQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElN VC9PTE47IExlZSBIb3dhcmQNCj4gQ2PCoDogb3BzYXdnQGlldGYub3JnOyBKQUNRVUVORVQgQ2hy aXN0aWFuIElNVC9PTE47IFNlbnRoaWwgU2l2YWt1bWFyDQo+IChzc2VudGhpbCk7IFFpbiBXdTsg c3VyZXNoa0BqdW5pcGVyLm5ldA0KPiBPYmpldMKgOiBSZTogQ0xBVCAod2FzIFRSOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb3BzYXdnLQ0KPiBuYXQteWFuZy0wMC50 eHQpDQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBMb29rcyBnb29kIHRvIG1lLCBhbmQgSSB0aGluayBp dCBjb3ZlcnMgYWxsIHRoZSBwb3NzaWJsZSBvcHRpb25zLCB3aGljaA0KPiBvbmUgZXhjZXB0aW9u Og0KPiANCj4gICAgICAgICAgICAgICAgICArLS1ydyBjbGF0LWlwdjQtYWRkcmVzcz8gICAgICAg ICAgICBpbmV0OmlwdjQtYWRkcmVzcw0KPiANCj4gWW91IG1heSB3YW50IHRvIHVzZSBhIHByZWZp eCwgbm90IGFuIGFkZHJlc3MuIElmIHlvdSBoYXZlIGEgQ0xBVCBzZXJ2aW5nIGENCj4g4oCcYmln 4oCdIG5ldHdvcmssIGluc3RlYWQgb2YgYSBzbWFsbCBDRSwgeW91IG1heSBuZWVkIHRvIHVzZSBh IHBvb2wgb2YNCj4gc2V2ZXJhbCBJUCBhZGRyZXNzZXMuIEZvciBleGFtcGxlLCBpbiBhIHJlY2Vu dCB0ZXN0aW5nLCBJIHVzZWQgZm9yIHRoZQ0KPiBzdGF0ZWxlc3MgQ0xBVCAoTkFUNDYpIHRoZSBm b2xsb3dpbmcgRUFNVCAoRXhwbGljaXQgQWRkcmVzcyBNYXBwaW5ncw0KPiBUYWJsZSwgUkZDNzc1 Nyk6DQo+IA0KPiBQb29sIElQdjQvTkFUNDY6IDEwMC42NC4wLjAvMTANCj4gUG9vbCBJUHY2OiAy MDAxOjQ3MDo2OGVlOjMwOjovMTA2DQo+IA0KPiAoSSB3YXMgYSBiaXQgZXhhZ2dlcmF0ZWQgaGVy ZSwgd2l0aCBzbyBiaWcgcG9vbCwgYnV0IGlzIG9ubHkgYW4gZXhhbXBsZSkNCj4gDQo+IFNvIG1h eSBiZSBzb21ldGhpbmcgbGlrZToNCj4gKy0tcncgY2xhdC1pcHY0LWFkZHJlc3M/ICAgICAgICAg ICAgaW5ldDppcHY0LWFkZHJlc3MNCj4gKy0tcncgY2xhdC1pcHY0LW1hc2s/ICAgICAgICAgICAg aW5ldDppcHY0LW1hc2sNCj4gDQo+IE5vdGUgdGhhdCBJ4oCZbSBOT1QgZXhwZXJ0IGluIFlBTkcs IGJ1dCBJIGp1c3QgcmVhZCB0aHJ1IGFsbCB5b3VyIElEIGFuZA0KPiBsb29rcyBvay4NCj4gDQo+ IFNvbWUgb3RoZXIgZGV0YWlscyB0aGF0IHlvdSBtYXkgd2FudCB0byBjb25zaWRlcjoNCj4gMSkg U2F5IHNvbWV0aGluZyBhYm91dCBDTEFUL05BVDQ2LzQ2NFhMQVQgaW4gdGhlIGFic3RyYWN0Lg0K PiAyKSBTYW1lIGZvciB0aGUgaW50cm8uDQo+IDMpIFNhbWUgaW4gc2VjdGlvbiAyLjIuDQo+IDQp IFlvdSBtYXkgbmVlZCB0byBhZGQgYWxzbyBzb21ldGhpbmcgaW4gMi44LCBhdCBwYXJhZ3JhcGg6 DQo+IEluIG9yZGVyIHRvIGNvdmVyIGJvdGggTkFUNjQgYW5kIE5BVDQ0IGZsYXZvcnMgaW4gcGFy dGljdWxhciwgdGhlIE5BVA0KPiAgICBtYXBwaW5nIHN0cnVjdHVyZSBhbGxvd3MgdG8gaW5jbHVk ZSBhbiBJUHY0IG9yIGFuIElQdjYgYWRkcmVzcyBhcyBhbg0KPiAgICBpbnRlcm5hbCBJUCBhZGRy ZXNzLiAgUmVtYWluaW5nIGZpZWxkcyBhcmUgY29tbW9uIHRvIGJvdGggTkFUDQo+ICAgIHNjaGVt ZXMuDQo+IDUpIEFsc28gSSB0aGluayBpbiAyLjgg4oCcTm90ZSB0aGF0IGEgbWFwcGluZyB0YWJs ZSBpcyBtYWludGFpbmVkIG9ubHkgZm9yDQo+IHN0YXRlbGVzcyBOQVTigJ0geW91IGFjdHVhbGx5 IG1lYW4gc3RhdGVmdWwgTkFUID8NCj4gNikgWW91IGNvdWxkIGFsc28gcmV3cml0ZSAoMi44KSDi gJxPYnZpb3VzbHksIG5vIG1hcHBpbmcgdGFibGUgaXMgbWFpbnRhaW5lZA0KPiBmb3IgTlBUdjYg Z2l2ZW4gdGhhdCBpdCBpcyBzdGF0ZWxlc3MgYW5kIHRyYW5zcG9ydC1hZ25vc3RpY+KAnSBhcw0K PiDigJxPYnZpb3VzbHksIG5vIG1hcHBpbmcgdGFibGUgaXMgbWFpbnRhaW5lZCBmb3IgYW55IHN0 YXRlbGVzcyBOQVQgKHN1Y2ggYXMNCj4gTkFUNDYpLCBuZWl0aGVyIGZvciBOUFR2NiBnaXZlbiB0 aGF0IGl0IGlzIHN0YXRlbGVzcyBhbmQgdHJhbnNwb3J0LQ0KPiBhZ25vc3RpY+KAnQ0KPiA3KSBJ bnN0ZWFkIG9mICstLXJ3IHN1YnNjcmliZXItbWFzay12Nj8sIHNob3VsZCBtYXNrIGJlIHByZWZp eC1sZW5ndGg/DQo+IDgpIEluIHNlY3Rpb24gMywgSSBzZWUgeW91IGhhdmUgc29tZSDigJxjb2Rl 4oCdIGZvciBlYWNoIE5BVCB0eXBlLCBzbyB5b3UgbWF5DQo+IG5lZWQgYWxzbyBmb3IgTkFUNDY/ DQo+IDkpIEFuZCBvZiBjb3Vyc2UsIHlvdSBtYXkgd2FudCB0byBhZGQgYSBDTEFUIGV4YW1wbGUg YXQgdGhlIGFwcGVuZGl4IDstKQ0KPiANCj4gSG9wZSBpdCBoZWxwcyENCj4gDQo+IFNhbHVkb3Ms DQo+IEpvcmRpDQo+IA0KPiANCj4gLS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCj4gRGU6IDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBSZXNwb25kZXIgYTogPG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb20+DQo+IEZlY2hhOiB2aWVybmVzLCAxOCBkZSBhZ29zdG8gZGUgMjAx NywgMTY6MTkNCj4gUGFyYTogTGVlIEhvd2FyZCA8bGVlQGFzZ2FyZC5vcmc+LCAiam9yZGkucGFs ZXRAY29uc3VsaW50ZWwuZXMiDQo+IDxqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4NCj4gQ0M6 ICJvcHNhd2ctY2hhaXJzQGlldGYub3JnIiA8b3BzYXdnLWNoYWlyc0BpZXRmLm9yZz4sIEpBQ1FV RU5FVCBDaHJpc3RpYW4NCj4gSU1UL09MTiA8Y2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFuZ2UuY29t PiwgIlNlbnRoaWwgU2l2YWt1bWFyIChzc2VudGhpbCkiDQo+IDxzc2VudGhpbEBjaXNjby5jb20+ LCBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4sICJzdXJlc2hrQGp1bmlwZXIubmV0Ig0KPiA8 c3VyZXNoa0BqdW5pcGVyLm5ldD4NCj4gQXN1bnRvOiBDTEFUICh3YXMgVFI6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LQ0KPiB5YW5nLTAwLnR4dCkN Cj4gDQo+ICAgICBIaSBMZWUsDQo+IA0KPiAgICAgKEknbSBhZGRpbmcgSm9yZGkgdG8gdGhlIGRp c2N1c3Npb24gc2luY2UgaGUgaXMgZmFtaWxpYXIgd2l0aCBDTEFUIGluDQo+IGEgQ1BFKQ0KPiAN Cj4gICAgIFlvdSBzdWdnZXN0ZWQgaW4gUHJhZ3VlIHRvIGFkZCBDTEFUIHRvIHRoZSBOQVQgWUFO RyBtb2R1bGUuDQo+IA0KPiAgICAgUGxlYXNlIGZpbmQgYmVsb3cgaG93IHdlIGFyZSBwbGFubmlu ZyB0byBjb3ZlciBpdCBpbiB0aGUgbmV4dA0KPiBpdGVyYXRpb24gb2YgdGhlIGRyYWZ0Og0KPiAN Cj4gICAgICgxKSBJZiBhIGRlZGljYXRlZCBwcmVmaXggaXMgY29uZmlndXJlZCBmb3IgQ0xBVCwg dGhlbiBvbmx5IGENCj4gc3RhdGVsZXNzIFhMQVQgd2lsbCBiZSByZXF1aXJlZC4gVGhhdCBpcywg bm8gbWFwcGluZyB0YWJsZSB3aWxsIGJlDQo+IG1haW50YWluZWQgYXQgYWxsLiBTaW5jZSB0aGUg bW9kdWxlIGFscmVhZHkgaW5jbHVkZXMgTkFUNjQgcHJlZml4KGVzKSwgdGhlDQo+IENMQVQgSVB2 NiBwcmVmaXggd2lsbCBiZSBtaXNzaW5nLiBUaGUgdHJlZSBzdHJ1Y3R1cmUgY2FuIGJlIHVwZGF0 ZWQgYXMNCj4gZm9sbG93czoNCj4gDQo+ICAgICBPTEQ6DQo+ICAgICAgICAgICAgICAgICAgKy0t cncgbmF0NjQtcHJlZml4ZXMqIFtuYXQ2NC1wcmVmaXhdDQo+ICAgICAgICAgICAgICAgICAgfCAg Ky0tcncgbmF0NjQtcHJlZml4ICAgICAgICAgICAgICAgaW5ldDppcHY2LXByZWZpeA0KPiAgICAg ICAgICAgICAgICAgIHwgICstLXJ3IGRlc3RpbmF0aW9uLWlwdjQtcHJlZml4KiBbaXB2NC1wcmVm aXhdDQo+ICAgICAgICAgICAgICAgICAgfCAgICAgKy0tcncgaXB2NC1wcmVmaXggICAgaW5ldDpp cHY0LXByZWZpeA0KPiANCj4gICAgIE5FVzoNCj4gDQo+ICAgICAgICAgICAgICAgICAgKy0tcncg bmF0NjQtcHJlZml4ZXMqIFtuYXQ2NC1wcmVmaXhdDQo+ICAgICAgICAgICAgICAgICAgfCAgKy0t cncgbmF0NjQtcHJlZml4ICAgICAgICAgICAgICAgaW5ldDppcHY2LXByZWZpeA0KPiAgICAgICAg ICAgICAgICAgIHwgICstLXJ3IGRlc3RpbmF0aW9uLWlwdjQtcHJlZml4KiBbaXB2NC1wcmVmaXhd DQo+ICAgICAgICAgICAgICAgICAgfCAgICAgKy0tcncgaXB2NC1wcmVmaXggICAgaW5ldDppcHY0 LXByZWZpeA0KPiAgICAgICAgICAgICAgICAgICstLXJ3IGNsYXQtaXB2Ni1wcmVmaXg/ICAgICAg ICAgICAgIGluZXQ6aXB2Ni1wcmVmaXgNCj4gDQo+ICAgICAoMikgSWYgbm8gZGVkaWNhdGVkIC82 NCBwcmVmaXggaXMgcHJvdmlkZWQsIGEgTkFUNDQgd2lsbCBiZSByZXF1aXJlZC4NCj4gQSBzdGF0 ZWxlc3MgWExBVCB3aWxsIGJlIHRoZW4gYXBwbGllZCBvbiBOQVRlZCBwYWNrZXRzLiBUaGlzIGNh c2UgaXMNCj4gbmF0aXZlbHkgc3VwcG9ydGVkIGJ5IHRoZSBjdXJyZW50IFlBTkcgbW9kZWwuDQo+ IA0KPiAgICAgQSBDTEFUIG1vZHVsZSBjYW4gYXV0b21hdGljYWxseSBzZWxlY3QgYW4gSVB2NCBh ZGRyZXNzIGZyb20NCj4gMTkyLjAuMC4wLzI5IChSRkM3MzM1KS4gVGhpcyBhZGRyZXNzIGNhbiBh bHNvIGJlIHNldC4gVG8gZG8gc28sIHRoZSB0cmVlDQo+IHN0cnVjdHVyZSBjYW4gYmUgdXBkYXRl ZCB3aXRoOg0KPiANCj4gICAgIE5FVzoNCj4gICAgICAgICAgICAgICAgICAuLi4NCj4gICAgICAg ICAgICAgICAgICArLS1ydyBjbGF0LWlwdjQtYWRkcmVzcz8gICAgICAgICAgICBpbmV0OmlwdjQt YWRkcmVzcw0KPiAgICAgICAgICAgICAgICAgIC4uLg0KPiANCj4gICAgIFRoZSBDTEFUIElQdjQg YWRkcmVzcyB3aWxsIGJlIHRha2VuIGJ5IGRlZmF1bHQgZnJvbSAxOTIuMC4wLjAvMjkuDQo+IE90 aGVyIGFkZHJlc3NlcyBjYW4gYmUgdXNlZC4NCj4gDQo+ICAgICBMZWUvSm9yZGksIGFyZSB0aGVy ZSBhbnkgb3RoZXIgcmVxdWlyZWQgY2hhbmdlcz8NCj4gDQo+ICAgICBUaGFuayB5b3UuDQo+IA0K PiAgICAgQ2hlZXJzLA0KPiAgICAgTWVkDQo+IA0KPiAgICAgPiAtLS0tLU1lc3NhZ2UgZCdvcmln aW5lLS0tLS0NCj4gICAgID4gRGUgOiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRm Lm9yZ10gRGUgbGEgcGFydCBkZQ0KPiAgICAgPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t DQo+ICAgICA+IEVudm95w6kgOiB2ZW5kcmVkaSAxOCBhb8O7dCAyMDE3IDE1OjQ2DQo+ICAgICA+ IMOAIDogb3BzYXdnQGlldGYub3JnDQo+ICAgICA+IENjIDogc3VyZXNoa0BqdW5pcGVyLm5ldDsg SkFDUVVFTkVUIENocmlzdGlhbiBJTVQvT0xODQo+ICAgICA+IE9iamV0IDogW09QU0FXR10gVFI6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctDQo+IG5hdC0N Cj4gICAgID4geWFuZy0wMC50eHQNCj4gICAgID4NCj4gICAgID4gRGVhciBhbGwsDQo+ICAgICA+ DQo+ICAgICA+IFRoZSAtMDAgdmVyc2lvbiBpbnRlZ3JhdGVzIHRoZSBjb21tZW50cyByZWNlaXZl ZCBkdXJpbmcgdGhlIENhbGwgZm9yDQo+ICAgICA+IEFkb3B0aW9uOg0KPiAgICAgPg0KPiAgICAg PiAtIENsYXJpZnkgaG93IERlc3RpbmF0aW9uIE5BVCBpcyBjb3ZlcmVkIChUaWFucmFuKQ0KPiAg ICAgPiAtIEZvbGxvdyB0aGUgTk1EQSBndWlkZWxpbmVzIChKdWVyZ2VuIGFuZCBRaW4pDQo+ICAg ICA+IC0gSW5jbHVkZSBhIGdlbmVyaWMgc3RydWN0dXJlIGZvciBBTEdzIGluc3RlYWQgb2YgbGlz dGluZyBzdXBwb3J0ZWQNCj4gb25lcw0KPiAgICAgPiAoSnVlcmdlbikNCj4gICAgID4gLSBJbmNs dWRlIGEgZGlzY3Vzc2lvbiBhYm91dCBob3cgb3RoZXIgdHJhbnNwb3J0IHByb3RvY29scyBhcmUv Y2FuDQo+IGJlDQo+ICAgICA+IHN1cHBvcnRlZCAoSnVlcmdlbikNCj4gICAgID4gLSBJbmNsdWRl IGEgY29tcHJlaGVuc2l2ZSBsaXN0IG9mIGV4YW1wbGVzICAoSnVlcmdlbikNCj4gICAgID4gLSBN b3ZlIHRoZSBleGFtcGxlIHRvIGFuIGFwcGVuZGl4IChKdWVyZ2VuKQ0KPiAgICAgPg0KPiAgICAg PiBXZSBkbyBzdGlsbCBoYXZlIG9uZSBwZW5kaW5nIGNvbW1lbnQgdGhhdCB3YXMgcmFpc2VkIGJ5 IExlZSBIb3dhcmQNCj4gd2hlbiBJDQo+ICAgICA+IHByZXNlbnRlZCBpbiBQcmFndWU6IGFkZCBD TEFUIHRvIHRoZSBsaXN0Lg0KPiAgICAgPg0KPiAgICAgPiBDb21tZW50cyBhcmUgbW9yZSB0aGFu IHdlbGNvbWUuIFBsZWFzZSByZXZpZXcuDQo+ICAgICA+DQo+ICAgICA+IENoZWVycywNCj4gICAg ID4gTWVkDQo+ICAgICA+DQo+ICAgICA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ ICAgICA+ID4gRGUgOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddDQo+ICAgICA+ID4gRW52b3nDqSA6IHZlbmRyZWRpIDE4IGFvw7t0IDIw MTcgMTU6MzENCj4gICAgID4gPiDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IFNlbnRo aWwgU2l2YWt1bWFyOyBKQUNRVUVORVQNCj4gQ2hyaXN0aWFuDQo+ICAgICA+ID4gSU1UL09MTjsg b3BzYXdnLWNoYWlyc0BpZXRmLm9yZzsgUWluIFd1DQo+ICAgICA+ID4gT2JqZXQgOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLQ0KPiAwMC50 eHQNCj4gICAgID4gPg0KPiAgICAgPiA+DQo+ICAgICA+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLTAwLnR4dA0KPiAgICAgPiA+IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIgYW5kIHBvc3RlZCB0bw0K PiB0aGUNCj4gICAgID4gPiBJRVRGIHJlcG9zaXRvcnkuDQo+ICAgICA+ID4NCj4gICAgID4gPiBO YW1lOgkJZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmcNCj4gICAgID4gPiBSZXZpc2lvbjoJMDAN Cj4gICAgID4gPiBUaXRsZToJCUEgWUFORyBEYXRhIE1vZGVsIGZvciBOZXR3b3JrIEFkZHJlc3Mg VHJhbnNsYXRpb24NCj4gKE5BVCkgYW5kDQo+ICAgICA+ID4gTmV0d29yayBQcmVmaXggVHJhbnNs YXRpb24gKE5QVCkNCj4gICAgID4gPiBEb2N1bWVudCBkYXRlOgkyMDE3LTA4LTE4DQo+ICAgICA+ ID4gR3JvdXA6CQlvcHNhd2cNCj4gICAgID4gPiBQYWdlczoJCTY3DQo+ICAgICA+ID4gVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LQ0KPiBvcHNhd2ctDQo+ICAgICA+ID4gbmF0LXlhbmctMDAudHh0DQo+ICAgICA+ID4gU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtDQo+ IG9wc2F3Zy1uYXQtDQo+ICAgICA+ID4geWFuZy8NCj4gICAgID4gPiBIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLW5hdC0NCj4geWFu Zy0NCj4gICAgID4gMDANCj4gICAgID4gPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLQ0KPiBvcHNhd2ctDQo+ICAgICA+ID4g bmF0LXlhbmctMDANCj4gICAgID4gPg0KPiAgICAgPiA+DQo+ICAgICA+ID4gQWJzdHJhY3Q6DQo+ ICAgICA+ID4gICAgRm9yIHRoZSBzYWtlIG9mIG5ldHdvcmsgYXV0b21hdGlvbiBhbmQgdGhlIG5l ZWQgZm9yIHByb2dyYW1taW5nDQo+ICAgICA+ID4gICAgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0 aW9uIChOQVQpIGZ1bmN0aW9uIGluIHBhcnRpY3VsYXIsIGENCj4gZGF0YQ0KPiAgICAgPiA+ICAg IG1vZGVsIGZvciBjb25maWd1cmluZyBhbmQgbWFuYWdpbmcgdGhlIE5BVCBpcyBlc3NlbnRpYWwu ICBUaGlzDQo+ICAgICA+ID4gICAgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBm b3IgdGhlIE5BVCBmdW5jdGlvbi4NCj4gTkFUNDQsDQo+ICAgICA+ID4gICAgTkFUNjQsIGFuZCBO UFR2NiBhcmUgY292ZXJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KPiAgICAgPiA+DQo+ICAgICA+ID4N Cj4gICAgID4gPg0KPiAgICAgPiA+DQo+ICAgICA+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gICAgID4gPiBzdWJt aXNzaW9uDQo+ICAgICA+ID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdA0KPiB0b29scy5pZXRmLm9yZy4NCj4gICAgID4gPg0KPiAgICAgPiA+IFRo ZSBJRVRGIFNlY3JldGFyaWF0DQo+ICAgICA+DQo+ICAgICA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICA+IE9QU0FXRyBtYWlsaW5nIGxpc3QN Cj4gICAgID4gT1BTQVdHQGlldGYub3JnDQo+ICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb3BzYXdnDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gSVB2NCBpcyBvdmVyDQo+ IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiBodHRwOi8vd3d3LmNvbnN1 bGludGVsLmVzDQo+IFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+IFRoaXMgZWxlY3Ryb25pYyBtZXNz YWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+IGNv bmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgdXNl IG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlDQo+IHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlp bmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMNCj4gaW5mb3Jt YXRpb24sIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgcHJvaGliaXRlZC4NCj4gDQo+IA0K DQo= From nobody Mon Aug 21 11:26:01 2017 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 B838C132A25; Mon, 21 Aug 2017 11:25:52 -0700 (PDT) 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.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150333995271.6827.999435211986848928@ietfa.amsl.com> Date: Mon, 21 Aug 2017 11:25:52 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-07.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: Mon, 21 Aug 2017 18:25:53 -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 : The TACACS+ Protocol Authors : Thorsten Dahm Andrej Ota Douglas C. Medway Gash David Carrel Lol Grant Filename : draft-ietf-opsawg-tacacs-07.txt Pages : 42 Date : 2017-08-21 Abstract: TACACS+ provides Device Administration for routers, network access servers and other networked computing devices via one or more centralized servers. This document describes the protocol that is used by TACACS+. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-07 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 22 06:38:16 2017 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 2F227132397; Tue, 22 Aug 2017 06:38:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Bjorklund To: Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150340909415.6001.14045177084948571272@ietfa.amsl.com> Date: Tue, 22 Aug 2017 06:38:14 -0700 Archived-At: Subject: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-mud-08 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, 22 Aug 2017 13:38:14 -0000 Reviewer: Martin Bjorklund Review result: Ready with Issues Hi, I am the assigned YANG doctors reviewer for this document. Here are my comments: o Section 2 says: The MUD file is limited to the serialization of a small number of YANG schema, including the models specified in the following documents: o [I-D.ietf-netmod-acl-model] o [RFC6991] Is the intention that *only* these models are included, or *at least* these models are included? RFC6991 doesn't define any data nodes, so I don't think it needs to be listed. I suggest you are a bit more specific, and list: o ietf-access-control-list [I-D.ietf-netmod-acl-model] o ietf-mud [...] o Section 3 uses the term "element" (it is used in other places as well). YANG uses the term "data node" or "node". Or "YANG data node". I suggest you use one of these terms, and import the term in your Terminology section. Also, the YANG module uses the term "element" to refer to "device": leaf is-supported { type boolean; description "The element is currently supported by the manufacturer."; } o In your Terminology section you introduce the term "Thing". But the text often use "device". Maybe use "device" consistently? o In order to get consistent indentation of the YANG modules, I suggest you run: pyang -f yang ietf-mud.yang (and same for ietf-acldns.yang) o Ensure that description statements contain proper sentences. Also ensure that the descriptions are descriptive. As an example of the latter, this is not a good description: description "Which way are we talking about?"; In general, I found that the main document had better descriptions than the YANG module. Consider moving the text from the main document to the YANG module (this also reduces the risk of inconsistencies). If don't want to move text, I think you need to spend some effort on almost all descriptions in the YANG module. o In both modules, make sure you have a single revision statement. Note that in IETF-terms, a revision statement is added when a new version of the module is publsihed as an RFC (so the initial RFC would have one revision statement). o The "ietf-mud" module is a bit unorthodox; it defines configuration data nodes, but it is not supposed to be implemented by a normal NETCONF/RESTCONF server. Rather, it will be instantiated in a JSON file. I think this should be stated in the description of the module. o I don't think the feature "mud-acl" is necessary. It is only used to make the acl augment conditional on the feature. I think that if this module is supported, the feature is also supported. Or do you envision implementations of this module that would not support this feature? If so, maybe you can explain that use case in the document. o leaf cache-validity could use a "units" statement: units "hours"; o I suggest you rename the grouping "access_lists" to "access-lists" for consitency. o Should any of the leafs in "/metainfo" be mandatory? o The "extensions" leaf-list mentions an IANA registry for extensions. It would be usefule to mention this registry by name. Also, shouldn't this registry be defined in the IANA Considerations section? o Section 3.7 mentions a leaf "packet-direction". There is no such leaf in the YANG module. There is one called "direction-initiated" though. But since the "/device" container contains two different ACL sets, one for "to" and one for "from", is this augmentation really necessary? o The model has: leaf local-networks { type empty; description "this string is used to indicate networks considered local in a given environment."; This leaf is of type "empty", but the description says it is a string. Also, what is the format of this string? (Hmm, I think the description is wrong, this should indeed be type empty). o Would it be useful with an indication of the revision of "ietf-mud" that is used as the schema for a MUD file? I.e., something like a leaf "mud-module-revision" in the "metainfo" container. o The example in section 8 has some errors, e.g., it has some camelCase node names. From nobody Tue Aug 22 07:03:30 2017 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 415C113239C; Tue, 22 Aug 2017 07:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 182b4q95RZPe; Tue, 22 Aug 2017 07:03:18 -0700 (PDT) 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 49FA8132256; Tue, 22 Aug 2017 07:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6478; q=dns/txt; s=iport; t=1503410597; x=1504620197; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=d9d8Mq96mwc9t/tmEaS5iAXD1bie9SbJJQB/mbuueU8=; b=RsI6h5muAOtBGwJXm4YAlbkNQ+Znb7vXTr5GNebWQC+wb3J/zZ25VtyF 8SFSkphIDJTaVEb2FUr+x4VyhTu6y6vD0BZ8YUVS43F8Q+ivcCn71HDkd dZGZakCWsNbKi/vi7cwkYp8vUS6i2DHYzt6nFnZqWYYjf6+VBZm8cMUNe M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAABKOJxZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBk2Z0kHAilh+CEgeFQAKEYxgBAgEBAQEBAQFrKIUZAQUjVhALDgoqAgJ?= =?us-ascii?q?XBgEMCAEBii2sVoImi10BAQEBAQEBAQEBAQEBAQEBAQERD4MqhTErC4JxhEwRg?= =?us-ascii?q?ymCQh8FigqHEI87hDOCIYRWiRmLSocWlikfOIEKMiEIHBVJhxw+iQqCQQEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,412,1498521600"; d="asc'?scan'208";a="696684402" 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; 22 Aug 2017 14:03:12 +0000 Received: from [10.61.78.225] (ams3-vpn-dhcp3809.cisco.com [10.61.78.225]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7ME3COT012371; Tue, 22 Aug 2017 14:03:12 GMT To: Martin Bjorklund , yang-doctors@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org References: <150340909415.6001.14045177084948571272@ietfa.amsl.com> From: Eliot Lear Message-ID: Date: Tue, 22 Aug 2017 16:03:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150340909415.6001.14045177084948571272@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="akLgnsE2FgsC8XkWr2VSJDKJHqoeJROo5" Archived-At: Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-mud-08 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, 22 Aug 2017 14:03:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --akLgnsE2FgsC8XkWr2VSJDKJHqoeJROo5 Content-Type: multipart/mixed; boundary="NpalEjFVgXifh93lfTC01Xe8A7jvkTiBf"; protected-headers="v1" From: Eliot Lear To: Martin Bjorklund , yang-doctors@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org Message-ID: Subject: Re: Yangdoctors early review of draft-ietf-opsawg-mud-08 References: <150340909415.6001.14045177084948571272@ietfa.amsl.com> In-Reply-To: <150340909415.6001.14045177084948571272@ietfa.amsl.com> --NpalEjFVgXifh93lfTC01Xe8A7jvkTiBf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Thanks, Martin, for your timely review.=C2=A0 We'll sort through the issu= es and come back to the group and to you. Eliot On 8/22/17 3:38 PM, Martin Bjorklund wrote: > Reviewer: Martin Bjorklund > Review result: Ready with Issues > > Hi, > > I am the assigned YANG doctors reviewer for this document. Here are > my comments: > > > o Section 2 says: > > The MUD file is limited to the serialization of a > small number of YANG schema, including the models specified in the > following documents: > > o [I-D.ietf-netmod-acl-model] > > o [RFC6991] > > Is the intention that *only* these models are included, or *at > least* these models are included? > > RFC6991 doesn't define any data nodes, so I don't think it needs to > be listed. I suggest you are a bit more specific, and list: > > o ietf-access-control-list [I-D.ietf-netmod-acl-model] > > o ietf-mud [...] > > > o Section 3 uses the term "element" (it is used in other places as > well). YANG uses the term "data node" or "node". Or "YANG data > node". I suggest you use one of these terms, and import the term > in your Terminology section. > > Also, the YANG module uses the term "element" to refer to "device": > > leaf is-supported { > type boolean; > description > "The element is currently supported > by the manufacturer."; > } > > > o In your Terminology section you introduce the term "Thing". But > the text often use "device". Maybe use "device" consistently? > > > o In order to get consistent indentation of the YANG modules, I > suggest you run: > > pyang -f yang ietf-mud.yang > > (and same for ietf-acldns.yang) > > > o Ensure that description statements contain proper sentences. Also > ensure that the descriptions are descriptive. As an example of the > latter, this is not a good description: > > description > "Which way are we talking about?"; > > In general, I found that the main document had better descriptions > than the YANG module. Consider moving the text from the main > document to the YANG module (this also reduces the risk of > inconsistencies). If don't want to move text, I think you need to > spend some effort on almost all descriptions in the YANG module. > > > o In both modules, make sure you have a single revision > statement. Note that in IETF-terms, a revision statement is added > when a new version of the module is publsihed as an RFC (so the > initial RFC would have one revision statement). > > > o The "ietf-mud" module is a bit unorthodox; it defines configuration > data nodes, but it is not supposed to be implemented by a normal > NETCONF/RESTCONF server. Rather, it will be instantiated in a JSON > file. I think this should be stated in the description of the > module. > > > o I don't think the feature "mud-acl" is necessary. It is only used > to make the acl augment conditional on the feature. I think that > if this module is supported, the feature is also supported. Or do > you envision implementations of this module that would not support > this feature? If so, maybe you can explain that use case in the > document. > > > o leaf cache-validity could use a "units" statement: > > units "hours"; > > > o I suggest you rename the grouping "access_lists" to "access-lists" > for consitency. > > > o Should any of the leafs in "/metainfo" be mandatory? > > > o The "extensions" leaf-list mentions an IANA registry for > extensions. It would be usefule to mention this registry by name. > > Also, shouldn't this registry be defined in the IANA Considerations > section? > > > o Section 3.7 mentions a leaf "packet-direction". There is no such > leaf in the YANG module. There is one called "direction-initiated" > though. > > But since the "/device" container contains two different ACL sets, > one for "to" and one for "from", is this augmentation really > necessary? > > > o The model has: > > leaf local-networks { > type empty; > description > "this string is used to indicate networks > considered local in a given environment."; > > This leaf is of type "empty", but the description says it is a > string. > > Also, what is the format of this string? (Hmm, I think the > description is wrong, this should indeed be type empty). > > > o Would it be useful with an indication of the revision of "ietf-mud" > that is used as the schema for a MUD file? I.e., something like a > leaf "mud-module-revision" in the "metainfo" container. > > > o The example in section 8 has some errors, e.g., it has some > camelCase node names. > > > --NpalEjFVgXifh93lfTC01Xe8A7jvkTiBf-- --akLgnsE2FgsC8XkWr2VSJDKJHqoeJROo5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZnDmhAAoJEIe2a0bZ0nozuF8IAJflk0XAvIHFQa3NvYedOnOc jNobKsTSD+0ho/uJ8zgMd+J/91VO5fziC4VOXq70Rba0LAYHI8kF4lxJWKd/s2O9 uaCvy+VXeTHf+wk+RcE+2rpguL3iMRlueUeRqVlXPWTCb+/RlqALUsgSv676zhUP WB/SpFGrUAdbUxANkqrxqi1AThcwsBK/Da6d5f7Kmd+RtA91YX11MEcommaW3HCp AYrwSNXsZro9cHcM5in8IPibkI+ZzeF2OfB94g93VmTuRUweLsM0TzbWH+S3rAsi wTtWkSq8Ht8rPpSLjtrTCy9LKhd5a3Z6nel7hNXb8bdeGwcu4Ig3JfvZg/mKSqU= =XHvi -----END PGP SIGNATURE----- --akLgnsE2FgsC8XkWr2VSJDKJHqoeJROo5-- From nobody Tue Aug 22 12:27:49 2017 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 24DCD132A18; Tue, 22 Aug 2017 12:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 AcPFZn-nOfMx; Tue, 22 Aug 2017 12:27:44 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761751326DF; Tue, 22 Aug 2017 12:27:44 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7MJRajm007125; Tue, 22 Aug 2017 20:27:36 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7MJRY54007117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2017 20:27:35 +0100 Reply-To: From: "Adrian Farrel" To: , "'Tianran Zhou'" , Cc: References: <787AE7BB302AE849A7480A190F8B93300A014245@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A014245@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 22 Aug 2017 20:27:30 +0100 Message-ID: <039b01d31b7c$b35da5f0$1a18f1d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH3xPK8SnNx+dJdxeKTifN90yR7aQIsSZSpojXkxMA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23276.001 X-TM-AS-Result: No--13.563-10.0-31-10 X-imss-scan-details: No--13.563-10.0-31-10 X-TMASE-MatchedRID: gzVbiXtWD9unykMun0J1wpmug812qIbznuwCcgqnTfCiUP5F9sCEMH3H PSmzsEzIPWV+rAFy8m3o1pEdsWYJ27s5lGfHdzcVSDkh6bW+bceRS1J577nsgeeU0qFv58B+4O6 D2PAgEXkGq9QtUkVTW6Xyg47PAFhUsk3Xm9yiC76OjIrMSa2sR23eqxoVjgMErY9uF6odMly4HV USbzJgElABXHwdiftsdN0J1A6KyKjLIr1irshncnH7HV/mO4UT1pnvzMqQcsYwplGJ7NxS060Ro mhWPJaQepYdDkfIivoBCtgvuWiKAwbLd7s3c5s0pD3o+89TxIu9vtwsX5fX6EBpkKVpxuvGVZ8x QvqztIQzgLLh7dLxYmsYFJHVAm2qAM0/G7XUdeNDU5wIS9P5t4+YVJqrrEz4buBZJ8qsrIRJtV8 +KY5jwp4BO573JYaAwHbJ/+q6Za8OCdl4y9zfjo3Zcf6Q+mOM6Jj6zYvfFASI92Gm1naXaaPFjJ EFr+olfeZdJ1XsorhCITlsmPfzAAtuKBGekqUpI/NGWt0UYPDcSP/EZAQGVBSimqOq/j08YikCB IquO8USnGMFshQ5zf+5Yi9v5HOJ Archived-At: Subject: Re: [OPSAWG] WG LC for 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: Tue, 22 Aug 2017 19:27:47 -0000 Hi Med, Thanks again for your review. I'm just in the process of updating the draft and wanted to let you know what changes I'm making. > - Remove RFC7426 and RFC8049 from the normative references. Those are cited > as examples. Yes. No problem with that. > - Simplify the text in the abstract as follows: > > OLD : > > The IETF has produced a considerable number of data modules in the > YANG modelling language. The majority of these modules are used to > construct data models to model devices or monolithic functions and > ^^^^^^^^^^^^^^ > they allow access for configuration and to read operational status.^ > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^ > > NEW: > The IETF has produced a considerable number of data modules in the > YANG modelling language. The majority of these modules are used to > construct data models for devices or monolithic functions. OK > - Introduction: > > * Please cite RFC7149 in addition to [RFC7426] to have both IETF and IRTF > perspectives. OK > * Please update this text as follows: > > OLD: > Within the context of Software Defined Networking (SDN) [RFC7426] > YANG data models may be used on Southbound Interfaces (SBIs) between > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > a controller and network devices, and between network orchestrators > and controllers. > > NEW: > Within the context of Software Defined Networking (SDN) [RFC7426] > YANG data models may be used on the interface between > a controller and network devices, and between network orchestrators > and controllers. OK > * Update this text as follows: > > OLD: > Recently there has been interest in using YANG to define and document > ^^^^^^^^ > data models that describe services in a portable way that is > independent of which network operator uses the model. > > NEW: > There has been interest in using YANG to define and document > data models that describe services in a portable way that is > independent of which network operator uses the model. > > Or change s/Recently/Recently (as per 2017) Yeah, you're right. Don't need temporal commentary. > * s/ Customer- Provider Interface/Customer-Provider Interface Wow! That's careful reading! (That was an XML2RFC bug) > - Section 2: > s/i.e., routers or switches/e.g., routers or switches I think we really meant "i.e." > - Section 3: > > * Fix the following: > > OLD: > This is shown simply in Figure 1 > > NEW: > This is shown simply in Figure 1. Ack > * Fix the following: > > OLD: > The IETF uses the YANG data modeling language defined in [RFC6020] > > NEW: > The IETF uses the YANG data modeling language defined in [RFC6020]. Ack > - Section 4: Update this text as follows (the introduction text is about "many > figures") > > OLD: > [RFC7491] describes an interface between... > > NEW: > Figure 1 of [RFC7491] shows an interface between... OK > - Section 5: I don't understand what is meant by "standard feature" in this text: > > "but these are not > standard features of the service as described in the customer > service model" > > Do you mean: those are not mandatory features to be included in a service > model? Well, I think the point is that these features are not part of this service model, and for the reason that they are not the sort of thing that service provides will agree about. > - Section 6: I would shorten this text because L3WG is already introduced and > stated many times in the document: > > Several initiatives within the IETF are developing customer service > models. The most advanced presents the Layer Three Virtual Private > Network (L3VPN) service as described by a network operator to a > customer. This L3VPN service model (L3SM) is documented in [RFC8049] > where its usage is described as in Figure 5 which is reproduced from > that document. As can be seen, the L3SM is a customer service model > as described in this document. Yes. I have made some edits through the text for this. Thanks again for your careful reading. I hope this addresses your points. Adrian From nobody Wed Aug 23 01:38:19 2017 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 8B2BB1321B7 for ; Wed, 23 Aug 2017 01:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Oes9wEtVlnoD for ; Wed, 23 Aug 2017 01:38:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C39A1328DB for ; Wed, 23 Aug 2017 01:38:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7N8cDWP011335; Wed, 23 Aug 2017 09:38:13 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7N8cCOf011326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2017 09:38:13 +0100 Reply-To: From: "Adrian Farrel" To: Cc: References: <010301d30968$186c8410$49458c30$@olddog.co.uk> In-Reply-To: <010301d30968$186c8410$49458c30$@olddog.co.uk> Date: Wed, 23 Aug 2017 09:38:09 +0100 Message-ID: <043f01d31beb$267f5560$737e0020$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFqyy8irvd3/FbyVkKh1BMxk4t9NKNiOcBQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23276.006 X-TM-AS-Result: No--14.570-10.0-31-10 X-imss-scan-details: No--14.570-10.0-31-10 X-TMASE-MatchedRID: 9d2LtCNB3NLD66A+AisN3Z21GZGE81yGAHN/Ezu9EnFXPwnnY5XL5MPs a/GuZVGDT7JBDjlfRugva/i9y46xldM5f7kKWsRIb/5HBZ6dvRixc8j0PhSuLr/tumWFs8JCDTK KX+jBlEAnuyoP1IkYjDNvu0+lyu1bV0jfPUUyZ7fFlCgYxEaGEyOSuAnftGqP0KaJBUk7woBKmd YCx6oJHicFWpzXYgAQqQFPLlO3XEhqxgfCZhqtfPpVg+t0N2l6E7JInT4wddpaW2Ktn+I8/rNZX oegIJ13VDyzD5zG+DmFkpB3+k29g9v440MZW5WEf1/NmFM9578SUsfu0Jv3SmGf9yHLcNDMIDyu djRTUrN4yDkdKHEF3p6yGZobfdHDHN0r1kHymECc50HP4uT3qAXAhAGZB7BnXCmcAC8DBrNpxmg QfRgShA/zNC14iAaYjdNZ3LwREdpUOK+EhzoLGIzb2GR6Ttd3nophrTcsI7abKItl61J/ycnjLT A/UDoApPKClyoUSzyNo+PRbWqfRDsAVzN+Ov/sAnWhHtLVO9vqBSDWiCHk3SoNt0DMcaj9rQev3 Nrc3YhObACnE2tgCA== Archived-At: Subject: Re: [OPSAWG] WG LC for 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: Wed, 23 Aug 2017 08:38:18 -0000 Hi Dan, Thank for the review. I'm currently updating the document. Here are my answers to your comments. > Comment #1 - The current abstract could be simmered down to: > > The IETF has produced a number of data modules in the YANG modelling > 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 Three Virtual Private Network Service Model produced by > the L3SM working group and documented in RFC 8049). > > This document describes the role of an IETF service model, and 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 > engineered and delivered to the customer; details of how network protocols > and devices are engineered to deliver a service are captured in other models > that are not exposed through the Customer-Provider Interface. Yes. Less is more. > Comment #2 - A mix of "modelling" and "modeling" usage in the document. > British or American is fine, but maybe not both. OK. Have gone American. > Comment #3 - Section 1. Introduction, second paragraph, last sentence: > ""There may also be a hierarchy of such components with super-controllers, > domain controllers, and device controllers all exchanging information and > instructions using YANG models" > > The only reference to "super-controller" I found (using a popular search > engine) was an accessory for the Nintendo Entertainment System video game > console. Maybe the authors might want to use the term "super controller". OK > Comment #4 - Section 1. Introduction, third paragraph, last sentence: > "Ultimately they could be used in online, software-driven dynamic systems." > > Why not use the term "software defined networks" or "SDN systems", instead > of "online, software-driven dynamic systems". You use the term "software > defined networks" in the abstract and earlier in the introductory text, and > again in section 4. OK. Added the term "SDN". > Comment #5 - Section 3. Using Service Models, third paragraph, last > sentence: > > "However, co-located software components might use an API, while systems > with more direct human interactions might use web pages or even paper > forms." > > Indeed RFC6241 and RFC8040 are data-model/schema-driven APIs. Should the > sentence read ("internal API" or "private API"), as in: > > "However, co-located software components might use an internal API, while > systems with more direct human interactions might use web pages or even > paper forms." OK to add the word "internal". > Comment #6 - The document uses capitalised and non-capitalised instances of > "Control Plane". OK Comments #7 and #8 intentionally left blank? > Comment #9 - Section 9. Manageability Considerations > > You use the term "Service Orchestration" in this section but I found no > reference, or previous definition, in the document. Section 4 discusses splitting the orchestration function between a "Service Orchestrator" and a "Network Orchestrator". And figure 3 presents a service orchestrator. Additionally, the service orchestrator and service orchestration are mentioned in a few other sections. So I think this issue is covered. Thanks, Adrian From nobody Wed Aug 23 03:55:10 2017 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 44B22132BE6; Wed, 23 Aug 2017 03:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 6yqdHsHciM7G; Wed, 23 Aug 2017 03:54:58 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2901E132946; Wed, 23 Aug 2017 03:54:57 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7NAsjFx031520; Wed, 23 Aug 2017 11:54:45 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7NAse0g031495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2017 11:54:45 +0100 Reply-To: From: "Adrian Farrel" To: "'Carl Moberg \(camoberg\)'" Cc: "'Tianran Zhou'" , , Date: Wed, 23 Aug 2017 11:54:37 +0100 Message-ID: <046b01d31bfe$3958a430$ac09ec90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMb/cWLoe/agY+QSUOLBURNF8jkiA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23276.006 X-TM-AS-Result: No--18.242-10.0-31-10 X-imss-scan-details: No--18.242-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkAwJ6xbTjBa5nBRIrj8R47FC/ExpXrHizwwplGJ7NxS0yFS iPJ1ANBwZzS8ZvLgTL7FWxtOlTkSH/GU4m5A0eV9jNvYZHpO13escK/K2DlvjhrUQ7A9MrmGbwI uAyuB59z2q691x1hzEuIBOCyLid9eE0atn7xLb21jHWM8krL4PHJ8yHMhx0aa31GU/N5W5BDEZK HidzhUXFQrQWfNw93S+IzjYvoE5ups/McbADTE9hrnPqLp7GEA8A6q6O7uVrWbcaUfWN//FKpG5 DG7+eX49ZhzYUzjfq3El/ZgS/rppqjmA6eZ5vSkxuvd33/I/WR+K68qL2G5pmecrqZc3vabpdAU S79bY2P3Cch9qVOlxiDUpjC7ZebTHdkkLawA7SETfrsx9o3DwyQqzcugG1CVDYbe/PyX8gRjJEI JQgmokDGi8cBs2wIG+wpG/M7VPBc6TM2EjQ3+Mi1Hx9UxMGjdxJPgzHrfYvrSYAzZ6KmqWmyVWb I4AesfLEIJ3FoU1ViFDHJl22isXIxa53hcnHRIrK1919cGzDJQLBvX11RpSci9AjK6C8p1Ggdt5 59CgdQjQfvQ+LHAjA/T5w0N7FJJaRefeuTiJNyJZq1lQ6Po67/I3arxTrvio8y5CypU1eFdB6ml nUbtbdDszvlp5NqqsxaW9sBm3nsyquK3NWAbFhNEPNwNrw/rZijLrBI/sgWqG/oAv7EtlUaFMIz /3JwCx880dMw/la/YVWK8wmsL7b4OJaSfu96X+mHRL3uzOiJA8JZETQujwp4rd07+pHvAIwKXTP 7P9qXY0jno/xmKIX/y39vn+l1htnydkaPfO+OeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt Archived-At: Subject: Re: [OPSAWG] [netmod] Cross-post to Netmod for LC comments//FW: WG LC for 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: Wed, 23 Aug 2017 10:55:01 -0000 Hi Carl, I'm in the process of updating the document and wanted to let you know = what changes are being made. >>> - The term =E2=80=9CNetwork Service Model=E2=80=9D in RFC 8199 is = intended to cover both >>> "Customer Service Model=E2=80=9D as well as =E2=80=9CService = Delivery Model=E2=80=9D as defined >>> in draft-ietf-opsawg-service-model-explained. At the time of the = first >>> revision of what was >>> draft-bogdanovic-netmod-yang-model-classification >>> we discussed further splitting "Network Service Model=E2=80=9D = into smaller >>> components, but decided against it since we did not see a = consensus on >>> what that split would look like. I believe the authors here is >>> suggesting such a further split. >> >> I think that an "issue" with RFC 8199 is that is appears to imply = that the >> "Network Service Module" (sic) it defines is used on a specific = interface rather >> than simply being the classification of "all modules used north of = this point". This >> our draft is doing slightly more than partitioning the = classification. The last couple >> of rounds of edits to what became 8199 were working with Dean to = slightly >> soften thee language used to make this more consistent. >=20 > Right, and the reason why we took the "all modules used north of this = point=E2=80=9D is > that we have not seen any sign of convergence around abstractions into = smaller > components. In short: implementations of =E2=80=9CYANG for = services=E2=80=9D is currently all > over the map. >=20 >> But see below... >> >>> There is one specific passage in this draft that I would suggest = could >>> use rephrasing if the authors agree to the above: >>> >>> """ >>> As previously noted, [I-D.ietf-netmod-yang-model-classification] >>> provides a classification of YANG data models. It introduces the >>> term "Network Service YANG Module" to identify the type of model = used >>> to "describe the configuration, state data, operations and >>> notifications of abstract representations of services implemented = on >>> one or multiple network elements." These are service delivery = models >>> as described in this document, that is, they are the models used = on >>> the interface between the Service Orchestrator or OSS/BSS and the >>> Network Orchestrator as shown in Figure 3. >>> """ >> >> You suggest this could be rephrased, but don't suggest how:-) >> I just checked 8199 and I see that the quote we have is still = accurate. >> >> I am wondering what it is specifically about this text that worries = you. Again, this >> may come back to the use of a module on a functional interface. I = read 8199 as >> saying that the "Network Service YANG Modules are used by the OSS/BSS = in >> talking to the network elements (o perhaps Controllers?) to configure = the >> network to deliver the service. Am I wrong? >> >> If I'm right in my reading we are not "splitting" the classification, = but introducing >> a new class that lives further north (where the atmosphere is thinner = and the >> temperature colder) >=20 > I think at the core of the feedback (and sorry that it took two = rounds of email to > make it shorter :-) is that in 8199 the Service Orchestrator is = assumed to be an > integral part of OSS/BSS. More below. OK. This is much clearer to me now, and leads into the stuff below. >>> - And this gets to my second point of feedback. Figure 4. in the = draft >>> seems to suggest that the "Service Orchestrator" is an entity = separate >>> from the "Operations and Business Support Systems (OSS/BSS)". >> >> I want to jump into this paragraph at once just to say "no, no, no!" >> This figure (like most I draw in ASCII these days) displays = functional components >> not physical entities. >> How you choose to implement is entirely up to you. >> It seems likely (to me) that the interface between customer and = operator is >> externally exposed (but not necessarily realised using RESTconf). >=20 > This is perhaps also at the core of the feedback. I have never seen = an > implementation/architecture with a functionally distinct Service = Orchestrator > (outside of OSS/BSS) exposed directly to customers. There is usually = at least > something like an order manager (as part of the OSS/BSS) between the = customer > and the service orchestrator. Even in the instances of self-service = portals (which > are naturally located very close to the network) there is at least = some notion of > pricing and billing involved. Funny that I find I agree and disagree :-) You are completely right about the status quo. Also about the importance = of commercial tools as part of the system. On the other hand, we (well, I) don't want to inhibit developmental = approaches. For example, a customer might (within some pre-established = bounds) be allowed to request and modify services directly and have the = commercial repercussions follow on. All that said we converge below... >> It does not seem obvious to me that the Service Orchestrator and the = OSS/BSS >> are separate blobs, except to note that the OSS/BSS deployed today = does not >> support the Customer Service YANG Modules and so the extent to which = it >> provides "service orchestration" is limited. >=20 > Well, a common pattern is to have the order manager put in orders for = technical > service activation from a service orchestrator. The uptake of YANG = seems to be > mostly in the interface between the order manager (an integral part of = OSS/BSS) > and the service orchestrator. >=20 >> I might also claim that an OSS/BSS possibly operates on a single = network where >> the orchestration of a service *might* involve the coordination of = more than one >> network. >=20 > Hmm, since the actual business is accounted for in the OSS/BSS = (including rating, > charging, billing) I=E2=80=99m not sure how a multi-network service = orchestrator outside of > an OSS/BSS context would work. >=20 >>> And also that >>> Customers (as defined) in Section 2 interface directly with that = entity. >>> This is a very unusual construct, in the sense that: >>> o The common taxonomomy from e.g. TMForum would classify a = service >>> orchestrator as a part of the OSS/BSS stack, since... >>> o The successful activation of a service includes many parts of = the >>> OSS/BSS-stack including operational readiness (are there = physical >>> ports available), billing management (is the customer allowed = to >>> perform e.g. this resource expansion), and assurance (changed >>> services require new assurance parameters). This makes it hard >>> to separate out a Customer interface to service orchestration >>> only, separate from the OSS/BSS stack. >> >> I am not (overly) familiar with the TMF work, however, your text = "TMForum >> would classify a service orchestrator as a part of the OSS/BSS stack" = suggests the >> acceptance of service orchestration as "a thing". If you were writing = code, you >> *might* write a separate module (even library) to handle service = orchestration, >> and maintain that as a separate module from billing management, etc. = That does >> not make them completely separate, but does result in them showing as >> separate functional components in the "OSS/BSS stack.=E2=80=9D >=20 > Exactly right. The term =E2=80=9COSS/BSS=E2=80=9D itself as = I=E2=80=99m used to hearing it is a means of > grouping a (huge) set of functions under a common label. >=20 >>> This an informational draft and as such is for general information, = and >>> not necessarily intended to represent community consensus or >>> recommendation, just like 8119. >> >> I choose to disagree! 8199 had WG and IETF last call. It has = community >> consensus. >=20 > True. It was a heavy-handed attempt at pushing on the fact that = we=E2=80=99re not > writing standards here, but merely working to inform. But = you=E2=80=99re absolutely right > that WG work items reflect consensus. >=20 >> The intention of this draft is that it, too, will have IETF community = consensus. >> But be aware that we are neither trying to force that consensus, nor = dictate the >> terminology. What we are doing is trying to answer the (often = repeated) >> question: "Where do L2SM and L3SM fit into the picture since they = don't seem to >> be intended to talk to network devices or controllers?=E2=80=9D >=20 > Makes sense. And in my simplistic (8199-infused) mind, e.g. = ietf-l2vpn- > svc@2016-08-19.yang is a great example of a Network Service Module. So = far so > good ;-) Whether we can come up with further classification to = robustly capture > the "scope of and purpose of an IETF service model=E2=80=9D is next. >=20 >>> But I would suggest the document could be >>> improved by elaborating the point of the separation of the = orchestrator >>> and the BSS/OSS and the resulting difference in module types. >> >> I could certainly add text around Figure 4 to say "...this = illustrates a functional >> architecture and an implementation might not choose to make the = distinctions >> shown such that separations and interfaces illustrated might fall = within a single >> implementation." Would that help? >=20 > With the further elaboration above, would this make sense? OK. We're working with that figure. =20 > +---------------+ > | | > | Customers | > | | > +---------------+ >=20 > - - - - - - - - - - - - - - > Customer Service YANG Modules >=20 > +-------------------------------------------------------------+ > | Operations and Business Support System (OSS/BSS) | > | +--------------------------+ | > | | Service Orchestrator | | > | +--------------------------+ | > +-------------------------------------------------------------+ >=20 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Network Service YANG Modules >=20 > +------------+ +-------------+ +-------------+ = +-------------+ > | | | | | | | = | > | - L2VPN | | - L2VPN | | EVPN | | L3VPN = | > | - VPWS | | - VPLS | | | | = | > | | | | | | | = | > +------------+ +-------------+ +-------------+ = +-------------+ >=20 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Network Element YANG Modules >=20 > +------------+ +------------+ +-------------+ +------------+ > | | | | | | | | > | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | > | | | | | | | | > +------------+ +------------+ +-------------+ +------------+ >=20 > L2VPN: Layer 2 Virtual Private Network > L3VPN: Layer 3 Virtual Private Network > VPWS: Virtual Private Wire Service > VPLS: Virtual Private LAN Service Cheers, Adrian From nobody Wed Aug 23 06:29:39 2017 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 15A4A132351; Wed, 23 Aug 2017 06:29:37 -0700 (PDT) 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.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150349497701.19491.18140971342789118846@ietfa.amsl.com> Date: Wed, 23 Aug 2017 06:29:37 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-02.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, 23 Aug 2017 13:29:37 -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-02.txt Pages : 75 Date : 2017-08-23 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 data model for the NAT function. NAT44, Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit Address Mappings for Stateless IP/ICMP Translation (SIIT EIM), and IPv6 Network Prefix Translation (NPTv6) are covered in this document. 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat-yang-02 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 Aug 23 06:43:40 2017 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 11EFE132977 for ; Wed, 23 Aug 2017 06:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 WA2uRHkXEqeL for ; Wed, 23 Aug 2017 06:43:37 -0700 (PDT) Received: from relais-inet.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 D46DA132518 for ; Wed, 23 Aug 2017 06:43:36 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 8B159204AC; Wed, 23 Aug 2017 15:43:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 5FE381A007D; Wed, 23 Aug 2017 15:43:35 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0361.001; Wed, 23 Aug 2017 15:43:35 +0200 From: To: "opsawg@ietf.org" CC: Fred Baker Thread-Topic: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-02.txt Thread-Index: AQHTHBPhYGtcoOwF7UGxcvDboHXGO6KR7/Yw Date: Wed, 23 Aug 2017 13:43:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A02E70D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <150349497701.19491.18140971342789118846@ietfa.amsl.com> In-Reply-To: <150349497701.19491.18140971342789118846@ietfa.amsl.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.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-02.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, 23 Aug 2017 13:43:39 -0000 Dear all,=20 Fred (Baker) has kindly accepted to review the NPTv6 part of this specifica= tion. Many thanks to him.=20 This new version integrates the comments raised by Fred. The main changes a= re: - Specify the interface(s) on which the translation function applies. The m= odel allows to characterize both internal and external interfaces. When no = interface is defined, this assumes that the underlying system is capable to= determine the interface on which the NAT must be executed. For example, a = CPE device is able to determine its LAN and WAN interfaces. - Rename "pool-id" under NPTv6 prefixes to "translation-id" to avoid confus= ing with a NAT44 pool - Update the NPTv6 appendix accordingly.=20 Fred may still have comments on this version. I will let him confirm/infirm= .=20 Cheers, Med > -----Message d'origine----- > De=A0: OPSAWG [mailto:opsawg-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mercredi 23 ao=FBt 2017 15:30 > =C0=A0: i-d-announce@ietf.org > Cc=A0: opsawg@ietf.org > Objet=A0: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-02.txt >=20 >=20 > 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 : 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-02.txt > Pages : 75 > Date : 2017-08-23 >=20 > 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 data model for the NAT function. >=20 > NAT44, Network Address and Protocol Translation from IPv6 Clients to > IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit > Address Mappings for Stateless IP/ICMP Translation (SIIT EIM), and > IPv6 Network Prefix Translation (NPTv6) are covered in this document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-02 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-nat-yang-02 >=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 From nobody Wed Aug 23 08:28:44 2017 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 E94751329BA; Wed, 23 Aug 2017 08:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 C4UXkVSWcyio; Wed, 23 Aug 2017 08:28:40 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4500132938; Wed, 23 Aug 2017 08:28:39 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7NFSSG6027712; Wed, 23 Aug 2017 16:28:28 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7NFSQtk027700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2017 16:28:27 +0100 Reply-To: From: "Adrian Farrel" To: "'LUIS MIGUEL CONTRERAS MURILLO'" , "'Tianran Zhou'" , Cc: References: <028e01d2e6ab$8cb9ab20$a62d0160$@olddog.co.uk> In-Reply-To: Date: Wed, 23 Aug 2017 16:28:21 +0100 Message-ID: <04b101d31c24$75a58ae0$60f0a0a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHTPawIDXDMTslJzeQqpAnPR3LeKAFNC4xVAPxshNmifzgwAA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23278.000 X-TM-AS-Result: No--15.750-10.0-31-10 X-imss-scan-details: No--15.750-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtGUi/HvzBgKWfSG/+sPtZVkLi2dwKiMR9yqvcIF1TcLYCg5 EdjA8p/cnGmMQczJdBlQs9zZ6FJD22JZXQNDzktSxZQoGMRGhhPomPrNi98UBBRZ/9wBMhGsdFj d7F9Z+i7Mt0nZdIBppa1zERmpltZe/02XRYC/8euSRFDtqiM5SyaXATIpQghop+cg3PT8JVwPj8 zQ9VPOnmlYLDyOlhcPS2CVBdAUwlis+UyNZ22pjFz+axQLnAVBMhomkrNJ+ux/LEiGeMsxKYm/7 /wGGUaziQLTIWegTQYr/qaImEqNQAIYBynKuUYqxuvd33/I/WShi9MC6OBOwoFN4EqoFGbySHPP xU51gn1o/cWzX00HyaXhn7HkPN58dh8zW9wXHN7v9TsmYymKIVGyQSSKWoGSK6rsMmth5SZNKyb r/WG4khZ3vcrcNZAcl7HzIw2VJsznC5LyYJwD3ylrosmS0SOAc1tWSEjKtCOtj24Xqh0yXIRjb6 q99slJ6c0e5RHmWEtHNYhRdLnB5zRn2xdwrsXpU+OjsPhIWDik2H/b/X5aJR1u7K8HqaNcGwREU TS8dqNTyVoafDrj0A2tRxM8QIkMqvQ/vMrfepljoaO27r+3fc6XjCcGFXerh5Q1ArtCPlz2vKca kQSReUtq5Y1lo/OGnmCqhV+Wa/OXvbahSGf3YPsWQZL8R7LYlavqJJda2A+VvypVes2MRd//lX/ iMGgAlxs7JkoGqyJL/GGjLwaQxX/Viz/sSvmwOXon7t5qW1baoFJAcCHymEUNHQAoZf5cZ/pbr3 Q41hbl+2iJoPAIPUaAYpU2z1XFK4gIv0V7SZmeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtBiSYry2lpJeOmKt5W3cddSHS2bSbrBK+Twn+iDmIBNGBhQt/fW3p7A== Archived-At: Subject: Re: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06 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, 23 Aug 2017 15:28:43 -0000 Hey Luis, As we are updating the draft for last call comment, here are responses to your comments. > *Specific comments* > > - There are several sentences along the document trying to define the scope of > service model in the context of IETF. These are: (1) in Terms and Concepts, for > Service, "... A service in the context of this document (sometimes called a > Network Service) is some form of connectivity between customer sites and the > Internet, or between customer sites across the network operator's network and > across the Internet"; (2) section 5, first bullet, "The services we are discussing are > services provided by network operators to customers ... network operators may > offer value-added services as well as network connection services to their > customers."; (3) section 6.4, "The IETF's work on service models is typically > smaller offering a simple, self-contained service YANG module". > Since in the abstract it is stated that "This document briefly sets out the scope of > and purpose of an IETF service model", probably the best would be to include at > the very beginning a clear sentence with such definition, in order to focus the > reader. OK. That is easy to add. In summary, a service model is a formal representation of the data elements that describe a network service as that service is described to or requested by a customer of a network operator. Details included in the service model include a description of the service as experienced by the customer, but not features of how that service is delivered or realized by the service provider. > - In abstract: "... details of how network protocols and devices are engineered to > deliver a service are captured in other models that are not exposed through the > Customer-Provider Interface" <-- Thinking on recursiveness, the Customer- > Provide Interface can require low-level details or models. In other words, when a > Network Operator is Customer of another Network Operator, what kind of > interface would you consider for that relationship? For me, recursion does not add detail. So, a network operator that engages with another network operator as a customer could do so exactly using the service model. If the relationship is internal to a commercial organisation then it is possible that the interface will be more transparent. It is also true that if the recursion happens lower down (e.g., at the service delivery interface) then more details are exposed. I don't believe that any of this has direct bearing on this document, but I can see that there may be space for more architectural debate about how SDN systems are constructed. MEF, ETSI, and TMF seem to be having this sort of discussion. > - Figure 2: in contrast with Figure 3, where would be positioned here the Service > Delivery models? Should it be assumed a collapse of functionality in the > Orchestrator of Fig. 2 including both Service and Network Orchestrator? Would > be those models internal? Maybe it could be convenient to reflect also in Fig. 2 > both Service Delivery and Network Configuration models, for consistency. I think that is exactly the point. The "traditional" SDN approach shown in Figure 2 makes it hard to place these different models in context, so we introduce an extended view in Figure 3. > - In section 4, below Fig. 2: "This means that the service request must be mapped > to the orchestrator's view, and this mapping may include a choice of which > networks and technologies to use depending on which service features have > been requested." < -- Such mapping is performed by the Orchestrator itself, > right? So maybe the sentence can be rephrased (e.g., ... the service request must > be mapped by the orchestrator ...). Yeah. OK. > - Figure 3. The Customer Service model in segment (a) would be probably > something else than a connectivity/transport service, even though parts of such > service request are out of scope of IETF. I mean, e.g. a Network Service > Descriptor in NFV. So the Service Orchestrator purpose can be broader than what > is the scope of IETF. This can be maybe clarified. It is true that there is a broader architectural picture sitting behind this. One that includes the NFV features and might be modeled after the ETSI NFV work. As you note, those features are out of scope of the IETF. And this document is quite clear that its scope is to discuss the IETF's use of service models. As I said above, I can see that there may be space for a document discussing a wider architecture. That would probably not be an IETF document, but it could go to the NFVRG. > - Figure 3. As part of the figure or in the text description, it would be nice to have > hints about how recursiveness or east/west relationships (for multiple > administrative domains) are mapped to model categories here. The L3SM work talks a little about multi-operator service delivery, but this is handled in a relatively simplistic way because the interface between operators is a complex commercial relationship and the involvement of customers in that relationship is beyond complex. I think we can talk about a multi-network solution where those networks are all under the control of one service provider. And I think this document does that OK (although I'd be happy to hear specific suggestions for improvement) by the text you suggested to be modified, above. The orchestrator must map the service request to its view, and this mapping may include a choice of which networks and technologies to use depending on which service features have been requested. This, of course, does not speak to an east/west relationship, but to a coordinated north/south relationship. > - Section 5, bullets about Commercial terms and SLAs. Maybe it can be > convenient to explicitly say that they are out of the scope. It is mentioned that is > hard to standardize this, but no assertive indication if both are out of the scope. Yes. Good idea. Added text to both bullets. > - Section 6: "... interface between the Service Orchestrator or OSS/BSS ...". Does > it apply as well to Fig. 3? If so, maybe it would be nice also to include in Fig. 3 for > consistency. This is already shown in Figure 3. Perhaps something is not clear in that figure do we will add a second label (b) on the communication between OSS/BSS and Network Orchestrator. > - Figure 4. I think that the figure it is not clear at all. There is a mix of functional > elements (e.g. Service Orchestrator, OSS/BSS) with models. Probably a more > homogeneous figure could be better. Figure 4 comes from RFC 8199 (with only minor modifications) and is not in scope for us to change. Probably gets clearer with several readings of RFC 8199 which is a normative reference. > - Section 6.2: it would be nice to make clear what of the sample models can be > categorized as Service Delivery model, and what of them can be categorized as > network Element (or device) models. :-) No, I don't plan to walk into that minefield! Well, not in this document that is not actually about either of those categories of model. In fact, the reason why we grouped all of these models into one section was because we didn't see rapid convergence (even among the authors of those documents) and didn't want to get distracted from the purpose of this document. > - MEF work is mentioned in section 6.4. I think it would be necessary to > cover/describe some other initiatives like the one of ETSI NFV with respect to > Network Service Descriptors. In earlier revisions of this draft we had a lot more text about the MEF architecture and made attempts to compare and draw some parallels. But over time we discovered that that wasn't so easy so we collapsed the section into something quite simple that gives the reference and states that the approaches fill a similar space but are different. We could easily include a similar section on ETSI NFV, but: - Someone else would have to write it as I'm not familiar with that work - I am very cautious about attempting to reach completeness with regard to all other approaches. Fundamentally, we are writing about IETF service models. > - Section 6.4: "This does not invalidate either approach, but only observes that > they are different." More than different, MEF as described here is broader in > scope. Maybe the sentence can be rephrased in this sense. You can't be "more than different". The text already summarises the breadth of scope of the MEF work and says that "the IETF's work on service models is typically smaller offering a simple, self-contained service YANG module". I think that this cover the point you wanted made and that we don't want to get into any further comparison. > - Section 7.2: it is not clear if policies are considered or not as part of the scope of > the customer service models. Difficulties on identifying common policies for the > operators are mentioned. But similar situation is also mentioned in section 7.3 > with the result of identifying common parametrization after working on it. So > maybe it can be mentioned that such kind of work is required, instead of not > covering policies at all. Right. Like the bullets in Section 5 that you mentioned, this will be clarified. > - Section 8: the interface between Service Orchestrator and Network > Orchestrator can be also external, and then security measures should be applied. Agreed. > - Section 9, last paragraph: Reporting is essential for SLAs (monitoring) and > accounting / billing (resource usage). But it seems (as mentioned before in the > document) that commercial terms and SLAs are not part of the customer service > models. Then, if reporting is included as part of the customer service model, as > suggested by this paragraph, it is apparently inconsistent with the fact of not > having the ways of requesting SLAs and billing, but having the necessary > information for that being reported (in other words, how can I express what > information is of interest for me if I cannot express SLAs or commercial terms?). You're right. Monitoring information is on a similar level to SLA description (although personally I've never quite trusted the service provider's reports of performance as evidence that they are meeting the SLA :-). This text needs to be treated the same way as the bullet you pointed to in section 5, and we'll do that. > *Editorial comments* > > - In abstract: RFC 8049 should be included between brackets. Well, actually, no. There should be no citations in an Abstract because that piece of text must be able to stand alone. > - In section 2, Terms and concepts: for Network Operator -> it is mentioned that > "The term is also used to refer to an individual who performs operations and > management on those networks." <-- Since it is not used with this meaning in the > text, I would remove that clarification to avoid ambiguity. Could catch. And we previously fixed the ambiguity by saying "human operator" when we needed to. > - In section 2, Terms and concepts: for Data Model -> the following sentence > seems to be editorial, maybe it can be removed: "so it may be helpful to quote > some text to give context within this document." Yup. > - Section 6.2 < -- Probably it would be better to separate Service Delivery from > Network Element models in different sections, with sample models referred As above. The authors really don't want to go there. > - Same section. Network Element model is introduced here for 1st time. In figure > 3 it is referred as device configuration model. It would be better to have an > homogeneous naming. Well, "Network Element model" shows in 6.1 and comes from RFC 8199. "Device models" comes from draft-ietf-l2sm-l2vpn-service-model. So we're stuck with both terms, but I've added text to help with the terminology mapping. > - Section 9, first sentence: "... related to network management." -> "... related to > network management and control." OK Many thanks for your really helpful review. Adrian From nobody Thu Aug 24 14:02:49 2017 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 2E84B1323A3; Thu, 24 Aug 2017 14:02:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsawg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150360856815.15052.9956488039578006197@ietfa.amsl.com> Date: Thu, 24 Aug 2017 14:02:48 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-service-model-explained-02.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, 24 Aug 2017 21:02:48 -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 : Service Models Explained Authors : Qin Wu Will Liu Adrian Farrel Filename : draft-ietf-opsawg-service-model-explained-02.txt Pages : 22 Date : 2017-08-24 Abstract: The IETF has produced many data 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 Three Virtual Private Network Service Model 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 models that are not exposed through the Customer-Provider Interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-service-model-explained-02 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-model-explained-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-model-explained-02 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 Thu Aug 24 14:28:05 2017 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 9DA4D120720; Thu, 24 Aug 2017 14:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 oyHC9tEcGXO7; Thu, 24 Aug 2017 14:28:01 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498A513218E; Thu, 24 Aug 2017 14:28:01 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7OLRwwl028877; Thu, 24 Aug 2017 22:27:58 +0100 Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7OLRvJH028865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2017 22:27:58 +0100 Reply-To: From: "Adrian Farrel" To: Cc: Date: Thu, 24 Aug 2017 22:27:50 +0100 Message-ID: <06ef01d31d1f$d7e5a720$87b0f560$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdMdH9SSXNue5r8BRMS42Iy2rLsiKw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23280.003 X-TM-AS-Result: No--13.094-10.0-31-10 X-imss-scan-details: No--13.094-10.0-31-10 X-TMASE-MatchedRID: Iws/ZZZHCofXFDY6Be2LleBKa0pUJhagmru3TC/mLU61eX0jEQ9c6mlb b2DwZL4D48CHU6S1ISHOCRsgJ4DzkVcotqvUhZyqkkRQ7aojOUt6i0kxz7SsQiQmbjFvb7/Z5lt DD1Xe9ZvJ6HLqrzpDeJ32qYgzLO4cjEoe6+qhWGOp4G6k2AuBh+iZcG9oG7pOd71AOvz4tNyzI9 xgBJUBhDx1aPrla0Wk6ORL6NYVbbZ/dZAjNXEbFvzu9Lw9C7fAELbqrOgWzydCOsFqnOK3lkDXS sSRElNr0mSf2p0moVsGMk4xUJf2Co4a2rhHAtuZvHKClHGjjr0hmbYg1ZcOnmTYnZ5/c13f9Os/ l7x5zsG36h2hK5rvdpGTpe1iiCJqtD9qpBlNF8pWdFebWIc3VsRB0bsfrpPIfiAqrjYtFiSliEU oieXEDU2IrDSuN7KB34foUYnqaG24G2e5Udtkvn7cGd19dSFd Archived-At: Subject: [OPSAWG] Post last call revision: draft-ietf-opsawg-service-model-explained-02.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, 24 Aug 2017 21:28:03 -0000 Hi chairs, Think we have addressed all open issues. Back to you :-) Adrian > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: 24 August 2017 22:03 > To: i-d-announce@ietf.org > Cc: opsawg@ietf.org > Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-service-model-explained-02.txt > > > 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 : Service Models Explained > Authors : Qin Wu > Will Liu > Adrian Farrel > Filename : draft-ietf-opsawg-service-model-explained-02.txt > Pages : 22 > Date : 2017-08-24 > > Abstract: > The IETF has produced many data 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 Three Virtual Private Network Service Model > 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 models that are > not exposed through the Customer-Provider Interface. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-service-model-explained-02 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-model- > explained-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-model-explained-02 > > > 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/ > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Aug 24 18:03:47 2017 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 8773D124B18; Thu, 24 Aug 2017 18:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 KeMMiuMNBSew; Thu, 24 Aug 2017 18:03:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B878A1329D5; Thu, 24 Aug 2017 18:03:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNH02591; Fri, 25 Aug 2017 01:03:39 +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.301.0; Fri, 25 Aug 2017 02:03:38 +0100 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.0235.001; Fri, 25 Aug 2017 09:03:31 +0800 From: Tianran Zhou To: "adrian@olddog.co.uk" , "opsawg-chairs@ietf.org" CC: "opsawg@ietf.org" Thread-Topic: Post last call revision: draft-ietf-opsawg-service-model-explained-02.txt Thread-Index: AdMdH9SSXNue5r8BRMS42Iy2rLsiKwAHewYw Date: Fri, 25 Aug 2017 01:03:24 +0000 Message-ID: References: <06ef01d31d1f$d7e5a720$87b0f560$@olddog.co.uk> In-Reply-To: <06ef01d31d1f$d7e5a720$87b0f560$@olddog.co.uk> 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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.599F776C.002C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dde2193c8006bb6e392ae8d2da0c8c37 Archived-At: Subject: Re: [OPSAWG] Post last call revision: draft-ietf-opsawg-service-model-explained-02.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, 25 Aug 2017 01:03:45 -0000 Great! Will work on the shepherd write up. Tianran > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, August 25, 2017 5:28 AM > To: opsawg-chairs@ietf.org > Cc: opsawg@ietf.org > Subject: Post last call revision: > draft-ietf-opsawg-service-model-explained-02.txt >=20 > Hi chairs, >=20 > Think we have addressed all open issues. >=20 > Back to you :-) >=20 > Adrian >=20 > > -----Original Message----- > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: 24 August 2017 22:03 > > To: i-d-announce@ietf.org > > Cc: opsawg@ietf.org > > Subject: [OPSAWG] I-D Action: > > draft-ietf-opsawg-service-model-explained-02.txt > > > > > > 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 : Service Models Explained > > Authors : Qin Wu > > Will Liu > > Adrian Farrel > > Filename : draft-ietf-opsawg-service-model-explained-02.txt > > Pages : 22 > > Date : 2017-08-24 > > > > Abstract: > > The IETF has produced many data 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 Three Virtual Private Network Service Model > > 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 models that ar= e > > not exposed through the Customer-Provider Interface. > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-expla > > ined/ > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-opsawg-service-model-explained- > > 02 > > > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-model- > > explained-02 > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-service-model-expl > > ained-02 > > > > > > 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/ > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg From nobody Fri Aug 25 12:14:22 2017 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 1575F132C39 for ; Fri, 25 Aug 2017 12:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqiHAGMD4d82 for ; Fri, 25 Aug 2017 12:14:18 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 5BACE132C21 for ; Fri, 25 Aug 2017 12:14:17 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id z132so5086064wmg.1 for ; Fri, 25 Aug 2017 12:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=2KCCDKlClfKhPi9OqMtrOqczBXlbgcJWOIHUhRTqp88=; b=FeAeFl+59n0IiNbL7cdsQgdrYi7GBcRdUa04ECMBrRxr542KL3HX7fLcMIGBAL9sNf fu0xUTNTy4FHPqlwd2iRzZ7Om18cPI0nTqos2r4P9CxfBON9lx+uOJfNCXJq5OLNw2ip Mwz37FSNPQuy7Dp1d/qbH3ADwIclulk5M99M9BiuSD05wfJkIXo867mid6a4LYqcBbQJ Vb90I3zGHEMd7JQC/fxQcMOWeJbsK3KX95BvYKO9haGGEWDueF1NqpauPBCgiQbrpMch D5AOD+MXDuPrlwghpuwg2+CBi69QUzprzrdqpkq+iIpmpEDCl4GMNP1Q+T9g28jFi3u2 MARA== 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=2KCCDKlClfKhPi9OqMtrOqczBXlbgcJWOIHUhRTqp88=; b=uE5INslIt5s5LlP87RfFLkh3xbmIgBn0pKhVBmzssGLUH82KpUsZYLdhDm0fcAK9Sp zGOnuka4pbQqDYzCuZG+qsQoPhW8sP7VYqJoZAGKQ0D335uOridHHk8snDBuhGHaXUIQ yg+FAtXTFvZhD8WhAk/xs+7cOLv8FL39/BkrafHSgvA+PYs8RZ9ZbU1nqPBNQRNfqpcZ NE5zSw4JQonrXysxha6Wx6o8dTECU9ijf0rVGvuK+mi+N77jh4vug4j32QDe4reRucBm OQZG4p3fMAmAwmp8VuwZoEwu+s5Ycf9BtLRUbJWjCGkix0/cXY5haH6l6ow37OMFBHT2 Yl8A== X-Gm-Message-State: AHYfb5jYqoBcBWcUc7DaFg1RX70dHxfuXgDukN9f0PQQv3YyMmTwPVI4 kbTneM0qfFDbI1CS/3pFaKutvOYkwsKqSWqrRw== X-Received: by 10.28.107.69 with SMTP id g66mr242838wmc.119.1503688454983; Fri, 25 Aug 2017 12:14:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Fri, 25 Aug 2017 12:13:34 -0700 (PDT) From: Warren Kumari Date: Fri, 25 Aug 2017 15:13:34 -0400 Message-ID: To: opsawg@ietf.org, "rfc-ise@rfc-editor.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [OPSAWG] Looking for a reviewer for draft-daveor-cgn-logging 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, 25 Aug 2017 19:14:20 -0000 Hi there all, Nevil Brownlee (the Independent Submissions Editor) is looking for a few reviewers for the "Approaches to Address the Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies" ( draft-daveor-cgn-logging ) document. The abstract is: The use of large-scale IP address sharing technologies (commonly known as "carrier-grade NAT") presents a challenge for law enforcement agencies due to the fact that incoming source port information is not routinely logged by Internet-facing servers. The absence of this information means that it is becoming increasingly difficult for law enforcement agencies to identify suspects in criminal activity online. This document considers the reasons why source port information is not routinely logged by Internet-facing servers and proposes some immediate-term actions that can be taken to help improve the situation. A deployment maturity model has been developed and a study of the support for logging incoming source port information in common server software is also presented." I'm looking for some folk to step up an volunteer to help review this document; if you've be willing to, please let myself, Nevil, or the whole list know. Thanks, and much appreciated, W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sun Aug 27 06:29:51 2017 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 03E0A13219E; Sun, 27 Aug 2017 06:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville To: Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150384057895.866.9675653302394719026@ietfa.amsl.com> Date: Sun, 27 Aug 2017 06:29:39 -0700 Archived-At: Subject: [OPSAWG] Secdir early review of draft-ietf-opsawg-mud-08 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, 27 Aug 2017 13:29:39 -0000 Reviewer: Adam Montville Review result: Has Issues Hi. I am the assigned SECDIR reviewer for this document's early review reuqest. What follows is what I would write if this were a last call review, more or less. The summary of the review is ready with (potential) issues and nits. The draft is interesting in that it seeks to define a mechanism for devices to self-identify in a trusted manner, so that the infrastructure in which the devices operate may appropriately manage security-related configurations pertaining to those devices. The examples provided are exclusively network flow realted, but extension points are provided for future capabilities. The mechanism is defined as a Manufacturer Usage Description, as expressed in a file containing a YANG-based JSON serialization. This file is obtained from a device-provided URL, which is trusted to varying degrees and communitacted to the infrastructure in one of several different ways (i.e. via DHCP, 802.1AR, 802.1AB). Thus, the device emits a URL via one of the identified methods, and the URL is used to obtain the MUD, which can then be interpreted and appropriate action taken. The security consideraitons appear well-thought and is worth a read. This seems like a solution intended to take time to reach full potential, given that there are devices deployed in the real world that know nothing about this, and that there are different trust mechanisms at play. The intent seems less about perfection and more about moving the needle, which seems to be the right approach. Finally, I found myself wondering if this type of appraoch - communicating intended use - could be extended to software installed on general purpose devices. For example, it would be interesting to consider how a given installed software package could communicate not only its intended use, but it's preferred configuration. Some questions to consider (these are potential issues): At the top of page 9, the draft describes controller behavior for mobile devices - configurations should be removed when the device is removed. Does this apply also to intermittent devices? When would a device be considered "removed" instead of simply powered down? Also, when reading that paragraph I began wondering about the load on Web servers serving MUD files - not that this draft should say anything about it, but that it's something manufacturers are going to have to consider and account for. Is a stronger statement needed on the first bullet of section 4? Should it read: Anything not explicitly permitted MUST be denied? Similarly for other requirements in MUD file processing. At about this point, I began wondering if additional security considerations may be required for the controller. Section 9.2 describes DHCP server behavior, and is written in a manner presuming the DHCP server knows what's happening with these building blocks. I am not a DHCP expert, so there may be something in DHCP instructing a server to ignore everything it doesn't understand, but if that is not the case, then what is expected to happen when DHCP is not expecting these options and is not going to ignore them? Nits follow: First paragraph of section 1.5: s/another example might to follow/another example might be to follow/ Recommend the following for definition of Thing: the device emitting a MUD URL. Suggest striking last two sentences of Manufacturer definition, as irrelevant. Is there a way to make the ASCII art in section 1.7 a little cleaner? One possibility is to move the right side of the bounding box to the left by two or three places. Also, the arrows to the line text isn't necessary (e.g. "----->get URL->" is cleaner as "---get URL--->"). Second bullet on page 11: s/other otherwise/otherwise/ Should there be a newline after "" at the start of section 6? On page 17: s/end(ed)/end(s\/ed)/ Basically, the sentence without "ended" should read, "Information about when support ends, and when to refresh." Vertial spacing could be improved for the first bit in section 9, so that the look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_v6 Section 11, first sentence: s/link layer protocols/link layer protocol/ From nobody Mon Aug 28 01:32:10 2017 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 1BBAA132CEF; Mon, 28 Aug 2017 01:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Qv2a5GOU4MHI; Mon, 28 Aug 2017 01:32:00 -0700 (PDT) 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 868AF132025; Mon, 28 Aug 2017 01:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18653; q=dns/txt; s=iport; t=1503909120; x=1505118720; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=jKDtCfQWBoCvmqacSDM7y9sirWQAuzC/6oAhU0e3fio=; b=aykh8zZDPzqL0Oinj6hHfEt0Zq004IoZKv5pDi1qjIfcqZVrRqUNQsIy 4paE1HevKz/iVnOBR3QBFyvHnhuBe4Z9AS6zET0FerJ4ezDnSKjLD+PZ5 FmP3xII+Bgbs+qnINUXsyHJ9io93LeL+iZGwHBrlNfQZCV95R8p1HeL8b M=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPAQD006NZ/xbLJq1bGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm+GW4oddJESkGiFPg6CBAeFQAKELhgBAgEBAQEBAQFrKIUZAQQBI1Y?= =?us-ascii?q?FCwsONAICVwYBDAgBAYolCLIRgicnizIBAQEBAQEBAwEBAQEBAQEBAQEBDg+DK?= =?us-ascii?q?oUzK4J9hE4PAoMpgkIfBYoNhxSHCYg6hDSCIYRXiRqCEoVmg1mHF4l0jEkfOIE?= =?us-ascii?q?NMiEIHBVJhx0+iF2CQQEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,440,1498521600"; d="asc'?scan'208,217";a="654230079" 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; 28 Aug 2017 08:31:55 +0000 Received: from [10.61.198.200] ([10.61.198.200]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7S8VsC8018749; Mon, 28 Aug 2017 08:31:54 GMT To: Martin Bjorklund , yang-doctors@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org References: <150340909415.6001.14045177084948571272@ietfa.amsl.com> From: Eliot Lear Message-ID: Date: Mon, 28 Aug 2017 10:31:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150340909415.6001.14045177084948571272@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ms80gB9GTWU6M7pfNQSOrbCm6J39Nenac" Archived-At: Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-mud-08 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, 28 Aug 2017 08:32:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ms80gB9GTWU6M7pfNQSOrbCm6J39Nenac Content-Type: multipart/mixed; boundary="Wp4IGo5rKcnlqcO8gmEmVG1WhuX67JoGm"; protected-headers="v1" From: Eliot Lear To: Martin Bjorklund , yang-doctors@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org Message-ID: Subject: Re: Yangdoctors early review of draft-ietf-opsawg-mud-08 References: <150340909415.6001.14045177084948571272@ietfa.amsl.com> In-Reply-To: <150340909415.6001.14045177084948571272@ietfa.amsl.com> --Wp4IGo5rKcnlqcO8gmEmVG1WhuX67JoGm Content-Type: multipart/alternative; boundary="------------3EEC0AC16D5F76F97C91F768" Content-Language: en-US This is a multi-part message in MIME format. --------------3EEC0AC16D5F76F97C91F768 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Martin, Thanks for performing the review. Please see responses below. =C2=A0On 8/22/17 3:38 PM, Martin Bjorklund wrote: > Reviewer: Martin Bjorklund > Review result: Ready with Issues > > Hi, > > I am the assigned YANG doctors reviewer for this document. Here are > my comments: > > > o Section 2 says: > > The MUD file is limited to the serialization of a > small number of YANG schema, including the models specified in the > following documents: > > o [I-D.ietf-netmod-acl-model] > > o [RFC6991] > > Is the intention that *only* these models are included, or *at > least* these models are included? ONLY. > RFC6991 doesn't define any data nodes, so I don't think it needs to > be listed. =20 Will remove. > I suggest you are a bit more specific, and list: > > o ietf-access-control-list [I-D.ietf-netmod-acl-model] > > o ietf-mud [...] Will do. > o Section 3 uses the term "element" (it is used in other places as > well). YANG uses the term "data node" or "node". Or "YANG data > node". I suggest you use one of these terms, and import the term > in your Terminology section. Will replace. > Also, the YANG module uses the term "element" to refer to "device": > > leaf is-supported { > type boolean; > description > "The element is currently supported > by the manufacturer."; > } > Will correct. > o In your Terminology section you introduce the term "Thing". But > the text often use "device". Maybe use "device" consistently? > Will correct. > o In order to get consistent indentation of the YANG modules, I > suggest you run: > > pyang -f yang ietf-mud.yang > > (and same for ietf-acldns.yang) > We are making some changes, and are making heavy use of pyang --ietf --strict... > o Ensure that description statements contain proper sentences. Also > ensure that the descriptions are descriptive. As an example of the > latter, this is not a good description: > > description > "Which way are we talking about?"; > > In general, I found that the main document had better descriptions > than the YANG module. Consider moving the text from the main > document to the YANG module (this also reduces the risk of > inconsistencies). If don't want to move text, I think you need to > spend some effort on almost all descriptions in the YANG module. As we move toward completion I may ask for your help.=C2=A0 I am nervous = of simply moving chunks of text into the descriptions because I think we have a fairly readable document outside of the model.=C2=A0=C2=A0 I am pe= rfectly happy to copy text in, however. > o In both modules, make sure you have a single revision > statement. Note that in IETF-terms, a revision statement is added > when a new version of the module is publsihed as an RFC (so the > initial RFC would have one revision statement). Ok. > o The "ietf-mud" module is a bit unorthodox; it defines configuration > data nodes, but it is not supposed to be implemented by a normal > NETCONF/RESTCONF server. Rather, it will be instantiated in a JSON > file. I think this should be stated in the description of the > module. > Ok. > o I don't think the feature "mud-acl" is necessary. It is only used > to make the acl augment conditional on the feature. I think that > if this module is supported, the feature is also supported. Or do > you envision implementations of this module that would not support > this feature? If so, maybe you can explain that use case in the > document. Fair point.=C2=A0 This was included in keeping with the acl model's direction, but given that it is already an augment, you're right. > o leaf cache-validity could use a "units" statement: > > units "hours"; > Ok. > o I suggest you rename the grouping "access_lists" to "access-lists" > for consitency. Ok. > o Should any of the leafs in "/metainfo" be mandatory? > Yes.=C2=A0 This has been the subject of considerable discussion. I propo= se to modify the model to include an rc:yang-data statement, as well as t= o make the mud container a presence container. I believe either would al= low us to address this matter. In addition, we'll add a mud-url element = to make it possible for the entry to be self-identifying. This would all= ow for a very simply "uses", should someone want to borrow the model to b= uild out a configuration data store. Indeed, based on these changes, we're attempting to consolidate the # of = containers (or at least avoid an explosion of them). Finally, this leaves open precisely which nodes should be mandatory. To = me, last-update should be mandatory, as well as the mud-url. Joe would l= ike "is-supported" covered, and I am not adverse. I don't think "cache-v= alidity" needs to be mandatory, but rather should have a default value of= 48 hours. =C2=A0 > o The "extensions" leaf-list mentions an IANA registry for > extensions. It would be usefule to mention this registry by name. > > Also, shouldn't this registry be defined in the IANA Considerations > section? Yes. > o Section 3.7 mentions a leaf "packet-direction". There is no such > leaf in the YANG module. There is one called "direction-initiated" > though. This is an artifact of an earlier version that needs to be removed. > But since the "/device" container contains two different ACL sets, > one for "to" and one for "from", is this augmentation really > necessary? Precisely so.=C2=A0 I've updated the working copy. > o The model has: > > leaf local-networks { > type empty; > description > "this string is used to indicate networks > considered local in a given environment."; > > This leaf is of type "empty", but the description says it is a > string. > Also, what is the format of this string? (Hmm, I think the > description is wrong, this should indeed be type empty). > That shouldn't say string.=C2=A0 It's empty. > o Would it be useful with an indication of the revision of "ietf-mud" > that is used as the schema for a MUD file? I.e., something like a > leaf "mud-module-revision" in the "metainfo" container. For what purpose? > o The example in section 8 has some errors, e.g., it has some > camelCase node names. That's corrected. Thanks VERY much again. There are still finishing touches to do to the model, such that it is wel= l documented and easily serialized, given the above changes. Eliot --------------3EEC0AC16D5F76F97C91F768 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
Hi Martin,

Thanks for performing the review.  Please see responses below.

=C2=A0On 8/22/17 3:38 PM, Martin Bjorklund wrote:

Reviewer: Martin Bjorklund
Review result: Ready with Issues

Hi,

I am the assigned YANG doctors reviewer for this document.  Here are
my comments:


o  Section 2 says:

   The MUD file is limited to the serialization of a
   small number of YANG schema, including the models specified in the
   following documents:

   o  [I-D.ietf-netmod-acl-model]

   o  [RFC6991]

   Is the intention that *only* these models a=
re included, or *at
   least* these models are included?

ONLY.

   RFC6991 doesn't define any data nodes, so I don=
't think it needs to
   be listed. =20

Will remove.


I suggest you are a bit more specific, and list:

     o  ietf-access-control-list [I-D.ietf-netmod-acl-model]

     o  ietf-mud [...]

Will do.

o  Section 3 uses the term "element" (it is used in other places as
   well).  YANG uses the term "data node" or "node".  Or "YANG data
   node".  I suggest you use one of these terms, and import the term
   in your Terminology section.

Will replace.

   Also, the YANG module uses the term "element" t=
o refer to "device":

    leaf is-supported {
      type boolean;
      description
        "The element is currently supported
         by the manufacturer.";
    }


Will correct.

o  In your Terminology section you introduce the t=
erm "Thing".  But
   the text often use "device".  Maybe use "device" consistently?


Will correct.


o  In order to get consistent indentation of the Y=
ANG modules, I
   suggest you run:

     pyang -f yang ietf-mud.yang

   (and same for ietf-acldns.yang)


We are making some changes, and are making heavy use=
 of pyang --ietf
--strict...


o  Ensure that description statements contain prop=
er sentences.  Also
   ensure that the descriptions are descriptive.  As an example of the
   latter, this is not a good description:

    description
      "Which way are we talking about?";

   In general, I found that the main document had better descriptions
   than the YANG module.  Consider moving the text from the main
   document to the YANG module (this also reduces the risk of
   inconsistencies).  If don't want to move text, I think you need to
   spend some effort on almost all descriptions in the YANG module.

As we move toward completion I may ask for your help=
=2E=C2=A0 I am nervous of
simply moving chunks of text into the descriptions because I think we
have a fairly readable document outside of the model.=C2=A0=C2=A0 I am pe=
rfectly
happy to copy text in, however.


o  In both modules, make sure you have a single re=
vision
   statement.  Note that in IETF-terms, a revision statement is added
   when a new version of the module is publsihed as an RFC (so the
   initial RFC would have one revision statement).

Ok.

o  The "ietf-mud" module is a bit unorthodox; it d=
efines configuration
   data nodes, but it is not supposed to be implemented by a normal
   NETCONF/RESTCONF server.  Rather, it will be instantiated in a JSON
   file.  I think this should be stated in the description of the
   module.


Ok.


o  I don't think the feature "mud-acl" is necessar=
y.  It is only used
   to make the acl augment conditional on the feature.  I think that
   if this module is supported, the feature is also supported.  Or do
   you envision implementations of this module that would not support
   this feature?  If so, maybe you can explain that use case in the
   document.

Fair point.=C2=A0 This was included in keeping with =
the acl model's
direction, but given that it is already an augment, you're right.

o  leaf cache-validity could use a "units" stateme=
nt:

     units "hours";


Ok.


o  I suggest you rename the grouping "access_lists=
" to "access-lists"
   for consitency.

Ok.

o  Should any of the leafs in "/metainfo" be manda=
tory?


Yes.=C2=A0 This has been the subject of considerable=
 discussion.  I propose to modify the model to include an rc:yang-data st=
atement, as well as to make the mud container a presence container.  I be=
lieve either would allow us to address this matter.  In addition, we'll a=
dd a mud-url element to make it possible for the entry to be self-identif=
ying.  This would allow for a very simply "uses", should someone want to =
borrow the model to build out a configuration data store.

Indeed, based on these changes, we're attempting to consolidate the # of =
containers (or at least avoid an explosion of them).

Finally, this leaves open precisely which nodes should be mandatory.  To =
me, last-update should be mandatory, as well as the mud-url.  Joe would l=
ike "is-supported" covered, and I am not adverse.  I don't think "cache-v=
alidity" needs to be mandatory, but rather should have a default value of=
 48 hours.
=C2=A0

o  The "extensions" leaf-list mentions an IANA reg=
istry for
   extensions.  It would be usefule to mention this registry by name.

   Also, shouldn't this registry be defined in the IANA Considerations
   section?

Yes.

o  Section 3.7 mentions a leaf "packet-direction".  There is no such
   leaf in the YANG module.  There is one called "direction-initiated"
   though.

This is an artifact of an earlier version that needs=
 to be removed.

   But since the "/device" container contains two =
different ACL sets,
   one for "to" and one for "from", is this augmentation really
   necessary?

Precisely so.=C2=A0 I've updated the working copy.

o  The model has:

      leaf local-networks {
        type empty;
        description
          "this string is used to indicate networks
           considered local in a given environment.";

   This leaf is of type "empty", but the description says it is a
   string.

   Also, what is the format of this string?  (Hmm,=
 I think the
   description is wrong, this should indeed be type empty).


That shouldn't say string.=C2=A0 It's empty.

o  Would it be useful with an indication of the re=
vision of "ietf-mud"
   that is used as the schema for a MUD file?  I.e., something like a
   leaf "mud-module-revision" in the "metainfo" container.

For what purpose?

o  The example in section 8 has some errors, e.g., it has some
   camelCase node names.

That's corrected.


Thanks VERY much again.

There are still finishing touches to do to the model, such that it is wel=
l documented and easily serialized, given the above changes.

Eliot
--------------3EEC0AC16D5F76F97C91F768-- --Wp4IGo5rKcnlqcO8gmEmVG1WhuX67JoGm-- --Ms80gB9GTWU6M7pfNQSOrbCm6J39Nenac Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZo9T6AAoJEIe2a0bZ0noz3HEH/AiH43atQSpYPbhpBLCpWqYc OXJOA4WWUZ5o560qZ98KGUAyb3iZDpaL8DTZ8wlpjIKQEwKESncFWu0HUDmFcF7U qgT9UiX/T+jiVrceoGlaIx46Sd2Uj90TnGylA31vzvskmk6XQeT/SO4QbiElDnt6 p54QJ8SlE6uBFtNaaWCqK+sb/8jaiSdKyTzh0IaXlDCEbLbo/5YGmXquMTgWUDni vjtdsLArDtgzLvmN2LMoPnObKof2oARRxU4Uj9KmVdeJSqaslmEnA/FtgBDGtR3L PdOFxqY3lePz7nZL0fkWWONnHhUGtUoEOo0xDjf2ePgIoEHHeRCbW+IbB5YVEio= =/K+6 -----END PGP SIGNATURE----- --Ms80gB9GTWU6M7pfNQSOrbCm6J39Nenac-- From nobody Mon Aug 28 01:54:16 2017 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 DDEC7132358; Mon, 28 Aug 2017 01:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8SdmP0KaIZK5; Mon, 28 Aug 2017 01:54:12 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 71193132A65; Mon, 28 Aug 2017 01:54:11 -0700 (PDT) Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F0261AE02C9; Mon, 28 Aug 2017 10:54:09 +0200 (CEST) Date: Mon, 28 Aug 2017 10:52:42 +0200 (CEST) Message-Id: <20170828.105242.1597048530111501551.mbj@tail-f.com> To: lear@cisco.com Cc: yang-doctors@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org From: Martin Bjorklund In-Reply-To: References: <150340909415.6001.14045177084948571272@ietfa.amsl.com> <150340909415.6001.14045177084948571272@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-mud-08, Re: Yangdoctors early review of draft-ietf-opsawg-mud-08 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, 28 Aug 2017 08:54:15 -0000 Eliot Lear wrote: > Hi Martin, > = > Thanks for performing the review. Please see responses below. > = > =A0On 8/22/17 3:38 PM, Martin Bjorklund wrote: > = > > Reviewer: Martin Bjorklund > > Review result: Ready with Issues > > > > Hi, > > > > I am the assigned YANG doctors reviewer for this document. Here ar= e > > my comments: > > > > > > o Section 2 says: > > > > The MUD file is limited to the serialization of a > > small number of YANG schema, including the models specified in t= he > > following documents: > > > > o [I-D.ietf-netmod-acl-model] > > > > o [RFC6991] > > > > Is the intention that *only* these models are included, or *at > > least* these models are included? > = > ONLY. Ok. The text says "a small number ... including ...". I suggest this is clarified. > > RFC6991 doesn't define any data nodes, so I don't think it needs= to > > be listed. = > = > Will remove. > = > > I suggest you are a bit more specific, and list: > > > > o ietf-access-control-list [I-D.ietf-netmod-acl-model] > > > > o ietf-mud [...] > = > Will do. > = > > o Section 3 uses the term "element" (it is used in other places as= > > well). YANG uses the term "data node" or "node". Or "YANG data= > > node". I suggest you use one of these terms, and import the ter= m > > in your Terminology section. > = > Will replace. > = > > Also, the YANG module uses the term "element" to refer to "devic= e": > > > > leaf is-supported { > > type boolean; > > description > > "The element is currently supported > > by the manufacturer."; > > } > > > Will correct. > = > > o In your Terminology section you introduce the term "Thing". But= > > the text often use "device". Maybe use "device" consistently? > > > Will correct. > = > > o In order to get consistent indentation of the YANG modules, I > > suggest you run: > > > > pyang -f yang ietf-mud.yang > > > > (and same for ietf-acldns.yang) > > > We are making some changes, and are making heavy use of pyang --ietf > --strict... Ok, but --ietf does not check indentation etc. > > o Ensure that description statements contain proper sentences. Al= so > > ensure that the descriptions are descriptive. As an example of = the > > latter, this is not a good description: > > > > description > > "Which way are we talking about?"; > > > > In general, I found that the main document had better descriptio= ns > > than the YANG module. Consider moving the text from the main > > document to the YANG module (this also reduces the risk of > > inconsistencies). If don't want to move text, I think you need = to > > spend some effort on almost all descriptions in the YANG module.= > = > As we move toward completion I may ask for your help.=A0 I am nervous= of > simply moving chunks of text into the descriptions because I think we= > have a fairly readable document outside of the model.=A0=A0 I am perf= ectly > happy to copy text in, however. Ok. > > o In both modules, make sure you have a single revision > > statement. Note that in IETF-terms, a revision statement is add= ed > > when a new version of the module is publsihed as an RFC (so the > > initial RFC would have one revision statement). > = > Ok. > = > > o The "ietf-mud" module is a bit unorthodox; it defines configurat= ion > > data nodes, but it is not supposed to be implemented by a normal= > > NETCONF/RESTCONF server. Rather, it will be instantiated in a J= SON > > file. I think this should be stated in the description of the > > module. > > > Ok. > = > > o I don't think the feature "mud-acl" is necessary. It is only us= ed > > to make the acl augment conditional on the feature. I think tha= t > > if this module is supported, the feature is also supported. Or = do > > you envision implementations of this module that would not suppo= rt > > this feature? If so, maybe you can explain that use case in the= > > document. > = > Fair point.=A0 This was included in keeping with the acl model's > direction, but given that it is already an augment, you're right. > = > > o leaf cache-validity could use a "units" statement: > > > > units "hours"; > > > Ok. > = > > o I suggest you rename the grouping "access_lists" to "access-list= s" > > for consitency. > = > Ok. > = > > o Should any of the leafs in "/metainfo" be mandatory? > > > Yes.=A0 This has been the subject of considerable discussion. I > propose to modify the model to include an rc:yang-data > statement, Ok, but note that this makes your usage of access-lists problematic - if you define "rc:yang-data mud", you cannot have a file with "access-lists" within the "mud" container. I don't know how to solve this... > as well as to make the mud container a presence container. I believe= either would allow us to address this matter. In addition, we'll add = a mud-url element to make it possible for the entry to be self-identify= ing. This would allow for a very simply "uses", should someone want to= borrow the model to build out a configuration data store. > = > Indeed, based on these changes, we're attempting to consolidate the #= of containers (or at least avoid an explosion of them). > = > Finally, this leaves open precisely which nodes should be mandatory. = To me, last-update should be mandatory, as well as the mud-url. Joe w= ould like "is-supported" covered, and I am not adverse. I don't think = "cache-validity" needs to be mandatory, but rather should have a defaul= t value of 48 hours. > =A0 > = > > o The "extensions" leaf-list mentions an IANA registry for > > extensions. It would be usefule to mention this registry by nam= e. > > > > Also, shouldn't this registry be defined in the IANA Considerati= ons > > section? > = > Yes. > = > > o Section 3.7 mentions a leaf "packet-direction". There is no suc= h > > leaf in the YANG module. There is one called "direction-initiat= ed" > > though. > = > This is an artifact of an earlier version that needs to be removed. > = > > But since the "/device" container contains two different ACL set= s, > > one for "to" and one for "from", is this augmentation really > > necessary? > = > Precisely so.=A0 I've updated the working copy. > = > > o The model has: > > > > leaf local-networks { > > type empty; > > description > > "this string is used to indicate networks > > considered local in a given environment."; > > > > This leaf is of type "empty", but the description says it is a > > string. > > Also, what is the format of this string? (Hmm, I think the > > description is wrong, this should indeed be type empty). > > > That shouldn't say string.=A0 It's empty. > = > > o Would it be useful with an indication of the revision of "ietf-m= ud" > > that is used as the schema for a MUD file? I.e., something like= a > > leaf "mud-module-revision" in the "metainfo" container. > = > For what purpose? So that the MUD controller knows how to parse the mud file? OTOH, if it turns out to be necessary, you can add it as a mandatory leaf in a future model. > > o The example in section 8 has some errors, e.g., it has some > > camelCase node names. > = > That's corrected. > = > = > Thanks VERY much again. > = > There are still finishing touches to do to the model, such that it is= well documented and easily serialized, given the above changes. > = > Eliot /martin From nobody Mon Aug 28 02:54:00 2017 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 B0D87132932; Mon, 28 Aug 2017 02:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 8aRBJ9uAKFEJ; Mon, 28 Aug 2017 02:53:58 -0700 (PDT) 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 BA952132811; Mon, 28 Aug 2017 02:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3007; q=dns/txt; s=iport; t=1503914038; x=1505123638; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=1NIFh+QlrJeGecORVSNsA27F1uomxsb9zIaPOxsOUnI=; b=JyU5JczZxHH73T9p2on/jRk+vGmlTLk07PQSAyo/4EIVu3ukDLd3tcsT 0DFdC83EUpYxaKvAEdMD28W3Qz6I+v/V2Kndol4iIsHjPRfsV/5YThwQZ f+6EZa++evgKwSgXjzY5AecCgycy27RnBsQJJMFfoaKsNNbecShPvUs4D I=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAwDN56NZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBiUqLEZBwIpg4B4VAAoQ2FQECAQEBAQEBAWsohRkBBAEjVgULCw4tBwI?= =?us-ascii?q?CVwYNCAEBiiUIsXCCJ4taAQEBAQEBAQMBAQEBAQEBEg+DKoUzKwuCcogIgkIfB?= =?us-ascii?q?ZgqiDqENIIhjXGLUYcXlj01IoENMiEIHBWGFoFQPoseAQEB?= X-IronPort-AV: E=Sophos;i="5.41,441,1498521600"; d="asc'?scan'208";a="655254859" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2017 09:53:53 +0000 Received: from [10.61.198.200] ([10.61.198.200]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7S9rrqC004014; Mon, 28 Aug 2017 09:53:53 GMT To: Martin Bjorklund Cc: yang-doctors@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org References: <150340909415.6001.14045177084948571272@ietfa.amsl.com> <150340909415.6001.14045177084948571272@ietfa.amsl.com> <20170828.105242.1597048530111501551.mbj@tail-f.com> From: Eliot Lear Message-ID: Date: Mon, 28 Aug 2017 11:53:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170828.105242.1597048530111501551.mbj@tail-f.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iTUdKj5bInqGgappmd7oUDr40Da7RgBNm" Archived-At: Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-mud-08, Re: Yangdoctors early review of draft-ietf-opsawg-mud-08 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, 28 Aug 2017 09:54:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iTUdKj5bInqGgappmd7oUDr40Da7RgBNm Content-Type: multipart/mixed; boundary="4GiV0TGcHOToQNdP3wPBbrcg8WQOJUd0u"; protected-headers="v1" From: Eliot Lear To: Martin Bjorklund Cc: yang-doctors@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org Message-ID: Subject: Re: Yangdoctors early review of draft-ietf-opsawg-mud-08,Re: Yangdoctors early review of draft-ietf-opsawg-mud-08 References: <150340909415.6001.14045177084948571272@ietfa.amsl.com> <150340909415.6001.14045177084948571272@ietfa.amsl.com> <20170828.105242.1597048530111501551.mbj@tail-f.com> In-Reply-To: <20170828.105242.1597048530111501551.mbj@tail-f.com> --4GiV0TGcHOToQNdP3wPBbrcg8WQOJUd0u Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Martin, Trimming: On 8/28/17 10:52 AM, Martin Bjorklund wrote: >> ONLY. > Ok. The text says "a small number ... including ...". I suggest this > is clarified. So clarified. > Ok, but --ietf does not check indentation etc. Ok. >> Yes.=C2=A0 This has been the subject of considerable discussion. I >> propose to modify the model to include an rc:yang-data >> statement, > Ok, but note that this makes your usage of access-lists problematic - > if you define "rc:yang-data mud", you cannot have a file with > "access-lists" within the "mud" container. I don't know how to solve > this... That would be quite bad.=C2=A0 Then in the alternative, if we go without rc:yang-data, could we then simply leave the mud container as a presence container?=C2=A0 Given the presence of the MUD-URL this has roughly the concept intended with presence as I understand it. > >> For what purpose? > So that the MUD controller knows how to parse the mud file? OTOH, if > it turns out to be necessary, you can add it as a mandatory leaf in a > future model. ok.=C2=A0 Let's have a think about that one.=C2=A0 If the file is aiming = towards self-describing, then this is a good add. Eliot --4GiV0TGcHOToQNdP3wPBbrcg8WQOJUd0u-- --iTUdKj5bInqGgappmd7oUDr40Da7RgBNm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZo+gxAAoJEIe2a0bZ0nozpM0H/j9WyG/SeVckcpQxJqlwUPk6 76Xxnn0OQIrV3z9DR9gYtAbSzpmJLiq/EyIlMG83p+BwgVdID3JlBAOO2VqbQlQA fQjMwjkZFC2nlwa0FlQ7Bf/3vN15w7cVvU7PShEHQVGT28zgjR5O2DvNuDwzJVAf VkRPIMhI+3zjCKkLyaeh2lL177EVJwNBA3ay7zSWPefJzxnXB5XsgbCGjISypdXo x5LziIocs3pgRy7vH1fGHF2xna34vRQhIZ1psZZ6gy6BYFtM7TBE/Uxslyt6/56m GGtHsof0EnVy8Yc++FM0PcJyE1AkIt7gqqD7/ovePm7rSgiD1Nx8JV8/yUqDxMA= =jQzp -----END PGP SIGNATURE----- --iTUdKj5bInqGgappmd7oUDr40Da7RgBNm-- From nobody Mon Aug 28 07:50:49 2017 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 AE664132C2B; Mon, 28 Aug 2017 07:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 yd7nP64r0F1I; Mon, 28 Aug 2017 07:50:44 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00106.outbound.protection.outlook.com [40.107.0.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D6E1328DB; Mon, 28 Aug 2017 07:50:43 -0700 (PDT) Received: from VI1PR0602MB2942.eurprd06.prod.outlook.com (10.175.25.15) by VI1PR0602MB2797.eurprd06.prod.outlook.com (10.175.21.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Mon, 28 Aug 2017 14:50:40 +0000 Received: from VI1PR0602MB2942.eurprd06.prod.outlook.com ([fe80::55e1:2317:6303:9966]) by VI1PR0602MB2942.eurprd06.prod.outlook.com ([fe80::55e1:2317:6303:9966%14]) with mapi id 15.01.1385.013; Mon, 28 Aug 2017 14:50:40 +0000 From: LUIS MIGUEL CONTRERAS MURILLO To: "adrian@olddog.co.uk" , 'Tianran Zhou' , "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06 Thread-Index: AdLdnqvxxHWykNpkRwaeTXVzD7sXxAJDN94ACo/UplACzmVugAD6HBMg Date: Mon, 28 Aug 2017 14:50:39 +0000 Message-ID: References: <028e01d2e6ab$8cb9ab20$a62d0160$@olddog.co.uk> <04b101d31c24$75a58ae0$60f0a0a0$@olddog.co.uk> In-Reply-To: <04b101d31c24$75a58ae0$60f0a0a0$@olddog.co.uk> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=luismiguel.contrerasmurillo@telefonica.com; x-originating-ip: [195.235.92.36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0602MB2797; 6:JxE7vz0teLT7JWiuWrFdqdLMRA56hTTSd61rZ1mDioZlNpIDha1PpGusY9WCu9k2HrEy75W8fpZkItCXpTXosDCM4tp/ysz3D99dRIVR+jgCX3ePH7qrlYOrGEqAqgi0EM9Ew1kVZUlQiL33+3MJ0lSnkgWCQafGcTzhDQpS73LmWbjbIuyGBRwOWZ8KxvThruqUrYkX/Rb6g3RR3p7zEX02FhJkAcF7D86JkoAs9L19NHswcGetBSmL42amz+IHAOiw9WcMX41E5dGGJTn4pCrmY9AnDb6cIUYWX5wJ155B/6CIYom4XjSXvzaXWIXBbtehbf41/icKBjGQsPiF+g==; 5:6URqDK+RPG9vMuVw4oj4BuFehjso9aiHWE106zzIXzjKaAEJo54fhxWU3nHNLUuJ5ocHXx+h8irWUpePpYg8UTPdzG1TwjBnYTac0k0FmQ6Hfn9YnRsEWZYAHv9oOhryDA3Stw47nzmdOG34j5feHw==; 24:yW3j6bC3zv9gro/xbB+MAf1ltWeR6o6tHfDvGkBlrvc6ZNX5yilxkly4pukKWH2AVcbq23+5yS41E4wUZuFf/Hgna3FkNb4Kv7O2hzIx84U=; 7:AQ1DxMkEHfLZOMDQVRw6gBjVH0xgOHK227GESDujj6Ri6C8+JSU6qnxiYE/QFNZn6PohkVuKwpByBVe27vjAQU9pYLTk0nJLpjy3ObriRP4ZnJV16hAzApYs2UwQy5Rw8Mho0sW/6VpvcF6D1VUyDPnNavuMxNlrJEGsOtjMmkakU7ZYlTxdHa+/Z3siYMM6QeH1UbG/APdpkBuE7URFTWpZtgVx5rQR1jsvpWNWBtE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7324d646-e414-496e-687d-08d4ee2426a5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0602MB2797; x-ms-traffictypediagnostic: VI1PR0602MB2797: x-exchange-antispam-report-test: UriScan:(40392960112811)(20558992708506)(72170088055959)(192374486261705)(131327999870524)(50582790962513)(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0602MB2797; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0602MB2797; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(51914003)(66654002)(51444003)(199003)(59124004)(40134004)(25724002)(189002)(50986999)(2900100001)(106356001)(6246003)(14454004)(2906002)(7696004)(33656002)(2501003)(305945005)(5250100002)(229853002)(86362001)(81166006)(74316002)(6436002)(6506006)(81156014)(8936002)(8676002)(54356999)(2950100002)(76176999)(5660300001)(66066001)(7736002)(101416001)(97736004)(189998001)(105586002)(230783001)(68736007)(53936002)(25786009)(93886005)(9686003)(3660700001)(3280700002)(99286003)(6116002)(53346004)(478600001)(3846002)(102836003)(55016002)(4326008)(9010500006); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0602MB2797; H:VI1PR0602MB2942.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 14:50:39.9596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0602MB2797 Archived-At: Subject: Re: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-explained-06 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, 28 Aug 2017 14:50:47 -0000 Hi Adrian, Sorry for my late response. Thanks for the clarifications. They are fine to= me. Best regards Luis -----Mensaje original----- De: Adrian Farrel [mailto:adrian@olddog.co.uk] Enviado el: mi=E9rcoles, 23 de agosto de 2017 17:28 Para: LUIS MIGUEL CONTRERAS MURILLO ; 'Tianran Zhou' ; opsawg@ietf.org CC: opsawg-chairs@ietf.org Asunto: RE: [OPSAWG] WG adoption poll for draft-wu-opsawg-service-model-exp= lained-06 Hey Luis, As we are updating the draft for last call comment, here are responses to y= our comments. > *Specific comments* > > - There are several sentences along the document trying to define the > scope of service model in the context of IETF. These are: (1) in Terms > and Concepts, for > Service, "... A service in the context of this document (sometimes > called a Network Service) is some form of connectivity between > customer sites and the Internet, or between customer sites across the > network operator's network and across the Internet"; (2) section 5, > first bullet, "The services we are discussing are > services provided by network operators to customers ... network > operators may offer value-added services as well as network connection > services to their customers."; (3) section 6.4, "The IETF's work on > service models is typically smaller offering a simple, self-contained ser= vice YANG module". > Since in the abstract it is stated that "This document briefly sets > out the scope of > and purpose of an IETF service model", probably the best would be to > include at > the very beginning a clear sentence with such definition, in order to > focus the > reader. OK. That is easy to add. In summary, a service model is a formal representation of the data el= ements that describe a network service as that service is described to or re= quested by a customer of a network operator. Details included in the service= model include a description of the service as experienced by the customer, = but not features of how that service is delivered or realized by the service = provider. > - In abstract: "... details of how network protocols and devices are engineered to > deliver a service are captured in other models that are not exposed > through the > Customer-Provider Interface" <-- Thinking on recursiveness, the > Customer- Provide Interface can require low-level details or models. > In other words, when a > Network Operator is Customer of another Network Operator, what kind of > interface would you consider for that relationship? For me, recursion does not add detail. So, a network operator that engages = with another network operator as a customer could do so exactly using the s= ervice model. If the relationship is internal to a commercial organisation then it is pos= sible that the interface will be more transparent. It is also true that if the recursion happens lower down (e.g., at the serv= ice delivery interface) then more details are exposed. I don't believe that any of this has direct bearing on this document, but I= can see that there may be space for more architectural debate about how SD= N systems are constructed. MEF, ETSI, and TMF seem to be having this sort o= f discussion. > - Figure 2: in contrast with Figure 3, where would be positioned here > the Service > Delivery models? Should it be assumed a collapse of functionality in > the Orchestrator of Fig. 2 including both Service and Network > Orchestrator? Would be those models internal? Maybe it could be convenien= t to reflect also in Fig. 2 > both Service Delivery and Network Configuration models, for consistency. I think that is exactly the point. The "traditional" SDN approach shown in = Figure 2 makes it hard to place these different models in context, so we in= troduce an extended view in Figure 3. > - In section 4, below Fig. 2: "This means that the service request > must be mapped > to the orchestrator's view, and this mapping may include a choice of > which networks and technologies to use depending on which service > features have been requested." < -- Such mapping is performed by the > Orchestrator itself, right? So maybe the sentence can be rephrased > (e.g., ... the service request must > be mapped by the orchestrator ...). Yeah. OK. > - Figure 3. The Customer Service model in segment (a) would be > probably something else than a connectivity/transport service, even > though parts of such > service request are out of scope of IETF. I mean, e.g. a Network > Service Descriptor in NFV. So the Service Orchestrator purpose can be > broader than what > is the scope of IETF. This can be maybe clarified. It is true that there is a broader architectural picture sitting behind thi= s. One that includes the NFV features and might be modeled after the ETSI NFV = work. As you note, those features are out of scope of the IETF. And this document= is quite clear that its scope is to discuss the IETF's use of service mode= ls. As I said above, I can see that there may be space for a document discussin= g a wider architecture. That would probably not be an IETF document, but it= could go to the NFVRG. > - Figure 3. As part of the figure or in the text description, it would > be nice to have > hints about how recursiveness or east/west relationships (for multiple > administrative domains) are mapped to model categories here. The L3SM work talks a little about multi-operator service delivery, but thi= s is handled in a relatively simplistic way because the interface between o= perators is a complex commercial relationship and the involvement of custom= ers in that relationship is beyond complex. I think we can talk about a multi-network solution where those networks are= all under the control of one service provider. And I think this document d= oes that OK (although I'd be happy to hear specific suggestions for improve= ment) by the text you suggested to be modified, above. The orchestrator must map the service request to its view, and this mapping may include a choice of which networks and technologies to use depending on which service features have been requested. This, of course, does not speak to an east/west relationship, but to a coor= dinated north/south relationship. > - Section 5, bullets about Commercial terms and SLAs. Maybe it can be > convenient to explicitly say that they are out of the scope. It is > mentioned that is > hard to standardize this, but no assertive indication if both are out > of the scope. Yes. Good idea. Added text to both bullets. > - Section 6: "... interface between the Service Orchestrator or OSS/BSS .= ..". Does > it apply as well to Fig. 3? If so, maybe it would be nice also to > include in Fig. 3 for > consistency. This is already shown in Figure 3. Perhaps something is not clear in that f= igure do we will add a second label (b) on the communication between OSS/BS= S and Network Orchestrator. > - Figure 4. I think that the figure it is not clear at all. There is a > mix of functional > elements (e.g. Service Orchestrator, OSS/BSS) with models. Probably a > more homogeneous figure could be better. Figure 4 comes from RFC 8199 (with only minor modifications) and is not in = scope for us to change. Probably gets clearer with several readings of RFC 8199 which is a normativ= e reference. > - Section 6.2: it would be nice to make clear what of the sample > models can be categorized as Service Delivery model, and what of them > can be categorized as network Element (or device) models. :-) No, I don't plan to walk into that minefield! Well, not in this document that is not actually about either of those categ= ories of model. In fact, the reason why we grouped all of these models into= one section was because we didn't see rapid convergence (even among the au= thors of those documents) and didn't want to get distracted from the purpos= e of this document. > - MEF work is mentioned in section 6.4. I think it would be necessary > to cover/describe some other initiatives like the one of ETSI NFV with > respect to Network Service Descriptors. In earlier revisions of this draft we had a lot more text about the MEF arc= hitecture and made attempts to compare and draw some parallels. But over ti= me we discovered that that wasn't so easy so we collapsed the section into = something quite simple that gives the reference and states that the approac= hes fill a similar space but are different. We could easily include a similar section on ETSI NFV, but: - Someone else would have to write it as I'm not familiar with that work - I am very cautious about attempting to reach completeness with regard to = all other approaches. Fundamentally, we are writing about IETF service mode= ls. > - Section 6.4: "This does not invalidate either approach, but only > observes that > they are different." More than different, MEF as described here is > broader in scope. Maybe the sentence can be rephrased in this sense. You can't be "more than different". The text already summarises the breadth= of scope of the MEF work and says that "the IETF's work on service models = is typically smaller offering a simple, self-contained service YANG module"= . I think that this cover the point you wanted made and that we don't want to= get into any further comparison. > - Section 7.2: it is not clear if policies are considered or not as > part of the scope of > the customer service models. Difficulties on identifying common > policies for the > operators are mentioned. But similar situation is also mentioned in > section 7.3 > with the result of identifying common parametrization after working on > it. So maybe it can be mentioned that such kind of work is required, > instead of not covering policies at all. Right. Like the bullets in Section 5 that you mentioned, this will be clari= fied. > - Section 8: the interface between Service Orchestrator and Network > Orchestrator can be also external, and then security measures should > be applied. Agreed. > - Section 9, last paragraph: Reporting is essential for SLAs > (monitoring) and accounting / billing (resource usage). But it seems > (as mentioned before in the > document) that commercial terms and SLAs are not part of the customer > service models. Then, if reporting is included as part of the customer > service model, as > suggested by this paragraph, it is apparently inconsistent with the > fact of not > having the ways of requesting SLAs and billing, but having the > necessary information for that being reported (in other words, how can > I express what information is of interest for me if I cannot express > SLAs or commercial terms?). You're right. Monitoring information is on a similar level to SLA descripti= on (although personally I've never quite trusted the service provider's rep= orts of performance as evidence that they are meeting the SLA :-). This text needs to be treated the same way as the bullet you pointed to in = section 5, and we'll do that. > *Editorial comments* > > - In abstract: RFC 8049 should be included between brackets. Well, actually, no. There should be no citations in an Abstract because tha= t piece of text must be able to stand alone. > - In section 2, Terms and concepts: for Network Operator -> it is > mentioned that > "The term is also used to refer to an individual who performs > operations and management on those networks." <-- Since it is not used > with this meaning in the > text, I would remove that clarification to avoid ambiguity. Could catch. And we previously fixed the ambiguity by saying "human operato= r" when we needed to. > - In section 2, Terms and concepts: for Data Model -> the following > sentence seems to be editorial, maybe it can be removed: "so it may be > helpful to quote some text to give context within this document." Yup. > - Section 6.2 < -- Probably it would be better to separate Service > Delivery from > Network Element models in different sections, with sample models > referred As above. The authors really don't want to go there. > - Same section. Network Element model is introduced here for 1st time. > In figure > 3 it is referred as device configuration model. It would be better to > have an homogeneous naming. Well, "Network Element model" shows in 6.1 and comes from RFC 8199. "Device models" comes from draft-ietf-l2sm-l2vpn-service-model. So we're stuck with both terms, but I've added text to help with the termin= ology mapping. > - Section 9, first sentence: "... related to network management." -> "... related to > network management and control." OK Many thanks for your really helpful review. Adrian ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o From nobody Tue Aug 29 11:32:06 2017 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 13F29132941; Tue, 29 Aug 2017 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 O0tHFZpSSE_u; Tue, 29 Aug 2017 11:31:51 -0700 (PDT) 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 A7A70132951; Tue, 29 Aug 2017 11:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7095; q=dns/txt; s=iport; t=1504031510; x=1505241110; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=VZG6339rYaHJSnvJ6LZ61yhcCRf6ogtZlbY8zvBrtw8=; b=fsuioizn9Lrtr85g2uOm5Px4o+mUtyCD8+vPZMGKccig0qCSGDkVNlYQ rk31AifWh8/+J47cVn8fnZI8fRiMtjMMykcKS10iEiko04jpoG1BKNgde DGrPToJeQY8Khzge5/KR+w7HNybEZ/Xkqz3sznAM+A1nnmopLUOP6T/UV E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAgD5saVZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBiUqLEZB2IpY1ggQHggWDOwKEWBUBAgEBAQEBAQFrKIUYAQEBAQIBIwR?= =?us-ascii?q?EDgULCxgVFQICVwYBDAgBAYolCK5+gW06i18BAQEBAQEBAwEBAQEBAQEBEQ+DK?= =?us-ascii?q?oUzKwuCcoQwLQJVglSCYQEEiXcWiH2FIog8hDeCIY10ghKFZ4NZJIZ1lkI1IoE?= =?us-ascii?q?NMiEIHBVJhROCCj6MCgEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,445,1498521600"; d="asc'?scan'208";a="696830849" 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; 29 Aug 2017 18:31:47 +0000 Received: from [10.61.82.247] (ams3-vpn-dhcp4856.cisco.com [10.61.82.247]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7TIVlPu007306; Tue, 29 Aug 2017 18:31:47 GMT To: Adam Montville , secdir@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org References: <150384057895.866.9675653302394719026@ietfa.amsl.com> From: Eliot Lear Message-ID: Date: Tue, 29 Aug 2017 20:31:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150384057895.866.9675653302394719026@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jmgMsA6Cn433PtjGGFebCXJVwkOsEDnT7" Archived-At: Subject: Re: [OPSAWG] Secdir early review of draft-ietf-opsawg-mud-08 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, 29 Aug 2017 18:31:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jmgMsA6Cn433PtjGGFebCXJVwkOsEDnT7 Content-Type: multipart/mixed; boundary="ek3fMXD6SSlRctE5dK75NveXHsREUe6Fs"; protected-headers="v1" From: Eliot Lear To: Adam Montville , secdir@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Message-ID: Subject: Re: Secdir early review of draft-ietf-opsawg-mud-08 References: <150384057895.866.9675653302394719026@ietfa.amsl.com> In-Reply-To: <150384057895.866.9675653302394719026@ietfa.amsl.com> --ek3fMXD6SSlRctE5dK75NveXHsREUe6Fs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Adam, Thanks very much for your review.=C2=A0 I'm pleased you like the general approach.=C2=A0 You hit the nail on the head: this is NOT intended to be = a panacea, but a means by which the device (and its manufacturer) can enlist the network's protection. Indeed as I mentioned the first time I presented to SAAG, I will say now again (with feeling): NOTHING in that draft nor anywhere ELSE should excuse a manufacturer/developer from best coding practices and updating software.=C2=A0 The best form of protection will ALWAYS ALWAYS be a well secured device to begin with. MUD is simply there to add an additional layer for when the hacker gets there first... Please now see below. On 8/27/17 3:29 PM, Adam Montville wrote: > > Finally, I found myself wondering if this type of appraoch - communicat= ing > intended use - could be extended to software installed on general purpo= se > devices. For example, it would be interesting to consider how a given i= nstalled > software package could communicate not only its intended use, but it's > preferred configuration. I'd very much like to pursue this concept, but it seems to me it has to be rooted in some sort of hardware trust. > > Some questions to consider (these are potential issues): > > At the top of page 9, the draft describes controller behavior for mobil= e > devices - configurations should be removed when the device is removed. = Does > this apply also to intermittent devices?=20 Well indeed so.=C2=A0 I think the discussion around mobility is confusing= =2E=C2=A0 I've cleaned that up. > When would a device be considered > "removed" instead of simply powered down? I think the best way to look at this is to view the configuration information as ephemeral, and since the device provides the information on connect, or otherwise periodically (eg LLDP), you can regenerate the state. > Also, when reading that paragraph I > began wondering about the load on Web servers serving MUD files - not t= hat this > draft should say anything about it, but that it's something manufacture= rs are > going to have to consider and account for. Right. > > Is a stronger statement needed on the first bullet of section 4? Should= it > read: Anything not explicitly permitted MUST be denied? Similarly for o= ther > requirements in MUD file processing. At about this point, I began wonde= ring if > additional security considerations may be required for the controller. One of the principles we try to observe is that the administrator owns the network.=C2=A0 As such we should be somewhat cautious about how we ph= rase such things.=C2=A0 From a MUD perspective, what you end up with is an access-list that an administrator might choose to augment.=C2=A0 For instance, if he or she is running a special load on a Thing using 802.1AR certificates, he might want to augment the access to accommodate a new feature. In fact, it may be possible that a manufacturer writes such a complex MUD file that the network administrator desires an optimization.=C2=A0 We= do not yet have enough experience to know what sort of normative statement would cover that ;-) > > Section 9.2 describes DHCP server behavior, and is written in a manner > presuming the DHCP server knows what's happening with these building bl= ocks. I > am not a DHCP expert, so there may be something in DHCP instructing a s= erver to > ignore everything it doesn't understand, but if that is not the case, t= hen what > is expected to happen when DHCP is not expecting these options and is n= ot going > to ignore them? This is not a worry.=C2=A0 DHCP servers are very capable of ignoring unkn= own options, and they have to be well bullet proofed today or we have FAR FAR bigger fish to fry ;-) > > Nits follow: > > First paragraph of section 1.5: s/another example might to follow/anoth= er > example might be to follow/ Right! > > Recommend the following for definition of Thing: the device emitting a = MUD URL. Ok. > > Suggest striking last two sentences of Manufacturer definition, as irre= levant. Ahhh but this actually is a big deal to system integrators ;-)=C2=A0 They= want to know what their role in the ecosystem is. > > Is there a way to make the ASCII art in section 1.7 a little cleaner? O= ne > possibility is to move the right side of the bounding box to the left b= y two or > three places. Sure.=C2=A0 Done. > Also, the arrows to the line text isn't necessary (e.g. > "----->get URL->" is cleaner as "---get URL--->"). Done. > > Second bullet on page 11: s/other otherwise/otherwise/ right. > Should there be a newline after "" at the start of section= 6? I'm going to leave that one to the YANG doctors... > > On page 17: s/end(ed)/end(s\/ed)/ Basically, the sentence without "end= ed" > should read, "Information about when support ends, and when to refresh.= " This will change with the updating of the model, based on YANG doctor feedback.=C2=A0 That very container is likely to be consolidated away. > > Vertial spacing could be improved for the first bit in section 9, so th= at the > look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_= v6 Ok.=C2=A0 I think I addressed what you're talking about. > > Section 11, first sentence: s/link layer protocols/link layer protocol/= > > Good catch. Best regards and thanks again for your review. Eliot --ek3fMXD6SSlRctE5dK75NveXHsREUe6Fs-- --jmgMsA6Cn433PtjGGFebCXJVwkOsEDnT7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZpbMSAAoJEIe2a0bZ0nozLGEH/j1kGQfBV3gOCuIk+flybdTr GwCxvRmezsLCe4BnMCnA6NJWC0iC+HshNjFqoYG1IAuS5L1K8Kk30CDFAD6yULlo /kPFgl0M0ftYEuFc3CRniB9G0SBK1ivs6X9gWJwqK+0KqgvLhn0ddPWM7I0F5rL2 ni4fe1pr1bUdErQ8lcXwk0fHcru9y+4C/4FtaJNyhzUaiyNTmlMzTIp2RikZnLbb RZDzWh77lTeiPzw1J2Qbc3wCZapbCFpc6ovht30gdT3F92NjdqUVEKqSvIN7THQV GzQeZkdwPXDSh5YUWhgHxrZxOjI6Fv64O4kRo/GPcJ1RP5AvwJ8sHPUFFSHLEPw= =ueu9 -----END PGP SIGNATURE----- --jmgMsA6Cn433PtjGGFebCXJVwkOsEDnT7-- From nobody Tue Aug 29 11:50:32 2017 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 CEFCF1326EC; Tue, 29 Aug 2017 11:50:30 -0700 (PDT) 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=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 Q0eZNgiQBKDd; Tue, 29 Aug 2017 11:50:28 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 15AC013248B; Tue, 29 Aug 2017 11:50:28 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id o132so4502536itc.1; Tue, 29 Aug 2017 11:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1L15XunAXfD0LcRaF4p9Zt64Uw3nYwWAboSpb1hQCJo=; b=uh9eidmszsQMfP4IQQex37GLSKejdH547DSjbsRWfnwcMvaKh8dvZIwD9WyrNvy9vP YrszY1c1tA+dUIFTibEh77xhciBeGS3tfT5rGK4o3DTKC7+/oDR3p18VmAaYhlU7VE0p Di5boZ422Nd3K5Ox6BkXXi+7aY520O4020AOKzGLUvODLlsEoffit7R2NHFbuNpHiaH7 H1i5uwDtt6o3qLWsivL4/j880D3fB3yR7TkuQyneNQFGuT9g4Ess1mHqno+SiUpyJ3lj P+kKJ0hCUnsML1lFdZ2xs0IBS1sTpm2RJvlnFIdqcs2TovemyC6eCiksTS8UOH5aZgzF s3hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1L15XunAXfD0LcRaF4p9Zt64Uw3nYwWAboSpb1hQCJo=; b=FmgJrh6aqe3V4CGOMPZg63lpSzyCCTOtAD4tlSgA0VKTT99NMAXNaKlF013mkBR4HB ZxT9tehB+SrMrNomMyK9jGi1TuEp125f34yxbm+6YWjna+Smsa6fZwhsjnzn4N/CPbHN 1Sdj3Xp42TAMM+SCO3V5HeEQ/3hQcWnn0DCL9AS5uSlX0kMo5+yG/yeHy/Y8iKv+DzaE J+flKyCEVwBVn7FnpZywKdV5pd4uEM0eJ6eF35LcjFzN7b67FaG53e+vtcLhh5LDjv4R VgMuIePFX6oHB7s51PdrjwBEZ5pHSbPLJ2ErRyxoxqYGWfizFV5pynvTlsJFwgc3LvZ+ q1/w== X-Gm-Message-State: AHYfb5gHXL032zM6vT+TfG3VT9PeR2t4hIZ3EE0va1DBvnIFiYHgu33z yENV5CRBRdrgCi+Q6AoJ5ONSBZLwMw== X-Received: by 10.36.249.67 with SMTP id l64mr3371819ith.66.1504032627122; Tue, 29 Aug 2017 11:50:27 -0700 (PDT) MIME-Version: 1.0 References: <150384057895.866.9675653302394719026@ietfa.amsl.com> In-Reply-To: From: Adam Montville Date: Tue, 29 Aug 2017 18:50:15 +0000 Message-ID: To: Eliot Lear , secdir@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0475707864dc0557e8e2c4" Archived-At: Subject: Re: [OPSAWG] Secdir early review of draft-ietf-opsawg-mud-08 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, 29 Aug 2017 18:50:31 -0000 --94eb2c0475707864dc0557e8e2c4 Content-Type: text/plain; charset="UTF-8" Hi Eliot, You're welcome. Thanks for taking the time to consider, and even implement some of, my feedback. I agree on the hardware rooted trust for software intended use. Seems plausible, given work coming out of TCG. I'm sure there are others who may find this train of thought interesting. Kind regards, Adam On Tue, Aug 29, 2017 at 1:31 PM Eliot Lear wrote: > Hi Adam, > > Thanks very much for your review. I'm pleased you like the general > approach. You hit the nail on the head: this is NOT intended to be a > panacea, but a means by which the device (and its manufacturer) can > enlist the network's protection. Indeed as I mentioned the first time I > presented to SAAG, I will say now again (with feeling): > > NOTHING in that draft nor anywhere ELSE should excuse a > manufacturer/developer from best coding practices and updating > software. The best form of protection will ALWAYS ALWAYS be a well > secured device to begin with. > > MUD is simply there to add an additional layer for when the hacker gets > there first... > > Please now see below. > > > On 8/27/17 3:29 PM, Adam Montville wrote: > > > > Finally, I found myself wondering if this type of appraoch - > communicating > > intended use - could be extended to software installed on general purpose > > devices. For example, it would be interesting to consider how a given > installed > > software package could communicate not only its intended use, but it's > > preferred configuration. > > I'd very much like to pursue this concept, but it seems to me it has to > be rooted in some sort of hardware trust. > > > > > Some questions to consider (these are potential issues): > > > > At the top of page 9, the draft describes controller behavior for mobile > > devices - configurations should be removed when the device is removed. > Does > > this apply also to intermittent devices? > Well indeed so. I think the discussion around mobility is confusing. > I've cleaned that up. > > > When would a device be considered > > "removed" instead of simply powered down? > > I think the best way to look at this is to view the configuration > information as ephemeral, and since the device provides the information > on connect, or otherwise periodically (eg LLDP), you can regenerate the > state. > > > Also, when reading that paragraph I > > began wondering about the load on Web servers serving MUD files - not > that this > > draft should say anything about it, but that it's something > manufacturers are > > going to have to consider and account for. > Right. > > > > Is a stronger statement needed on the first bullet of section 4? Should > it > > read: Anything not explicitly permitted MUST be denied? Similarly for > other > > requirements in MUD file processing. At about this point, I began > wondering if > > additional security considerations may be required for the controller. > > One of the principles we try to observe is that the administrator owns > the network. As such we should be somewhat cautious about how we phrase > such things. From a MUD perspective, what you end up with is an > access-list that an administrator might choose to augment. For > instance, if he or she is running a special load on a Thing using > 802.1AR certificates, he might want to augment the access to accommodate > a new feature. > > In fact, it may be possible that a manufacturer writes such a complex > MUD file that the network administrator desires an optimization. We do > not yet have enough experience to know what sort of normative statement > would cover that ;-) > > > > > Section 9.2 describes DHCP server behavior, and is written in a manner > > presuming the DHCP server knows what's happening with these building > blocks. I > > am not a DHCP expert, so there may be something in DHCP instructing a > server to > > ignore everything it doesn't understand, but if that is not the case, > then what > > is expected to happen when DHCP is not expecting these options and is > not going > > to ignore them? > > This is not a worry. DHCP servers are very capable of ignoring unknown > options, and they have to be well bullet proofed today or we have FAR > FAR bigger fish to fry ;-) > > > > Nits follow: > > > > First paragraph of section 1.5: s/another example might to follow/another > > example might be to follow/ > Right! > > > > Recommend the following for definition of Thing: the device emitting a > MUD URL. > > Ok. > > > > Suggest striking last two sentences of Manufacturer definition, as > irrelevant. > > Ahhh but this actually is a big deal to system integrators ;-) They > want to know what their role in the ecosystem is. > > > > > Is there a way to make the ASCII art in section 1.7 a little cleaner? One > > possibility is to move the right side of the bounding box to the left by > two or > > three places. > > Sure. Done. > > Also, the arrows to the line text isn't necessary (e.g. > > "----->get URL->" is cleaner as "---get URL--->"). > > Done. > > > > Second bullet on page 11: s/other otherwise/otherwise/ > > right. > > Should there be a newline after "" at the start of section > 6? > > I'm going to leave that one to the YANG doctors... > > > > On page 17: s/end(ed)/end(s\/ed)/ Basically, the sentence without > "ended" > > should read, "Information about when support ends, and when to refresh." > > This will change with the updating of the model, based on YANG doctor > feedback. That very container is likely to be consolidated away. > > > > Vertial spacing could be improved for the first bit in section 9, so > that the > > look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL_v6 > > Ok. I think I addressed what you're talking about. > > > > Section 11, first sentence: s/link layer protocols/link layer protocol/ > > > > > > Good catch. > > Best regards and thanks again for your review. > > Eliot > > --94eb2c0475707864dc0557e8e2c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eliot,

You're welcome. Thanks fo= r taking the time to consider, and even implement some of, my feedback.

I agree on the hardware rooted trust for software int= ended use. Seems plausible, given work coming out of TCG. I'm sure ther= e are others who may find this train of thought interesting.

=
Kind regards,

Adam

On Tue, Aug 29, 2017 at 1:31 PM Eliot Lea= r <lear@cisco.com> wrote:
Hi Adam,

Thanks very much for your review.=C2=A0 I'm pleased you like the genera= l
approach.=C2=A0 You hit the nail on the head: this is NOT intended to be a<= br> panacea, but a means by which the device (and its manufacturer) can
enlist the network's protection. Indeed as I mentioned the first time I=
presented to SAAG, I will say now again (with feeling):

NOTHING in that draft nor anywhere ELSE should excuse a
manufacturer/developer from best coding practices and updating
software.=C2=A0 The best form of protection will ALWAYS ALWAYS be a well secured device to begin with.

MUD is simply there to add an additional layer for when the hacker gets
there first...

Please now see below.


On 8/27/17 3:29 PM, Adam Montville wrote:
>
> Finally, I found myself wondering if this type of appraoch - communica= ting
> intended use - could be extended to software installed on general purp= ose
> devices. For example, it would be interesting to consider how a given = installed
> software package could communicate not only its intended use, but it&#= 39;s
> preferred configuration.

I'd very much like to pursue this concept, but it seems to me it has to=
be rooted in some sort of hardware trust.

>
> Some questions to consider (these are potential issues):
>
> At the top of page 9, the draft describes controller behavior for mobi= le
> devices - configurations should be removed when the device is removed.= Does
> this apply also to intermittent devices?
Well indeed so.=C2=A0 I think the discussion around mobility is confusing.= =C2=A0
I've cleaned that up.

> When would a device be considered
> "removed" instead of simply powered down?

I think the best way to look at this is to view the configuration
information as ephemeral, and since the device provides the information
on connect, or otherwise periodically (eg LLDP), you can regenerate the
state.

>=C2=A0 Also, when reading that paragraph I
> began wondering about the load on Web servers serving MUD files - not = that this
> draft should say anything about it, but that it's something manufa= cturers are
> going to have to consider and account for.
Right.
>
> Is a stronger statement needed on the first bullet of section 4? Shoul= d it
> read: Anything not explicitly permitted MUST be denied? Similarly for = other
> requirements in MUD file processing. At about this point, I began wond= ering if
> additional security considerations may be required for the controller.=

One of the principles we try to observe is that the administrator owns
the network.=C2=A0 As such we should be somewhat cautious about how we phra= se
such things.=C2=A0 From a MUD perspective, what you end up with is an
access-list that an administrator might choose to augment.=C2=A0 For
instance, if he or she is running a special load on a Thing using
802.1AR certificates, he might want to augment the access to accommodate a new feature.

In fact, it may be possible that a manufacturer writes such a complex
MUD file that the network administrator desires an optimization.=C2=A0 We d= o
not yet have enough experience to know what sort of normative statement
would cover that ;-)

>
> Section 9.2 describes DHCP server behavior, and is written in a manner=
> presuming the DHCP server knows what's happening with these buildi= ng blocks. I
> am not a DHCP expert, so there may be something in DHCP instructing a = server to
> ignore everything it doesn't understand, but if that is not the ca= se, then what
> is expected to happen when DHCP is not expecting these options and is = not going
> to ignore them?

This is not a worry.=C2=A0 DHCP servers are very capable of ignoring unknow= n
options, and they have to be well bullet proofed today or we have FAR
FAR bigger fish to fry ;-)
>
> Nits follow:
>
> First paragraph of section 1.5: s/another example might to follow/anot= her
> example might be to follow/
Right!
>
> Recommend the following for definition of Thing: the device emitting a= MUD URL.

Ok.
>
> Suggest striking last two sentences of Manufacturer definition, as irr= elevant.

Ahhh but this actually is a big deal to system integrators ;-)=C2=A0 They want to know what their role in the ecosystem is.

>
> Is there a way to make the ASCII art in section 1.7 a little cleaner? = One
> possibility is to move the right side of the bounding box to the left = by two or
> three places.

Sure.=C2=A0 Done.
> Also, the arrows to the line text isn't necessary (e.g.
> "----->get URL->" is cleaner as "---get URL--->= ;").

Done.
>
> Second bullet on page 11: s/other otherwise/otherwise/

right.
> Should there be a newline after "<CODE BEGINS>" at the= start of section 6?

I'm going to leave that one to the YANG doctors...
>
> On page 17: s/end(ed)/end(s\/ed)/=C2=A0 Basically, the sentence withou= t "ended"
> should read, "Information about when support ends, and when to re= fresh."

This will change with the updating of the model, based on YANG doctor
feedback.=C2=A0 That very container is likely to be consolidated away.
>
> Vertial spacing could be improved for the first bit in section 9, so t= hat the
> look/feel surrounding OPTION_MUD_URL_V4 matches that of OPTION_MUD_URL= _v6

Ok.=C2=A0 I think I addressed what you're talking about.
>
> Section 11, first sentence: s/link layer protocols/link layer protocol= /
>
>

Good catch.

Best regards and thanks again for your review.

Eliot

--94eb2c0475707864dc0557e8e2c4-- From nobody Tue Aug 29 14:40:40 2017 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 9DEE21321B6; Tue, 29 Aug 2017 14:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vf6bxIUcmpTf; Tue, 29 Aug 2017 14:40:31 -0700 (PDT) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 6FC21132031; Tue, 29 Aug 2017 14:40:30 -0700 (PDT) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v7TLeRcT024193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Aug 2017 23:40:28 +0200 Received: from [192.168.16.50] (134.102.43.163) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 29 Aug 2017 23:40:21 +0200 To: iot-dir CC: , From: Henk Birkholz Message-ID: Date: Tue, 29 Aug 2017 23:40:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.43.163] Archived-At: Subject: [OPSAWG] IoT-DIR early review of draft-ietf-opsawg-mud-08 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, 29 Aug 2017 21:40:34 -0000 Reviewer: Henk Birkholz Review result: Has Issues Hi, I am the assigned IoT-DIR reviewer for this document's early review. Please find my comments in kramdown below. Viele Grüße, Henk # IoT-DIR Early Review of I-D.ietf-opsawg-mud-08 ## Draft Summary This draft defines a canonical way to compose an URI that points to a specific resource called a MUD file. A MUD file is a text resource that contains imperative guidance in the form of YANG-based ACL policies represented in JSON. The imperative guidance is intended to be applied to things that can be identified by the segments of the MUD URI via a specific controller. The version of MUD is a component (segment) of the MUD URI and there are three examples in what to embed a MUD URI in (DHCP option, X.509 extension, and LLDP extension). ## Comments on General Topics This draft could be a significant step towards to self-descriptiveness of things. Constrained things might require imperative guidance or declarative guidance in order to be managed appropriately - which in includes aspects, such as isolation, clustering, service/capability discovery/exposure, and therefore security automation in general. In a lot of usage scenarios, it might not be feasible to store that guidance on the thing itself and MUD URI could be a solution to support a lot of vendor supplied information, such as reference integrity measurements, intended composition of composite devices, etc. ### Scope of Application On one hand, this drafts limits the potential usage of the MUD architecture to the use of one specific branch of YANG modules regarding ACL policies. There is no way to express other manufacture usage description "information-types" or "content-types" on a fundamental level and section 13 specifically states that "coupled with the fact that we have also chosen to leverage existing mechanisms, we are left with no ability to negotiate extensions and a limited desire for those extensions in any event." Creating augments for the metainfo container as it is also described in Section 13, on the other hand, allows for virtually any kind of information to be expressed and conveyed via a MUD file, but on a semantic level that seems to be a bit perplexing. This comment is not intended to question the feasibility of the technical approach - which is okay - but more taking into account the principle of least surprise. Hence, a strong proposal - in respect to the already included universal extension mechanism - to consider: * aligning ACL content and "other" content on the same semantic level in the YANG module, and * maybe indicating the corresponding semantics of the MUD file in the MUD URI itself. ### Intended & Allowed Representations/Formats The assumption is that neither the MUD controller nor the server serving the MUD files are constrained devices. The things that the imperative guidance is intended to address can be constrained devices. YANG modules are used to create the MUD files and the representation in the MUD files is JSON. In the scope of the extensibility feature highlighted, is it intended that every MUD file must contain content that relates to the structure of a YANG module (or are there other data models for data at rest planned for)? Is JSON intended to be the only allowed representation used for the representation of content in MUD files (a question in respect to the CBOR-based CoMI draft in the CORE WG)? ### Segment "mud-rev" There seems to be conflicting definitions about the semantic of the segment "mud-rev": Section "5. What does a MUD URL look like?" states that a "mud-rev signifies the version of the manufacturer usage description file" and "this memo specifies "v1" of that file". The passages quoted here seem to imply that mud-rev is about the instance of JSON that is the content of the MUD file. Section "13. Extensibility" though states "at a coarse grain, a protocol version is included in a MUD URL. This memo specifies MUD version 1. Any and all changes are entertained when this version is bumped.", which implies that mud-rev is intended to state the version of the MUD protocol and probably the respective YANG module(s). Probably, you want both? Most certainly, this has to be clarified. ### Segment "model" Every device typically is a composite. Similarly, the hardware device-model identifier is a potential composite of device-type, device-model & device-version (and probably even more). The text is very vague on this part, maybe deliberatively so because the authors do not want to prescribe how to compose the string that constitutes the model segment - but a bit more guidance on what this typically means and what could be caveats if you concatenate this potentially very complex identifier into a single string is strongly recommended. Also, model is supposed to include in a not further specified way an identifier of the "version" of the software next to the "version" of the hardware. Even in very small things, software components can be composites, too. Furthermore, a software version may run on more than one device-model or even device-type. While it might introduce complexity in respect to URI composition (one/two extra segments), separating the hardware composite-identifier from the software/firmware composite-identifier will be helpful and provide more clear semantics to both humans and machines. ### Query "extra" While this option is included in the composition guidance of a MUD URI, it is not included in the text anywhere. One guess of its purpose could be to provide subsets of the modules via xpath or subtree expressions. Is that the case? Additionally, including a variable in an immutable container, e.g. DevID, seems to negate the intend of it being a variable? Maybe this should be highlighted in the upcoming section that illustrates what the "extra" query option is for? ### Signing MUD files The given openssl example basically allows for every kind of certificate- or key-type. Is that intentional? While most individuals will be able to inflate "mancertfile" or "mankey" to manufacturer certificate and manufacturer key, respectively, I strongly recommend to provide more guidance here - especially in regard to command parameters and appropriate hash and cipher algorithms with a low footprint. Providing examples here will be beneficial (maybe ECDSA & EDDSA). ## Nits What does the expression "relative to XML" intends to convey in "JSON is used as a serialization for compactness and readability, relative to XML."? %s/Application\/pkcs7-signature/application\/pkcs7-signature/g From nobody Wed Aug 30 00:56:25 2017 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 636061326DF; Wed, 30 Aug 2017 00:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 LeT-ZHW-lnxy; Wed, 30 Aug 2017 00:56:21 -0700 (PDT) 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 834CD1323B5; Wed, 30 Aug 2017 00:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13748; q=dns/txt; s=iport; t=1504079780; x=1505289380; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=+ewFIXD1zF1m80Uh1zblIQfF5pA9n6Nw8H87eYBso7Y=; b=jg+fy7RmvQvy8YW0ZHAh6dyWDFSLsMGrGkOmKEHOcRQ5HPG6Obtsn8vr wVpCewXbPwfdxsk08RJMirci7Zexe41OedZaWFz8YU8R2uBFXVPvqy8xa Mt/909OqT9cUpo/2r4xIuisgwK5Sd9d9dTY/RWpfpemOoI8YK5QTMh0N+ 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQAlb6ZZ/xbLJq1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYlKixKRF5YnDoIEB4IFgzsChFkXAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?CASNWEAsSBhUVAgJJDgYBDAgBAReKDgitJ4Ini0YBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEOD4MqhTMrgn2EMAkRBBFVglSCYQWKDY4fiDyEN4IhhBFJiRqCEoVng1k?= =?us-ascii?q?khnWJd4xLIQI0gQ0yIQgcFYVgARyBaT6IYoJBAQEB?= X-IronPort-AV: E=Sophos;i="5.41,448,1498521600"; d="asc'?scan'208";a="696845253" 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 Aug 2017 07:56:09 +0000 Received: from [10.61.82.247] (ams3-vpn-dhcp4856.cisco.com [10.61.82.247]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7U7u8u3018260; Wed, 30 Aug 2017 07:56:09 GMT To: Henk Birkholz , iot-dir Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org References: From: Eliot Lear Message-ID: <32f3d662-ce1e-47a6-d239-f8004ebfb1d8@cisco.com> Date: Wed, 30 Aug 2017 09:56:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2os6KvTvnJmRItuUEGpfg5oSFCf5hvfp3" Archived-At: Subject: Re: [OPSAWG] IoT-DIR early review of draft-ietf-opsawg-mud-08 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, 30 Aug 2017 07:56:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2os6KvTvnJmRItuUEGpfg5oSFCf5hvfp3 Content-Type: multipart/mixed; boundary="eN43kkCWvsGG9wwq0aWgnf31iRC4iU9oi"; protected-headers="v1" From: Eliot Lear To: Henk Birkholz , iot-dir Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org Message-ID: <32f3d662-ce1e-47a6-d239-f8004ebfb1d8@cisco.com> Subject: Re: IoT-DIR early review of draft-ietf-opsawg-mud-08 References: In-Reply-To: --eN43kkCWvsGG9wwq0aWgnf31iRC4iU9oi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Henk and thanks very much for your review. Please see below. On 8/29/17 11:40 PM, Henk Birkholz wrote: > > > # IoT-DIR Early Review of I-D.ietf-opsawg-mud-08 > > ## Draft Summary > > This draft defines a canonical way to compose an URI that points to a > specific resource called a MUD file. A MUD file is a text resource > that contains imperative guidance in the form of YANG-based ACL > policies represented in JSON. The imperative guidance is intended to > be applied to things that can be identified by the segments of the MUD > URI via a specific controller. The version of MUD is a component > (segment) of the MUD URI and there are three examples in what to embed > a MUD URI in (DHCP option, X.509 extension, and LLDP extension). > > ## Comments on General Topics > > This draft could be a significant step towards to self-descriptiveness > of things. Constrained things might require imperative guidance or > declarative guidance in order to be managed appropriately - which in > includes aspects, such as isolation, clustering, service/capability > discovery/exposure, and therefore security automation in general. In a > lot of usage scenarios, it might not be feasible to store that > guidance on the thing itself and MUD URI could be a solution to > support a lot of vendor supplied information, such as reference > integrity measurements, intended composition of composite devices, etc.= Ok, but a cautionary note: this draft intentionally focuses NOT on giving the Thing guidance but on giving the *network* guidance.=C2=A0 Tha= t isn't to say that Things couldn't derive guidance from extensions to the model (we'll talk about that below), but at the moment, the pain point is protecting them. > > ### Scope of Application > > On one hand, this drafts limits the potential usage of the MUD > architecture to the use of one specific branch of YANG modules > regarding ACL policies. There is no way to express other manufacture > usage description "information-types" or "content-types" on a > fundamental level and section 13 specifically states that "coupled > with the fact that we have also chosen to leverage existing > mechanisms, we are left with no ability to negotiate extensions and a > limited desire for those extensions in any event." > > Creating augments for the metainfo container as it is also described > in Section 13, on the other hand, allows for virtually any kind of > information to be expressed and conveyed via a MUD file, but on a > semantic level that seems to be a bit perplexing. > > This comment is not intended to question the feasibility of the > technical approach - which is okay - but more taking into account the > principle of least surprise. Hence, a strong proposal - in respect to > the already included universal extension mechanism - to consider: > > * aligning ACL content and "other" content on the same semantic level > in the YANG module, and > * maybe indicating the corresponding semantics of the MUD file in the > MUD URI itself. On the first point, that is precisely the intent of the previous reorg, to demote, if you will, access control so that other mechanisms can be employed.=C2=A0 I'll speak more to this below. On the second point, one reason for referencing information is so that the underlying information can change as needed without the need to change the URL itself.=C2=A0 While it may be possible in some instances t= o update the URL, this will not always be the case.=C2=A0=C2=A0 Consider th= at the URL may be inside a signed certificate that is burned into the device.=C2= =A0 This having been said, we leave open the possibility that the MUD controller may wish to modify the URI through "extras".=C2=A0 See below f= or more details. > > ### Intended & Allowed Representations/Formats > > The assumption is that neither the MUD controller nor the server > serving the MUD files are constrained devices. The things that the > imperative guidance is intended to address can be constrained devices. > YANG modules are used to create the MUD files and the representation > in the MUD files is JSON. That is indeed the assumption.=C2=A0 The initial consumers of this information are going to be switches and access control systems that generally speaking can easily parse JSON.=C2=A0 Furthermore, at least as = we get started, it's important for humans to be able to read and debug this stuff. > > In the scope of the extensibility feature highlighted, is it intended > that every MUD file must contain content that relates to the structure > of a YANG module (or are there other data models for data at rest > planned for)? If the extension augments the YANG module then, well, yes ;-)=C2=A0 On th= e other hand, if the extension is a reference to something else, then the rules are up to that "something else".=C2=A0 Let's take an example.=C2=A0= Suppose there is an extension that points to some form of WoT/schema.org-based description.=C2=A0 That description could be in the form of a URN, that a= network might use to populate a CoAP resource directory, that other Things could then retrieve.=C2=A0 The rules for the form of all of that w= ould be well outside the scope of MUD, which would be a good thing, because I just referenced a bunch of stuff that you know a lot more about than I do ;-)=C2=A0 All the encoding rules and semantics are left to you to defi= ne.=C2=A0 At that point, a network management system would have to obey your semantics if the device wants want to play. If you like the above text, we could add something like it. > > > Is JSON intended to be the only allowed representation used for the > representation of content in MUD files (a question in respect to the > CBOR-based CoMI draft in the CORE WG)? Yes, for reasons given above. > > ### Segment "mud-rev" > > There seems to be conflicting definitions about the semantic of the > segment "mud-rev": > > Section "5. What does a MUD URL look like?" states that a "mud-rev > signifies the version of the manufacturer usage description file" and > "this memo specifies "v1" of that file". The passages quoted here seem > to imply that mud-rev is about the instance of JSON that is the > content of the MUD file. I wouldn't go that far.=C2=A0 The point of externalizing the version # fr= om JSON is so that the next version could return something else.=C2=A0 Many = of us have lived through ASN.1 BER/DER, SGML, HTML, XML, RDF (and numerous other forms of XML), JSON, CBOR, and YAML in all of its looseness.=C2=A0 = It would be presumptuous to believe that either JSON or CBOR are the be-all end-all, especially since we're discussing them here.=C2=A0 Also, one cou= ld easily envision an entire conceptual reorganization in the next version, but let's hope that will be down the road a bit. Having written all of this, clearly the draft led you who are knowledgeable in this subject to somehow believe otherwise.=C2=A0 If ther= e is a textual change that clarify that, let's make it. > > Section "13. Extensibility" though states "at a coarse grain, a > protocol version is included in a MUD URL. This memo specifies MUD > version 1. Any and all changes are entertained when this version is > bumped.", which implies that mud-rev is intended to state the version > of the MUD protocol and probably the respective YANG module(s). > > Probably, you want both? Most certainly, this has to be clarified. > > ### Segment "model" > > Every device typically is a composite. Similarly, the hardware > device-model identifier is a potential composite of device-type, > device-model & device-version (and probably even more). The text is > very vague on this part, maybe deliberatively so because the authors > do not want to prescribe how to compose the string that constitutes > the model segment - but a bit more guidance on what this typically > means and what could be caveats if you concatenate this potentially > very complex identifier into a single string is strongly recommended. > > Also, model is supposed to include in a not further specified way an > identifier of the "version" of the software next to the "version" of > the hardware. Even in very small things, software components can be > composites, too. Furthermore, a software version may run on more than > one device-model or even device-type. While it might introduce > complexity in respect to URI composition (one/two extra segments), > separating the hardware composite-identifier from the > software/firmware composite-identifier will be helpful and provide > more clear semantics to both humans and machines. You've caught an important point, and we should review the text: OLD: > This string matches the entire MUD URL, thus covering the model that > is unique within the context of the authority.=C2=A0 It may also includ= e > product version information.=C2=A0 Thus how this field is constructed i= s > entirely a local matter for the manufacturer. I propose the following to address your point: NEW: > > This string matches the entire MUD URL, thus covering the model that > is unique within the context of the authority.=C2=A0 It is attended to > uniquely identify > a particular class of device.=C2=A0 It may contain not only model > information, but > versioning information as well, and any other information that the > manufacturer > wishes to add.=C2=A0 The intended use is for devices of this precise cl= ass > to match, to permit or > deny communication between one another. To make this point clearer, I also propose a change to the non-terminal in the ABNF to avoid confusion, as well as a modest change to the text that follows. > > ### Query "extra" > > While this option is included in the composition guidance of a MUD > URI, it is not included in the text anywhere. One guess of its purpose > could be to provide subsets of the modules via xpath or subtree > expressions. Is that the case? Additionally, including a variable in > an immutable container, e.g. DevID, seems to negate the intend of it > being a variable? Maybe this should be highlighted in the upcoming > section that illustrates what the "extra" query option is for? Here I can only but agree that "extra" is under-specified, and I believe an earlier reviewer mentioned this as well.=C2=A0 Here is what I have in = mind for text: NEW: > "extras" is intended for use by the MUD controller to provide > additional information such as posture about the Thing to the MUD file > server.=C2=A0=C2=A0 =C2=A0 This field MUST not be configured on the Thi= ng itself by a > manufacturer - that is what "modelinfo" is for.=C2=A0 It is left as fut= ure > work to define the full semantics of this field. > > ### Signing MUD files > > The given openssl example basically allows for every kind of > certificate- or key-type. Is that intentional? While most individuals > will be able to inflate "mancertfile" or "mankey" to manufacturer > certificate and manufacturer key, respectively, I strongly recommend > to provide more guidance here - especially in regard to command > parameters and appropriate hash and cipher algorithms with a low > footprint. Providing examples here will be beneficial (maybe ECDSA & > EDDSA). Keep in mind that the signature is intended to be consumed by a MUD controller.=C2=A0 This having been said, I'll examine this and see if we = can add guidance. > > ## Nits > > What does the expression "relative to XML"=C2=A0 intends to convey in "= JSON > is used as a serialization for compactness and readability, relative > to XML."? I don't know about you, but I find XML as easy to parse as binary.=C2=A0 = I say, relative to XML because I certainly don't want to claim that JSON is EASIEST for humans to read.=C2=A0 A natural language such as English o= r German is far easier. > > %s/Application\/pkcs7-signature/application\/pkcs7-signature/g > Very good.=C2=A0 I hope this answer addresses your issues. Eliot --eN43kkCWvsGG9wwq0aWgnf31iRC4iU9oi-- --2os6KvTvnJmRItuUEGpfg5oSFCf5hvfp3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZpm+ZAAoJEIe2a0bZ0nozkTcH/2xguHbPuLQsjFOSiHMTToeS UEjLYLID2I2UujRvD3+SBw6NCsbZNmGJlM0PFYtc2OLTLsUqMH/huE+FJUebs+Hj AS7JZS6XQbWWh6EO9Xn/WdSRUWQ3DMUOaOHEkHcEyiMOWHG60zFmF6G3vfbmx9Ua IaLVIRh4xztc0d4tjyKVHOn8Y1L3HZiuKdxeTQMBNyT9KgEVJ3Lj6DEmTyHuQmOx zJB3XxX4d+tCVckD/EeXPZ9KTNj0qsM5A/VMloJC6niFp8RG8JukyVoLyl6a79/7 BDfrtgziQsHGm+wXec29F3J2nYe3wX7RPs4QctFmUdos7CRBXfkjB06x/YSbvtY= =RHjt -----END PGP SIGNATURE----- --2os6KvTvnJmRItuUEGpfg5oSFCf5hvfp3-- From nobody Wed Aug 30 09:50:45 2017 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 EA9C91201F8; Wed, 30 Aug 2017 09:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 qFAE89Ldtumd; Wed, 30 Aug 2017 09:50:32 -0700 (PDT) Received: from iron02.fraunhofer.de (iron02.fraunhofer.de [153.96.1.56]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 054DF1321B7; Wed, 30 Aug 2017 09:50:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2HaAwDw66ZZ/xoHYZlUAQkbAQEBAwEBAQkBAQGDWoIAg3CaOIFxljWCBIIMgzsChCdXAQIBAQEBAQIDaCiFGAEBAQECASMPAQVBEAkCEgYCAhEVAgJHAg4GAQwBAwQBAReKDgcBBAGPBZ1mgieLQgEBAQEGAQEBAQEBAQEggQ2CHYICgU6BYyuCfYQwCREBAxFVglSCYQWKD5ZdgQWBJ4g9SYsshWeDVAUkhnWJd4xMWIENUyWFdAEcgWlCiH2BMgGBDgEBAQ X-IPAS-Result: A2HaAwDw66ZZ/xoHYZlUAQkbAQEBAwEBAQkBAQGDWoIAg3CaOIFxljWCBIIMgzsChCdXAQIBAQEBAQIDaCiFGAEBAQECASMPAQVBEAkCEgYCAhEVAgJHAg4GAQwBAwQBAReKDgcBBAGPBZ1mgieLQgEBAQEGAQEBAQEBAQEggQ2CHYICgU6BYyuCfYQwCREBAxFVglSCYQWKD5ZdgQWBJ4g9SYsshWeDVAUkhnWJd4xMWIENUyWFdAEcgWlCiH2BMgGBDgEBAQ X-IronPort-AV: E=Sophos;i="5.41,449,1498514400"; d="scan'208";a="80753715" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by iron02.fraunhofer.de with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 30 Aug 2017 18:50:26 +0200 X-IronPort-AV: E=Sophos;i="5.41,449,1498514400"; d="scan'208";a="259688290" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Aug 2017 18:50:25 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v7UGoOY3000980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 18:50:25 +0200 Received: from [134.102.160.121] (134.102.160.121) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 30 Aug 2017 18:50:19 +0200 From: Henk Birkholz To: Eliot Lear , iot-dir References: <32f3d662-ce1e-47a6-d239-f8004ebfb1d8@cisco.com> CC: , Message-ID: Date: Wed, 30 Aug 2017 18:50:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <32f3d662-ce1e-47a6-d239-f8004ebfb1d8@cisco.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.160.121] Archived-At: Subject: Re: [OPSAWG] IoT-DIR early review of draft-ietf-opsawg-mud-08 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, 30 Aug 2017 16:50:37 -0000 Hello Eliot, thank you for your fast feedback! I still have some comments and questions for another round, though. I hope that is okay - please see comments in-line. Viele Grüße, Henk On 08/30/2017 09:56 AM, Eliot Lear wrote: > Hi Henk and thanks very much for your review. > > Please see below. > > > On 8/29/17 11:40 PM, Henk Birkholz wrote: >> >> >> # IoT-DIR Early Review of I-D.ietf-opsawg-mud-08 >> >> ## Draft Summary >> >> This draft defines a canonical way to compose an URI that points to a >> specific resource called a MUD file. A MUD file is a text resource >> that contains imperative guidance in the form of YANG-based ACL >> policies represented in JSON. The imperative guidance is intended to >> be applied to things that can be identified by the segments of the MUD >> URI via a specific controller. The version of MUD is a component >> (segment) of the MUD URI and there are three examples in what to embed >> a MUD URI in (DHCP option, X.509 extension, and LLDP extension). >> >> ## Comments on General Topics >> >> This draft could be a significant step towards to self-descriptiveness >> of things. Constrained things might require imperative guidance or >> declarative guidance in order to be managed appropriately - which in >> includes aspects, such as isolation, clustering, service/capability >> discovery/exposure, and therefore security automation in general. In a >> lot of usage scenarios, it might not be feasible to store that >> guidance on the thing itself and MUD URI could be a solution to >> support a lot of vendor supplied information, such as reference >> integrity measurements, intended composition of composite devices, etc. > > Ok, but a cautionary note: this draft intentionally focuses NOT on > giving the Thing guidance but on giving the *network* guidance. That > isn't to say that Things couldn't derive guidance from extensions to the > model (we'll talk about that below), but at the moment, the pain point > is protecting them. This has to be clearly stated in the abstract and the introduction, I think. From my point of view, filter rules that are disabler and enabler of communication are a very specific subset of imperative network guidance, which are a distinct subset of the the usage descriptions a manufacturer would want to provide for a thing. To give a specific example: the passage "These devices therefore have a purpose to their use. By definition, therefore, all other purposes are NOT intended." is basically mirroring the definition of verifying if a thing is a Trusted System (see RFC4949), which can require, for example, reference integrity measurements (RIM) to enable integrity appraisal or Security Profiles to enable enforcement. But as you state, these are out of the scope of the document. I would propose to compose an abstract and introduction that is limited to what MUD is intended to do - to provide ACL for a specific class of devices - up front. because the architecture of your solution would be able to address a lot of complementary requirements that are explicitly not in scope, as it seems. > >> >> ### Scope of Application >> >> On one hand, this drafts limits the potential usage of the MUD >> architecture to the use of one specific branch of YANG modules >> regarding ACL policies. There is no way to express other manufacture >> usage description "information-types" or "content-types" on a >> fundamental level and section 13 specifically states that "coupled >> with the fact that we have also chosen to leverage existing >> mechanisms, we are left with no ability to negotiate extensions and a >> limited desire for those extensions in any event." >> >> Creating augments for the metainfo container as it is also described >> in Section 13, on the other hand, allows for virtually any kind of >> information to be expressed and conveyed via a MUD file, but on a >> semantic level that seems to be a bit perplexing. >> >> This comment is not intended to question the feasibility of the >> technical approach - which is okay - but more taking into account the >> principle of least surprise. Hence, a strong proposal - in respect to >> the already included universal extension mechanism - to consider: >> >> * aligning ACL content and "other" content on the same semantic level >> in the YANG module, and >> * maybe indicating the corresponding semantics of the MUD file in the >> MUD URI itself. > > On the first point, that is precisely the intent of the previous reorg, > to demote, if you will, access control so that other mechanisms can be > employed. I'll speak more to this below. Maybe an example on how to include a trivial non-ACL-focussed extension into the module via an (exemplary/bogus) augment would clarify how to include "other" content in a MUD file. A corresponding example of a JSON instance (MUD file) that then includes content defined by the augment would also be beneficial, I think. Would that be okay? > > On the second point, one reason for referencing information is so that > the underlying information can change as needed without the need to > change the URL itself. While it may be possible in some instances to > update the URL, this will not always be the case. Consider that the > URL may be inside a signed certificate that is burned into the device. > This having been said, we leave open the possibility that the MUD > controller may wish to modify the URI through "extras". See below for > more details. Please also consider that the URI can be composed. Most of its parts (segments, etc.) are probably represented redundantly in a DevID or can be inferred from context (MUD controller, domain, etc.). For example, you could get the content of most of the segments out of the attributes that are already stored in the DevID and just include the "missing additional parts" in a specific "mud-attribute". This is possible, because there is a precise rule how to compose the MUD URI canonically. Next to "arcance content" and unnecessary verbose encoding, redundancy inside Identity Documents is a problem the constrained-node network world is struggling with. Also, this "burning in" is only effecting content of URI path segments that are to be defined by the manufacturer. If there would be a canonical tree of paths coming after the > "/.well-known/mud/" mud-rev "/" model e.g. a set of paths segments/branches, such as > "/" acl|rim|composition then there would be no problem to provide semantic separate MUD files, because it would be the canonical URI where to find them - circumventing the "burned into the device" issue. You only need to find the "burned in" values to compose your canonical MUD URI. A task presumably conducted by the MUD controller. Would that be correct? > >> >> ### Intended & Allowed Representations/Formats >> >> The assumption is that neither the MUD controller nor the server >> serving the MUD files are constrained devices. The things that the >> imperative guidance is intended to address can be constrained devices. >> YANG modules are used to create the MUD files and the representation >> in the MUD files is JSON. > That is indeed the assumption. The initial consumers of this > information are going to be switches and access control systems that > generally speaking can easily parse JSON. Furthermore, at least as we > get started, it's important for humans to be able to read and debug this > stuff. It was not my intention to open the box of worms that is "what is a readable representation" :) Having said that, I will come back to this at the end, anyways. I am okay with JSON in v1. Please allow me to mention, for me (human), starting cat or openssl in order to read the content of a file makes no difference in respect to debugging. >> >> In the scope of the extensibility feature highlighted, is it intended >> that every MUD file must contain content that relates to the structure >> of a YANG module (or are there other data models for data at rest >> planned for)? > > If the extension augments the YANG module then, well, yes ;-) On the > other hand, if the extension is a reference to something else, then the > rules are up to that "something else". Let's take an example. Suppose > there is an extension that points to some form of WoT/schema.org-based > description. That description could be in the form of a URN, that a > network might use to populate a CoAP resource directory, that other > Things could then retrieve. The rules for the form of all of that would > be well outside the scope of MUD, which would be a good thing, because I > just referenced a bunch of stuff that you know a lot more about than I > do ;-) All the encoding rules and semantics are left to you to define. > At that point, a network management system would have to obey your > semantics if the device wants want to play. > > If you like the above text, we could add something like it. Yes please. I actually thought that this was out-of-scope at the moment. Please let me highlight here, the canonical composition of the MUD URI is the center-piece of all of this, I think. > >> >> >> Is JSON intended to be the only allowed representation used for the >> representation of content in MUD files (a question in respect to the >> CBOR-based CoMI draft in the CORE WG)? > > Yes, for reasons given above. I am okay with JSON in v1 here, but see my reasoning below for why I think otherwise, in general. >> >> ### Segment "mud-rev" >> >> There seems to be conflicting definitions about the semantic of the >> segment "mud-rev": >> >> Section "5. What does a MUD URL look like?" states that a "mud-rev >> signifies the version of the manufacturer usage description file" and >> "this memo specifies "v1" of that file". The passages quoted here seem >> to imply that mud-rev is about the instance of JSON that is the >> content of the MUD file. > > I wouldn't go that far. The point of externalizing the version # from > JSON is so that the next version could return something else. Many of > us have lived through ASN.1 BER/DER, SGML, HTML, XML, RDF (and numerous > other forms of XML), JSON, CBOR, and YAML in all of its looseness. It > would be presumptuous to believe that either JSON or CBOR are the be-all > end-all, especially since we're discussing them here. Also, one could > easily envision an entire conceptual reorganization in the next version, > but let's hope that will be down the road a bit. > > Having written all of this, clearly the draft led you who are > knowledgeable in this subject to somehow believe otherwise. If there is > a textual change that clarify that, let's make it. As a reader of the document, I just want to know under which conditions the version will change from v1 to something else. At the moment the text picks up on that MUD version at multiple places and in different ways somehow. Consolidating that into one place and illustrating the exact conditions in which there will be a version change, will address this comment, I think. > >> >> Section "13. Extensibility" though states "at a coarse grain, a >> protocol version is included in a MUD URL. This memo specifies MUD >> version 1. Any and all changes are entertained when this version is >> bumped.", which implies that mud-rev is intended to state the version >> of the MUD protocol and probably the respective YANG module(s). >> >> Probably, you want both? Most certainly, this has to be clarified. >> >> ### Segment "model" >> >> Every device typically is a composite. Similarly, the hardware >> device-model identifier is a potential composite of device-type, >> device-model & device-version (and probably even more). The text is >> very vague on this part, maybe deliberatively so because the authors >> do not want to prescribe how to compose the string that constitutes >> the model segment - but a bit more guidance on what this typically >> means and what could be caveats if you concatenate this potentially >> very complex identifier into a single string is strongly recommended. >> >> Also, model is supposed to include in a not further specified way an >> identifier of the "version" of the software next to the "version" of >> the hardware. Even in very small things, software components can be >> composites, too. Furthermore, a software version may run on more than >> one device-model or even device-type. While it might introduce >> complexity in respect to URI composition (one/two extra segments), >> separating the hardware composite-identifier from the >> software/firmware composite-identifier will be helpful and provide >> more clear semantics to both humans and machines. > > You've caught an important point, and we should review the text: > > OLD: >> This string matches the entire MUD URL, thus covering the model that >> is unique within the context of the authority. It may also include >> product version information. Thus how this field is constructed is >> entirely a local matter for the manufacturer. > > I propose the following to address your point: > > NEW: > >> >> This string matches the entire MUD URL, thus covering the model that >> is unique within the context of the authority. It is attended to >> uniquely identify >> a particular class of device. It may contain not only model >> information, but >> versioning information as well, and any other information that the >> manufacturer >> wishes to add. The intended use is for devices of this precise class >> to match, to permit or >> deny communication between one another. I am okay with the change. It still mixes hardware and software identifiers, but if that is okay for the group, it is okay with me. > > To make this point clearer, I also propose a change to the non-terminal > in the ABNF to avoid confusion, as well as a modest change to the text > that follows. >> >> ### Query "extra" >> >> While this option is included in the composition guidance of a MUD >> URI, it is not included in the text anywhere. One guess of its purpose >> could be to provide subsets of the modules via xpath or subtree >> expressions. Is that the case? Additionally, including a variable in >> an immutable container, e.g. DevID, seems to negate the intend of it >> being a variable? Maybe this should be highlighted in the upcoming >> section that illustrates what the "extra" query option is for? > Here I can only but agree that "extra" is under-specified, and I believe > an earlier reviewer mentioned this as well. Here is what I have in mind > for text: > > NEW: > >> "extras" is intended for use by the MUD controller to provide >> additional information such as posture about the Thing to the MUD file >> server. This field MUST not be configured on the Thing itself by a >> manufacturer - that is what "modelinfo" is for. It is left as future >> work to define the full semantics of this field. Could you please provide an example of "posture about the Thing" that could be requested as an option from the MUD file server by the MUD controller? I am still not really sure what to make of it. If this is future work in the scope of this draft, we can just revisit this at a later point. > >> >> ### Signing MUD files >> >> The given openssl example basically allows for every kind of >> certificate- or key-type. Is that intentional? While most individuals >> will be able to inflate "mancertfile" or "mankey" to manufacturer >> certificate and manufacturer key, respectively, I strongly recommend >> to provide more guidance here - especially in regard to command >> parameters and appropriate hash and cipher algorithms with a low >> footprint. Providing examples here will be beneficial (maybe ECDSA & >> EDDSA). > > Keep in mind that the signature is intended to be consumed by a MUD > controller. This having been said, I'll examine this and see if we can > add guidance. In general, the MUD controller might benefit from canonical guidance what signature to expect and how to verify it. Because, as it seems to be at the moment, the manufacturer decides on this, right? Could getting this information be one of the uses of the extra query? > >> >> ## Nits >> >> What does the expression "relative to XML" intends to convey in "JSON >> is used as a serialization for compactness and readability, relative >> to XML."? > > I don't know about you, but I find XML as easy to parse as binary. I > say, relative to XML because I certainly don't want to claim that JSON > is EASIEST for humans to read. A natural language such as English or > German is far easier. Coming back to the box of worms "easy to read" :) If I look at a raw JSON file without line-breaks it is "impossible" for me to read (aka I can, but it stresses me out). The same way I can read a DevID via a hex viewer (but that also stresses me out). JSON becomes easy to read for me, if I pipe it into jq. A DevID becomes easy to read for me, if I decode it with (admittedly, an appropriate version of) openssl. From a workflow point of view, there is no difference for me, personally. And off-topic and most certainly not intended to be implying the discussed draft: sometimes, the most tedious thing for me to do, is to distill the actual meaning out of easy to read English or German text ;) > >> >> %s/Application\/pkcs7-signature/application\/pkcs7-signature/g >> > > Very good. I hope this answer addresses your issues. > > Eliot > Viele Grüße, Henk From nobody Wed Aug 30 10:21:17 2017 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 07793132386; Wed, 30 Aug 2017 10:21:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150411366399.21627.17047458871931107094@ietfa.amsl.com> Date: Wed, 30 Aug 2017 10:21:04 -0700 Archived-At: Subject: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08 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, 30 Aug 2017 17:21:04 -0000 Reviewer: Robert Sparks Review result: Almost Ready This is an exciting concept, and the draft overall is approachable. I have identified a few areas I think need more detail, and have a longish list of nits (please don't take that to be negative). ==Issues== I find the structure of the introduction unclear. Please consider reworking it. I would suggest even more succinctly listing goals and constraints, and then intended applicability (these things are in the current text, but I think you can render them much more efficiently). In particular, the argument that implementers of things are incented only to provide the minimal amount of behavior to get their thingyness could be more strongly highlighted. The document proposes "reputation services". It needs more words about whether those exist, and what scopes the architecture imagines (an enterprise might have a different idea of a reputation service than a residence). There is a notion of "decent web reputations" in the security considerations section. Who determines that? The security considerations section should talk about attacks against the reputation services. In the first paragraph of Section 2, it's not clear if you are trying to restrict the models to only those in the two documents in the list following the paragraph. I am not a YANG doctor, so this may be in the weeds, but it feels like there's a discrepancy between the diagram at the end of section 2 and the element definitions in section 3. In particular 3.7 doesn't seem to align with what the diagram or the example in Appendix B uses. Should you be defining "from-device-policy" and "to-device-policy" instead of "packet-direction"? (I'm wondering if 3.7 reflects an older design?) At section 3.13, the description of my-controller is not quite right. This bit signals to the mud controller to use a mapping that it knows about or creates. Something else established that class (and maybe gave it a name). I talked about this with Eliot and he has a better description to use. It's not clear to me that this is a good use of .well-known. I suggest getting an expert review on the proposed usage. (I had a quick conversation with Mark Nottingham and got some initial feedback that I'm passing along here. I'm sure there's more that an in-depth review would identify.) Why wouldn't a URI template (RFC6570) do the job? Rather than use RFC3986's query, consider pointing to HTML5 (which would bring the more familiar key=value format). The document needs to say more about how HTTP is used. I assume you only intend to use GET, and that you expect redirects to be followed, and that nothing special needs to be considered with caching? The document needs to be explicit about it. Take a look at . (There's been some conversation about it on the art list, so Eliot, at least, is already aware of it - see ) I think there needs to be more discussion of the PKI used for signing MUD files. Consider discussing whether the stacks used by typical things will let them add DHCP options (or include bits in the other protocols being enabled). If it's well known (I can't say) that these stacks typically _won't_ provide that functionality, then you should punch up the discussion of the controllers mapping other identifiers to MUD URLs on behalf of the thing. You suggest the DHCP Client (which is a thing) SHOULD log or report improper acknowledgments from servers. That's asking a bit much from a thing. I suspect the requirement is unrealistic and should be removed or rewritten to acknowledge that things typically won't do that. The security and deployment considerations sections talk about what the need for coordination if control over the domain name used in the URL changes. It should talk more about what happens if the new administration of the domain is not interested in facilitating a transition (consider the case of a young company with a few thousand start-up-ish things out there that loses a suit over its name). Please discuss whether or not suddenly losing the MUD assisted network configuration is expected to leave the devices effectively cut-off. Right now, you leave the DHCP server (when it's used) responsible for clearing state in the MUD controller. Please discuss what happens when those are distinct elements (as you have in the end of section 9.2) and the DHCP server reboots. Perhaps it would make sense for the DHCP server to hand the length of the lease it has granted to the MUD controller and let the MUD controller clean up on its own? The document currently suggests that a piece of software inspect the WHOIS database to see if registration ownership of a domain has changed. Do you really mean software, or should this be advice to the administrator of the controller instead? ==Nits== I recommend an editorial pass focusing on simplifying sentences. Look particularly where the word "therefore" is used and consider restructuring the surrounds. (It is used non-sequitur in a couple of places). Be careful to call out actors explicitly (I note the places that particularly caught my eye below). Some specific nits: The abstract speaks only about properties of MUD but does not describe what MUD _is_, or is good for. A few more words here would help. Next to last paragraph of section 1 (before 1.1): A means for _who_ to retrieve the description? (Consider rendering the three list elements on their own lines.) The last sentence of section 1 treats "enterprise networks" more specially than it intends, I think. Why couldn't _any_ network do this? Could the sentence be reworded to make it clear that enterprise networks are an example? First sentence of 1.1: Perhaps you mean "general purpose computing devices" instead of "general computing"? "their" has an unclear antecedent. Last paragraph of 1.3: It's unclear what "such an approach" is intended to point to. Would "a general solution that required capabilities their particular device would not use" make more sense? First paragraph of 1.5: "might to allow" is probably meant to be "might be to allow". What does it mean for a controller to "need to speak COAP". Do you mean "controllers capable of speaking COAP"? Fourth paragraph of 1.5 at the discussion of time and effort: Consider rephrasing this to focus on the result of the time and effort (high quality) rather than the time and effort itself. In the list of abstractions at the end of 1.5, you have three things you describe as devices and one thing you describe as a class. You later talk about the abstractions you've described as devices as classes. At this point in the document what you mean by "class" has not been made as explicit as it could be. Section 1.8, item 3: the MUD file doesn't have hosts in it (it has identifiers of some kind). Consider being more explicit about what you mean by testing that against a reputation service. Section 3.1: You say "Which turn was taken". I think you meant "Which, in turn, was taken". Consider deleting "for those keeping score". Section 3.3 is missing a word at "the location any MASA service"? I found the prose in the descriptions of the "manufacturer" and "same-manufacturer" elements (3.8 and 3.9) very confusing. I think additional prose introducing the concepts and maybe some examples would be very useful. What do you mean by "matches" at 3.10. Do you mean "is"? The caution in the 2nd paragraph of 3.12 is not clear. At section 4, consider pointing out that you are not allowing DHCP by default, and that devices that are expected to use DHCP need to have an explicit allow in their MUD file. The description of the manufacturer leaf in the MUD YANG model could be made more useful. Provide a reference for "giaddr" when you use it in section 9.2. Section 14, 2nd paragraph: additional segmentation of what? Second paragraph of Section 15 - it would help to be more precise with agency. _Who_ should review the class? In the security considerations section, when you get to the "if for some reason it is not possible to determine whether ownership has changed", _who_ are you suggesting conduct further review? ==Micro-nits== 1,$s/enorcement/enforcement/g s/autjors/authors/ From nobody Wed Aug 30 15:01:47 2017 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 8EE9F132C2D; Wed, 30 Aug 2017 15:01:40 -0700 (PDT) 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=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 rjceE1cR4ltK; Wed, 30 Aug 2017 15:01:36 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 5FC3113239A; Wed, 30 Aug 2017 15:01:36 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id z91so21869322wrc.1; Wed, 30 Aug 2017 15:01:36 -0700 (PDT) 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=+T7Q6L51NeRK1n4AjvQ2Pjs7eQdrq5lKwzJIajcHE24=; b=Yj44iPYMTTWdRUXtkzaq7eTupHmEonZSi/EmmGttlT8V41IAFr2MfwEXyaimkh5dIu EtrYNxNYLoSlDWfrOfpiBxN39sQiTurhy1uGBmtP62QnPa++6DeqSTXmdwLI5ZgXFbyH fRNxv5E+bWbw9bqfFvzY+kZL4ft/DHT5PrExv/UwEeOxY3Em4Nu7j+PxX1Zu2ZzE75+7 H3g57OplvL97dkmxtiDjMeiw6ZOAlr5RejbRln89xR6b3BY7vEO6HAgRiKPS4keFhcvU NwocAvOUC2izpniiIg05rjTIBYnt+U+6qrKJdESe2++QE1ZhAKnfeos1/x7iFTNV0kkv o5DQ== 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=+T7Q6L51NeRK1n4AjvQ2Pjs7eQdrq5lKwzJIajcHE24=; b=A8k7Re/Izo4V+PjhGB18lRIgmrXwzOq43aBu5pnitpAPgX/lOPQuSn1aZ7HEg83UYx qZpL0JkV6hb48+nulMLwplGru5ySpaLfCDKnvA1He0VOSNONZYDmYHwJ7RNr7PKLXqow TwtsSfSCflO8f0sMNku7joDdCIipNn33/fSNV0I1VHeLuiQbnKrIBjc7Afl1PKTJ1v30 jkrbe7PIpeRm4F59VxN36Due7X4J4hJt7ARW5l7skX76i1OLXHdPXy7AUlf9zuhTNuyT UO1NwGX2oM1nKzujn+4XcxOSf123B+MVE6LXVsdEx9P5pEj7W2+PTx3TGABB5fyPW4QJ r3/g== X-Gm-Message-State: AHYfb5jxV2CZqdJXqeF2d8CeGUWnXugHP9y06vYuchG6Uy/G89rO7ZEl uGV6Tiz3IBUy+NhbEUrBcpjE4i3lriB8 X-Received: by 10.223.143.82 with SMTP id p76mr1693509wrb.261.1504130494642; Wed, 30 Aug 2017 15:01:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.71 with HTTP; Wed, 30 Aug 2017 15:00:53 -0700 (PDT) In-Reply-To: <150411366399.21627.17047458871931107094@ietfa.amsl.com> References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> From: "M. Ranganathan" Date: Wed, 30 Aug 2017 18:00:53 -0400 Message-ID: To: Robert Sparks Cc: gen-art@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary="f403045f4daad43fa80557ffaba3" Archived-At: Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08 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, 30 Aug 2017 22:01:41 -0000 --f403045f4daad43fa80557ffaba3 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks wrote: > > > Right now, you leave the DHCP server (when it's used) responsible for > clearing state in the MUD controller. Please discuss what happens when > those are distinct elements (as you have in the end of section 9.2) and > the DHCP server reboots. Perhaps it would make sense for the DHCP server > to hand the length of the lease it has granted to the MUD controller and > let the MUD controller clean up on its own? > I would like to add a few words to the comprehensive review presented by Robert Sparks (I hope it is proper etiquette on this list to do so). With respect to the observation above: There is also a cache timeout in the MUD profile. Does it make sense that the MUD controller should take the minimum of the DHCP lease time and the cache timeout and use that to time out the installed ACLs (?) The DHCP server should also pass to the MUD controller, some way of identifying the device to which the lease has been granted (for example the MAC address of the device). The draft also not specify how the DHCP server will communicate with the MUD controller (presumably via a simple REST interface but what is the URL to be used and how are the parameters passed?). I think this should be specified for interoperability between DHCP clients and MUD servers. Maybe words describing this interaction can be added here. Thanks, Ranga. > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- M. Ranganathan --f403045f4daad43fa80557ffaba3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks <rjsparks@nostrum.co= m> wrote:

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


-= -
M. Ranganathan
--f403045f4daad43fa80557ffaba3-- From nobody Wed Aug 30 15:03:35 2017 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 0C3F4132C03; Wed, 30 Aug 2017 15:03:20 -0700 (PDT) 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 VliVya8fEbci; Wed, 30 Aug 2017 15:03:17 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 4A400132C2E; Wed, 30 Aug 2017 15:03:17 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id u126so17766500wmg.1; Wed, 30 Aug 2017 15:03:17 -0700 (PDT) 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=l4wZRgVgf6jFPP6U4X4XY1JwLFh4/f0KwaTD+3j5Otk=; b=T32ruub2ear01seLjzvRC8XgGPu0keeDZE1cykiV4fUf5IlYVOAqs94KO9mXCsU2Wt +0X0OGhZAoUr/zhiw247J7fDCWXlVENsJko4UJxC8IWCS5R+gVlc7xP7evXd6R/QJrg/ YasUIXTcGGQTcxRSvY+DMHCnWBo4d3QCFRQJYv/AzPt20xkVIcqZm3ITn03M5wyhu8ko BrSNxPellV6m9BJwe//+3qssptTUg00BL+a17IhquDsjivecZY3nEXNP0DipNL5jMkCp jI8tfBhNLHnMzn8Acs6BkLeLgxXhCSboymjnkS6dp4dxWT6Lrq9GH9Aon6Q/Sb6Qf0SK 9URA== 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=l4wZRgVgf6jFPP6U4X4XY1JwLFh4/f0KwaTD+3j5Otk=; b=uSv1Tjga50B9PhtRzkUUftyYSlGNGrqD3s/zKnyIonZnEo2hvZ41+aZ32EzSGYo02z 4hpcdcygNkv+50ZihyLD22VbvVwQaSIbKgp2kj4Im1+wabgilA2eVH1HXl/+1rWLZNVW SqE+0yzAMfzomZMLS3sy4fyIa3AIH+im7OMxh74TIFMQnVJA1OB1Zvxpp/l9lZSGJ3t/ lxXBVczUBeKGAv8zgYF6QZNkhE/7D0FLQXHjQSTyjx6ZHu5/JIBH1eW8AAQPbq5ue2BF +kkQbW92FcnfIrhycVK+fyQ2/o3Y3UDlXYuoJ/mE1OZbGhnyK1bNc5AXJnje8oS6woz7 xlAg== X-Gm-Message-State: AHYfb5g5xdq2ufaWbY8sibS02wqYEfvt+0rm+wi6aQbeMvbxByjF3cqM V4dZwFv+ufB8QeiU8wHkzXn/KKUpBA== X-Received: by 10.28.167.131 with SMTP id q125mr2470643wme.11.1504130595678; Wed, 30 Aug 2017 15:03:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.71 with HTTP; Wed, 30 Aug 2017 15:02:35 -0700 (PDT) In-Reply-To: References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> From: "M. Ranganathan" Date: Wed, 30 Aug 2017 18:02:35 -0400 Message-ID: To: Robert Sparks Cc: gen-art@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary="001a114b9bdcd9ecf20557ffb18c" Archived-At: Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08 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, 30 Aug 2017 22:03:20 -0000 --001a114b9bdcd9ecf20557ffb18c Content-Type: text/plain; charset="UTF-8" On Wed, Aug 30, 2017 at 6:00 PM, M. Ranganathan wrote: > > > On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks > wrote: > >> >> >> Right now, you leave the DHCP server (when it's used) responsible for >> clearing state in the MUD controller. Please discuss what happens when >> those are distinct elements (as you have in the end of section 9.2) and >> the DHCP server reboots. Perhaps it would make sense for the DHCP server >> to hand the length of the lease it has granted to the MUD controller and >> let the MUD controller clean up on its own? >> > > I would like to add a few words to the comprehensive review presented by > Robert Sparks (I hope it is proper etiquette on this list to do so). > > With respect to the observation above: > > There is also a cache timeout in the MUD profile. Does it make sense that > the MUD controller should take the minimum of the DHCP lease time and the > cache timeout and use that to time out the installed ACLs (?) The DHCP > server should also pass to the MUD controller, some way of identifying the > device to which the lease has been granted (for example the MAC address of > the device). > > The draft also not specify how the DHCP server will communicate with the > MUD controller (presumably via a simple REST interface but what is the URL > to be used and how are the parameters passed?). I think this should be > specified for interoperability between DHCP clients and MUD servers. Maybe > words describing this interaction can be added here. > Sorry: I meant interoperability between DHCP servers and MUD controllers above. > > Thanks, > > Ranga. > > > >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > -- > M. Ranganathan > -- M. Ranganathan --001a114b9bdcd9ecf20557ffb18c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 30, 2017 at 6:00 PM, M. Ranganathan <<= a href=3D"mailto:mranga@gmail.com" target=3D"_blank">mranga@gmail.com&g= t; wrote:


On = Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks <rjsparks@nostrum.com= > wrote:

Right now, you leave the DHCP server (when it's used) responsible for clearing state in the MUD controller. Please discuss what happens when
those are distinct elements (as you have in the end of section 9.2) and
the DHCP server reboots. Perhaps it would make sense for the DHCP server to hand the length of the lease it has granted to the MUD controller and let the MUD controller clean up on its own?

=
I would like to add a few words to the comprehensive review pre= sented by Robert Sparks (I hope it is proper etiquette on this list to do s= o).

With respect to the observation above:
=
There is also a cache timeout in the MUD profile. Does it make sense=C2= =A0 that the MUD controller should take the minimum of the DHCP lease time = and the cache timeout and use that to time out the installed ACLs (?) The D= HCP server should also=C2=A0 pass to the MUD controller, some way of identi= fying the device to which the lease has been granted (for example the MAC a= ddress of the device).

The draft also not specify how th= e DHCP server will communicate with the MUD controller (presumably via a si= mple REST interface but what is the URL to be used and how are the paramete= rs passed?). I think this should be specified for interoperability between = DHCP clients and MUD servers. Maybe words describing this interaction can b= e added here.

S= orry: I meant interoperability between DHCP servers and MUD controllers abo= ve.
=C2=A0

Thank= s,

Ranga.

=C2=A0

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

--
M. Ranganathan



--
M. Ranganathan
--001a114b9bdcd9ecf20557ffb18c-- From nobody Wed Aug 30 19:02:22 2017 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 932DB12008A for ; Wed, 30 Aug 2017 19:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 p9F7q_IUcioo for ; Wed, 30 Aug 2017 19:02:14 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 254B6124207 for ; Wed, 30 Aug 2017 19:02:14 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id nEnpdMlJO0qIUnEo8dTSv0; Thu, 31 Aug 2017 02:02:12 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-18v.sys.comcast.net with SMTP id nEo7diKwg0EZInEo7da7Sy; Thu, 31 Aug 2017 02:02:12 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v7V22APD021285; Wed, 30 Aug 2017 22:02:10 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v7V229hs021282; Wed, 30 Aug 2017 22:02:09 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: gen-art@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org, mranga@gmail.com, Robert Sparks In-Reply-To: <150411366399.21627.17047458871931107094@ietfa.amsl.com> (rjsparks@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 30 Aug 2017 22:02:09 -0400 Message-ID: <87shg8fqam.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBK4GTPIGch3KjJ2fBr5XEi2qlesAQRaXHZM9x4W90G2h/s2+jrwT7m3Pu/xQKaMfsvYHroOSwScdFFpghuUTEs9F/zrJeFodE8ZtLFXO2ezQveHnt1G S0+TH07ULVrjburw9LVT4QxaQ4ZLLeVzZjZFfe/JzgWNndzHoULFWY8b7pDpQ/ZOoG+AwGXY1T80+ljPcPX1VT5HlAKZLmDxxJK9IZg4o2Sr/avwLvktAyck dKfRe6AdomKY+jd/xpxqsLJoP7eALpyM1nfS32zwDLQ28tg2VvYvzGtjQSbLU5odX9MdrH5aHgHxkoQYbw0Bng== Archived-At: Subject: Re: [OPSAWG] [Gen-art] Genart early review of draft-ietf-opsawg-mud-08 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, 31 Aug 2017 02:02:16 -0000 This draft raises some fascinating questions. One is "How do we ensure that the manufacturer cannot proscribe the uses of a device that it is capable of and that its purchaser desires?" Another is "How do we ensure that the manufacturer cannot reduce the permitted uses of the device after its purchase?" Dale From nobody Thu Aug 31 00:16:04 2017 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 81733132D18; Thu, 31 Aug 2017 00:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, 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 dcIE0DSjpvqT; Thu, 31 Aug 2017 00:15:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681B1132D13; Thu, 31 Aug 2017 00:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1201; q=dns/txt; s=iport; t=1504163748; x=1505373348; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tQ+gD5jtIXktfWp9vtPK4f0L7IQdQdXbCaWKd+8eWOI=; b=NDDSkayDDWIVOfetkk2AVO8WLWupVIVCjRXbf3kJkQPLAeOxGIn9AnQk Couq7IjkkfHuR/lyB22/d7pyXyre8CGVkKoR3rLIIkjQwWaLH6TgsPHNK 90eEK78VyMhmJUoYTo8I4lcEaaJKkAKQ5kjU6IIb4Dm8MQrDSu27XprZM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAQBvtqdZ/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZIEVnjWBcZYnghIhC4FggmxPAoQrQBcBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQE4NAsFCwIBCBgeECcLJQIEDgWKKQgQsUWLQwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgyqCAoNcgkg1hHWDQ4IxBYoPlmAClE+CE5BbiXiMTAEhAzO?= =?us-ascii?q?BDXcVSRIBhwh2ij0BAQE?= X-IronPort-AV: E=Sophos;i="5.41,451,1498521600"; d="scan'208";a="279212680" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2017 07:15:47 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v7V7Flod010610 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 07:15:47 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 03:15:46 -0400 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1263.000; Thu, 31 Aug 2017 03:15:46 -0400 From: "Einar Nilsen-Nygaard (einarnn)" To: "Dale R. Worley" CC: "gen-art@ietf.org" , "draft-ietf-opsawg-mud.all@ietf.org" , "opsawg@ietf.org" , "ietf@ietf.org" , "mranga@gmail.com" , Robert Sparks Thread-Topic: [OPSAWG] [Gen-art] Genart early review of draft-ietf-opsawg-mud-08 Thread-Index: AQHTIf1EDowo5AKrbEuACYGVNIL1daKeDfNe Date: Thu, 31 Aug 2017 07:15:46 +0000 Message-ID: <25FFA75E-330B-4A5A-B6B9-D1817A86D7B2@cisco.com> References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> (rjsparks@nostrum.com),<87shg8fqam.fsf@hobgoblin.ariadne.com> In-Reply-To: <87shg8fqam.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSAWG] [Gen-art] Genart early review of draft-ietf-opsawg-mud-08 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, 31 Aug 2017 07:15:50 -0000 I think we need to bear in mind that the MUD files constitute recommendatio= ns for how a device should be treated and what policies/security should be = applied to it by a network. This draft, in itself, cannot allow a manufactu= rer to actually proscribe anything. Today, the only way to achieve what you= note below, AFAIK, is for the device to have a software update of some kin= d applied to it. Also, we could also argue that a manufacturer-published MUD file actually h= as the potential to increase transparency as it should explicitly define th= e traffic flows required for "proper operations". Cheers, Einar > On Aug 31, 2017, at 03:02, Dale R. Worley wrote: >=20 > This draft raises some fascinating questions. One is "How do we ensure > that the manufacturer cannot proscribe the uses of a device that it is > capable of and that its purchaser desires?" Another is "How do we > ensure that the manufacturer cannot reduce the permitted uses of the > device after its purchase?" >=20 > Dale >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Thu Aug 31 01:41:40 2017 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 C0B67132620; Thu, 31 Aug 2017 01:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 hgd3xnssRLaG; Thu, 31 Aug 2017 01:41:31 -0700 (PDT) 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 D88C8132358; Thu, 31 Aug 2017 01:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8823; q=dns/txt; s=iport; t=1504168890; x=1505378490; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=WK2LzKZOb0zgqg2jYdZ9Hpa6qyPK0Lrh6HBZOFfnWG0=; b=RbFj9UOYfKBdZ207GDMvut6TZXne4ZJ0E7RNsxZXM/vquPMK52j6aNjM gxtHWG2GbBcXiSTYUXjfUuWsPPgOIn05AelCyzrfggBlvknvCr2rZyQAd ZUYWFdO8Ihn/EnlWSzEao+kUBBhj8hWHO7X/paWmB1CqlTrYElqBUdEEL A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEAwAJy6dZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy2CJoN3ixSQeSKQaYU+ghIHhUAChGwWAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FI1YQCxgnAwICRhEGAQwGAgEBii2wHYInJ4sdAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBDg+DKoVeC4FlgQ2EX4MpgmEBBKBvhDmCIY13ghOFZ4NZhxuWRSYFLIENMiE?= =?us-ascii?q?IHBVJhRgcgWk+Noo9AQEB?= X-IronPort-AV: E=Sophos;i="5.41,451,1498521600"; d="asc'?scan'208,217";a="696869282" 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; 31 Aug 2017 08:41:25 +0000 Received: from [10.61.80.230] (ams3-vpn-dhcp4327.cisco.com [10.61.80.230]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7V8fOHi030151; Thu, 31 Aug 2017 08:41:25 GMT To: "M. Ranganathan" , Robert Sparks Cc: gen-art@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> From: Eliot Lear Message-ID: <8a26b512-495b-4315-a885-32acd41c5460@cisco.com> Date: Thu, 31 Aug 2017 10:41:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0qe0LOGonjdSE19rTg8FL8PgpeM1CSBp1" Archived-At: Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08 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, 31 Aug 2017 08:41:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0qe0LOGonjdSE19rTg8FL8PgpeM1CSBp1 Content-Type: multipart/mixed; boundary="bcHIUviXj0h4b1KO2Txhro1v43MXr30kT"; protected-headers="v1" From: Eliot Lear To: "M. Ranganathan" , Robert Sparks Cc: gen-art@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Message-ID: <8a26b512-495b-4315-a885-32acd41c5460@cisco.com> Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08 References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> In-Reply-To: --bcHIUviXj0h4b1KO2Txhro1v43MXr30kT Content-Type: multipart/alternative; boundary="------------7ACAF6105FDD6C8F1A23D99D" Content-Language: en-US This is a multi-part message in MIME format. --------------7ACAF6105FDD6C8F1A23D99D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ranga, Robert wrote a great review, and I'll respond to him in due course with suggested changes.=C2=A0 I wanted to take just a moment to comment to you= on your point: On 8/31/17 12:00 AM, M. Ranganathan wrote: > > > On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks > wrote: > > > > Right now, you leave the DHCP server (when it's used) responsible f= or > clearing state in the MUD controller. Please discuss what happens w= hen > those are distinct elements (as you have in the end of section > 9.2) and > the DHCP server reboots. Perhaps it would make sense for the DHCP > server > to hand the length of the lease it has granted to the MUD > controller and > let the MUD controller clean up on its own? > > > I would like to add a few words to the comprehensive review presented > by Robert Sparks (I hope it is proper etiquette on this list to do so).= > > With respect to the observation above: > > There is also a cache timeout in the MUD profile. Does it make sense=C2= =A0 > that the MUD controller should take the minimum of the DHCP lease time > and the cache timeout and use that to time out the installed ACLs (?) > The DHCP server should also=C2=A0 pass to the MUD controller, some way = of > identifying the device to which the lease has been granted (for > example the MAC address of the device). > > The draft also not specify how the DHCP server will communicate with > the MUD controller (presumably via a simple REST interface but what is > the URL to be used and how are the parameters passed?). I think this > should be specified for interoperability between DHCP clients and MUD > servers. Maybe words describing this interaction can be added here. That's right.=C2=A0 At the moment, this is an "internalized" function.=C2= =A0 That is to say that the DHCP server is said to be tightly coupled to the MUD controller without standardized interfaces.=C2=A0 In my first implementat= ion, I literally just tailed dhcpd syslog entries and triggered MUD based on DHCPREQUEST messages.=C2=A0 Clean-up state had to do with RELEASE or peri= odic SNMP queries.=C2=A0 Our implementation at Cisco does something different.= However... if the OPSAWG would like, and there is interest, we can formalize that interface.=C2=A0 I don't want to do it in THIS draft (it's= already fairly involved), but there's nothing to say we couldn't do some follow-on work. Fair enough? Eliot --------------7ACAF6105FDD6C8F1A23D99D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Ranga,

Robert wrote a great review, and I'll respond to him in due course with suggested changes.=C2=A0 I wanted to take just a moment= to comment to you on your point:


On 8/31/17 12:00 AM, M. Ranganathan wrote:


On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks <rjsparks@nostrum.com> wrote:


Right now, you leave the DHCP server (when it's used) responsible for
clearing state in the MUD controller. Please discuss what happens when
those are distinct elements (as you have in the end of section 9.2) and
the DHCP server reboots. Perhaps it would make sense for the DHCP server
to hand the length of the lease it has granted to the MUD controller and
let the MUD controller clean up on its own?

I would like to add a few words to the comprehensive review presented by Robert Sparks (I hope it is proper etiquette on this list to do so).

With respect to the observation above:

There is also a cache timeout in the MUD profile. Does it make sense=C2=A0 that the MUD controller should take the minimum of the DHCP lease time and the cache timeout and use that to time out the installed ACLs (?) The DHCP server should also=C2=A0 pass to the MUD controller, some w= ay of identifying the device to which the lease has been granted (for example the MAC address of the device).

The draft also not specify how the DHCP server will communicate with the MUD controller (presumably via a simple REST interface but what is the URL to be used and how are the parameters passed?). I think this should be specified for interoperability between DHCP clients and MUD servers. Maybe words describing this interaction can be added here.

That's right.=C2=A0 At the moment, this is an "internalized" function= =2E=C2=A0 That is to say that the DHCP server is said to be tightly coupled to the MUD controller without standardized interfaces.=C2=A0 In my first= implementation, I literally just tailed dhcpd syslog entries and triggered MUD based on DHCPREQUEST messages.=C2=A0 Clean-up state had= to do with RELEASE or periodic SNMP queries.=C2=A0 Our implementation at= Cisco does something different.

However... if the OPSAWG would like, and there is interest, we can formalize that interface.=C2=A0 I don't want to do it in THIS draft (= it's already fairly involved), but there's nothing to say we couldn't do some follow-on work.

Fair enough?

Eliot
--------------7ACAF6105FDD6C8F1A23D99D-- --bcHIUviXj0h4b1KO2Txhro1v43MXr30kT-- --0qe0LOGonjdSE19rTg8FL8PgpeM1CSBp1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZp8u4AAoJEIe2a0bZ0nozDTsH+QHLJuJDZ+8NukV0ymJeXV9C erUw1YFMaTHOAvdKjjvzE1Kv5S4sJmaGn2Y0WhT5ha878xEOx/dfhd4LMtN4JUkP WuaTHSaLsVrjQkWsQ0BKERLuMVBwz69o/jb+cNXBTn/h+lA79Ufs0L8EarKb0T6s FSlwCAlGvhBUVbW0/HHJJIKBfcxhU416IAYBiIE1Q6YNrYJMsl0KdE652GW8HaRz +gMqjtJ145GYcQs+hDLPtvtt/a1ixDCVf91WSZx1cGA5bg70kufqR76e8/yBEk2t o8kPJwTPVJpeCBsZOTFzZ/eL1vQ1Z5IPBcGzxUhZq00Bgmq1yL1nwdusuIJsdYc= =F8Zk -----END PGP SIGNATURE----- --0qe0LOGonjdSE19rTg8FL8PgpeM1CSBp1-- From nobody Thu Aug 31 04:52:47 2017 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 B5192132D5A; Thu, 31 Aug 2017 04:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 aOZiyTwObq_X; Thu, 31 Aug 2017 04:52:42 -0700 (PDT) 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 56581132D56; Thu, 31 Aug 2017 04:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11500; q=dns/txt; s=iport; t=1504180361; x=1505389961; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=fCGQCeYObVEIGbWnsSz5JEb6E3QWKPAFZlgRK4Z8S7U=; b=Ad0oy1NKu2eGhwuj98kRD+X9pXGfzaO9Vf1kUWggDoW1aBd0atTF94sz HvtuUpo5uUrz5xVelgAEAsehrsLMQZNPj7gXZhN1cElLpqVekhiERMGV8 pSfXWbrz3fyhMhK5s8rfPqZ9c0t3Gq8U2uqP6zb8io44KCcwulHaRvboT Q=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AACq96dZ/xbLJq1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYlKiiB0kRuWJw6CBAeFQAKEVRgBAgEBAQEBAQFrKIUYAQEBAQI?= =?us-ascii?q?BI1YFCwkCEgYqAgJJDgYBDAgBAYolCJEjnWaCJ4tFAQEBAQEBAQMBAQEBAQEBA?= =?us-ascii?q?REPgyYEhTMrgn2EORIUgymCYQEEig+WYIQ5giGNd4IThWeDWYcbiXiMTR84gQ0?= =?us-ascii?q?yIQgcFUmFFwEcgWk+inMBAQE?= X-IronPort-AV: E=Sophos;i="5.41,453,1498521600"; d="asc'?scan'208";a="696873444" 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; 31 Aug 2017 11:52:36 +0000 Received: from [10.61.80.230] (ams3-vpn-dhcp4327.cisco.com [10.61.80.230]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7VBqaSI000855; Thu, 31 Aug 2017 11:52:36 GMT To: Henk Birkholz , iot-dir Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, Robert Sparks References: <32f3d662-ce1e-47a6-d239-f8004ebfb1d8@cisco.com> From: Eliot Lear Message-ID: <72d87c83-724c-c006-fd17-e116ee686ea5@cisco.com> Date: Thu, 31 Aug 2017 13:52:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iw2pMmcIx8k7gNSItixaC5J0uVTC2XM5m" Archived-At: Subject: Re: [OPSAWG] IoT-DIR early review of draft-ietf-opsawg-mud-08 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, 31 Aug 2017 11:52:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iw2pMmcIx8k7gNSItixaC5J0uVTC2XM5m Content-Type: multipart/mixed; boundary="5KE5Cm2S8ekGWUP3FG6SHAE69d8dr06io"; protected-headers="v1" From: Eliot Lear To: Henk Birkholz , iot-dir Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, Robert Sparks Message-ID: <72d87c83-724c-c006-fd17-e116ee686ea5@cisco.com> Subject: Re: IoT-DIR early review of draft-ietf-opsawg-mud-08 References: <32f3d662-ce1e-47a6-d239-f8004ebfb1d8@cisco.com> In-Reply-To: --5KE5Cm2S8ekGWUP3FG6SHAE69d8dr06io Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Henk, On 8/30/17 6:50 PM, Henk Birkholz wrote: > Hello Eliot, > > thank you for your fast feedback! I still have some comments and > questions for another round, though. I hope that is okay - please see > comments in-line. Soon, please. > >> Ok, but a cautionary note: this draft intentionally focuses NOT on >> giving the Thing guidance but on giving the *network* guidance.=C2=A0 = That >> isn't to say that Things couldn't derive guidance from extensions to t= he >> model (we'll talk about that below), but at the moment, the pain point= >> is protecting them. > > This has to be clearly stated in the abstract and the introduction, I > think. From my point of view, filter rules that are disabler and > enabler of communication are a very specific subset of imperative > network guidance, which are a distinct subset of the the usage > descriptions a manufacturer would want to provide for a thing. > Taken together with Robert's comments, I'm proposing the following change= s: The abstract: OLD: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). This includes 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. NEW: > 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.=C2=A0 The initial focu= s is > on access control.=C2=A0 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. > Maybe an example on how to include a trivial non-ACL-focussed > extension into the module via an (exemplary/bogus) augment would > clarify how to include "other" content in a MUD file. A corresponding > example of a JSON instance (MUD file) that then includes content > defined by the augment would also be beneficial, I think. > > Would that be okay? > Ok, with the understanding that it is illustrative.=C2=A0 Someone who sha= ll remain nameless for just the moment talked about an indicator as to whether DETNET is used.=C2=A0 I've done that, complete with serialization= for the new draft.=C2=A0 Ironically for brevity purposes, I will not include = it here ;-) >> >> On the second point, one reason for referencing information is so that= >> the underlying information can change as needed without the need to >> change the URL itself.=C2=A0 While it may be possible in some instance= s to >> update the URL, this will not always be the case.=C2=A0=C2=A0 Consider= that the >> URL may be inside a signed certificate that is burned into the device.= >> This having been said, we leave open the possibility that the MUD >> controller may wish to modify the URI through "extras".=C2=A0 See belo= w for >> more details. > > Please also consider that the URI can be composed. Most of its parts > (segments, etc.) are probably represented redundantly in a DevID or > can be inferred from context (MUD controller, domain, etc.). For > example, you could get the content of most of the segments out of the > attributes that are already stored in the DevID and just include the > "missing additional parts" in a specific "mud-attribute". This is > possible, because there is a precise rule how to compose the MUD URI > canonically. Next to "arcance content" and unnecessary verbose > encoding, redundancy inside Identity Documents is a problem the > constrained-node network world is struggling with. > > Also, this "burning in" is only effecting content of URI path segments > that are to be defined by the manufacturer. If there would be a > canonical tree of paths coming after the > >> "/.well-known/mud/" mud-rev "/" model > > e.g. a set of paths segments/branches, such as > >> "/" acl|rim|composition > > then there would be no problem to provide semantic separate MUD files, > because it would be the canonical URI where to find them - > circumventing the "burned into the device" issue. You only need to > find the "burned in" values to compose your canonical MUD URI. A task > presumably conducted by the MUD controller. Would that be correct? > Right.=C2=A0 We discussed this in the working group, and substantial issu= es developed, mostly around versioning.=C2=A0 On the whole we must be very cautious in these circumstances around composibility, especially when it introduces either linkage or complexity.=C2=A0 This, to be sure, is a tra= deoff. {{json readability discussion elided}} > >>> >>> In the scope of the extensibility feature highlighted, is it intended= >>> that every MUD file must contain content that relates to the structur= e >>> of a YANG module (or are there other data models for data at rest >>> planned for)? >> >> If the extension augments the YANG module then, well, yes ;-)=C2=A0 On= the >> other hand, if the extension is a reference to something else, then th= e >> rules are up to that "something else".=C2=A0 Let's take an example.=C2= =A0 Suppose >> there is an extension that points to some form of WoT/schema.org-based= >> description.=C2=A0 That description could be in the form of a URN, tha= t a >> network might use to populate a CoAP resource directory, that other >> Things could then retrieve.=C2=A0 The rules for the form of all of tha= t would >> be well outside the scope of MUD, which would be a good thing, because= I >> just referenced a bunch of stuff that you know a lot more about than I= >> do ;-)=C2=A0 All the encoding rules and semantics are left to you to d= efine. >> At that point, a network management system would have to obey your >> semantics if the device wants want to play. >> >> If you like the above text, we could add something like it. > > Yes please. I actually thought that this was out-of-scope at the moment= =2E > As it happens, we have something of a good example of how that might be done, already in the draft.=C2=A0 It's the masa-server node.=C2=A0 There = we don't attempt to define all the semantics of BRSKI, but instead simply reference the work.=C2=A0 One could easily do that again as an extension.= =C2=A0 Therefore, I propose the following text: OLD: > This optional leaf-list names MUD extensions that are used in the MUD > file. > Note that NO MUD extensions may be used in a MUD file prior to the > extensions > being declared.=C2=A0 Implementations MUST ignore any elements in this = file > that > they do not understand. NEW: > This optional leaf-list names MUD extensions that are used in the MUD > file. > Note that NO MUD extensions may be used in a MUD file prior to the > extensions > being declared.=C2=A0 Implementations MUST ignore any node in this file= that > they do not understand. The extensions list MUST appear prior to > extension use. > > Note that extensions can either extend the MUD file as described in > the previous paragraph, or they might reference other work.=C2=A0 A goo= d > example of how this might be done is the masa-server URI that is > defined in the base model.=C2=A0 We say nothing about the semantics of = that > work here, but rather leave that to the underlying specification found = in > {{I-D.anima-bootstrapping-keyinfra}}. {{snip}} >>> "extras" is intended for use by the MUD controller to provide >>> additional information such as posture about the Thing to the MUD fil= e >>> server.=C2=A0=C2=A0=C2=A0=C2=A0 This field MUST not be configured on = the Thing itself by a >>> manufacturer - that is what "modelinfo" is for.=C2=A0 It is left as f= uture >>> work to define the full semantics of this field. > > Could you please provide an example of "posture about the Thing" that > could be requested as an option from the MUD file server by the MUD > controller? I am still not really sure what to make of it. If this is > future work in the scope of this draft, we can just revisit this at a > later point. Sure.=C2=A0 Think about NEA values as parameters (RFC 5209) as an example= =2E > >> >>> >>> ### Signing MUD files >>> >>> The given openssl example basically allows for every kind of >>> certificate- or key-type. Is that intentional? While most individuals= >>> will be able to inflate "mancertfile" or "mankey" to manufacturer >>> certificate and manufacturer key, respectively, I strongly recommend >>> to provide more guidance here - especially in regard to command >>> parameters and appropriate hash and cipher algorithms with a low >>> footprint. Providing examples here will be beneficial (maybe ECDSA & >>> EDDSA). >> >> Keep in mind that the signature is intended to be consumed by a MUD >> controller.=C2=A0 This having been said, I'll examine this and see if = we can >> add guidance. > > In general, the MUD controller might benefit from canonical guidance > what signature to expect and how to verify it. Because, as it seems to > be at the moment, the manufacturer decides on this, right? Could > getting this information be one of the uses of the extra query? I'm not particularly comfortable with that for a few reasons, the first of which is that this seems like a possible downgrade attack, should the device specify weak algorithm choices, and the second is that CMS is already self-contained.=C2=A0 Again, let's ponder your original point a b= it. Eliot --5KE5Cm2S8ekGWUP3FG6SHAE69d8dr06io-- --iw2pMmcIx8k7gNSItixaC5J0uVTC2XM5m Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZp/iIAAoJEIe2a0bZ0noz3L0IAI+UpUDSAfiL9y4VTUvUpbet frl4jzWqsHN1izHs0qg5VzKwvd80q2oZi347dgty3j/K3Ve7iHsmB4pJKNXScwq9 tMPmtp580Im/r5EcLtZuztKrsgo2ayE1lDULH9Q32HHmqHV1YEA1ltZSkfayXylT +VBpQlrIP9KVccWbZ6IXX6kVzZWxgizEKVE8WXPLCQjsN/sUojdvx8rD/eIjafCn fcwQddSL149qd7kDlNmKlxW4t0cTWUp4e5YcQXNeJLGGPTmQqBGdOMhiqoIVIkL5 /tbYUNX052LlV8MCdBMDDgkWO37urW428ATKVeDQL7n88TzUAU6+ovkgmFvkNZY= =bL8i -----END PGP SIGNATURE----- --iw2pMmcIx8k7gNSItixaC5J0uVTC2XM5m-- From nobody Thu Aug 31 07:39:34 2017 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 7D6E8132DF0; Thu, 31 Aug 2017 07:39:12 -0700 (PDT) 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=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 TPa7L4sAbQcd; Thu, 31 Aug 2017 07:39:10 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 659C8132E13; Thu, 31 Aug 2017 07:39:07 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id v2so6285104wmf.0; Thu, 31 Aug 2017 07:39:07 -0700 (PDT) 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=It9yk55Cg9x59By8gfRA1zp0v4KLs7UIz40Zw4xeD1g=; b=AjaTQkH2I5Tl31T+03GbPYVrcDsOsdy66ASICKClysQ6dZjeGOyg52KTQPygRDAb/d idQDXIkQ6/PgvhxJqdIrtzmeKZPe70LuJUl1DfRG4nI+cHXgCc17zux5Q6+V596f4Wg2 yDEgeO0Kj/mmz4gyeLrmMBXbD4adt/JqDWKmJXc55fYb/mR83WvYSMb+vSUqkjXOE1fK 4l2CV1xJVrRofeBmO5EiyjrPEysi4bovAhUmawbUcWXZHTH6BIY3ifNUUYffHp6FezsF Jdtgw0WiYSK1HRIv3NozPP1bo6cPJOs7Z4BztARWYdDtX9sNxCj/SUv4nycz773Xnthx CIDw== 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=It9yk55Cg9x59By8gfRA1zp0v4KLs7UIz40Zw4xeD1g=; b=uEAuMRFGzDw2+AOIqZXHrg+xsEUCMme5FCqbixvxy93qqp2cSRMbRPvLAaLnmmBU2Y Cl9NHVk9CN7jLkf6hE01Lbv9l2noisLu0h7A96ogTNaP+e8dEONVSkWWQ1r+1/kbIwCl kPRfgbzvrSQsVeK25W+ILXU7xY1eN+8HDIseEktS1bnVspBsBzeM1EoESk1BFRORqWJC hhBtBrzx9a8FQ/cYjkfb4+88HomWFQRBfp4HOVVFZC9IR5quBZ9NrJb+asbypyy6Ozni S+OThYhYdyM3uq9Vedkz4Rjzt0QkZ/EN6CoVF/xHTxlM2srzDzlR88fGx54cPtVnzWpS A6iQ== X-Gm-Message-State: AHPjjUiq8g6ODlje22/oYUa/kisOoCZYNoOMpDgLWGw8rIrr//8IxDKY NhhvQ2YL1zTwfsGAMfgyHQOYqWgO3Q== X-Google-Smtp-Source: ADKCNb7zbhHE2Ulc3DVXkk4nmfGIHnXxu1R0sxAlirDfGtqhkFcBWXQRa1J1R7HQUuiOC5npM/nOIGU/onWoMFrRNnc= X-Received: by 10.28.95.134 with SMTP id t128mr624749wmb.67.1504190345428; Thu, 31 Aug 2017 07:39:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.71 with HTTP; Thu, 31 Aug 2017 07:38:24 -0700 (PDT) In-Reply-To: <8a26b512-495b-4315-a885-32acd41c5460@cisco.com> References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> <8a26b512-495b-4315-a885-32acd41c5460@cisco.com> From: "M. Ranganathan" Date: Thu, 31 Aug 2017 10:38:24 -0400 Message-ID: To: Eliot Lear Cc: Robert Sparks , gen-art@ietf.org, draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Content-Type: multipart/alternative; boundary="001a1148e96e36c57605580d9b61" Archived-At: Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08 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, 31 Aug 2017 14:39:12 -0000 --001a1148e96e36c57605580d9b61 Content-Type: text/plain; charset="UTF-8" Hi Eliot, Reply in line below: On Thu, Aug 31, 2017 at 4:41 AM, Eliot Lear wrote: > Hi Ranga, > > Robert wrote a great review, and I'll respond to him in due course with > suggested changes. I wanted to take just a moment to comment to you on > your point: > > On 8/31/17 12:00 AM, M. Ranganathan wrote: > > > > On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks > wrote: > >> >> >> Right now, you leave the DHCP server (when it's used) responsible for >> clearing state in the MUD controller. Please discuss what happens when >> those are distinct elements (as you have in the end of section 9.2) and >> the DHCP server reboots. Perhaps it would make sense for the DHCP server >> to hand the length of the lease it has granted to the MUD controller and >> let the MUD controller clean up on its own? >> > > I would like to add a few words to the comprehensive review presented by > Robert Sparks (I hope it is proper etiquette on this list to do so). > > With respect to the observation above: > > There is also a cache timeout in the MUD profile. Does it make sense that > the MUD controller should take the minimum of the DHCP lease time and the > cache timeout and use that to time out the installed ACLs (?) The DHCP > server should also pass to the MUD controller, some way of identifying the > device to which the lease has been granted (for example the MAC address of > the device). > > The draft also not specify how the DHCP server will communicate with the > MUD controller (presumably via a simple REST interface but what is the URL > to be used and how are the parameters passed?). I think this should be > specified for interoperability between DHCP clients and MUD servers. Maybe > words describing this interaction can be added here. > > > That's right. At the moment, this is an "internalized" function. That is > to say that the DHCP server is said to be tightly coupled to the MUD > controller without standardized interfaces. In my first implementation, I > literally just tailed dhcpd syslog entries and triggered MUD based on > DHCPREQUEST messages. Clean-up state had to do with RELEASE or periodic > SNMP queries. Our implementation at Cisco does something different. > > However... if the OPSAWG would like, and there is interest, we can > formalize that interface. I don't want to do it in THIS draft (it's > already fairly involved), but there's nothing to say we couldn't do some > follow-on work. > > Fair enough? > > Eliot > No problem with waiting to see if there's interest from OPSAWG and others before considering this. By way of explanation on why I think this makes sense to standardize in MUD: I had envisioned an architecture where the MUD controller runs in the Service Provider cloud. The DHCP server would run in the CPE router (e.g. as part of the firmware on a home router + NAT ). If the statement above makes sense, since the home router is typically not made by the same party as the service provider software, I was thinking there should be a standardized interface between the DHCP server and MUD controller. Thanks. Ranga -- M. Ranganathan --001a1148e96e36c57605580d9b61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eliot,

Reply in line below:
<= div>

On Thu, = Aug 31, 2017 at 4:41 AM, Eliot Lear <lear@cisco.com> wrote:
=
=20 =20 =20

Hi Ranga,

Robert wrote a great review, and I'll respond to him in due course with suggested changes.=C2=A0 I wanted to take just a moment t= o comment to you on your point:


On 8/31/17 1= 2:00 AM, M. Ranganathan wrote:
=20


On Wed, Aug 30, 2017 at 1:21 PM, Robert Sparks <rjsparks@nostrum.com> wrote:


Right now, you leave the DHCP server (when it's used) responsible for
clearing state in the MUD controller. Please discuss what happens when
those are distinct elements (as you have in the end of section 9.2) and
the DHCP server reboots. Perhaps it would make sense for the DHCP server
to hand the length of the lease it has granted to the MUD controller and
let the MUD controller clean up on its own?

I would like to add a few words to the comprehensive review presented by Robert Sparks (I hope it is proper etiquette on this list to do so).

With respect to the observation above:

There is also a cache timeout in the MUD profile. Does it make sense=C2=A0 that the MUD controller should take the minimum of the DHCP lease time and the cache timeout and use that to time out the installed ACLs (?) The DHCP server should also=C2=A0 pass to the MUD controller, some way of identifying the device to which the lease has been granted (for example the MAC address of the device).

The draft also not specify how the DHCP server will communicate with the MUD controller (presumably via a simple REST interface but what is the URL to be used and how are the parameters passed?). I think this should be specified for interoperability between DHCP clients and MUD servers. Maybe words describing this interaction can be added here.

 That's right.=C2=A0 At the moment, this is an "internalized&qu= ot; function.=C2=A0 That is to say that the DHCP server is said to be tightly coupled to the MUD controller without standardized interfaces.=C2=A0 In my first implementation, I literally just tailed dhcpd syslog entries and triggered MUD based on DHCPREQUEST messages.=C2=A0 Clean-up state had t= o do with RELEASE or periodic SNMP queries.=C2=A0 Our implementation at Cisco does something different.

However... if the OPSAWG would like, and there is interest, we can formalize that interface.=C2=A0 I don't want to do it in THIS draft= (it's already fairly involved), but there's nothing to say we couldn'= t do some follow-on work.

Fair enough?

Eliot

No problem with waiting to see if there's intere= st from OPSAWG and others before considering this.

By way of explanation on why I think this makes sense to s= tandardize in MUD:

I had envisioned an architecture where the MUD co= ntroller runs in the Service Provider cloud. The DHCP server would run in t= he CPE router (e.g. as part of the firmware on a home router + NAT ).
If the statement above makes sense, sinc= e the home router is typically not made by the same party as the service pr= ovider software, I was thinking there should be a standardized interface be= tween the DHCP server and MUD controller.

Thanks.

Ranga




--
M. Ranganathan
--001a1148e96e36c57605580d9b61-- From nobody Thu Aug 31 12:08:00 2017 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 80AF0132936; Thu, 31 Aug 2017 12:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 SB4i4_LT2gXn; Thu, 31 Aug 2017 12:07:42 -0700 (PDT) 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 74EFB132386; Thu, 31 Aug 2017 12:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37009; q=dns/txt; s=iport; t=1504206461; x=1505416061; h=from:subject:to:cc:references:message-id:date: mime-version:in-reply-to; bh=dckF/tUr53UtqJvW5oOQIQauZWBi26SiZayCVsExxAw=; b=Pk+SfmZBL4p5k6c2XGBtJVZjJMwsDu61nJ35eVcCbUTfUXveMZZoVbSv fysf6UREoRwXTnAINNbpTN+0Fd4pgeLi9y+xfXieMMGrPNTSBX9KR4vmQ OV9vPjFMvM7v0QN5Mp75BG2bbUohsNXtsNKhxd62F+057u+cq6H+KsLeu c=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQDUXahZ/xbLJq1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMtgRGQIJBwK5YnDoIEByWBYIM7AoRPFwECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEaCUgOBQsLDgQGIAoCAkkOBgEMCAEBF4oOCBCwD4InJ4s2AQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBDgoFgyYEhTMrgXCBDYMmgSQFDgKDKYJhBYoPhxaHDIg?= =?us-ascii?q?+hDmCIYEBjHaCE4Vng1mHG5ZFIAE2WzIyIQgcFUmFE4IKPohQgkABAQE?= X-IronPort-AV: E=Sophos;i="5.41,454,1498521600"; d="asc'?scan'208,217";a="654314000" 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; 31 Aug 2017 19:07:36 +0000 Received: from [10.61.64.148] (ams3-vpn-dhcp148.cisco.com [10.61.64.148]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7VJ7ZvI004252; Thu, 31 Aug 2017 19:07:35 GMT From: Eliot Lear To: Robert Sparks , gen-art@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> Message-ID: <0a8c04d6-eb0f-09d0-eeed-da2dacf8260c@cisco.com> Date: Thu, 31 Aug 2017 21:07:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150411366399.21627.17047458871931107094@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pULS9gljHiv2ktcJk5STwulUp2eUHMRCK" Archived-At: Subject: Re: [OPSAWG] Genart early review of draft-ietf-opsawg-mud-08 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, 31 Aug 2017 19:07:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pULS9gljHiv2ktcJk5STwulUp2eUHMRCK Content-Type: multipart/mixed; boundary="Ma5O97xAdO2Q4S738tCSCi7AXw1KMNJpE"; protected-headers="v1" From: Eliot Lear To: Robert Sparks , gen-art@ietf.org Cc: draft-ietf-opsawg-mud.all@ietf.org, opsawg@ietf.org, ietf@ietf.org Message-ID: <0a8c04d6-eb0f-09d0-eeed-da2dacf8260c@cisco.com> Subject: Re: Genart early review of draft-ietf-opsawg-mud-08 References: <150411366399.21627.17047458871931107094@ietfa.amsl.com> In-Reply-To: <150411366399.21627.17047458871931107094@ietfa.amsl.com> --Ma5O97xAdO2Q4S738tCSCi7AXw1KMNJpE Content-Type: multipart/alternative; boundary="------------644AF31A95E871F10DA4D106" Content-Language: en-US This is a multi-part message in MIME format. --------------644AF31A95E871F10DA4D106 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Robert, As I wrote earlier, this was a great review.=C2=A0 Thanks for that.=C2=A0= Please see below. On 8/30/17 7:21 PM, Robert Sparks wrote: > Reviewer: Robert Sparks > Review result: Almost Ready > > This is an exciting concept, and the draft overall is approachable. I > have identified a few areas I think need more detail, and have a=20 > longish list of nits (please don't take that to be negative). > > =3D=3DIssues=3D=3D > > I find the structure of the introduction unclear. Please consider > reworking it. I would suggest even more succinctly listing goals and > constraints, and then intended applicability (these things are in the > current text, but I think you can render them much more efficiently). I= n > particular, the argument that implementers of things are incented only = to > provide the minimal amount of behavior to get their thingyness could be= > more strongly highlighted. I've received conflicting reviews here.=C2=A0 Most like what's there and while I'm open to specific textual changes, a full reorganization would likely be destabilizing. > The document proposes "reputation services". It needs more words about > whether those exist, and what scopes the architecture imagines (an > enterprise might have a different idea of a reputation service than a > residence). There is a notion of "decent web reputations" in the securi= ty > considerations section. Who determines that? The security consideration= s > section should talk about attacks against the reputation services. This is discussed in security considerations: > It may also be useful > to limit retrieval of MUD URLs to only those sites that are known to > have decent web reputations. What I am specifically talking about are web or domain reputation services.=C2=A0 These are pretty commonplace today.=C2=A0 Your browser us= es one, and numerous companies offer them, including our own.=C2=A0 But to be clearer, I propose to use the term "web or domain reputation services", so that people know what I'm talking about. > In the first paragraph of Section 2, it's not clear if you are trying > to restrict the models to only those in the two documents in the list > following the paragraph.=20 Right.=C2=A0 This was caught earlier, and I'll correct. > I am not a YANG doctor, so this may be in the weeds, but it feels like > there's a discrepancy between the diagram at the end of section 2 and t= he > element definitions in section 3. In particular 3.7 doesn't seem to ali= gn > with what the diagram or the example in Appendix B uses. Should you be = > defining "from-device-policy" and "to-device-policy" instead of > "packet-direction"? (I'm wondering if 3.7 reflects an older design?) Yupper.=C2=A0 Fixed (I think). > At section 3.13, the description of my-controller is not quite right. > This bit signals to the mud controller to use a mapping that it knows > about or creates. Something else established that class (and maybe gave= > it a name). I talked about this with Eliot and he has a better=20 > description to use. Proposed text: > This null-valued node signals to the MUD controller to use whatever > mapping it has for this URL to a controller class".=C2=A0 This may requ= ire > prompting the administrator for class members.=C2=A0 Future work should= > seek to automate membership management. > It's not clear to me that this is a good use of .well-known. I suggest > getting an expert review on the proposed usage. (I had a quick=20 > conversation with Mark Nottingham and got some initial feedback that=20 > I'm passing along here. I'm sure there's more that an in-depth review > would identify.) Why wouldn't a URI template (RFC6570) do the job?=20 > Rather than use RFC3986's query, consider pointing to HTML5 (which > would bring the more familiar key=3Dvalue format).=20 The key issue is that we want to externalize versioning AND hardcode it in the URL so that it's independent of transport.=C2=A0 Remember, there i= s very little information exchange between the Thing and the network, and I will claim that's a good thing. > The document needs to say more about how HTTP is used. I assume you onl= y > intend to use GET, and that you expect redirects to be followed, and th= at > nothing special needs to be considered with caching? The document needs= > to be explicit about it. Take a look at=20 > . (There's been some conversation= > about it on the art list, so Eliot, at least, is already aware of it - = > see ) What we say today is the following; > Processing of this > URL occurs as specified in {{RFC2818}} and {{RFC3986}}. There is one aspect of caching semantics we should probably capture, which is that the cache-validity period should exceed the HTTP cache or expiry period as specified by max-age or Expires.=C2=A0 Does that sound a= bout right to you? > I think there needs to be more discussion of the PKI used for signing M= UD > files. We do have some discussion in Section 12.2.=C2=A0 I'm happy to add an additional sentence or two, but would seek guidance on where you think we're missing. > Consider discussing whether the stacks used by typical things will let > them add DHCP options (or include bits in the other protocols being=20 > enabled). If it's well known (I can't say) that these stacks typically > _won't_ provide that functionality, then you should punch up the > discussion of the controllers mapping other identifiers to MUD URLs on > behalf of the thing. I agree.=C2=A0 We allude to this in the draft.=C2=A0 We say, for instance= : > It is possible that there may be other means for a MUD URL to be > learned by a network.=C2=A0 For instance, if a device has a serial numb= er, > it may be possible for the MUD controller to perform a lookup of the > device, if it has some knowledge as to who the device manufacturer > is, and what its MUD file server is.=C2=A0 Such mechanisms are not > described in this memo, but are possible. The case we have in mind is LoRaWAN.=C2=A0 Should we go further? > You suggest the DHCP Client (which is a thing) SHOULD log or report=20 > improper acknowledgments from servers. That's asking a bit much from > a thing. I suspect the requirement is unrealistic and should be removed= > or rewritten to acknowledge that things typically won't do that. I think there's a philosophical thing hiding here, though: what expectations should we have of device.=C2=A0 As a SHOULD we're saying, if= you have good cause not to, ok.=C2=A0 But otherwise, for the sake of the sani= ty of the customer, please log. > The security and deployment considerations sections talk about what the= > need for coordination if control over the domain name used in the URL > changes. It should talk more about what happens if the new administrati= on > of the domain is not interested in facilitating a transition (consider > the case of a young company with a few thousand start-up-ish things out= > there that loses a suit over its name). Please discuss whether or not > suddenly losing the MUD assisted network configuration is expected to > leave the devices effectively cut-off.=20 It should not, and here's why: * Assuming the device has already been used, there is no reason to simply delete the MUD file from one's cache.=C2=A0 The cache-validity= value is meant as a timer to keep implementations for harassing the MUD file server, but there's the information is still useful, even if it may not have been freshened. * In the case where the MUD file service is unavailable when the device is first turned up, it's as if it had not included a MUD-URL in the first place.=C2=A0 While this may be a downgrade attack, there= is, as I understand it, really no way to get around it, other than for the MUD controller to log a problem. > Right now, you leave the DHCP server (when it's used) responsible for > clearing state in the MUD controller. Please discuss what happens when > those are distinct elements (as you have in the end of section 9.2) and= > the DHCP server reboots. Perhaps it would make sense for the DHCP serve= r > to hand the length of the lease it has granted to the MUD controller an= d > let the MUD controller clean up on its own? See other response. > The document currently suggests that a piece of software inspect the > WHOIS database to see if registration ownership of a domain has changed= =2E > Do you really mean software, or should this be advice to the > administrator of the controller instead?=20 The controller.=C2=A0 The idea is to catch bad behavior and anomalies.=C2= =A0 And the bigger idea is to reduce the number of decisions that the administrator must make, while providing relevant information with which to make the decisions. > =3D=3DNits=3D=3D > > I recommend an editorial pass focusing on simplifying sentences. Look > particularly where the word "therefore" is used and consider > restructuring the surrounds. (It is used non-sequitur in a couple of > places). Be careful to call out actors explicitly (I note the places=20 > that particularly caught my eye below). ok. > Some specific nits: > > The abstract speaks only about properties of MUD but does not describe > what MUD _is_, or is good for. A few more words here would help. Right.=C2=A0 See response to Henk. > Next to last paragraph of section 1 (before 1.1): A means for _who_ to > retrieve the description? (Consider rendering the three list elements o= n > their own lines.) Right.=C2=A0 Fixed. > The last sentence of section 1 treats "enterprise networks" more > specially than it intends, I think. Why couldn't _any_ network do this?= > Could the sentence be reworded to make it clear that enterprise network= s > are an example? s/enterprise networks/local deployments/ ? > First sentence of 1.1: Perhaps you mean "general purpose computing > devices" instead of "general computing"? "their" has an unclear > antecedent. Indeed.=C2=A0 fixed. > Last paragraph of 1.3: It's unclear what "such an approach" is intended= > to point to. Would "a general solution that required capabilities their= > particular device would not use" make more sense? Reworded. > First paragraph of 1.5: "might to allow" is probably meant to be "might= > be to allow". What does it mean for a controller to "need to speak COAP= ". > Do you mean "controllers capable of speaking COAP"? Fixed. > Fourth paragraph of 1.5 at the discussion of time and effort: Consider > rephrasing this to focus on the result of the time and effort (high > quality) rather than the time and effort itself. Existence is good enough in this case ;-) > In the list of abstractions at the end of 1.5, you have three things yo= u > describe as devices and one thing you describe as a class. You later ta= lk > about the abstractions you've described as devices as classes. At this > point in the document what you mean by "class" has not been made as > explicit as it could be. I've tried to review all instances of class to be clear that it is used consistently.=C2=A0 This is somewhat difficult given natural language, bu= t I hope I've gotten it right. > > Section 1.8, item 3: the MUD file doesn't have hosts in it (it has > identifiers of some kind). Consider being more explicit about what > you mean by testing that against a reputation service. Actually, it can have hosts in it, but see above. > Section 3.1: You say "Which turn was taken". I think you meant > "Which, in turn, was taken". Consider deleting "for those keeping score= ". Awwww.=C2=A0 Just a bit of humor? ;-) > > Section 3.3 is missing a word at "the location any MASA service"? Ok it's cleaned up. > > I found the prose in the descriptions of the "manufacturer" and > "same-manufacturer" elements (3.8 and 3.9) very confusing. I think > additional prose introducing the concepts and maybe some examples would= > be very useful. Added examples per your suggestion. > > What do you mean by "matches" at 3.10. Do you mean "is"? All of this is applicable in the context of the matches statement in the ACL model.=C2=A0 I've added some explanatory text at the beginning of the= chapeau. > > The caution in the 2nd paragraph of 3.12 is not clear. Ok, I've cleaned that up and added an example. > > At section 4, consider pointing out that you are not allowing=20 > DHCP by default, and that devices that are expected to use DHCP > need to have an explicit allow in their MUD file.=20 Hmm.=C2=A0 The issue here is that DHCP is an L2 protocol that isn't forwarded.=C2=A0 Do you think it needs to be listed anyway? > > The description of the manufacturer leaf in the MUD YANG model > could be made more useful. ALL the descriptions have been improved. > > Provide a reference for "giaddr" when you use it in section 9.2. Cleaned up (that's defined in RFC 2131, already normatively referenced, but I expanded). > > Section 14, 2nd paragraph: additional segmentation of what? Make that "network segmentation". > > Second paragraph of Section 15 - it would help to be more precise > with agency. _Who_ should review the class? Fixed. > > In the security considerations section, when you get to the "if for som= e > reason it is not possible to determine whether ownership has changed", > _who_ are you suggesting conduct further review? It's always the network administrator. > > =3D=3DMicro-nits=3D=3D > > 1,$s/enorcement/enforcement/g Doh! > > s/autjors/authors/ > Fixed. Thanks again, Eliot --------------644AF31A95E871F10DA4D106 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Robert,

As I wrote earlier, this was a great review.=C2=A0 Thanks for that= =2E=C2=A0 Please see below.


On 8/30/17 7:21 PM, Robert Sparks wrote:
Reviewer: Robert Sparks
Review result: Almost Ready

This is an exciting concept, and the draft overall is approachable. I
have identified a few areas I think need more detail, and have a=20
longish list of nits (please don't take that to be negative).

=3D=3DIssues=3D=3D

I find the structure of the introduction unclear. Please consider
reworking it.  I would suggest even more succinctly listing goals and
constraints, and then intended applicability (these things are in the
current text, but I think you can render them much more efficiently). In
particular, the argument that implementers of things are incented only to=

provide the minimal amount of behavior to get their thingyness could be
more strongly highlighted.

I've received conflicting reviews here.=C2=A0 Most like what's there = and while I'm open to specific textual changes, a full reorganization would likely be destabilizing.

The document proposes "reputation services". It need=
s more words about
whether those exist, and what scopes the architecture imagines (an
enterprise might have a different idea of a reputation service than a
residence). There is a notion of "decent web reputations" in the security=

considerations section. Who determines that? The security considerations
section should talk about attacks against the reputation services.

This is discussed in security considerations:
It may also be useful
to limit retrieval of MUD URLs to only those sites that are known to
have decent web reputations.
What I am specifically talking about are web or domain reputation services.=C2=A0 These are pretty commonplace today.=C2=A0 Your browse= r uses one, and numerous companies offer them, including our own.=C2=A0 But = to be clearer, I propose to use the term "web or domain reputation services", so that people know what I'm talking about.




In the first paragraph of Section 2, it's not clear if you are trying
to restrict the models to only those in the two documents in the list
following the paragraph.

Right.=C2=A0 This was caught earlier, and I'll correct.

I am not a YANG doctor, so this may be in the weeds, but it feels like
there's a discrepancy between the diagram at the end of section 2 and the=

element definitions in section 3. In particular 3.7 doesn't seem to align=

with what the diagram or the example in Appendix B uses. Should you be=20
defining "from-device-policy" and "to-device-policy" instead of
"packet-direction"? (I'm wondering if 3.7 reflects an older design?)

Yupper.=C2=A0 Fixed (I think).
At section 3.13, the description of my-controller is not quite right.
This bit signals to the mud controller to use a mapping that it knows
about or creates. Something else established that class (and maybe gave
it a name). I talked about this with Eliot and he has a better=20
description to use.

Proposed text:

This null-valued node signals to the MUD controller to use whatever
mapping it has for this URL to a controller class".=C2=A0 This may require
prompting the administrator for class members.=C2=A0 Future work sh= ould
seek to automate membership management.

It's not clear to me that this is a good use of .well-known. I suggest
getting an expert review on the proposed usage. (I had a quick=20
conversation with Mark Nottingham and got some initial feedback that=20
I'm passing along here. I'm sure there's more that an in-depth review
would identify.) Why wouldn't a URI template (RFC6570) do the job?=20
Rather than use RFC3986's query, consider pointing to HTML5 (which
would bring the more familiar key=3Dvalue format).

The key issue is that we want to externalize versioning AND hardcode it in the URL so that it's independent of transport.=C2=A0 Remember, there is very little information exchange between the Thing and the network, and I will claim that's a good thing.

The document needs to say more about how HTTP is used. I assume you only
intend to use GET, and that you expect redirects to be followed, and that=

nothing special needs to be considered with caching? The document needs
to be explicit about it. Take a look at=20
<https://mnot.github.io/I-D/bcp56bis/>. (There's been s=
ome conversation
about it on the art list, so Eliot, at least, is already aware of it -=20
see <https://mailarchive.ietf.org/arch/searc=
h/?q=3Dbcp56bis>)

What we say today is the following;
Processing of this
URL occurs as specified in {{RFC2818}} and {{RFC3986}}. There is one aspect of caching semantics we should probably capture, which is that the cache-validity period should exceed the HTTP cache or expiry period as specified by max-age or Expires.=C2=A0 Does that sound about right to you?

I think there needs to be more discussion of the PKI used for signing MUD=

files.

We do have some discussion in Section 12.2.=C2=A0 I'm happy to add an= additional sentence or two, but would seek guidance on where you think we're missing.

Consider discussing whether the stacks used by typical things will let
them add DHCP options (or include bits in the other protocols being=20
enabled). If it's well known (I can't say) that these stacks typically
_won't_ provide that functionality, then you should punch up the
discussion of the controllers mapping other identifiers to MUD URLs on
behalf of the thing.

I agree.=C2=A0 We allude to this in the draft.=C2=A0 We say, for inst= ance:
It is possible that there may be other mean= s for a MUD URL to be
learned by a network.=C2=A0 For instance, if a device has a serial number,
it may be possible for the MUD controller to perform a lookup of the
device, if it has some knowledge as to who the device manufacturer<= br> is, and what its MUD file server is.=C2=A0 Such mechanisms are not<= br> described in this memo, but are possible.

The case we have in mind is LoRaWAN.=C2=A0 Should we go further?


You suggest the DHCP Client (which is a thing) SHOULD log or report=20
improper acknowledgments from servers. That's asking a bit much from
a thing. I suspect the requirement is unrealistic and should be removed
or rewritten to acknowledge that things typically won't do that.
I think there's a philosophical thing hiding here, though: what expectations should we have of device.=C2=A0 As a SHOULD we're saying= , if you have good cause not to, ok.=C2=A0 But otherwise, for the sake of = the sanity of the customer, please log.

The security and deployment considerations sections talk about what the
need for coordination if control over the domain name used in the URL
changes. It should talk more about what happens if the new administration=

of the domain is not interested in facilitating a transition (consider
the case of a young company with a few thousand start-up-ish things out
there that loses a suit over its name). Please discuss whether or not
suddenly losing the MUD assisted network configuration is expected to
leave the devices effectively cut-off.

It should not, and here's why:

  • Assuming the device has already been used, there is no reason to simply delete the MUD file from one's cache.=C2=A0 The cache-validity value is meant as a timer to keep implementations for harassing the MUD file server, but there's the information is still useful, even if it may not have been freshened.
  • In the case where the MUD file service is unavailable when the device is first turned up, it's as if it had not included a MUD-URL in the first place.=C2=A0 While this may be a downgrade attack, there is, as I understand it, really no way to get around it, other than for the MUD controller to log a problem. 
Right now, you leave the DHCP server (when it's used) responsible for
clearing state in the MUD controller. Please discuss what happens when
those are distinct elements (as you have in the end of section 9.2) and
the DHCP server reboots. Perhaps it would make sense for the DHCP server
to hand the length of the lease it has granted to the MUD controller and
let the MUD controller clean up on its own?

See other response.

The document currently suggests that a piece of software inspect the
WHOIS database to see if registration ownership of a domain has changed.
Do you really mean software, or should this be advice to the
administrator of the controller instead?

The controller.=C2=A0 The idea is to catch bad behavior and anomalies= =2E=C2=A0 And the bigger idea is to reduce the number of decisions that the administrator must make, while providing relevant information with which to make the decisions.

=3D=3DNits=3D=3D

I recommend an editorial pass focusing on simplifying sentences. Look
particularly where the word "therefore" is used and consider
restructuring the surrounds. (It is used non-sequitur in a couple of
places). Be careful to call out actors explicitly (I note the places=20
that particularly caught my eye below).

ok.
Some specific nits:

The abstract speaks only about properties of MUD but does not describe
what MUD _is_, or is good for. A few more words here would help.
Right.=C2=A0 See response to Henk.
Next to last paragraph of section 1 (before 1.1): A means for _who_ to
retrieve the description? (Consider rendering the three list elements on
their own lines.)
Right.=C2=A0 Fixed.
The last sentence of section 1 treats "enterprise networks" more
specially than it intends, I think. Why couldn't _any_ network do this?
Could the sentence be reworded to make it clear that enterprise networks
are an example?

s/enterprise networks/local deployments/

?

First sentence of 1.1: Perhaps you mean "general purpose computing
devices" instead of "general computing"? "their" has an unclear
antecedent.

Indeed.=C2=A0 fixed.

Last paragraph of 1.3: It's unclear what "such an approach" is intended
to point to. Would "a general solution that required capabilities their
particular device would not use" make more sense?

Reworded.

First paragraph of 1.5: "might to allow" is probably meant to be "might
be to allow". What does it mean for a controller to "need to speak COAP".=

Do you mean "controllers capable of speaking COAP"?
Fixed.
Fourth paragraph of 1.5 at the discussion of time an=
d effort: Consider
rephrasing this to focus on the result of the time and effort (high
quality) rather than the time and effort itself.

Existence is good enough in this case ;-)

In the list of abstractions at the end of 1.5, you have three things you
describe as devices and one thing you describe as a class. You later talk=

about the abstractions you've described as devices as classes. At this
point in the document what you mean by "class" has not been made as
explicit as it could be.
I've tried to review all instances of class to be clear that it is used consistently.=C2=A0 This is somewhat difficult given natural language, but I hope I've gotten it right.


Section 1.8, item 3: the MUD file doesn't have hosts in it (it has
identifiers of some kind). Consider being more explicit about what
you mean by testing that against a reputation service.

Actually, it can have hosts in it, but see above.

Section 3.1: You say "Which turn was taken". I think you meant
"Which, in turn, was taken". Consider deleting "for those keeping score".=

Awwww.=C2=A0 Just a bit of humor? ;-)


Section 3.3 is missing a word at "the location any MASA service"?

Ok it's cleaned up.


I found the prose in the descriptions of the "manufacturer" and
"same-manufacturer" elements (3.8 and 3.9) very confusing. I think
additional prose introducing the concepts and maybe some examples would
be very useful.

Added examples per your suggestion.


What do you mean by "matches" at 3.10. Do you mean "is"?

All of this is applicable in the context of the matches statement in the ACL model.=C2=A0 I've added some explanatory text at the beginnin= g of the chapeau.

The caution in the 2nd paragraph of 3.12 is not clear.

Ok, I've cleaned that up and added an example.


At section 4, consider pointing out that you are not allowing=20
DHCP by default, and that devices that are expected to use DHCP
need to have an explicit allow in their MUD file.

Hmm.=C2=A0 The issue here is that DHCP is an L2 protocol that isn't forwarded.=C2=A0 Do you think it needs to be listed anyway?


The description of the manufacturer leaf in the MUD YANG model
could be made more useful.

ALL the descriptions have been improved.

Provide a reference for "giaddr" when you use it in section 9.2.

Cleaned up (that's defined in RFC 2131, already normatively referenced, but I expanded).

Section 14, 2nd paragraph: additional segmentation of what?

Make that "network segmentation".

Second paragraph of Section 15 - it would help to be more precise
with agency. _Who_ should review the class?

Fixed.


In the security considerations section, when you get to the "if for some
reason it is not possible to determine whether ownership has changed",
_who_ are you suggesting conduct further review?

It's always the network administrator.

=3D=3DMicro-nits=3D=3D

1,$s/enorcement/enforcement/g

Doh!


s/autjors/authors/

Fixed.

Thanks again,

Eliot

--------------644AF31A95E871F10DA4D106-- --Ma5O97xAdO2Q4S738tCSCi7AXw1KMNJpE-- --pULS9gljHiv2ktcJk5STwulUp2eUHMRCK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZqF58AAoJEIe2a0bZ0nozZJQH/RmARIDac/p6xTK/ga5t/1b/ p86ZgXtuE6Ww5KJkY9J/IANO68HkBWHyNpnF3VDHOrEvXv4jfjcYu6lCdZwD9Fy8 aeRJh2fso+6d+AuEddrBMCtMKsTVBqX5bdNH9NXlavPl09qXOsCI/VGW50nbxF/z luESyMSY1+JkJxxFE78A0+rx2Kesmvg+5WNvl/S5TJ+v251G66skH8c/0bo3q2GK h0sugbOpEIF4q8xjX3ZikQpe/jT+Ror6RoG0bX6qgTkSQIn/zk45AI+XWLly9NLp Oh/EzY6y3BKR6u4X18b6TvF+DEUnVZdTGZ5L+hD6u5I7LAwvPmCAD5MV7c9jnz0= =ykaw -----END PGP SIGNATURE----- --pULS9gljHiv2ktcJk5STwulUp2eUHMRCK-- From nobody Thu Aug 31 13:52:19 2017 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 7B8271326EA for ; Thu, 31 Aug 2017 13:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 Kv1MLw5zcwDF for ; Thu, 31 Aug 2017 13:52:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7D513248B for ; Thu, 31 Aug 2017 13:52:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUN90351; Thu, 31 Aug 2017 20:52:13 +0000 (GMT) Received: from DGGEMA405-HUB.china.huawei.com (10.3.20.46) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 31 Aug 2017 21:52:12 +0100 Received: from DGGEMA505-MBX.china.huawei.com ([169.254.1.46]) by DGGEMA405-HUB.china.huawei.com ([10.3.20.46]) with mapi id 14.03.0301.000; Fri, 1 Sep 2017 04:52:07 +0800 From: h chan To: "opsawg@ietf.org" Thread-Topic: Re: [OPSAWG] New Version Notification for draft-pularikkal-opsawg-wifi-calling-03.txt Thread-Index: AdMilvnPQEPKAshET6yruwHu6CR7nw== Date: Thu, 31 Aug 2017 20:52:06 +0000 Message-ID: <6E31144C030982429702B11D6746B98C7711A15A@DGGEMA505-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.197] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C7711A15ADGGEMA505MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59A876FD.0121, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.46, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a5bab188c75290eef2ab1712e068756e Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-pularikkal-opsawg-wifi-calling-03.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, 31 Aug 2017 20:52:18 -0000 --_000_6E31144C030982429702B11D6746B98C7711A15ADGGEMA505MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read through this draft. The deployment considerations provided are = useful. I made a few suggested changes which I hope may help. Under session 2 Terminology: Groups Special Mobile Association (GSMA) - Are you sure this is right for t= he acronym GSMA? I thought although GSM was originally the acronym for the = French words: Groupe Special Mobile, it did not translate word by word into= English. In English it was turned into the acronym for Global System for M= obile Communications. Evolved Packet Core represents the core network in the 3GPP LTE system Arch= itecture - I thought EPC is the core network whereas LTE is used in Radio a= ccess network. So EPC is not "in" LTE, LTE is not the entire architecture. = Perhaps you may say: Evolved Packet Core represents the 3GPP core network s= upporting the LTE RAN. PDN Gateway .... Based up on the policy ... - upon is one word - also in se= veral other places in the draft IP Multi-Media Subsystem (IMS) - Multimedia (one word). - also in other pla= ces in the draft. Under session 4: For the Heading 4: Wi-Fi Calling Deployment Considerations and the Heading = 4.1 Wi-Fi to Packet Core Integration. It appears that the entire session 4 = is on Wi-Fi to Packet Core Integration, whereas sessions 4, 5, 6, 7, 8, 9 a= re all on deployment considerations. I wonder if it may help merge the sepa= rate headings: 4 and 4.1 into the same heading 4. I might have misunderstoo= d your intention though. Under 4.1 Alternatively the Mobile Network Operator may deploy a Managed Wi-Fi networ= k for the Enterprise and SMB customers. The MNO managed ... Define MNO before you use MNO: Alternatively the Mobile Network Operator (MNO) may ... Also have you defined the acronym SMB yet? *Support of Non-SIM devices: The MNO can provide value-added services, incl= uding voice services on Non-SIM devices The Untrusted Wi-Fi architecture is= compatible with Non-SIM devices and provide the same capabilities to these= devices as for the SIM devices. ... devices. The ... provides Under session 5: A seamless WLAN onboarding is critical for the smooth hand off of the voice= call from LTE to Wi-Fi. I guess you mean "handoff" But with any of the EAP methods, once the credentials have been established= on the UE device, then authentication happens automatically without user i= ntervention and greatly improves the onboarding experience. Consider changing to Yet with any of the EAP methods, once the credentials have been established= on the UE device, authentication happens automatically without user interv= ention and greatly improves the onboarding experience. Option leverages the same set of identity and credentials (unified identity= ) for WLAN onboarding and packet core connectivity will simplify the identi= ty management for Wi-Fi calling. Option which leverages ... will simplify ... and an EAP method used for Non-SIM devices. "is used for ..." H. Anthony Chan --_000_6E31144C030982429702B11D6746B98C7711A15ADGGEMA505MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read through this draft. The deployment considerations provided= are useful. I made a few suggested changes which I hope may help.

 

Under session 2 Terminology:

Groups Special Mobile Association (GSMA) – Are you sure this is = right for the acronym GSMA? I thought although GSM was originally the acron= ym for the French words: Groupe Special Mobile, it did not translate word by word into English. In English it was turned into the= acronym for Global System for Mobile Communications.

 

Evolved Packet Core represents the core network in the 3GPP LTE system= Architecture – I thought EPC is the core network whereas LTE is used= in Radio access network. So EPC is not “in” LTE, LTE is not the entire architecture. Perhaps you may say: Evolved Packet Core r= epresents the 3GPP core network supporting the LTE RAN.

 

PDN Gateway …. Based up on the policy … - upon is one word= – also in several other places in the draft

 

IP Multi-Media Subsystem (IMS) – Multimedia (one word). – = also in other places in the draft.

 

Under session 4:

For the Heading 4: Wi-Fi Calling Deployment Considerations and the Hea= ding 4.1 Wi-Fi to Packet Core Integration. It appears that the entire sessi= on 4 is on Wi-Fi to Packet Core Integration, whereas sessions 4, 5, 6, 7, 8, 9 are all on deployment considerations. I wonder i= f it may help merge the separate headings: 4 and 4.1 into the same heading = 4. I might have misunderstood your intention though.

 

Under 4.1

Alternatively the Mobile Network Operator may deploy a Manag= ed Wi-Fi network for the Enterprise and SMB customers.  The MNO manage= d …

 

Define MNO before you use MNO:

Alternatively the Mobile Network Operator (MNO) may …<= o:p>

Also have you defined the acronym SMB yet?

 

*Support of Non-SIM devices: The MNO can provide v= alue-added services, including voice services on Non-SIM devices The Untrusted Wi-Fi architecture i= s compatible with Non-SIM devices and provide the same capabilities to these dev= ices as for the SIM devices.

 

… devices. The … provides

 

 

Under session 5:

A seamless WLAN onboarding is critical for the smo= oth hand off of the voice call from LTE to Wi-= Fi.

 

I guess you mean “handoff”

 

But with any of the EAP methods, once the credentials have been establi= shed on the UE device, then authentication happens automatically = without user intervention and greatly improves the onboarding experience.

 

Consider changing to

 

Yet with any of the EAP methods, once the credentials have been establi= shed on the UE device, authentication happens automatically without user intervention and greatly improves the onboarding experience.<= o:p>

 

Option leverages the same set of identity and credentials (unified ide= ntity) for WLAN onboarding and packet core connectivity will simplify the i= dentity management for Wi-Fi calling.

 

Option which leverages … will simplify …

 

and an EAP method used for Non-SIM devices.

“is used for …”

 

H. Anthony Chan

 

--_000_6E31144C030982429702B11D6746B98C7711A15ADGGEMA505MBXchi_-- From nobody Thu Aug 31 20:19:33 2017 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 60C2E132FFA; Thu, 31 Aug 2017 20:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pRtAfnEiwqtj; Thu, 31 Aug 2017 20:19:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D95132FF0; Thu, 31 Aug 2017 20:19:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DUO22841; Fri, 01 Sep 2017 03:19:27 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 1 Sep 2017 04:19:26 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 1 Sep 2017 11:19:23 +0800 From: Tianran Zhou To: "opsawg@ietf.org" CC: "opsawg-chairs@ietf.org" Thread-Topic: Move forward draft-ietf-opsawg-service-model-explained-02 Thread-Index: AdMi0RreCniHI1OjR9ah0Ho4I+eAFQ== Date: Fri, 1 Sep 2017 03:19:05 +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 X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59A8D1BF.006B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 56ba651c34d71003f65523815ea70e62 Archived-At: Subject: [OPSAWG] Move forward draft-ietf-opsawg-service-model-explained-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: Fri, 01 Sep 2017 03:19:32 -0000 Hi All, Thanks authors for incorporating all the comments during the WGLC. And we have received all responses to the IPR call. So let's move forward and request the publication. Please see the status information https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ Cheers, Tianran, Co-Chair