From nobody Sun Oct 1 23:24: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 47AEE134C46; Sun, 1 Oct 2017 23:23:53 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150692543324.28804.12074546401118667771@ietfa.amsl.com> Date: Sun, 01 Oct 2017 23:23:53 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-05.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, 02 Oct 2017 06:23: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 : 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-05.txt Pages : 79 Date : 2017-10-01 Abstract: For the sake of network automation and the need for programming Network Address Translation (NAT) function in particular, a data model for configuring and managing the NAT is essential. This document defines a YANG module for the NAT function. NAT44, Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit Address Mappings for Stateless IP/ICMP Translation (SIIT EAM), 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat-yang-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 1 23:31:24 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 AF1C2134C76 for ; Sun, 1 Oct 2017 23:31:23 -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 iNNXoN5lPZoQ for ; Sun, 1 Oct 2017 23:31:22 -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 DF50A134C70 for ; Sun, 1 Oct 2017 23:31:21 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 3E80E21017; Mon, 2 Oct 2017 08:31:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 16CC71C0064; Mon, 2 Oct 2017 08:31:20 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0361.001; Mon, 2 Oct 2017 08:31:14 +0200 From: To: "opsawg@ietf.org" CC: Senthil Sivakumar , JACQUENET Christian IMT/OLN , Qin Wu , "sureshk@juniper.net" Thread-Topic: New Version Notification for draft-ietf-opsawg-nat-yang-05.txt Thread-Index: AQHTO0cGwUnnSW1Ztk+wIdLTQ2BwjqLQGCdQ Date: Mon, 2 Oct 2017 06:31:14 +0000 Message-ID: <129f587a-36a4-4057-a58a-ac034d502d3d@OPEXCLILM7D.corporate.adroot.infra.ftgroup> References: <150692543342.28804.14971606653762640844.idtracker@ietfa.amsl.com> In-Reply-To: <150692543342.28804.14971606653762640844.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.5] 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-05.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, 02 Oct 2017 06:31:24 -0000 RGVhciBhbGwsIA0KDQpUaGUgbmV3IHZlcnNpb24gY2xhcmlmaWVzIGhvdyBib3RoIHN0YXRlbGVz cyBhbmQgc3RhdGVmdWwgTkFUNjQgYXJlIGNvdmVyZWQuIA0KDQpUaGlzIHdhcyBhIGNvbW1lbnQg cmVjZWl2ZWQgb2ZmbGluZSBmcm9tIFJhaml2IEFzYXRpLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBsdW5k aSAyIG9jdG9icmUgMjAxNyAwODoyNA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xO OyBTZW50aGlsIFNpdmFrdW1hcjsgSkFDUVVFTkVUIENocmlzdGlhbg0KPiBJTVQvT0xOOyBvcHNh d2ctY2hhaXJzQGlldGYub3JnOyBRaW4gV3UNCj4gT2JqZXTCoDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wNS50eHQNCj4gDQo+IA0KPiBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmctMDUudHh0DQo+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIgYW5k IHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWll dGYtb3BzYXdnLW5hdC15YW5nDQo+IFJldmlzaW9uOgkwNQ0KPiBUaXRsZToJCUEgWUFORyBEYXRh IE1vZGVsIGZvciBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRpb24gKE5BVCkNCj4gYW5kIE5ldHdv cmsgUHJlZml4IFRyYW5zbGF0aW9uIChOUFQpDQo+IERvY3VtZW50IGRhdGU6CTIwMTctMTAtMDEN Cj4gR3JvdXA6CQlvcHNhd2cNCj4gUGFnZXM6CQk3OQ0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb3BzYXdnLQ0KPiBuYXQt eWFuZy0wNS50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtb3BzYXdnLW5hdC0NCj4geWFuZy8NCj4gSHRtbGl6ZWQ6ICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0w NQ0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1pZXRmLW9wc2F3Zy0NCj4gbmF0LXlhbmctMDUNCj4gRGlmZjogICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2F3Zy1uYXQtDQo+ IHlhbmctMDUNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBGb3IgdGhlIHNha2Ugb2YgbmV0d29yayBh dXRvbWF0aW9uIGFuZCB0aGUgbmVlZCBmb3IgcHJvZ3JhbW1pbmcNCj4gICAgTmV0d29yayBBZGRy ZXNzIFRyYW5zbGF0aW9uIChOQVQpIGZ1bmN0aW9uIGluIHBhcnRpY3VsYXIsIGEgZGF0YQ0KPiAg ICBtb2RlbCBmb3IgY29uZmlndXJpbmcgYW5kIG1hbmFnaW5nIHRoZSBOQVQgaXMgZXNzZW50aWFs LiAgVGhpcw0KPiAgICBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBtb2R1bGUgZm9yIHRoZSBOQVQg ZnVuY3Rpb24uDQo+IA0KPiAgICBOQVQ0NCwgTmV0d29yayBBZGRyZXNzIGFuZCBQcm90b2NvbCBU cmFuc2xhdGlvbiBmcm9tIElQdjYgQ2xpZW50cyB0bw0KPiAgICBJUHY0IFNlcnZlcnMgKE5BVDY0 KSwgQ3VzdG9tZXItc2lkZSB0cmFuc0xBVG9yIChDTEFUKSwgRXhwbGljaXQNCj4gICAgQWRkcmVz cyBNYXBwaW5ncyBmb3IgU3RhdGVsZXNzIElQL0lDTVAgVHJhbnNsYXRpb24gKFNJSVQgRUFNKSwg YW5kDQo+ICAgIElQdjYgTmV0d29yayBQcmVmaXggVHJhbnNsYXRpb24gKE5QVHY2KSBhcmUgY292 ZXJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3Vi bWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Oct 3 09: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 0AA44134F5F for ; Tue, 3 Oct 2017 09:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 cfWRlUfw7FqT for ; Tue, 3 Oct 2017 09:41:24 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 98E7A1346A9 for ; Tue, 3 Oct 2017 09:41:23 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id l24so3894147wre.1 for ; Tue, 03 Oct 2017 09:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LqKPfcDTgnXXkusruPvcRBzgKLBMioRrUhiJE+V9VGU=; b=QgFB7oFuZvOrhV2+xwIzWUB783Ou/KWV9UZAsx0GsMis3Z97L922nY80W/GrWF5TVF 7gy9zfQWNqgQ4KaQjFnvLCaRF+RJABnHuumX/frPinwX9yDNNkXcPS/72Uzqk37282eZ 5KPID+N2FH39+0SRwX8HWK2naZ5Ho9E02HVzYzLyO6F9nGtId9KSEwHk5AtKDjpv4/y5 7mhIjLhEGf+qpRyQRW+L0bWG+T7qU33C8Vo7gUjY5eX/hd2W444SrUQ3cB8C6orkUTd5 pc7o1Ddmg5YYfbXwhTzbYV4CJTMx3biMSxqRlmytw1vsuNWKT/rRETbcdUsAGtCdOqjV Oemg== 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=LqKPfcDTgnXXkusruPvcRBzgKLBMioRrUhiJE+V9VGU=; b=aw5uw+H76yuzw8LtEMvu6zs1QXD/73E97ZkKFhazNIwi5iyQ5+aSh07pcerTuMvW5N 2bArgBJDUjN8qm1LygvD8R8BpUTKaoJCmM+acgEr53nMJSluZ8BzgOdUWsYjABuv3I1K dPQoiyWWaMnwngDBSj7r2RHRRj0t7gSsNeoUvG4/KtkALxF38fBPWky3klflXQ8ufrAg SecXqY9fEWAQimC14zPBGXvMKXXqjjgoc7dfl2ESR2vz9KaTh/auF5xXT+2HjZCYn7s4 Egk529xTTdvsXnpcgtWjBa/ybRmSbUQpg3k/VTE46rpKB1xFAM6Qhydol735WMWQ4sAu 9BFQ== X-Gm-Message-State: AMCzsaXHnEY6+DiJ96r9Y+Lz67fB8jLR9H/nxdG3hdUsh/nH6WfuU/Xm JhA9coXXA8yZzmYmyf9oq9V/cA7NtlXc1b1p0Cw= X-Google-Smtp-Source: AOwi7QAsF/ptsqT1FG+dkoSDkyuMpPHXP7EolLw89JjyCNDY7jVfW+xg1ZK1mn8PDcQQLjmdanqrXO/YCEFO/MvQPls= X-Received: by 10.223.157.39 with SMTP id k39mr10153954wre.49.1507048881738; Tue, 03 Oct 2017 09:41:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.175.213 with HTTP; Tue, 3 Oct 2017 09:40:41 -0700 (PDT) From: "M. Ranganathan" Date: Tue, 3 Oct 2017 12:40:41 -0400 Message-ID: To: opsawg@ietf.org Content-Type: multipart/alternative; boundary="f40304388f18415c60055aa729af" Archived-At: Subject: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS. 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, 03 Oct 2017 16:41:25 -0000 --f40304388f18415c60055aa729af Content-Type: text/plain; charset="UTF-8" MUD suggests that devices should always have access to DHCP and DNS. However, I don't know how to communicate this information to the MUD controller so that appropriate ACLs can be installed when a device comes up. A logical place to put this would be in the request sent out by the DHCP server to the MUD controller when it gets the OPTIONS 161 from the device. Would this be the way this is envisioned to work? Would it be worthwhile documenting this interaction (in followup work). Thanks. -- M. Ranganathan --f40304388f18415c60055aa729af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
MUD suggests that devices should always have access t= o DHCP and DNS. However, I don't know how to communicate this informati= on to the MUD controller so that appropriate ACLs can be installed when a d= evice comes up. A logical place to put this would be in the request sent ou= t by the DHCP server to the MUD controller when it gets the OPTIONS 161 fro= m the device. Would this be the way this is envisioned to work?=C2=A0
<= br>
Would it be worthwhile documenting this interaction (in followup w= ork).

Thanks.

-= -
M. = Ranganathan
--f40304388f18415c60055aa729af-- From nobody Tue Oct 3 09:52:23 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 CE4F9134F5C for ; Tue, 3 Oct 2017 09:52:14 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-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 HfkGMJPV7y5W for ; Tue, 3 Oct 2017 09:52:13 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1030B1346A6 for ; Tue, 3 Oct 2017 09:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4870; q=dns/txt; s=iport; t=1507049532; x=1508259132; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=DeEbDOuVAEST4FIyoXHbip6k6mnwSEBgcebSrZC7Z9A=; b=iORWp0vMdyDlB+h4mknH7jK10ZT5TYWX4sjrV5DzgvJ9993AeFS4aDPi bmjUVv4c+VQN0DnYJEsmCGsEJbDvMWr+Fu/oKGVQA40cB5rsxqrgUG7v+ gZDmkhz6sd+x6lxh05n6ar+y2MPAyLy2KkQz78HI2Kaz8KFcjhR2MoAeA 8=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAAD4v9NZ/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg11kbieDeYofdI5vgVQiiEOIK4U+ghIHAxgBCoRJTwKETj8YAQI?= =?us-ascii?q?BAQEBAQEBayiFGAEBAQECAQEBIUsLBQsLBBQqAgIhBjAGE4oYAw0IEKUugieHP?= =?us-ascii?q?Q2DZAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4KBYMtggKBRwqCFQuCcoJeghCDKS+?= =?us-ascii?q?CMgWYWIgePIQ8gyKIDoR5kwmMcIUsgziBOR84gQ4yIQgdFUkSAYJ0hDJaigMBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.42,474,1500940800"; d="asc'?scan'208,217";a="306638540" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Oct 2017 16:52:11 +0000 Received: from saucy.localdomain (saucy.cisco.com [64.100.220.11]) by alln-core-7.cisco.com (8.14.5/8.14.5) with SMTP id v93GqB7x015686; Tue, 3 Oct 2017 16:52:11 GMT Received: from srichybook.ddns.asig.cisco.com (srichybook.ddns.asig.cisco.com [64.100.220.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by saucy.localdomain (Postfix) with ESMTPS id 3y64nl3cBdzFpf4; Tue, 3 Oct 2017 12:52:11 -0400 (EDT) From: Steven Rich Message-Id: <7B1589B4-15E4-4793-8A28-965021EBE6CB@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_08941F3B-EC04-4826-9FA5-1F4977B88576"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 3 Oct 2017 12:52:10 -0400 In-Reply-To: Cc: Steve Rich , opsawg@ietf.org To: "M. Ranganathan" References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS. 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, 03 Oct 2017 16:52:15 -0000 --Apple-Mail=_08941F3B-EC04-4826-9FA5-1F4977B88576 Content-Type: multipart/alternative; boundary="Apple-Mail=_F3A033C0-A534-4585-B0E9-9445A0EF7872" --Apple-Mail=_F3A033C0-A534-4585-B0E9-9445A0EF7872 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 3, 2017, at 12:40 , M. Ranganathan wrote: >=20 > MUD suggests that devices should always have access to DHCP and DNS. = However, I don't know how to communicate this information to the MUD = controller so that appropriate ACLs can be installed when a device comes = up. A logical place to put this would be in the request sent out by the = DHCP server to the MUD controller when it gets the OPTIONS 161 from the = device. Would this be the way this is envisioned to work? >=20 > Would it be worthwhile documenting this interaction (in followup = work). I and Thorsten are trying to capture some of these notions in https://tools.ietf.org/html/draft-srich-opsawg-mud-net-lifecycle-01 = although your particular case isn=E2=80=99t covered explicitly (I=E2=80=99= ll add that). Do you mind reading section 3.3 =E2=80=9CNetwork Device = Configuration=E2=80=9D there and seeing if the wording is helpful? The = draft is not complete, and as always, feedback is appreciated. Thanks, sjr >=20 > Thanks. >=20 > -- > M. Ranganathan > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail=_F3A033C0-A534-4585-B0E9-9445A0EF7872 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 3, 2017, at 12:40 , M. Ranganathan <mranga@gmail.com> = wrote:

MUD suggests that devices should = always have access to DHCP and DNS. However, I don't know how to = communicate this information to the MUD controller so that appropriate = ACLs can be installed when a device comes up. A logical place to put = this would be in the request sent out by the DHCP server to the MUD = controller when it gets the OPTIONS 161 from the device. Would this be = the way this is envisioned to work? 

Would it be worthwhile documenting this interaction (in = followup work).

I and Thorsten are trying to capture some of these = notions in


although your particular = case isn=E2=80=99t covered explicitly (I=E2=80=99ll add that).  Do = you mind reading section 3.3 =E2=80=9CNetwork Device Configuration=E2=80=9D= there and seeing if the wording is helpful?  The draft is not = complete, and as always, feedback is appreciated.

Thanks,
sjr


Thanks.

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

= --Apple-Mail=_F3A033C0-A534-4585-B0E9-9445A0EF7872-- --Apple-Mail=_08941F3B-EC04-4826-9FA5-1F4977B88576 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlnTwDsACgkQJ1Qk+VAStoj1pwCfU9mCEApv8+rFjTZQsVXYT8OH RRUAniTxUAilk9AAGikG3yu728LVpEp2 =Fnl6 -----END PGP SIGNATURE----- --Apple-Mail=_08941F3B-EC04-4826-9FA5-1F4977B88576-- From nobody Tue Oct 3 11:39: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 BCEEC133061 for ; Tue, 3 Oct 2017 11:39:25 -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=unavailable 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 6FTFYYvdD-kZ for ; Tue, 3 Oct 2017 11:39:19 -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 103581344D2 for ; Tue, 3 Oct 2017 11:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2460; q=dns/txt; s=iport; t=1507055485; x=1508265085; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=7rcLzKwMx2wyCcAOZ+WT+V1MefDnNqmpp4KBYKyjYLc=; b=gNJg2Ckvbaq+GqZePPEhuu3ey0h4bq6V3bDLNXMWFU32WZlztJ829OmF UFG1zm6Mh9/UfVkc18lmXdbYnijhGGW4HUrVfiDz7m89DpZX/YBEhgdDu DkAnVNS7otkBNCxwronGG525JeeIsS2AGcQBAGtbYklM/uSm3jOt+9VAR w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAQAI19NZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhS+EIIsTkDorliyCEgcDhTsChQ4XAQIBAQEBAQEBayiFGQEFI2Y?= =?us-ascii?q?LGCoCAlcGAQwIAQGKLKUwgieLHwEBAQEBAQQBAQEBAQEBEg+DLYVogn2EboMpg?= =?us-ascii?q?mEBBKEyhDyCIY4Ii12HLJVUgTkhAjSBDjIhCB0VSYcfPoo5AQEB?= X-IronPort-AV: E=Sophos;i="5.42,474,1500940800"; d="asc'?scan'208";a="697746216" 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; 03 Oct 2017 18:31:17 +0000 Received: from [10.61.238.204] ([10.61.238.204]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v93IVGtR029541; Tue, 3 Oct 2017 18:31:17 GMT To: "M. Ranganathan" , opsawg@ietf.org References: From: Eliot Lear Message-ID: Date: Tue, 3 Oct 2017 20:31:19 +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="UDbUAVtvs64iiANMokPD3vJcxOBsHHEA4" Archived-At: Subject: Re: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS. 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, 03 Oct 2017 18:39:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UDbUAVtvs64iiANMokPD3vJcxOBsHHEA4 Content-Type: multipart/mixed; boundary="HLUmxoda2Evc71OHVA5rnh6sVWCGm2XDx"; protected-headers="v1" From: Eliot Lear To: "M. Ranganathan" , opsawg@ietf.org Message-ID: Subject: Re: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS. References: In-Reply-To: --HLUmxoda2Evc71OHVA5rnh6sVWCGm2XDx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Ranga, On 10/3/17 6:40 PM, M. Ranganathan wrote: > MUD suggests that devices should always have access to DHCP and DNS. > However, I don't know how to communicate this information to the MUD > controller so that appropriate ACLs can be installed when a device > comes up. A logical place to put this would be in the request sent out > by the DHCP server to the MUD controller when it gets the OPTIONS 161 > from the device. Would this be the way this is envisioned to work?=C2=A0= This is covered in the document in Section 4, with NTP and DNS being given access by default, and it is covered as well in Appendix B.=C2=A0 T= he intent is that your MUD controller should be aware of the DNS and NTP servers, perhaps through configuration.=C2=A0 Thus when constructing an access-list, appropriate permits should be generated without reference within the MUD file.=C2=A0 Does this need more clarity? Eliot --HLUmxoda2Evc71OHVA5rnh6sVWCGm2XDx-- --UDbUAVtvs64iiANMokPD3vJcxOBsHHEA4 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 iQEbBAEBCAAGBQJZ09d3AAoJEIe2a0bZ0noz9WkH9iWSvOHq9kxCsXNNdAB9rTkA muLM44fgopujw66dzbXxKuI+1rh3UGxjw6RX1HElGMQFZ+KX4UUUYkQ8IQoENE2h WWN8Xkx3zrRlrNtmQcxTX5prm7Y6oZdMj1e4jw2iQnO6DxocJqqxEcI+qwkrYk61 03H6mxXNe2DD/ptW0BSM9RH5M8aQ0h7YWJGZ+xI46f4cDeJcTfy79GSOlSjlB0td C2efHCRawxHT+DvwIuN19PbvaeQk29eOhEvTTHmoojCcLGhrixp3Wt3Jwuys4zXR iksQ+NIfPXv8+eekJFLswmWTdefGFOdELD7+6Qc9xeGGP06mbLo3jUdnKfG02Q== =LfrK -----END PGP SIGNATURE----- --UDbUAVtvs64iiANMokPD3vJcxOBsHHEA4-- From nobody Tue Oct 3 12:43:43 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 DD11F1331BA for ; Tue, 3 Oct 2017 12:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nxBYTqMJJ6DV for ; Tue, 3 Oct 2017 12:43:41 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDFD13307B for ; Tue, 3 Oct 2017 12:43:41 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id k62so7160710wrc.9 for ; Tue, 03 Oct 2017 12:43:41 -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=dWJKT52J7tNOTsP57Ue/lD0Z+2ut+pgniIm7xU6/zIc=; b=gYg0JMKBwmrTha9fF4iuLA1mxRQIlg5dx2JEn1+zRWokKDQxznpOGqA6wqgcubTbb5 LnxynnnBSXMPCn68uJBq0eiuUZUFfkJRxtRGMwOShXWtWJOWSvQlKqEhnXDBW7jQbSe/ 8PPf1COTFRdEVpazH8XEBrWRfNOSCqX5Ykja/PhxRIXVS3J+GZ2y2+1SeOOBp6uwGwPs 1EThSMjwWO3+fK5AFm1PuM1cVEwoOt4HT/RqdvwoiKHseicySnn4BncHJl7zrEvcJzNc QikL5YmpHulxWbXTvoZ2v+DWOkYrTzPmsNqa4WRzk9vXM1q2PdID2JWUySJcpZFjPHd5 sORQ== 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=dWJKT52J7tNOTsP57Ue/lD0Z+2ut+pgniIm7xU6/zIc=; b=P3V7S2GGPJ/esbO+3Jnwmsx37jHVbWHizztD5cw3zlXLWfSy38Ft2ZNXa1L/8M8Qcs rqliOVUS8id0zXXNmZ+o8YdYxJ19T1R4U9VdmdPPRG3dRrwMut7suFr8cklCVgyFjk+/ biO3p6k7JvzpCvTJaD/s7ra2g2/7CYOLbRHedgCRJBBCV7ixitw95IKYsPoX4dzyE79w r+IFxgnIkvb5GomPtN0AXKOajjEtfGJckAo0YGxet6VBTDJZuiAbPZge0eY6y+ANriB1 QWPpaEsOBLGAJX0bZRmZ+DCS1Ve5NwXR6E//nhvTFAdmpmXZ8CTzAXUHYR81U//bjgKx ZCJg== X-Gm-Message-State: AMCzsaVOEURMvFDDe3gn4VhWO4mJpEib8oLmuetLwsqp2kcR6fsaZb6t iyQKLFz9sOG9ehbtPDM/KctvClkLgDzJMd6zDoM= X-Google-Smtp-Source: AOwi7QASB+FO9IIq3lj4u70KP1N21B5F7kSREqhm6nmNZMSZ8BzlIX14wx5C7/6H352cFnQDNaigzm1vFO8SiDBnlJA= X-Received: by 10.223.157.39 with SMTP id k39mr10588905wre.49.1507059819396; Tue, 03 Oct 2017 12:43:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.175.213 with HTTP; Tue, 3 Oct 2017 12:42:58 -0700 (PDT) In-Reply-To: References: From: "M. Ranganathan" Date: Tue, 3 Oct 2017 15:42:58 -0400 Message-ID: To: Eliot Lear Cc: opsawg@ietf.org Content-Type: multipart/alternative; boundary="f40304388f1830c4fa055aa9b51b" Archived-At: Subject: Re: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS. 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, 03 Oct 2017 19:43:43 -0000 --f40304388f1830c4fa055aa9b51b Content-Type: text/plain; charset="UTF-8" Eliot, The MUD draft says: Local DNS and NTP are, by default, permitted to and from the Thing. Looking at the example in Appendix B I see : "controller": "urn:ietf:params:mud:dns" Which implies this string has to map to the ip address where DNS is hosted. I am wondering where/how that mapping takes place. For example, if a DHCP server were to communicate with the MUD controller, it could make this information available to the MUD controller but how? Perhaps an example of how to do this would help implementers. Also in appendix B is the syntax of the ACL for the example correct ? Thanks, Ranga. On Tue, Oct 3, 2017 at 2:31 PM, Eliot Lear wrote: > Hi Ranga, > > > On 10/3/17 6:40 PM, M. Ranganathan wrote: > > MUD suggests that devices should always have access to DHCP and DNS. > > However, I don't know how to communicate this information to the MUD > > controller so that appropriate ACLs can be installed when a device > > comes up. A logical place to put this would be in the request sent out > > by the DHCP server to the MUD controller when it gets the OPTIONS 161 > > from the device. Would this be the way this is envisioned to work? > > This is covered in the document in Section 4, with NTP and DNS being > given access by default, and it is covered as well in Appendix B. The > intent is that your MUD controller should be aware of the DNS and NTP > servers, perhaps through configuration. Thus when constructing an > access-list, appropriate permits should be generated without reference > within the MUD file. Does this need more clarity? > > Eliot > > > -- M. Ranganathan --f40304388f1830c4fa055aa9b51b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eliot,

The MUD draft= says:

    Local DNS and NTP are, by de=
fault, permitted to and from the Thing.

Looking at the example= in Appendix B I see :
       "control=
ler": "urn:ietf:params:mud:dns"

Which implies= this string has to map to the ip address where DNS is hosted. I am wonderi= ng where/how that mapping takes place. For example, if a DHCP server were t= o communicate with the MUD controller, it could make this information avail= able to the MUD controller but how?

Perhaps an example of how = to do this would help implementers.

Also in appendix B is the = syntax of the ACL for the example correct ?

Thanks,
<= div>

Ranga.

On Tue, Oct 3, 2017 at 2:31 PM, Eliot Lear <lear@cisco= .com> wrote:
Hi Ranga,


On 10/3/17 6:40 PM, M. Ranganathan wrote:
> MUD suggests that devices should always have access to DHCP and DNS. > However, I don't know how to communicate this information to the M= UD
> controller so that appropriate ACLs can be installed when a device
> comes up. A logical place to put this would be in the request sent out=
> by the DHCP server to the MUD controller when it gets the OPTIONS 161<= br> > from the device. Would this be the way this is envisioned to work?=C2= =A0

This is covered in the document in Section 4, with NTP and DNS being=
given access by default, and it is covered as well in Appendix B.=C2=A0 The=
intent is that your MUD controller should be aware of the DNS and NTP
servers, perhaps through configuration.=C2=A0 Thus when constructing an
access-list, appropriate permits should be generated without reference
within the MUD file.=C2=A0 Does this need more clarity?

Eliot





--
M. Ranganathan
=
--f40304388f1830c4fa055aa9b51b-- From nobody Wed Oct 4 06:51:08 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 5E219132697 for ; Wed, 4 Oct 2017 06:51:07 -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 63IDJWMl7hZD for ; Wed, 4 Oct 2017 06:51:05 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B700132031 for ; Wed, 4 Oct 2017 06:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2816; q=dns/txt; s=iport; t=1507125065; x=1508334665; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ww/Ba+TG8EUM15305lPgA9IvCukf5cUYdE+H7jwEGvg=; b=jXvLrmS4u2IiRCJuYD2eC6DFcSixdjjIqdI/tidqZowNcak0j8wD2nOm Xq2bLTLdAAcMV2UFtrK66iA3WofhEOWQI4IxRe1awZgiYUAKt4SwRwtfs 0Y844kCZifsIQM91HU3eS8AWzbvftaDHS3VckQKPi8zujTsdIT9cfsmZG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAQAL59RZ/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg11kbieDepoFgXaWOoIEChgLhElPAoRaVwECAQEBAQECayiFGAE?= =?us-ascii?q?BAQECAQEBIQ8BOwkCEAsYAgIREgMCAicfEQYBDAYCAQGKJAgQpWSCJ4siAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYEOgh+CAoFRgWorgn2DMoENDQUBEgFeglSCYQE?= =?us-ascii?q?EkUCPcodejQeCFFuFFINahyyVVIE5V4EDC1MlFR8qhzkkNocQgjQBAQE?= X-IronPort-AV: E=Sophos;i="5.42,477,1500940800"; d="scan'208";a="12532411" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2017 13:50:55 +0000 Received: from [10.150.55.239] (dhcp-10-150-55-239.cisco.com [10.150.55.239]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v94DosvW005828; Wed, 4 Oct 2017 13:50:55 GMT To: mohamed.boucadair@orange.com, "opsawg@ietf.org" Cc: JACQUENET Christian IMT/OLN References: <150661098669.27667.2985159583704772900.idtracker@ietfa.amsl.com> <3383eb88-5299-4e94-bec7-bc91a1b04373@OPEXCLILM24.corporate.adroot.infra.ftgroup> From: Joe Clarke Organization: Cisco Message-ID: Date: Wed, 4 Oct 2017 09:50:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3383eb88-5299-4e94-bec7-bc91a1b04373@OPEXCLILM24.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-nat-yang-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Oct 2017 13:51:07 -0000 On 9/28/17 11:07, mohamed.boucadair@orange.com wrote: > Dear WG, > > The new version takes into account the comments from Kris, mainly: > - allow for multiple config within the same NAT instance. > - bind an external interface with a specific NAT config. > > Chairs, now that we (authors) asked for external reviews covering (CLAT, EAM, NPTv6 and CGN), we do think that the document is now ready for an early YANG doctors review. Can you please arrange for it? Thank you. Thanks, Med. I dropped the ball here. I saw this email, and got distracted. Nonetheless, Tianran has requested a review from YANG Doc due by the 18th of this month. Joe > > Cheers, > Med > >> -----Message d'origine----- >> De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Envoyé : jeudi 28 septembre 2017 17:03 >> À : 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-04.txt >> >> >> A new version of I-D, draft-ietf-opsawg-nat-yang-04.txt >> has been successfully submitted by Mohamed Boucadair and posted to the >> IETF repository. >> >> Name: draft-ietf-opsawg-nat-yang >> Revision: 04 >> Title: A YANG Data Model for Network Address Translation (NAT) >> and Network Prefix Translation (NPT) >> Document date: 2017-09-28 >> Group: opsawg >> Pages: 78 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-opsawg- >> nat-yang-04.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat- >> yang/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-04 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg- >> nat-yang-04 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat- >> yang-04 >> >> Abstract: >> For the sake of network automation and the need for programming >> Network Address Translation (NAT) function in particular, a data >> model for configuring and managing the NAT is essential. This >> document defines a YANG module for the NAT function. >> >> NAT44, Network Address and Protocol Translation from IPv6 Clients to >> IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit >> Address Mappings for Stateless IP/ICMP Translation (SIIT EAM), and >> IPv6 Network Prefix Translation (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 Wed Oct 4 08:01:08 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 371BD132D45 for ; Wed, 4 Oct 2017 08:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.622 X-Spam-Level: X-Spam-Status: No, score=-12.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 VFkpTNP_tPv9 for ; Wed, 4 Oct 2017 08:01:05 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2865E1321AC for ; Wed, 4 Oct 2017 08:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=556; q=dns/txt; s=iport; t=1507129265; x=1508338865; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=YpCjMQAqZ0cpp8KXhWGMIaaL0nyi5zCg/IfV9hFherg=; b=P9kWdwPJsEG3tAYehRnZZC0peqautIvhxpvsC/sUI4R9W8Y+bTkR3pTD t0791BGS/HxaBmWaCafMQ1MtZ1lDmV2rQcg/xUTYIGdJIpZK7fdW/eWha Jz+KjP7kxwUAPcJDQhSkxmSVKQHpW712usNpoU3UJMuCcSgRYGnbCtO+W s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgAC99RZ/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg12BUoQhmgSBVJhgCooYVwECAQEBAQECax0LhUKBCwImAl8NCAE?= =?us-ascii?q?BiiyldIIniyIBAQEHAiaBDoIfggKBUYIVC4JyiBeCYQEEoTKBbYlQiSiBexmJS?= =?us-ascii?q?SSHCIoTi0GBOVeBDlMlFYgCJIl6AQEB?= X-IronPort-AV: E=Sophos;i="5.42,477,1500940800"; d="scan'208";a="12020528" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2017 15:01:04 +0000 Received: from [10.150.55.239] (dhcp-10-150-55-239.cisco.com [10.150.55.239]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v94F1368019501 for ; Wed, 4 Oct 2017 15:01:04 GMT To: "opsawg@ietf.org" From: Joe Clarke Organization: Cisco Message-ID: <9cc7868b-0993-db4e-245d-1cdcca22a734@cisco.com> Date: Wed, 4 Oct 2017 11:01:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [OPSAWG] Review of draft-ietf-opsawg-mud-11 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, 04 Oct 2017 15:01:06 -0000 I have re-read the latest MUD draft, and in general, it reads well and seems to address recent directorate comments. I noticed two small things in the latest example, though. First, the order of elements does not agree with the YANG model. It should be: mud-url last-update cache-validity is-supported systeminfo But the example lists: mud-url last-update is-supported systeminfo cache-validity Also, under the definition for ACE cl0-todev, the direction is specified as from-device when I think it should be to-device. Joe From nobody Wed Oct 4 08:59: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 4C1FE13430E for ; Wed, 4 Oct 2017 08:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 z2LGQao0M0zJ for ; Wed, 4 Oct 2017 08:59:04 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 C47D2134303 for ; Wed, 4 Oct 2017 08:59:03 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id l39so8985145wrl.12 for ; Wed, 04 Oct 2017 08:59:03 -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=KNSXPsgRph+YGUbN6ffEt/GhBP4MuwWLXDLR4A+2jaw=; b=uIELZ8eA6a3NyclOtO5DfNtytVu/DsdNJqG7ZXERdWBr9nxZUCP4lgjE1vSHg+584V D09BRMpdcy+AyInaV1jNGzpkw6/vClLHoFwmY/yUvcBiztxDtFP9qSg1Fq9LQVylVBfi 1l19reO61iDaG64vJ6mN4lCnmbe/IgcL3mtlgZna7p62KdG3phVhboN30iOOgDHyGndQ 2fH0aNyg4DnMTRidffFR//E9sfOD5OVj9iUoBUd5iCjcYOQy85pRen9f0EYWgTSuM/6r 01E/kJO2ElcMZXcLHSV8jmHKzY46WB4EyzoZfss5uppUPuuwpkKHmdCQIk2ROzuuCESY VzTw== 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=KNSXPsgRph+YGUbN6ffEt/GhBP4MuwWLXDLR4A+2jaw=; b=I4r4QZxLzIhn/lfCRyxXzx94aJClr/H/2VuNN36m2iO40EqkWTTWArODF7Xk1zQSox dlJV0+WC9xU0o+sL0ahM+1vN2bKkflIkOyHaXs76e4ACVAE/E1pSreyG3WQ1lP5Kb/qs Wim5DwsIZC06HUsrdV48mn2oQI4hajKNt+tFf4wNDctZBPfZ/imVbAofPHq73rXxK6eP 7Au0oPnUSgLoURGOntiMkvqUY9/+ks9X03ROvG/O4tOHgzbFN3wr7KesOdx9yTEqjHVc ElgF9IB15Xrwn7OWYSXGgJb2dxwabW7Mtaju4/U5Zo+cYdqz26b4p2FIwbAn7yoz6BWz risQ== X-Gm-Message-State: AMCzsaWxTV+tXvsz6vvvaJyq3nW0iwS9ZITRFFbXIxG/uChC01HimWcz POYiQyE5UGkZQFSUQUFS+AcUU66nx3Yofnuy/ko= X-Google-Smtp-Source: AOwi7QCdL5ilN6zv7+0VXjuxe8gf0uKss4uthtq0gU/q4L8FmnzKYs+gKe2g2YPIB6MOV6T33PtL8RDYoY6/DZKvDnY= X-Received: by 10.223.177.143 with SMTP id q15mr1629723wra.49.1507132741940; Wed, 04 Oct 2017 08:59:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.175.213 with HTTP; Wed, 4 Oct 2017 08:58:21 -0700 (PDT) In-Reply-To: <7B1589B4-15E4-4793-8A28-965021EBE6CB@cisco.com> References: <7B1589B4-15E4-4793-8A28-965021EBE6CB@cisco.com> From: "M. Ranganathan" Date: Wed, 4 Oct 2017 11:58:21 -0400 Message-ID: To: Steven Rich Cc: opsawg@ietf.org Content-Type: multipart/alternative; boundary="f403045e7452b67b78055abaaf6d" Archived-At: Subject: Re: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS. 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, 04 Oct 2017 15:59:11 -0000 --f403045e7452b67b78055abaaf6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Architecturally, there are four functional blocks: MUD file server : Serves MUD files. This is an optional component. MUD files could be directly bundled with the device itself if is-supported flag is False MUD Controller: Transmits the mud file and auxiliary information (such as the local address of the default network services) to the MUD policy server. Manages the cache (retrieves policy files from the MUD file server periodically and supplies them to the MUD policy server). For example, this functionality may be implemented in an enhanced DHCP server or as a cloud resident caching service. MUD policy server: Resolves MUD ACLs and installs them on switch (e.g. as a set of Flow rules). The MUD policy server could be a NETCONF or SDN controller managing multiple switches. ACL / SDN capable switch. If my terminology is wrong, please correct. Looking through section 3 (comments in line) The MUD Policy Server may support caching retrieved MUD files. If it does, then the operator may choose to enable, tune, test, and monitor this functionality as well. Details about caching MUD files as well as each task above will be covered later in this document. Does the MUD policy server need to do this? If "is-supported" is True then the MUD Controller may do cache management as well (?). The goal of MUD is to enable the near-automatic management of device segmentation for the class of devices which have MUD support. That is, we want to automatically map devices with different sensitivities to different network segments. That is not necessarily the only goal. One could limit the behavior of specific devices without introducing the notion of network segments. 1. Able to "see" a MUD URI 2. Able to retrieve a MUD file 3. Able to map a specific device (for example via a MAC id) to a MUD file that has been retrieved from the cloud. Does section 3.4 (Testing) belong in section 3? Cache management could be important because a manufacturer could update the MUD file. So at least when a device boots, if is-supported is True then a new copy of the file should be retrieved. Good work on the draft! Regards, Ranga. (Affiliation: NIST / Advanced Networking Technologies Division) On Tue, Oct 3, 2017 at 12:52 PM, Steven Rich wrote: > > On Oct 3, 2017, at 12:40 , M. Ranganathan wrote: > > MUD suggests that devices should always have access to DHCP and DNS. > However, I don't know how to communicate this information to the MUD > controller so that appropriate ACLs can be installed when a device comes > up. A logical place to put this would be in the request sent out by the > DHCP server to the MUD controller when it gets the OPTIONS 161 from the > device. Would this be the way this is envisioned to work? > > Would it be worthwhile documenting this interaction (in followup work). > > > I and Thorsten are trying to capture some of these notions in > > https://tools.ietf.org/html/draft-srich-opsawg-mud-net-lifecycle-01 > > although your particular case isn=E2=80=99t covered explicitly (I=E2=80= =99ll add that). > Do you mind reading section 3.3 =E2=80=9CNetwork Device Configuration=E2= =80=9D there and > seeing if the wording is helpful? The draft is not complete, and as > always, feedback is appreciated. > > Thanks, > sjr > > > Thanks. > > -- > M. Ranganathan > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > > --=20 M. Ranganathan --f403045e7452b67b78055abaaf6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Architecturally, t= here are four functional blocks:

MUD file server : Serves= MUD files. This is an optional component. MUD files could be directly bund= led with the device itself if is-supported flag is False

MUD Control= ler: Transmits the mud file and auxiliary information (such as the local ad= dress of the default network services) to the MUD policy server. Manages th= e cache (retrieves policy files from the MUD file server periodically and s= upplies them to the MUD policy server). For example, this functionality may= be implemented in an enhanced DHCP server or as a cloud resident caching s= ervice.

MUD policy server: Resolves MUD ACLs and installs them on sw= itch (e.g. as a set of Flow rules). The MUD policy server could be a NETCON= F or SDN controller managing multiple switches.

ACL / SDN= capable switch.


If my terminology is wron= g, please correct.


Looking through section= 3 (comments in line)


    The MUD P=
olicy Server may support caching retrieved MUD files.  If
   it does, then the operator may choose to enable, tune, test, and
   monitor this functionality as well.  Details about caching MUD
   files as well as each task above will be covered later in this
   document.

Does the MUD policy =
server need to do this? If "is-supported" is True then the MUD Co=
ntroller may do cache management as well (?). 

   The goal of MUD is to enable the near-automatic management=
 of
   device segmentation for the class of devices which have MUD
   support. 

That is, we want to =
automatically map devices with different sensitivities to different network=
 segments. That is not necessarily the only goal. One could 
limit the behavior of specific devices without intr=
oducing the notion of network segments.

   1. Able to "see" a MUD URI

   2. Able to retrieve a MUD file

3. Able to map a specific device (for example via a MAC id) to a MUD file =
that has been retrieved from the cloud.

Does section 3.4 (Testing) belong in section 3? 

Cache management =
could be important because a manufacturer could update the MUD file. So at =
least when a device boots, if is-supported is True then 
a new copy of the file should be retrieved.
<= /div>Good work on the draft!

Regards,

Ranga.=C2= =A0 (Affiliation: NIST / Advanced Networking Technologies Division)

=

On Tue, Oct= 3, 2017 at 12:52 PM, Steven Rich <srich@cisco.com> wrote:
=

On Oct 3, 2017, at 12:40 ,= M. Ranganathan <m= ranga@gmail.com> wrote:

MUD suggests that devices = should always have access to DHCP and DNS. However, I don't know how to= communicate this information to the MUD controller so that appropriate ACL= s can be installed when a device comes up. A logical place to put this woul= d be in the request sent out by the DHCP server to the MUD controller when = it gets the OPTIONS 161 from the device. Would this be the way this is envi= sioned to work?=C2=A0

Would it be worthwhile documenting this= interaction (in followup work).

I and Thorsten are trying to capture some of these notions in<= /div>

although your particular case isn=E2=80=99t covered explicitly = (I=E2=80=99ll add that).=C2=A0 Do you mind reading section 3.3 =E2=80=9CNet= work Device Configuration=E2=80=9D there and seeing if the wording is helpf= ul?=C2=A0 The draft is not complete, and as always, feedback is appreciated= .

Thanks,
sjr


Thanks.

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




--
M. Ranganathan
--f403045e7452b67b78055abaaf6d-- From nobody Wed Oct 4 09:33:57 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 3207B1342D2 for ; Wed, 4 Oct 2017 09:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.121 X-Spam-Level: X-Spam-Status: No, score=-13.121 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Ul09u_6XBHmn for ; Wed, 4 Oct 2017 09:33:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B529132076 for ; Wed, 4 Oct 2017 09:33:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=825; q=dns/txt; s=iport; t=1507134831; x=1508344431; h=subject:from:to:references:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=5K0x18TL8fOVNC8qu7jJ+/YwFMoeeqF+sPkxVRZYgb4=; b=i62cPFeP2kG91mQCCxK4xtTIvF2Rp8vNqrw+zBWelfMufo1yIUuNBlb8 gLyMFfKGQ+xNVutCRetlSjS3w7+kFlBpVTlj+zGWWwshw24vptE+k5KQi 290hA0WeDJhbuBd7uEApS9oPreuBkk67pyQ0BsiOfiUkGOR8fLtHtZbCl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAQDYDNVZ/5BdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg12BUoQhmguBdpg+CoU7AoRbQhUBAgEBAQEBAQFrHQuFGQEFI2Y?= =?us-ascii?q?LGAICJgICVwYNCAEBiiyld4InizEBAQEBAQEBAwEBAQEBI4EOgh+CAoFRghWCf?= =?us-ascii?q?YgXgmEBBKEyiz2JKIIUiUkkhwiKE4tBgTk1IoEOUyUViAIkiXoBAQE?= X-IronPort-AV: E=Sophos;i="5.42,477,1500940800"; d="scan'208";a="306511513" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2017 16:33:50 +0000 Received: from [10.150.55.239] (dhcp-10-150-55-239.cisco.com [10.150.55.239]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v94GXnTj026353 for ; Wed, 4 Oct 2017 16:33:50 GMT From: Joe Clarke To: "opsawg@ietf.org" References: <9cc7868b-0993-db4e-245d-1cdcca22a734@cisco.com> Organization: Cisco Message-ID: <4a420d67-966b-36e5-4fc1-6da5d579920b@cisco.com> Date: Wed, 4 Oct 2017 12:33:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9cc7868b-0993-db4e-245d-1cdcca22a734@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] Review of draft-ietf-opsawg-mud-11 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, 04 Oct 2017 16:33:56 -0000 On 10/4/17 11:01, Joe Clarke wrote: > I have re-read the latest MUD draft, and in general, it reads well and > seems to address recent directorate comments. > > I noticed two small things in the latest example, though. First, the > order of elements does not agree with the YANG model. It should be: > > mud-url > last-update > cache-validity > is-supported > systeminfo > > But the example lists: > > mud-url > last-update > is-supported > systeminfo > cache-validity > > Also, under the definition for ACE cl0-todev, the direction is specified > as from-device when I think it should be to-device. > One other thing I wanted to raise. Would it make sense to reference RFC7159 with respect to the JSON encoding of the MUD file? I'm thinking this should be added to Section 1.5. Joe From nobody Thu Oct 5 05:02: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 27A08134556 for ; Thu, 5 Oct 2017 05:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.1 X-Spam-Level: X-Spam-Status: No, score=-13.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 VhFmmqM82HDc for ; Thu, 5 Oct 2017 05:02:41 -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 693AB13455A for ; Thu, 5 Oct 2017 05:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2509; q=dns/txt; s=iport; t=1507204901; x=1508414501; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=l1CXJGbzsRQQtPZfCicwxnQrHuzFjWHN+CcAFyFKGvE=; b=dP4RDLm7URaByWMXT2YHzkEZ2DUKYVi2Tot7YHCj+Xsx+zWfCKLBi2o7 BO+eapm6AWcyJIxGl4cFUiSfrTZMTxcTjf5iQrm3deAx8Od+m7JUB+MwN s+CqxGIh2AC7y6oaQW0CZRauetLDBflEA1uRgrddJRqwNyqqKdRi6dm0u I=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.42,481,1500940800"; d="asc'?scan'208";a="655244951" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2017 12:01:39 +0000 Received: from [10.61.237.205] ([10.61.237.205]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v95C1drY006379; Thu, 5 Oct 2017 12:01:39 GMT To: Joe Clarke , "opsawg@ietf.org" References: <9cc7868b-0993-db4e-245d-1cdcca22a734@cisco.com> From: Eliot Lear Message-ID: Date: Thu, 5 Oct 2017 14:01:38 +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: <9cc7868b-0993-db4e-245d-1cdcca22a734@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SdpHRsKuueUHMLxtfNjCIUtWgr4KENdBa" Archived-At: Subject: Re: [OPSAWG] Review of draft-ietf-opsawg-mud-11 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, 05 Oct 2017 12:02:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SdpHRsKuueUHMLxtfNjCIUtWgr4KENdBa Content-Type: multipart/mixed; boundary="lDm9xrNk9RXjmkN2qTpumaLNwHdKopjtI"; protected-headers="v1" From: Eliot Lear To: Joe Clarke , "opsawg@ietf.org" Message-ID: Subject: Re: [OPSAWG] Review of draft-ietf-opsawg-mud-11 References: <9cc7868b-0993-db4e-245d-1cdcca22a734@cisco.com> In-Reply-To: <9cc7868b-0993-db4e-245d-1cdcca22a734@cisco.com> --lDm9xrNk9RXjmkN2qTpumaLNwHdKopjtI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Joe, Ranga, Kent, and others, Now that last call has closed I have a number of comments to resolve.=C2=A0= I will go through in the next day or so and indicate the resolution to each comment. Regards, Eliot On 10/4/17 5:01 PM, Joe Clarke wrote: > I have re-read the latest MUD draft, and in general, it reads well and > seems to address recent directorate comments. > > I noticed two small things in the latest example, though. First, the > order of elements does not agree with the YANG model. It should be: > > mud-url > last-update > cache-validity > is-supported > systeminfo > > But the example lists: > > mud-url > last-update > is-supported > systeminfo > cache-validity > > Also, under the definition for ACE cl0-todev, the direction is specifie= d > as from-device when I think it should be to-device. > > Joe > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --lDm9xrNk9RXjmkN2qTpumaLNwHdKopjtI-- --SdpHRsKuueUHMLxtfNjCIUtWgr4KENdBa 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 iQEcBAEBCAAGBQJZ1h8jAAoJEIe2a0bZ0nozdD4H/jPNwDH+l92xtT3o0lQ+pUrt AXOOsyRq+Rq4Jhu8rUPro9mCgyInZncfe6yYS8PGLrBYfAMxPtM6iaI2wMlfr7+3 px+0Lz+tfXeMgLnlX9FlM/X+v2N/w0P295gRe9Nnro+wSgAx/5pbbqd06irpvQcp p5cEfHaA5Tv/O3NPcXh+SdEAHOjcE7eVLBgiq+s99Ijvwby21oGIExPVsI8KIGS4 t/U9GYjD+3JOgsbXdRI22ghHAkty/4fQ447MKdDr5I8QYI6qSftXThidVGj2FLR/ 9VYjpQI/qQmLWGRGn3+PvKoJi1k3KK75bAPvcnV2WA9cVoAoof1m9dQL0T2BrCE= =A5jk -----END PGP SIGNATURE----- --SdpHRsKuueUHMLxtfNjCIUtWgr4KENdBa-- From nobody Thu Oct 5 07:27:53 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 6E382132143 for ; Thu, 5 Oct 2017 07:27:51 -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 CexLbMvOLExD for ; Thu, 5 Oct 2017 07:27:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB48B13454B for ; Thu, 5 Oct 2017 07:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1518; q=dns/txt; s=iport; t=1507213593; x=1508423193; h=subject:from:to:references:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=1msAt1pHKbnDWYe/emCN9AYa5i+6bO1EGSHV0oRi5v8=; b=L5mdD6IEURBkjqKwHmfPzoftQ0V4XYZJMpO79v0VmzoyrzlR61/eohuX /FVViFTbui68DRnH14X5CXETyg+inxr7a7wswfmqfLWzcmyvjcDaBF6eF Egqs6ZjF3Bucu+Or7YwUxJ0fS/tBI15uYMb80jz9NmYEmBs2mZBkheTYE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAQBQQNZZ/5xdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg11kbieDepoEgXaWLw6CBAoYDYRHTwKEIUAXAQIBAQEBAQEBax0?= =?us-ascii?q?LhRkBAQEDAQEhSxsLGAICJgICJzAGDQYCAQGKLBCmR4InizcBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARwFgQ6CH4ICgVGBaiuCfoMygR8BEgGDMoJhBaEzh16NB4IUhW+DWiS?= =?us-ascii?q?HCZVZgTkhAjSBAwtTJRVJhzkkNocLgjQBAQE?= X-IronPort-AV: E=Sophos;i="5.42,481,1500940800"; d="scan'208";a="302080756" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2017 14:26:32 +0000 Received: from [10.118.87.89] (rtp-jclarke-nitro8.cisco.com [10.118.87.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v95EQWXp020162 for ; Thu, 5 Oct 2017 14:26:32 GMT From: Joe Clarke To: "opsawg@ietf.org" References: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> Organization: Cisco Message-ID: <46f524b0-bb86-bc17-b142-93f1a025af50@cisco.com> Date: Thu, 5 Oct 2017 10:26:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1df4b02d-2484-1418-7900-c1ce63a5a283@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-mud-11 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, 05 Oct 2017 14:27:51 -0000 OPSAWG, Working group last call has concluded on this draft. Overall, we seem to be at consensus, but there were some final comments that came in. The authors are compiling them and will submit a new revision shortly. IPR has been disclosed already at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-opsawg-mud , but if the authors are aware of any other IPR, please disclose it and note it accordingly. I will be acting as the shepherd for this document moving forward. Thanks to the working group for excellent comments and feedback and to the authors for addressing feedback quickly and engaging in the on-list discussions. Joe (for the co-chairs) On 9/20/17 20:15, Joe Clarke wrote: > While this draft was already put through WGLC in March, there have been > a number of changes to it that should be reviewed. This document has > had early reviews by SEC-DIR, IOT-DIR, and GEN. The chairs are > particularly looking for a review of those items that have changed since > the -05 review (these are documented in the draft's Appendix A. > > This email starts a two-week period for last call comments for > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ . > > Please read this draft and provide any comments or questions to the list > on or before October 4, 2017. > > Joe for the opsawg chairs > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From nobody Thu Oct 5 11:51:53 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 24D6313232C; Thu, 5 Oct 2017 11:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 pszgrHwA4sXh; Thu, 5 Oct 2017 11:51:42 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 1571713293A; Thu, 5 Oct 2017 11:51:42 -0700 (PDT) X-AuditID: c6180641-4b94e9c000002d27-52-59d638d82aec Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id B1.E7.11559.8D836D95; Thu, 5 Oct 2017 15:51:20 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0352.000; Thu, 5 Oct 2017 14:51:39 -0400 From: David Sinicrope To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "draft-ietf-opsawg-service-model-explained.all@ietf.org" , "opsawg@ietf.org" Thread-Topic: RtgDir Review: draft-ietf-opsawg-service-model-explained Thread-Index: AQHTPgr6DIp07u0SF0SK5GRvLOpVgw== Date: Thu, 5 Oct 2017 18:51:39 +0000 Message-ID: <34AB742F-0243-4CF5-8151-281BCA3BB7CF@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171004 x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_34AB742F02434CF58151281BCA3BB7CFericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZXLonXPeGxbVIgy8/9S0OTdvParHi5GYm i5NzfjBbLFjzlN2BxWPJkp9MAYxRXDYpqTmZZalF+nYJXBk7P8kVHOxirVh75zJTA+Olnyxd jJwcEgImEhfmrGDrYuTiEBI4yijxYeI3dghnGaPEoSs/mUGq2ICq1m3cA9YhIqAp0d9ziwWk iFngOKPE9fWHmUASwgKOEnf/zmGGKHKTWHXmF1SDnsTyFa/ZQGwWARWJvXfnsoLYvAL2Ete/ /2IHsRkFxCS+n1oDNodZQFzi1pP5TBDnCUgs2XOeGcIWlXj5+B9YryjQzE/dBxkh4koSH3/P Z4foTZb4cOkY1HxBiZMzn7BMYBSehWTsLCRls5CUzWLkAIprSqzfpQ9RoigxpfshO4StIdE6 Zy6UbS3x8sY+RmQ1Cxg5VjFylBYX5OSmGxluYgTG0jEJNscdjHt7PQ8xCnAwKvHwrjO6FinE mlhWXJl7iFGCg1lJhHdZCVCINyWxsiq1KD++qDQntfgQozQHi5I477vyCxFCAumJJanZqakF qUUwWSYOTqkGxrm3NUqnNE7gm/Lry0fPKSn2zI5isgv0N5gF+b23OPqv1KVrW8bzzivnKg5m WSnl1mzM8Lr1Kt/66mTrilKXo8kr9opJbmr3Stozt7F8emjg3lIVs8873zwpr/3OG6Gn1VHJ f++KxdumTe/abE4kFhyYNE8oc3X3knWv/03U9Hn0hrlh8rL4F0osxRmJhlrMRcWJAKfieEqh AgAA Archived-At: Subject: [OPSAWG] RtgDir Review: draft-ietf-opsawg-service-model-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: Thu, 05 Oct 2017 18:51:46 -0000 --_000_34AB742F02434CF58151281BCA3BB7CFericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIZWxsbywNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciBkcmFmdDog4oCLaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQ8aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWlu ZWQvPi4NClRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRvIHJldmlldyBhbGwgcm91dGlu ZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFz dCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsIHJlcXVlc3Qu IFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3RhbmNlIHRvIHRo ZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGly ZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9y dGcvdHJhYy93aWtpL1J0Z0RpcjxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90 cmFjL3dpa2kvUnRnRGlyPg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBm b3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91 IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwg Y29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhy b3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCg0KDQpEb2N1bWVudDog ZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQtMDMudHh0DQpSZXZpZXdl cjogRGF2aWQgU2luaWNyb3BlDQpSZXZpZXcgRGF0ZTogNCBPY3QgMjAxNw0KSUVURiBMQyBFbmQg RGF0ZTogMjcgU2VwIDIwMTcNCkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25hbA0KU3VtbWFy eToNClRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0 IGhhcyBuaXRzIGFuZCBzb21lIG1pbm9yIGlzc3VlcyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVk IHByaW9yIHRvIHB1YmxpY2F0aW9uLg0KDQpDb21tZW50czoNCkkgZm91bmQgdGhlIGRvY3VtZW50 IGhlbHBmdWwgYW5kIGEgZ29vZCBhaWQgdG8gdGhvc2UgdHJ5aW5nIHRvIGdldCBhIGdyaXAgb24g dGhlIHZhcmlldHkgb2YgbW9kZWxpbmcgYWN0aXZpdGllcyBpbiB0aGUgSUVURi4gIFRoZSBuaXRz IGFuZCBtaW5vciBjb21tZW50cyBiZWxvdyBhcmUgb2ZmZXJlZCBpbiBhbiBhdHRlbXB0IHRvIGlt cHJvdmUgY2xhcml0eSBhbmQgcXVhbGl0eSBvZiB0aGUgZG9jdW1lbnQuICBOb25lIG9mIHRoZXNl IGNvbW1lbnRzIGFyZSBvZiBoaWdoIGVub3VnaCBwcmlvcml0eSB0byBibG9jayBwdWJsaWNhdGlv biBvZiB0aGUgZG9jdW1lbnQgc2hvdWxkIHRoZXkgcmVtYWluIHVucmVzb2x2ZWQuDQoNCk1pbm9y IElzc3VlcyBhbmQgTml0czoNCg0KDQoNCiAgKiAgIEFic3RyYWN0OiAiLi4uIHVzZWQgd2l0aGlu IHRoZSBJRVRGLi4uIi4gV291bGRuJ3QgdGhlIGRvY3VtZW50IHNlcnZlIGJldHRlciB0byBkZXNj cmliZSBob3cgdGhlIG1vZGVscyBjb3VsZC9hcmUgdXNlZCBieSB0aGUgaW5kdXN0cnkgaW5jbHVk aW5nIHdpdGhpbiBTRE4/IFNldmVyYWwgb2YgdGhlc2UgbW9kZWxzIGFyZSB1c2VkIGJ5IG90aGVy IFNET3MgZm9yIHRoZWlyIHdvcmsgaW4gZS5nLiwgcHJvdmlkaW5nIG5ldHdvcmsgYXJjaGl0ZWN0 dXJlLCBlcXVpcG1lbnQgcmVxdWlyZW1lbnRzLCBvcmNoZXN0cmF0aW9uLCBPQU0gYW5kIG1hbmFn ZW1lbnQgdG8gc3VwcG9ydCBhbmQgcHJvdmlkZSB0aGUgc2VydmljZS4gSSB3b3VsZCB0aGluayB0 aGF0IHRoZSBtYXR0ZXIgb2YgaG93IHRoZXNlIGFyZSB1c2VkIGJ5IHRoZSBJRVRGIHdvdWxkIGJl IG11Y2ggdG8gbmFycm93IGEgdmlldy4NCiAgKiAgIEludHJvIHBhcmEgMywgbGFzdCBzZW50ZW5j ZXMgLSBUaGlzIHRleHQgZGF0ZXMgaXRzZWxmLiBJdCB3b3VsZCBzdWZmaWNlIHRvIG5vdGUgdGhh dCB0aGUgbW9kZWxzIG1heSBiZSB1c2VkIGluIHRoZXNlIGVudmlyb25tZW50cyByZWdhcmRsZXNz IG9mIHRoZSB0aW1lIGZyYW1lLiAoZS5nLiwgZHJvcCDigJxldmVudHVhbGx5KQ0KICAqICAgSW50 cm8gcGFyYSA1IGxhc3Qgc2VudGVuY2UgLSBjdXN0b21lciAtIFByb3ZpZGVyIEludGVyZmFjZSBu ZWVkcyBhIGZvcndhcmQgcmVmZXJlbmNlIG9yIGJyaWVmIGRlZmluaXRpb24uIOKAqA0KICAqICAg SW50cm8gcGFyYSA2LiAtICJkZXNjcmliZWQgdG8iIG9yICJzdWJzY3JpYmVkIHRvIj8g4oCoDQog ICogICBJbnRybyBwYXJhIDYgLSBkb2VzIGl0IGRlc2NyaWJlIHRoZSBzZXJ2aWNlIG9yIHRoZSBh dHRyaWJ1dGVzIG9mIHRoZSBzZXJ2aWNlLiBJJ20gbm90IHN1cmUgYSBzZXJ2aWNlIG1vZGVsIGRl c2NyaWJlcyB0aGUgc2VydmljZSBvcGVyYXRpb24uICBBZGQgdGhlIHdvcmRzICJhdHRyaWJ1dGVz IG9mIHRoZSIg4oCoDQogICogICBTZWMgMSwgcGFyYSA0IC0g4oCcLi4uIHdpdGhpbiB0aGUgSUVU Ri4uLuKAnSBidXQgdGhlIGRvY3VtZW50IGFsc28gZGlzY3Vzc2VzIHRoZSBNRUYuIE5lZWQgdG8g bWFrZSBzdGF0ZW1lbnQgbW9yZSBnZW5lcmFsLiDigKgNCg0KICAqICAgRGVmaW5pdGlvbiBvZiBO ZXR3b3JrIE9wZXJhdG9yIC0gY2hhbmdlIHRvIHJlYWQgIi4uLiBvdGhlciBuZXR3b3JrIHNlcnZp Y2VzLiIgTm90IHN1cmUgb3RoZXIgbm9uLW5ldHdvcmsgc2VydmljZXMgYXJlIGludGVuZGVkLiDi gKgNCiAgKiAgIERlZmluaXRpb24gb2YgQ3VzdG9tZXI6IHN1Z2dlc3QgY2hhbmdlIOKAnHB1cmNo YXNlc+KAnSB0byDigJxzdWJzY3JpYmVz4oCdIOKAqA0KICAqICAgRGVmaW5pdGlvbiBvZiBDdXN0 b21lcjogRXhjbHVkZXMgcmVzaWRlbnRpYWwgY3VzdG9tZXIuLi4gd2h5PyDigKgNCiAgKiAgIERl ZmluaXRpb24gb2YgU2VydmljZTogLSBXb3VsZCBoZWxwIHRvIGdpdmUgdGl0bGVzIG9mIFJGQ3Ms IGJ1dCBtYXkgbm90IGJlIGFsaWduZWQgd2l0aCBjb252ZW50aW9ucy4NCg0KICAqICAgRGVmaW5p dGlvbiBvZiBEYXRhIE1vZGVsOiBSZWZlcnMgdG8gaW5mb3JtYXRpb24gbW9kZWwgYW5kIHJlbGF0 aW9uc2hpcHMgYmV0d2VlbiBtYW5hZ2VkIG9iamVjdHMuICBTaG91bGQgaXQgYmUganVzdCBvYmpl Y3RzPyDigKgNCiAgKiAgIERlZmluaXRpb24gb2YgU2VydmljZSBtb2RlbCAtIGluIElFVEYgaXQn cyBhIGRhdGEgbW9kZWwuIEluIG90aGVyIGdyb3Vwcz8gRS5nLiwgSVRVPyBJdCBjb3VsZCBiZSBh biBpbmZvcm1hdGlvbiBtb2RlbC7igKgNCiAgKiAgIERlZmluaXRpb24gb2YgQ3VzdG9tZXIgU2Vy dmljZSBNb2RlbDogTm90IHN1cmUgZXhhbXBsZSBvZiBvcmRlciBmdWxmaWxsbWVudCBzeXN0ZW0g aWxsdXN0cmF0ZXMgYSBodW1hbi4gIElzIHRoZXJlIGEgYmV0dGVyIGV4YW1wbGUgb2YgYSBodW1h biBjb25zdW1lcj8NCiAgKiAgIERlZmluaXRpb24gb2YgU2VydmljZSBtb2RlbCAtICIuLi4gYSBw b3J0YWJsZSB3YXkiLiBQb3J0YWJsZSB3YXk/IG9yIGRvIHlvdSBtZWFuIG1vcmUgYWdub3N0aWMg dG8gZGVwbG95bWVudCBhcmNoaXRlY3R1cmUgYW5kIGVxdWlwbWVudD8g4oCoDQogICogICBMYXN0 IHBhcmEganVzdCBiZWZvcmUgc2VjdGlvbiAzLiAtIHdoaWxlIGEgc2VydmljZSBtb2RlbCBhcyBh IHdob2xlIG1heSBub3QgYmUgaW50ZW5kZWQgdG8gYmUgc2VudCB0byBuZXR3b3JrIGRldmljZXMs IHBhcnRzIG9mIGl0IG1heSBiZSBzZW50IHRvIG5ldHdvcmsgZXF1aXBtZW50LiBUaGlzIGNvdWxk IGJlIGNsYXJpZmllZC4NCiAgKiAgIFNlYyAzLCAybmQgcGFyYSAtIOKAnC4uLiBjaG9pY2UgZm9y IHdob2V2ZXIgc3BlY2lmaWVzIHRoZSBtb2RlbC7igJ0gQW5kIHRoZSBuZXh0IHNlbnRlbmNlIG5v dGVzIHRoZSBJRVRGLiBJcyB0aGUgY2hvaWNlIHRoYXQgb2YgdGhlIG9yZ2FuaXphdGlvbiB3aGVy ZSB0aGUgbW9kZWwgaXMgc3BlY2lmaWVkLCB0aGUgaW5kaXZpZHVhbHMgc3BlY2lmeWluZyB0aGUg bW9kZWwgb3Igc29tZSBjb21iaW5hdGlvbiBvZiBib3RoPyDigKgNCiAgKiAgIFNlYyAzLCBwYXJh IDEmMiAtIHRoZXNlIHR3byBwYXJhZ3JhcGhzIGRvbuKAmXQgYWRkIHRvIHRoZSBkaXNjdXNzaW9u IGFuZCBkaXN0cmFjdCBmcm9tIHBhcmEgMyB3aGVyZSB0aGUg4oCoYWN0dWFsIGRpc2N1c3Npb24g c3RhcnRzLiDigKgNCiAgKiAgIFNlYyAzLCBwYXJhIDMsIGxhc3Qgc2VudGVuY2UgLSDigJwuLi4g ZGlyZWN0IGh1bWFuIGludGVyYWN0aW9uLi4u4oCdLiBUaGlzIGNyb3NzZXMgZnJvbSBpbXBsZW1l bnRhdGlvbiB0byBidXNpbmVzcyBwcm9jZXNzIGFuZCBzaG91bGQgYmUgbm90ZWQuIEFkZCBhIHNl bnRlbmNlIHRvIHRoZSBlZmZlY3Qgb2Yg4oCcV2hlcmUgZGlyZWN0IGh1bWFuIGludGVyYWN0aW9u IGNvbWVzIGludG8gcGxheSwgaW50ZXJmYWNlIGludGVyYWN0aW9ucyBtYXkgYmVjb21lIHJlYWxp emVkIHZpYSBidXNpbmVzcyBwcmFjdGljZXMgYW5kIG11c3QgYWNjb3VudCBmb3Igc29tZSBtYXJn aW4gb2YgZXJyb3IsIHRodXMgcmFpc2luZyB0aGUgcHJpb3JpdHkgZm9yIGF1dG9tYXRlZCwgZGV0 ZXJtaW5pc3RpYyBpbnRlcmZhY2VzLuKAnSDigKgNCiAgKiAgIEZpZ3VyZSAxIC1tb3ZlIGZpZ3Vy ZSB0byB0aGUgZGVmaW5pdGlvbiBvZiBjdXN0b21lciBzZXJ2aWNlIG1vZGVsIOKAqA0KICAqICAg U2VjIDMsIHBhcmEgOCwgbGFzdCBzZW50ZW5jZSAtIGRpc3RpbmN0aW9uIG9mIG1vZHVsZXMgYW5k IG1vZGVscy4gR29vZCBkZXNjcmlwdGlvbiBvZiBtb2R1bGVzLCBidXQgbmVlZHMgdG8gYmUgY29u dHJhc3RlZCB2cyBtb2RlbHMuIOKAqA0KICAqICAgU2VjIDMsIHBhcmEgNyDigJPigJwgVGhlIHBy YWN0aWNhbGl0eeKApuKAnSAgdGhlc2UgbGFzdCB0d28gcGFyYWdyYXBocyBoaWdobGlnaHQgYSBk ZWJhdGUgYW5kIHRoZSBkaWZmZXJlbnQgcG9pbnRzIG9mIHZpZXcuIFRoaXMgaXMgZGlmZmVyZW50 IGZyb20gdGhlIOKAnGJpZyBwaWN0dXJl4oCdIHVzYWdlIGRlc2NyaXB0aW9uIGluIHRoZSBwYXJh Z3JhcGhzIGFib3ZlLiBTdWJzZWN0aW9ucyAoZS5nLiwg4oCcVGhlIEJpZyBQaWN0dXJl4oCdIGFu ZCDigJxQcmFjdGljYWxseSBTcGVha2luZ+KAnSkgd291bGQgaGVscCBjYWxsIG91dCB0aGUgdHJh bnNpdGlvbiBpbiB0aGlua2luZyAmIGZsb3cuIOKAqA0KICAqICAgU2VjIDQsIGhlYWRpbmcgb3Ig cGFyYSAxLCAxc3Qgc2VudGVuY2UgLSDigJxTRE7igJ0gaGFzIGJlZW4gc3BlbGxlZCBvdXQgcHJl dmlvdXNseSBpbiB0aGUgaW50cm9kdWN0aW9uIGJ1dCBnaXZlbiB0aGUgZWxlbWVudGFyeSBsZXZl bCBvZiBleHBsYW5hdGlvbiBoZXJlLCBlLmcuLCDigJxjb250cm9sbGVy4oCdLCBpdCBtYXkgYmUg d29ydGggc3BlbGxpbmcgaXQgb3V0IGFnYWluLiDigKgNCiAgKiAgIFNlYyA0LCBwYXJhIDIsIDFz dCBzZW50ZW5jZSAtIHJlbW92ZSB0aGUg4oCcQnV04oCdIG9yIGNsYXJpZnkgd2hhdCB0aGUgc3Rh dGVtZW50IGlzIGNvbnRyYWRpY3Rpbmcgb3IganV4dGFwb3NpbmcuIOKAqA0KICAqICAgU2VjIDQs IHBhcmEgMiwgMm5kIHNlbnRlbmNlIOKAnCBUaGF0IGlzLOKApuKAnSAtIFRoaXMgc3RhdGVtZW50 IHNob3VsZCBiZSBjbGFyaWZpZWQuIEluaGVyZW50bHkgdGhlIHRlY2hub2xvZ3kgYXZhaWxhYmxl IHRvIGRlbGl2ZXIgYSBzZXJ2aWNlIHdpbGwgaW5mbHVlbmNlIHRoZSBmdW5jdGlvbnMgdGhhdCBh IGN1c3RvbWVyIGNhbiByZXF1ZXN0LiBFLmcuLCBhbiBFdGhlcm5ldCBjb25uZWN0aXZpdHkgc2Vy dmljZSB3aWxsIGJlIGRlZmluZWQgaW4gdGVybXMgb2YgTUFDIGFkZHJlc3NlcyxldGMuIEkgdGhp bmsgdGhlIHBvaW50IHRyeWluZyB0byBiZSBtYWRlIGhlcmUgaXMgdGhhdCB0aGUgdW5kZXJseWlu ZyB0ZWNobm9sb2d5IHNwZWNpZmljIGRldGFpbHMgc2hvdWxkIG5vdCwgb3IgdG8gdGhlIGxvd2Vz dCBleHRlbnQgcG9zc2libGUsIGJlIHJlZmxlY3RlZCBpbiBjdXN0b21lciBzZXJ2aWNlIHJlcXVl c3RzLiBFLmcuLCBvbmUgc2hvdWxkIG5vdCBoYXZlIHRvIHNwZWNpZnkgc3dpdGNoIG9yIHJvdXRl ciBpZHMsIElQIGFkZHJlc3NlcyBvciBNQUMgYWRkcmVzc2VzIGZvciBhIFRWIHNlcnZpY2UuIOKA qFNlZSBzZWN0aW9uIDcgb2YgdGhlIGRvY3VtZW50IOKAqA0KICAqICAgU2VjIDQsIHBhcmEgMiAm IDMgLSB3b3VsZG7igJl0IHRoaXMgcG9pbnQgYWJvdXQgYSBTZXJ2aWNlL05ldHdvcmsgc3BsaXQg YmUgdHJ1ZSBvdXRzaWRlIG9mIHRoZSBTRE4gY29udGV4dCBhcyB3ZWxsPyBXaHkgd291bGQgdGhp cyBiZSBsaW1pdGVkIHRvIFNETj8g4oCoDQogICogICBTZWMgNCwgRmlndXJlIDMgLSBjb3VsZCB0 aGUgZmlndXJlIHNob3cgYW4gb3JjaGVzdHJhdG9yIGludGVyYWN0aW5nIGRpcmVjdGx5IHRvIGEg bmV0d29yayBlbGVtZW50Pw0KICAqICAgU2VjIDUsIGJ1bGxldCAxIC0gSW4gdGhlIHRlcm1pbm9s b2d5IHNlY3Rpb24sIOKAnFNlcnZpY2XigJ0gaXMgZGVmaW5lZCBhcyBhIGNvbm5lY3Rpdml0eSBz ZXJ2aWNlLiBGb3IgcHVycG9zZXMgb2YgdGhpcyBkb2N1bWVudCB0aGVuIGl0IHNob3VsZCBub3Qg YmUgY29uZnVzZWQgd2l0aCBoaWdoZXIgbGF5ZXIgc2VydmljZXMuIFRoZSDigJxjdXN0b21lcuKA nSBmb3IgdGhpcyBkZWZpbml0aW9uICppcyogYXdhcmUgb2YgdGVjaG5vbG9neSBzcGVjaWZpYyBw YXJhbWV0ZXJzIGFuZCBjb25zdHJhaW50cyBvZiB0aGUgY29ubmVjdGl2aXR5IHNlcnZpY2UgdGhl eSBhcmUgc3Vic2NyaWJpbmcgdG8uIFRoZSBjYXVzZSBvZiB0aGUgY29uZnVzaW9uLCBhbmQgdGhp cyBpcyBhbiBhZ2Ugb2xkIHByb2JsZW0sIGlzIHRoYXQg4oCcc2VydmljZeKAnSBpcyBhIHJlY3Vy c2l2ZSB0ZXJtLiBUaGF0IGlzLCBhIGNvbnN1bWVyL2NsaWVudCBvZiBvbmUgbGV2ZWwgb2Ygc2Vy dmljZSAoZS5nLiwgRXRoZXJuZXQgY29ubmVjdGl2aXR5KSBpcyB0aGUgcHJvdmlkZXIvc2VydmVy IG9mIGFub3RoZXIgKGUuZy4sIEludGVybmV0IGFjY2VzcykgZm9yIGhpZ2hlciBsYXllciB1c2Ug KGUuZy4sIFRWIHNlcnZpY2UpIOKAqE1vZGVsaW5nIG1ldGhvZHMgKEcuODA1KSBoYXZlIGJlZW4g ZXN0YWJsaXNoZWQgdG8gZGVzY3JpYmUgdGhlIGNsaWVudC9zZXJ2ZXIgcmVsYXRpb25zaGlwLiDi gKgNCiAgKiAgIFNlYyA1LCBidWxsZXQgMiAtIOKAnGNvbXBsZXRlbHnigJ0gLT4gbWlnaHQgd2Fu dCB0byB0b25lIHRoaXMgZG93biBhIGJpdCwgdG8gYWNjb21tb2RhdGUgZXhjZXB0aW9ucyBub3Rl ZCBlbHNld2hlcmUgaW4gdGhlIGRvY3VtZW50LiBXaGlsZSBrZXB0IHRvIGEgbWluaW11bSwgbmV0 d29yayBvcGVyYXRpb24gaXMgbm90ICpjb21wbGV0ZWx5KiBvdXQgb2Ygc2NvcGUgd2hlbiBkaXNj dXNzaW5nIHNlcnZpY2UgYmV0d2VlbiBhIGN1c3RvbWVyIGFuZCBuZXR3b3JrIG9wZXJhdG9yLiBF LmcuLCBQYXJ0IG9mIGEgc2VydmljZSBjb3VsZCBiZSByb3V0aW5nIG9mIHRoZSBjb25uZWN0IHRv IGF2b2lkIGdlb3BvbGl0aWNhbCBib3JkZXJzLiAoTm90ZWQgb24gdGhlIHZlcnkgbmV4dCBwYWdl KSBhbm90aGVyIGV4YW1wbGUgaXMsIEZhdWx0IG5vdGlmaWNhdGlvbiBhbmQgcHJvdGVjdGlvbiBt ZWNoYW5pc21zIG1heSBiZSBkaXNjdXNzZWQuIOKAqFRoZSBzdGF0ZW1lbnQgaGVyZSBzZWVtcyB0 byBjb250cmFkaWN0IHRoZSBkZWZpbml0aW9uIG9mIEN1c3RvbWVyIFNlcnZpY2UgTW9kZWwgaW4g dGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gd2hlcmUgaXQgc3RhdGVzIHRoYXQg4oCcRXhjZXB0IHdo ZXJlIHNwZWNpZmljIHRlY2hub2xvZ3kgZGV0YWlscyAoc3VjaCBhcyBlbmNhcHN1bGF0aW9ucywg b3IgbWVjaGFuaXNtcyBhcHBsaWVkIG9uIGFjY2VzcyBsaW5rcykgYXJlIGRpcmVjdGx5IHBlcnRp bmVudCB0byB0aGUgY3VzdG9tZXIsIGN1c3RvbWVyIHNlcnZpY2UgbW9kZWxzIGFyZSB0ZWNobm9s b2d5IGFnbm9zdGljIHNvIHRoYXQgdGhlIGN1c3RvbWVyIGRvZXMgbm90IGhhdmUgaW5mbHVlbmNl IG92ZXIgb3Iga25vd2xlZGdlIG9mIGhvdyB0aGUgbmV0d29yayBvcGVyYXRvciBlbmdpbmVlcnMg dGhlIHNlcnZpY2Uu4oCdIOKAqFBlcmhhcHMgdXNlIOKAnG5vcm1hbGx54oCdIHZzIOKAnGNvbXBs ZXRlbHnigJ0g4oCoDQogICogICBTZWMgNSwgYnVsbGV0IDIgLSBwcm92aWRpbmcgZGV0YWlsIGFi b3V0IGhvdyB0aGUgc2VydmljZSBpcyBvZmZlcmVkIGNvdWxkIGFjdHVhbGx5IGJlIGNvbnNpZGVy ZWQgYSBzZWN1cml0eSDigKh2dWxuZXJhYmlsaXR5LiDigKgNCiAgKiAgIFNlYyA1LCBidWxsZXQg NCAtIGdpdmUgc29tZSBleGFtcGxlcyBvZiDigJxjb21tZXJjaWFsIHRlcm1z4oCdLiDigKgNCiAg KiAgIFNlYyA1LCBidWxsZXQgNSAtIGdpdmUgYW4gZXhhbXBsZSBvZiB0aGUg4oCcZmluZSBncmFp bmVkIGRldGFpbHPigJ0NCiAgKiAgIFNlYyA2LjIgbGlzdCBvZiBkcmFmdHMgLSB3aWxsIHRoZXNl IHdvcmtzIGluIHByb2dyZXNzIGJlIHN0YWJsZSBvciBmaW5hbCBiZWZvcmUgcHVibGljYXRpb24/ DQogICogICBTZWMgNi40LCBwYXJhIDIsM3JkIHNlbnRlbmNlIC0gdGhlIHN0YXRlbWVudCBvbiBp dCBiZWluZyBpbXByYWN0aWNhbCB0byBmaXQgSUVURiBtb2RlbHMgaW50byBNRUYgbW9kZWxzIHNl ZW1zIGEgYml0IGJyb2FkLiBIYXMgYW55b25lIGxvb2tlZCBpbnRvIHRoaXM/DQoNCg0KUmVsZXZh bnQgRGlyZWN0b3JhdGUgUmV2aWV3IEd1aWRhbmNlDQpNaW5vciBJc3N1ZXMgYW5kIE5pdHM6DQoN CiAgKiAgIE1pbm9yIGlzc3VlcyBhcmUgY29uY2VybnMgYWJvdXQgY2xhcml0eSBvciB0ZWNobmlj YWwgYWNjdXJhY3kgdGhhdCBzaG91bGQgYmUgZGlzY3Vzc2VkIGFuZCByZXNvbHZlZCBiZWZvcmUg cHVibGljYXRpb24sIGJ1dCB3aGljaCB3b3VsZCBub3JtYWxseSBiZSByZXNvbHZlZCBiZXR3ZWVu IHRoZSBhdXRob3JzIGFuZCB0aGUgcmV2aWV3ZXJzLg0KICAqICAgUGxlYXNlIGluY2x1ZGUgYWxs IG9mIHRoZSBtaW5vciBpc3N1ZXMgeW91IGhhdmUgZm91bmQuIEdpdmUgYXMgbXVjaCBjb250ZXh0 IGluZm9ybWF0aW9uIGFzIHBvc3NpYmxlIChlLmcuLCBzZWN0aW9uIG51bWJlcnMsIHBhcmFncmFw aCBjb3VudHMpLg0KICAqICAgSWYgeW91IGZpbmQgbm8gbWlub3IgaXNzdWVzLCBwbGVhc2Ugd3Jp dGU6ICJObyBtaW5vciBpc3N1ZXMgZm91bmQuIg0KDQogICogICBOaXRzIGFyZSBlZGl0b3JpYWwg b3IgbGF5b3V0IGl0ZW1zLiBUaGV5IGFyZSB0aGluZ3MgdGhhdCB3b3VsZCBpZGVhbGx5IGJlIHJl c29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbiB0byBtYWtlIHRoZSBkb2N1bWVudCBtb3JlIHJlYWRh YmxlLCBhbmQgbWF5IGJlIHJhaXNlZCBub3cgdG8gc2F2ZSB0aGUgUkZDIEVkaXRvciB3b3JrLg0K DQo= --_000_34AB742F02434CF58151281BCA3BB7CFericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <1D5B5981D6E4D2489C5B0B97AE3C1712@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0x OjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFn cmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0K CWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEgMSAtMSAtMSAtMSAtMSAtMSAtMSAtMSAt MTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0OiJcLiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLXRleHQ6IiI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCgl0ZXh0LWluZGVudDowaW47fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC10ZXh0OiIiOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDowaW47DQoJdGV4dC1pbmRlbnQ6MGluO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtdGV4dDoiIjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCXRleHQtaW5kZW50OjBpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjA7DQoJbXNvLWxldmVsLXRleHQ6IiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCgl0 ZXh0LWluZGVudDowaW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1zdGFydC1hdDow Ow0KCW1zby1sZXZlbC10ZXh0OiIiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDowaW47DQoJdGV4dC1pbmRl bnQ6MGluO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28t bGV2ZWwtdGV4dDoiIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCXRleHQtaW5kZW50OjBpbjt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLXRl eHQ6IiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCgl0ZXh0LWluZGVudDowaW47fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC10ZXh0OiIiOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDowaW47DQoJdGV4dC1pbmRlbnQ6MGluO30NCkBsaXN0IGwxDQoJe21z by1saXN0LWlkOjI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjIgMTAxIC0xIC0xIC0xIC0xIC0xIC0xIC0xIC0xO30NCkBsaXN0IGwxOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6IlwuIjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtdGV4dDoiIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCXRl eHQtaW5kZW50OjBpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLXRleHQ6IiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCgl0ZXh0LWluZGVu dDowaW47fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1s ZXZlbC10ZXh0OiIiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDowaW47DQoJdGV4dC1pbmRlbnQ6MGluO30N CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtdGV4 dDoiIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCXRleHQtaW5kZW50OjBpbjt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLXRleHQ6IiI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCgl0ZXh0LWluZGVudDowaW47fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC10ZXh0OiIiOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDowaW47DQoJdGV4dC1pbmRlbnQ6MGluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtdGV4dDoiIjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCXRleHQtaW5kZW50OjBpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjA7DQoJbXNvLWxldmVsLXRleHQ6IiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCgl0 ZXh0LWluZGVudDowaW47fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MzsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MyAyMDEgLTEgLTEgLTEgLTEgLTEg LTEgLTEgLTE7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDoiXC4iOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC10ZXh0 OiIiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgltYXJnaW4tbGVmdDowaW47DQoJdGV4dC1pbmRlbnQ6MGluO30NCkBsaXN0IGwy OmxldmVsMw0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtdGV4dDoiIjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCXRleHQtaW5kZW50OjBpbjt9DQpAbGlzdCBsMjpsZXZlbDQN Cgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLXRleHQ6IiI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdp bi1sZWZ0OjBpbjsNCgl0ZXh0LWluZGVudDowaW47fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1s ZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC10ZXh0OiIiOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDow aW47DQoJdGV4dC1pbmRlbnQ6MGluO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtdGV4dDoiIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCXRl eHQtaW5kZW50OjBpbjt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLXRleHQ6IiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCgl0ZXh0LWluZGVu dDowaW47fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1s ZXZlbC10ZXh0OiIiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDowaW47DQoJdGV4dC1pbmRlbnQ6MGluO30N CkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtdGV4 dDoiIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCXRleHQtaW5kZW50OjBpbjt9DQpAbGlzdCBs Mw0KCXttc28tbGlzdC1pZDozMTM2MTAwNDI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwMDY0 ODM1ODQ7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwz OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlk OjU3MzU4NTY0MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg5MzczODk2O30NCkBsaXN0IGw0 OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IixzZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs NDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDo2MDQxMTkwMTQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi02NDY0MjI0NDI7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNl cmlmOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw1 OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1Omxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGw2DQoJe21zby1saXN0LWlkOjY3NjE1NjEwNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6NjA0NTQ0MTkwO30NCkBsaXN0IGw2OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDY6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNjpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsNjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsNjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNw0KCXttc28t bGlzdC1pZDo2OTkwMTc2Mzc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi03MTk0MTg4NDIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDc6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDc6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsNzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNzpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlm O30NCkBsaXN0IGw3OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDc6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDgNCgl7bXNvLWxpc3QtaWQ6MTAzODg5ODYyMTsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6NDE5NDU4ODYwO30NCkBsaXN0IGw4OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDg6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsODpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsODpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsODpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOQ0KCXttc28t bGlzdC1pZDoxMjYzMTAzMzU2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjM0NDU0MDcyO30N CkBsaXN0IGw5OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsOTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsOTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsOTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTANCgl7bXNvLWxpc3QtaWQ6MTMwODU1 ODc0MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTEwNzA4MzQ5NDt9DQpAbGlzdCBsMTA6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IixzZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMTA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEw OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDEwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExDQoJe21zby1saXN0LWlkOjE0MTI1MDI3MTU7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIxMDc4NTQyNDt9DQpAbGlzdCBsMTE6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDox LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IixzZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMTE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMTpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDExOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEyDQoJe21zby1saXN0LWlkOjE0NjMzMDI4OTA7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi02NzI2MzEyNDY7fQ0KQGxpc3QgbDEyOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIs c2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDEyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMjpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDEyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTI6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxMw0KCXttc28tbGlzdC1pZDoxNTI2Nzk2MjEwOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMTI0NzM5OTY1ODt9DQpAbGlzdCBsMTM6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJp ZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTM6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEzOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMTM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEz OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMzpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE0DQoJe21zby1saXN0LWlkOjE4NTk1MzY2NjI7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi03NDM1NDEwMDY7fQ0KQGxpc3QgbDE0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE0OmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTQ6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUgYmVl biBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgZHJhZnQ6 DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9w c2F3Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZC8iPg0K4oCLaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQ8L2E+ LiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3Mg dGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24g c3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUN CiBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUmbmJzcDs8YSBocmVmPSJodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyIj7igItodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0 aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291 bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21t ZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbQ0KIHRocm91 Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RG9j dW1lbnQ6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IGRyYWZ0LWll dGYtb3BzYXdnLXNlcnZpY2UtbW9kZWwtZXhwbGFpbmVkLTAzLnR4dDxicj4NCjxiPlJldmlld2Vy OjwvYj4gRGF2aWQgU2luaWNyb3BlPGJyPg0KPGI+UmV2aWV3IERhdGU6PC9iPiA0IE9jdCAyMDE3 PGJyPg0KPGI+SUVURiBMQyBFbmQgRGF0ZTo8L2I+IDI3IFNlcCAyMDE3PGJyPg0KPGI+SW50ZW5k ZWQgU3RhdHVzOjwvYj4gSW5mb3JtYXRpb25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TdW1tYXJ5 Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou MjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoaXMgZG9jdW1lbnQgaXMgYmFz aWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBuaXRzIGFuZCBzb21lIG1pbm9y IGlzc3VlcyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5Db21tZW50czo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGZv dW5kIHRoZSBkb2N1bWVudCBoZWxwZnVsIGFuZCBhIGdvb2QgYWlkIHRvIHRob3NlIHRyeWluZyB0 byBnZXQgYSBncmlwIG9uIHRoZSB2YXJpZXR5IG9mIG1vZGVsaW5nIGFjdGl2aXRpZXMgaW4gdGhl IElFVEYuJm5ic3A7IFRoZSBuaXRzIGFuZCBtaW5vciBjb21tZW50cyBiZWxvdyBhcmUgb2ZmZXJl ZCBpbiBhbiBhdHRlbXB0DQogdG8gaW1wcm92ZSBjbGFyaXR5IGFuZCBxdWFsaXR5IG9mIHRoZSBk b2N1bWVudC4mbmJzcDsgTm9uZSBvZiB0aGVzZSBjb21tZW50cyBhcmUgb2YgaGlnaCBlbm91Z2gg cHJpb3JpdHkgdG8gYmxvY2sgcHVibGljYXRpb24gb2YgdGhlIGRvY3VtZW50IHNob3VsZCB0aGV5 IHJlbWFpbiB1bnJlc29sdmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1pbm9yIElzc3VlcyBhbmQgTml0 czo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+QWJzdHJhY3Q6ICZxdW90Oy4uLiB1c2VkIHdpdGhpbiB0aGUgSUVURi4u LiZxdW90Oy4gV291bGRuJ3QgdGhlIGRvY3VtZW50IHNlcnZlIGJldHRlciB0byBkZXNjcmliZSBo b3cgdGhlIG1vZGVscyBjb3VsZC9hcmUgdXNlZCBieSB0aGUgaW5kdXN0cnkgaW5jbHVkaW5nIHdp dGhpbiBTRE4/DQogU2V2ZXJhbCBvZiB0aGVzZSBtb2RlbHMgYXJlIHVzZWQgYnkgb3RoZXIgU0RP cyBmb3IgdGhlaXIgd29yayBpbiBlLmcuLCBwcm92aWRpbmcgbmV0d29yayBhcmNoaXRlY3R1cmUs IGVxdWlwbWVudCByZXF1aXJlbWVudHMsIG9yY2hlc3RyYXRpb24sIE9BTSBhbmQgbWFuYWdlbWVu dCB0byBzdXBwb3J0IGFuZCBwcm92aWRlIHRoZSBzZXJ2aWNlLiBJIHdvdWxkIHRoaW5rIHRoYXQg dGhlIG1hdHRlciBvZiBob3cgdGhlc2UgYXJlIHVzZWQgYnkgdGhlDQogSUVURiB3b3VsZCBiZSBt dWNoIHRvIG5hcnJvdyBhIHZpZXcuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbnRybyBwYXJhIDMsIGxhc3Qgc2VudGVu Y2VzIC0gVGhpcyB0ZXh0IGRhdGVzIGl0c2VsZi4gSXQgd291bGQgc3VmZmljZSB0byBub3RlIHRo YXQgdGhlIG1vZGVscyBtYXkgYmUgdXNlZCBpbiB0aGVzZSBlbnZpcm9ubWVudHMgcmVnYXJkbGVz cyBvZiB0aGUgdGltZSBmcmFtZS4NCiAoZS5nLiwgZHJvcCDigJxldmVudHVhbGx5KTxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+SW50cm8gcGFyYSA1IGxhc3Qgc2VudGVuY2UgLSBjdXN0b21lciAtIFByb3ZpZGVyIEludGVy ZmFjZSBuZWVkcyBhIGZvcndhcmQgcmVmZXJlbmNlIG9yIGJyaWVmIGRlZmluaXRpb24uDQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWlu Y2hvJnF1b3Q7LHNlcmlmIj7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+SW50cm8gcGFyYSA2LiAtICZxdW90O2Rlc2NyaWJlZCB0byZxdW90OyBvciAm cXVvdDtzdWJzY3JpYmVkIHRvJnF1b3Q7Pw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyxzZXJpZiI+4oCoPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkludHJvIHBhcmEgNiAt IGRvZXMgaXQgZGVzY3JpYmUgdGhlIHNlcnZpY2Ugb3IgdGhlIGF0dHJpYnV0ZXMgb2YgdGhlIHNl cnZpY2UuIEknbSBub3Qgc3VyZSBhIHNlcnZpY2UgbW9kZWwgZGVzY3JpYmVzIHRoZSBzZXJ2aWNl IG9wZXJhdGlvbi4gJm5ic3A7QWRkIHRoZSB3b3Jkcw0KICZxdW90O2F0dHJpYnV0ZXMgb2YgdGhl JnF1b3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtNUyBNaW5jaG8mcXVvdDssc2VyaWYiPuKAqDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWMgMSwgcGFyYSA0IC0g4oCcLi4uIHdpdGhpbiB0aGUg SUVURi4uLuKAnSBidXQgdGhlIGRvY3VtZW50IGFsc28gZGlzY3Vzc2VzIHRoZSBNRUYuIE5lZWQg dG8gbWFrZSBzdGF0ZW1lbnQgbW9yZSBnZW5lcmFsLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyxzZXJpZiI+4oCo PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjwvdWw+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVs MSBsZm8xMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlZmluaXRpb24gb2YgTmV0 d29yayBPcGVyYXRvciAtIGNoYW5nZSB0byByZWFkICZxdW90Oy4uLiBvdGhlciBuZXR3b3JrIHNl cnZpY2VzLiZxdW90OyBOb3Qgc3VyZSBvdGhlciBub24tbmV0d29yayBzZXJ2aWNlcyBhcmUgaW50 ZW5kZWQuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TVMgTWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEzIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGVmaW5pdGlvbiBvZiBDdXN0b21lcjogc3VnZ2VzdCBj aGFuZ2Ug4oCccHVyY2hhc2Vz4oCdIHRvIOKAnHN1YnNjcmliZXPigJ0NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDss c2VyaWYiPuKAqDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286 cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMTMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5EZWZpbml0aW9uIG9mIEN1c3RvbWVyOiBFeGNsdWRlcyByZXNpZGVudGlhbCBjdXN0b21lci4u LiB3aHk/DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TVMgTWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEzIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGVmaW5pdGlvbiBvZiBTZXJ2aWNlOiAtIFdvdWxkIGhl bHAgdG8gZ2l2ZSB0aXRsZXMgb2YgUkZDcywgYnV0IG1heSBub3QgYmUgYWxpZ25lZCB3aXRoIGNv bnZlbnRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjx1bCBzdHlsZT0ibWFyZ2lu LXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+RGVmaW5pdGlvbiBvZiBEYXRhIE1vZGVsOiBSZWZlcnMgdG8gaW5mb3JtYXRp b24gbW9kZWwgYW5kIHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBtYW5hZ2VkIG9iamVjdHMuJm5ic3A7 IFNob3VsZCBpdCBiZSBqdXN0IG9iamVjdHM/DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzE0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGVmaW5pdGlvbiBv ZiBTZXJ2aWNlIG1vZGVsIC0gaW4gSUVURiBpdCdzIGEgZGF0YSBtb2RlbC4gSW4gb3RoZXIgZ3Jv dXBzPyBFLmcuLCBJVFU/IEl0IGNvdWxkIGJlIGFuIGluZm9ybWF0aW9uIG1vZGVsLjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8m cXVvdDssc2VyaWYiPuKAqDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMTQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5EZWZpbml0aW9uIG9mIEN1c3RvbWVyIFNlcnZpY2UgTW9kZWw6IE5vdCBzdXJlIGV4 YW1wbGUgb2Ygb3JkZXIgZnVsZmlsbG1lbnQgc3lzdGVtIGlsbHVzdHJhdGVzIGEgaHVtYW4uJm5i c3A7IElzIHRoZXJlIGEgYmV0dGVyIGV4YW1wbGUgb2YgYSBodW1hbiBjb25zdW1lcj88bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkRlZmluaXRpb24gb2YgU2VydmljZSBtb2RlbCAtICZxdW90Oy4uLiBhIHBvcnRhYmxlIHdh eSZxdW90Oy4gUG9ydGFibGUgd2F5PyBvciBkbyB5b3UgbWVhbiBtb3JlIGFnbm9zdGljIHRvIGRl cGxveW1lbnQgYXJjaGl0ZWN0dXJlIGFuZCBlcXVpcG1lbnQ/DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7LHNlcmlm Ij7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzE0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TGFz dCBwYXJhIGp1c3QgYmVmb3JlIHNlY3Rpb24gMy4gLSB3aGlsZSBhIHNlcnZpY2UgbW9kZWwgYXMg YSB3aG9sZSBtYXkgbm90IGJlIGludGVuZGVkIHRvIGJlIHNlbnQgdG8gbmV0d29yayBkZXZpY2Vz LCBwYXJ0cyBvZiBpdCBtYXkgYmUgc2VudCB0byBuZXR3b3JrIGVxdWlwbWVudC4NCiBUaGlzIGNv dWxkIGJlIGNsYXJpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xNCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlYyAzLCAybmQgcGFyYSAtIOKAnC4uLiBjaG9p Y2UgZm9yIHdob2V2ZXIgc3BlY2lmaWVzIHRoZSBtb2RlbC7igJ0gQW5kIHRoZSBuZXh0IHNlbnRl bmNlIG5vdGVzIHRoZSBJRVRGLiBJcyB0aGUgY2hvaWNlIHRoYXQgb2YgdGhlIG9yZ2FuaXphdGlv biB3aGVyZSB0aGUgbW9kZWwNCiBpcyBzcGVjaWZpZWQsIHRoZSBpbmRpdmlkdWFscyBzcGVjaWZ5 aW5nIHRoZSBtb2RlbCBvciBzb21lIGNvbWJpbmF0aW9uIG9mIGJvdGg/IDwvc3Bhbj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90 OyxzZXJpZiI+4oCoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPlNlYyAzLCBwYXJhIDEmYW1wOzIgLSB0aGVzZSB0d28gcGFyYWdyYXBocyBkb27igJl0IGFk ZCB0byB0aGUgZGlzY3Vzc2lvbiBhbmQgZGlzdHJhY3QgZnJvbSBwYXJhIDMgd2hlcmUgdGhlDQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg TWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPmFjdHVhbCBkaXNjdXNzaW9uIHN0YXJ0cy4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDssc2VyaWYiPuKAqDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MiBsZXZlbDEgbGZvMTQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWMgMywgcGFy YSAzLCBsYXN0IHNlbnRlbmNlIC0g4oCcLi4uIGRpcmVjdCBodW1hbiBpbnRlcmFjdGlvbi4uLuKA nS4gVGhpcyBjcm9zc2VzIGZyb20gaW1wbGVtZW50YXRpb24gdG8gYnVzaW5lc3MgcHJvY2VzcyBh bmQgc2hvdWxkIGJlIG5vdGVkLiBBZGQgYSBzZW50ZW5jZQ0KIHRvIHRoZSBlZmZlY3Qgb2Yg4oCc V2hlcmUgZGlyZWN0IGh1bWFuIGludGVyYWN0aW9uIGNvbWVzIGludG8gcGxheSwgaW50ZXJmYWNl IGludGVyYWN0aW9ucyBtYXkgYmVjb21lIHJlYWxpemVkIHZpYSBidXNpbmVzcyBwcmFjdGljZXMg YW5kIG11c3QgYWNjb3VudCBmb3Igc29tZSBtYXJnaW4gb2YgZXJyb3IsIHRodXMgcmFpc2luZyB0 aGUgcHJpb3JpdHkgZm9yIGF1dG9tYXRlZCwgZGV0ZXJtaW5pc3RpYyBpbnRlcmZhY2VzLuKAnQ0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01T IE1pbmNobyZxdW90OyxzZXJpZiI+4oCoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xNCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkZpZ3VyZSAxIC1tb3ZlIGZpZ3VyZSB0byB0aGUgZGVmaW5pdGlvbiBv ZiBjdXN0b21lciBzZXJ2aWNlIG1vZGVsDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzE0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VjIDMsIHBhcmEgOCwg bGFzdCBzZW50ZW5jZSAtIGRpc3RpbmN0aW9uIG9mIG1vZHVsZXMgYW5kIG1vZGVscy4gR29vZCBk ZXNjcmlwdGlvbiBvZiBtb2R1bGVzLCBidXQgbmVlZHMgdG8gYmUgY29udHJhc3RlZCB2cyBtb2Rl bHMuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TVMgTWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+U2VjIDMsIHBhcmEgNyDigJPigJwgVGhlIHByYWN0aWNhbGl0 eeKApuKAnSZuYnNwOyB0aGVzZSBsYXN0IHR3byBwYXJhZ3JhcGhzIGhpZ2hsaWdodCBhIGRlYmF0 ZSBhbmQgdGhlIGRpZmZlcmVudCBwb2ludHMgb2Ygdmlldy4gVGhpcyBpcyBkaWZmZXJlbnQgZnJv bSB0aGUg4oCcYmlnIHBpY3R1cmXigJ0NCiB1c2FnZSBkZXNjcmlwdGlvbiBpbiB0aGUgcGFyYWdy YXBocyBhYm92ZS4gU3Vic2VjdGlvbnMgKGUuZy4sIOKAnFRoZSBCaWcgUGljdHVyZeKAnSBhbmQg 4oCcUHJhY3RpY2FsbHkgU3BlYWtpbmfigJ0pIHdvdWxkIGhlbHAgY2FsbCBvdXQgdGhlIHRyYW5z aXRpb24gaW4gdGhpbmtpbmcgJmFtcDsgZmxvdy4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDssc2VyaWYiPuKAqDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MiBsZXZlbDEgbGZvMTQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWMgNCwgaGVh ZGluZyBvciBwYXJhIDEsIDFzdCBzZW50ZW5jZSAtIOKAnFNETuKAnSBoYXMgYmVlbiBzcGVsbGVk IG91dCBwcmV2aW91c2x5IGluIHRoZSBpbnRyb2R1Y3Rpb24gYnV0IGdpdmVuIHRoZSBlbGVtZW50 YXJ5IGxldmVsIG9mIGV4cGxhbmF0aW9uIGhlcmUsIGUuZy4sDQog4oCcY29udHJvbGxlcuKAnSwg aXQgbWF5IGJlIHdvcnRoIHNwZWxsaW5nIGl0IG91dCBhZ2Fpbi4gPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyxzZXJp ZiI+4oCoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwyIGxldmVsMSBsZm8xNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNl YyA0LCBwYXJhIDIsIDFzdCBzZW50ZW5jZSAtIHJlbW92ZSB0aGUg4oCcQnV04oCdIG9yIGNsYXJp Znkgd2hhdCB0aGUgc3RhdGVtZW50IGlzIGNvbnRyYWRpY3Rpbmcgb3IganV4dGFwb3NpbmcuDQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg TWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+U2VjIDQsIHBhcmEgMiwgMm5kIHNlbnRlbmNlIOKAnCBUaGF0IGlzLOKA puKAnSAtIFRoaXMgc3RhdGVtZW50IHNob3VsZCBiZSBjbGFyaWZpZWQuIEluaGVyZW50bHkgdGhl IHRlY2hub2xvZ3kgYXZhaWxhYmxlIHRvIGRlbGl2ZXIgYSBzZXJ2aWNlIHdpbGwgaW5mbHVlbmNl IHRoZQ0KIGZ1bmN0aW9ucyB0aGF0IGEgY3VzdG9tZXIgY2FuIHJlcXVlc3QuIEUuZy4sIGFuIEV0 aGVybmV0IGNvbm5lY3Rpdml0eSBzZXJ2aWNlIHdpbGwgYmUgZGVmaW5lZCBpbiB0ZXJtcyBvZiBN QUMgYWRkcmVzc2VzLGV0Yy4gSSB0aGluayB0aGUgcG9pbnQgdHJ5aW5nIHRvIGJlIG1hZGUgaGVy ZSBpcyB0aGF0IHRoZSB1bmRlcmx5aW5nIHRlY2hub2xvZ3kgc3BlY2lmaWMgZGV0YWlscyBzaG91 bGQgbm90LCBvciB0byB0aGUgbG93ZXN0IGV4dGVudCBwb3NzaWJsZSwNCiBiZSByZWZsZWN0ZWQg aW4gY3VzdG9tZXIgc2VydmljZSByZXF1ZXN0cy4gRS5nLiwgb25lIHNob3VsZCBub3QgaGF2ZSB0 byBzcGVjaWZ5IHN3aXRjaCBvciByb3V0ZXIgaWRzLCBJUCBhZGRyZXNzZXMgb3IgTUFDIGFkZHJl c3NlcyBmb3IgYSBUViBzZXJ2aWNlLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyxzZXJpZiI+4oCoPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWUgc2VjdGlvbiA3IG9mIHRoZSBkb2N1bWVu dA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O01TIE1pbmNobyZxdW90OyxzZXJpZiI+4oCoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xNCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlNlYyA0LCBwYXJhIDIgJmFtcDsgMyAtIHdvdWxkbuKAmXQgdGhp cyBwb2ludCBhYm91dCBhIFNlcnZpY2UvTmV0d29yayBzcGxpdCBiZSB0cnVlIG91dHNpZGUgb2Yg dGhlIFNETiBjb250ZXh0IGFzIHdlbGw/IFdoeSB3b3VsZCB0aGlzIGJlIGxpbWl0ZWQgdG8gU0RO Pw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O01TIE1pbmNobyZxdW90OyxzZXJpZiI+4oCoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xNCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPlNlYyA0LCBGaWd1cmUgMyAtIGNvdWxkIHRoZSBmaWd1cmUgc2hv dyBhbiBvcmNoZXN0cmF0b3IgaW50ZXJhY3RpbmcgZGlyZWN0bHkgdG8gYSBuZXR3b3JrIGVsZW1l bnQ/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xNCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPlNlYyA1LCBidWxsZXQgMSAtIEluIHRoZSB0ZXJtaW5vbG9neSBzZWN0 aW9uLCDigJxTZXJ2aWNl4oCdIGlzIGRlZmluZWQgYXMgYSBjb25uZWN0aXZpdHkgc2VydmljZS4g Rm9yIHB1cnBvc2VzIG9mIHRoaXMgZG9jdW1lbnQgdGhlbiBpdCBzaG91bGQgbm90IGJlIGNvbmZ1 c2VkDQogd2l0aCBoaWdoZXIgbGF5ZXIgc2VydmljZXMuIFRoZSDigJxjdXN0b21lcuKAnSBmb3Ig dGhpcyBkZWZpbml0aW9uICppcyogYXdhcmUgb2YgdGVjaG5vbG9neSBzcGVjaWZpYyBwYXJhbWV0 ZXJzIGFuZCBjb25zdHJhaW50cyBvZiB0aGUgY29ubmVjdGl2aXR5IHNlcnZpY2UgdGhleSBhcmUg c3Vic2NyaWJpbmcgdG8uIFRoZSBjYXVzZSBvZiB0aGUgY29uZnVzaW9uLCBhbmQgdGhpcyBpcyBh biBhZ2Ugb2xkIHByb2JsZW0sIGlzIHRoYXQg4oCcc2VydmljZeKAnSBpcw0KIGEgcmVjdXJzaXZl IHRlcm0uIFRoYXQgaXMsIGEgY29uc3VtZXIvY2xpZW50IG9mIG9uZSBsZXZlbCBvZiBzZXJ2aWNl IChlLmcuLCBFdGhlcm5ldCBjb25uZWN0aXZpdHkpIGlzIHRoZSBwcm92aWRlci9zZXJ2ZXIgb2Yg YW5vdGhlciAoZS5nLiwgSW50ZXJuZXQgYWNjZXNzKSBmb3IgaGlnaGVyIGxheWVyIHVzZSAoZS5n LiwgVFYgc2VydmljZSkNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDssc2VyaWYiPuKAqDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+TW9kZWxpbmcgbWV0aG9kcyAoRy44MDUpIGhhdmUgYmVlbiBl c3RhYmxpc2hlZCB0byBkZXNjcmliZSB0aGUgY2xpZW50L3NlcnZlciByZWxhdGlvbnNoaXAuDQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg TWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+U2VjIDUsIGJ1bGxldCAyIC0g4oCcY29tcGxldGVseeKAnSAtJmd0OyBt aWdodCB3YW50IHRvIHRvbmUgdGhpcyBkb3duIGEgYml0LCB0byBhY2NvbW1vZGF0ZSBleGNlcHRp b25zIG5vdGVkIGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQuIFdoaWxlIGtlcHQgdG8gYSBtaW5p bXVtLCBuZXR3b3JrDQogb3BlcmF0aW9uIGlzIG5vdCAqY29tcGxldGVseSogb3V0IG9mIHNjb3Bl IHdoZW4gZGlzY3Vzc2luZyBzZXJ2aWNlIGJldHdlZW4gYSBjdXN0b21lciBhbmQgbmV0d29yayBv cGVyYXRvci4gRS5nLiwgUGFydCBvZiBhIHNlcnZpY2UgY291bGQgYmUgcm91dGluZyBvZiB0aGUg Y29ubmVjdCB0byBhdm9pZCBnZW9wb2xpdGljYWwgYm9yZGVycy4gKE5vdGVkIG9uIHRoZSB2ZXJ5 IG5leHQgcGFnZSkgYW5vdGhlciBleGFtcGxlIGlzLCBGYXVsdCBub3RpZmljYXRpb24NCiBhbmQg cHJvdGVjdGlvbiBtZWNoYW5pc21zIG1heSBiZSBkaXNjdXNzZWQuIDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDssc2Vy aWYiPuKAqDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIHN0YXRlbWVu dCBoZXJlIHNlZW1zIHRvIGNvbnRyYWRpY3QgdGhlIGRlZmluaXRpb24gb2YgQ3VzdG9tZXIgU2Vy dmljZSBNb2RlbCBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbg0KIHdoZXJlIGl0IHN0YXRlcyB0 aGF0IOKAnEV4Y2VwdCB3aGVyZSBzcGVjaWZpYyB0ZWNobm9sb2d5IGRldGFpbHMgKHN1Y2ggYXMg ZW5jYXBzdWxhdGlvbnMsIG9yIG1lY2hhbmlzbXMgYXBwbGllZCBvbiBhY2Nlc3MgbGlua3MpIGFy ZSBkaXJlY3RseSBwZXJ0aW5lbnQgdG8gdGhlIGN1c3RvbWVyLCBjdXN0b21lciBzZXJ2aWNlIG1v ZGVscyBhcmUgdGVjaG5vbG9neSBhZ25vc3RpYyBzbyB0aGF0IHRoZSBjdXN0b21lciBkb2VzIG5v dCBoYXZlIGluZmx1ZW5jZQ0KIG92ZXIgb3Iga25vd2xlZGdlIG9mIGhvdyB0aGUgbmV0d29yayBv cGVyYXRvciBlbmdpbmVlcnMgdGhlIHNlcnZpY2Uu4oCdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDssc2VyaWYiPuKA qDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGVyaGFwcyB1c2Ug4oCcbm9y bWFsbHnigJ0gdnMg4oCcY29tcGxldGVseeKAnQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyxzZXJpZiI+4oCoPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omwy IGxldmVsMSBsZm8xNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlYyA1LCBidWxs ZXQgMiAtIHByb3ZpZGluZyBkZXRhaWwgYWJvdXQgaG93IHRoZSBzZXJ2aWNlIGlzIG9mZmVyZWQg Y291bGQgYWN0dWFsbHkgYmUgY29uc2lkZXJlZCBhIHNlY3VyaXR5DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7LHNl cmlmIj7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPnZ1bG5lcmFiaWxp dHkuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TVMgTWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzE0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+U2VjIDUsIGJ1bGxldCA0IC0gZ2l2ZSBzb21lIGV4YW1wbGVz IG9mIOKAnGNvbW1lcmNpYWwgdGVybXPigJ0uDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7LHNlcmlmIj7igKg8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzE0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VjIDUsIGJ1bGxl dCA1IC0gZ2l2ZSBhbiBleGFtcGxlIG9mIHRoZSDigJxmaW5lIGdyYWluZWQgZGV0YWlsczwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBNaW5j aG8mcXVvdDssc2VyaWYiPuKAnTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMTQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5TZWMgNi4yIGxpc3Qgb2YgZHJhZnRzIC0gd2lsbCB0aGVzZSB3b3JrcyBpbiBw cm9ncmVzcyBiZSBzdGFibGUgb3IgZmluYWwgYmVmb3JlIHB1YmxpY2F0aW9uPw0KPG86cD48L286 cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMTQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5TZWMgNi40LCBwYXJhIDIsM3JkIHNlbnRlbmNlIC0gdGhlIHN0YXRlbWVudCBvbiBpdCBiZWlu ZyBpbXByYWN0aWNhbCB0byBmaXQgSUVURiBtb2RlbHMgaW50byBNRUYgbW9kZWxzIHNlZW1zIGEg Yml0IGJyb2FkLiBIYXMgYW55b25lIGxvb2tlZCBpbnRvIHRoaXM/DQo8bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5SZWxldmFudCBEaXJlY3RvcmF0ZSBSZXZpZXcgR3VpZGFuY2U8bzpwPjwvbzpwPjwvc3Bh bj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPk1pbm9yIElzc3VlcyBhbmQgTml0czo8L3NwYW4+PC9pPjwvYj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjx1 bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzEwIj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TWlub3IgaXNzdWVzIGFyZSBjb25jZXJucyBh Ym91dCBjbGFyaXR5IG9yIHRlY2huaWNhbCBhY2N1cmFjeSB0aGF0IHNob3VsZCBiZSBkaXNjdXNz ZWQgYW5kIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbiwgYnV0IHdoaWNoIHdvdWxkIG5vcm1h bGx5IGJlIHJlc29sdmVkDQogYmV0d2VlbiB0aGUgYXV0aG9ycyBhbmQgdGhlIHJldmlld2Vycy48 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvMTAiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5QbGVhc2UgaW5jbHVkZSBhbGwgb2YgdGhlIG1pbm9yIGlzc3VlcyB5 b3UgaGF2ZSBmb3VuZC4gR2l2ZSBhcyBtdWNoIGNvbnRleHQgaW5mb3JtYXRpb24gYXMgcG9zc2li bGUgKGUuZy4sIHNlY3Rpb24gbnVtYmVycywgcGFyYWdyYXBoIGNvdW50cykuPG86cD48L286cD48 L3NwYW4+PC9pPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzEwIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+SWYgeW91IGZpbmQgbm8gbWlub3IgaXNzdWVzLCBwbGVhc2Ugd3JpdGU6ICZxdW90O05v IG1pbm9yIGlzc3VlcyBmb3VuZC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9saT48L3Vs Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvMTEi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5OaXRzIGFyZSBlZGl0b3JpYWwgb3Ig bGF5b3V0IGl0ZW1zLiBUaGV5IGFyZSB0aGluZ3MgdGhhdCB3b3VsZCBpZGVhbGx5IGJlIHJlc29s dmVkIGJlZm9yZSBwdWJsaWNhdGlvbiB0byBtYWtlIHRoZSBkb2N1bWVudCBtb3JlIHJlYWRhYmxl LCBhbmQgbWF5IGJlIHJhaXNlZA0KIG5vdyB0byBzYXZlIHRoZSBSRkMgRWRpdG9yIHdvcmsuPG86 cD48L286cD48L3NwYW4+PC9pPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_34AB742F02434CF58151281BCA3BB7CFericssoncom_-- From nobody Sat Oct 7 04:56:31 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 6599D1332CE; Sat, 7 Oct 2017 04:56:30 -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.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150737739036.11112.718690273314652329@ietfa.amsl.com> Date: Sat, 07 Oct 2017 04:56:30 -0700 Archived-At: Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-12.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 11:56:30 -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-12.txt Pages : 55 Date : 2017-10-07 Abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects. This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix specification, an X.509 certificate extension and a means to sign and verify the descriptions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-mud-12 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 7 04:59: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 177D0134697 for ; Sat, 7 Oct 2017 04:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.48 X-Spam-Level: X-Spam-Status: No, score=-13.48 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 pC9lZkPLO3vC for ; Sat, 7 Oct 2017 04:59:02 -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 C2CB91332CE for ; Sat, 7 Oct 2017 04:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4161; q=dns/txt; s=iport; t=1507377542; x=1508587142; h=subject:cc:references:from:message-id:date:mime-version: in-reply-to; bh=C5edCHIRHihVTpv9Bo4Rv+VoT9kBVtMCjz0Ro/+QnEo=; b=JqH32KqiQssZSK23kwByXRz8mp5tkSbmHe1JUmHJQOKM/rZgFOgrJYKP CCuQQpeiWBHTAets1XFdvZnnrZlSkWfp4mTQnmsg6hBhQOjGbslAIp43c cEZRJDbA5ZiJl8MuN1a3j85qlRROq6iuroHHFIoxqhzUqw7jYUtya2Iuq E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAAA0wNhZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEFuGA+DeoofdJBOIpYvghIHAxgLhElPAiaEORgBAgEBAQEBAQF?= =?us-ascii?q?rKIUQCQEBAQMBASEERwsQCQISBioCAiciDhMGAgEBhW6EPhCIJJ1ngW06izMBA?= =?us-ascii?q?QEBAQUBAQEBARQPgy2FaAuCc4MygTyDKROCTgWKHpcVhDyCIYEBjQeCFFuFFIN?= =?us-ascii?q?ahy2VWYE5HziBDjIhCB0VHyp2D4YaPjaJPQEBBQ?= X-IronPort-AV: E=Sophos;i="5.42,489,1500940800"; d="asc'?scan'208";a="655298273" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Oct 2017 11:58:59 +0000 Received: from [10.61.106.132] (dhcp-10-61-106-132.cisco.com [10.61.106.132]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v97BwxTX025550 for ; Sat, 7 Oct 2017 11:58:59 GMT Cc: opsawg@ietf.org References: <150737739036.11112.718690273314652329@ietfa.amsl.com> From: Eliot Lear Message-ID: <9bad5899-c16b-04bc-2287-50f90d0c3b07@cisco.com> Date: Sat, 7 Oct 2017 13:58:59 +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: <150737739036.11112.718690273314652329@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7I86Xpp3DogNUdQ8e6rmHsfh1JgaHhAXH" Archived-At: Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-12.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: Sat, 07 Oct 2017 11:59:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7I86Xpp3DogNUdQ8e6rmHsfh1JgaHhAXH Content-Type: multipart/mixed; boundary="bxT3PkKaciVSOkJ4DPVTded7TH3s3wSkR"; protected-headers="v1" From: Eliot Lear Cc: opsawg@ietf.org Message-ID: <9bad5899-c16b-04bc-2287-50f90d0c3b07@cisco.com> Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-12.txt References: <150737739036.11112.718690273314652329@ietfa.amsl.com> In-Reply-To: <150737739036.11112.718690273314652329@ietfa.amsl.com> --bxT3PkKaciVSOkJ4DPVTded7TH3s3wSkR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US This version is intended to address all outstanding issues based on last call.=C2=A0 That includes the following: =C2=A0=C2=A0 o=C2=A0 Correct examples based on ACL model changes. =C2=A0=C2=A0 o=C2=A0 Change ordering nodes. =C2=A0=C2=A0 o=C2=A0 Additional explanatory text around systeminfo. =C2=A0=C2=A0 o=C2=A0 Change ordering in examples. =C2=A0=C2=A0 o=C2=A0 Make it VERY VERY VERY VERY clear that these are rec= ommendations, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 not mandates. =C2=A0=C2=A0 o=C2=A0 DHCP -> NTP in some of the intro text. =C2=A0=C2=A0 o=C2=A0 Remove masa-server =C2=A0=C2=A0 o=C2=A0 "Things" to "network elements" in a few key places. =C2=A0=C2=A0 o=C2=A0 Reference to JSON YANG RFC added. Eliot On 10/7/17 1:56 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-12.txt > Pages : 55 > Date : 2017-10-07 > > Abstract: > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for= > Things to signal to the network what sort of access and network > functionality they require to properly function. The initial focus > is on access control. Later work can delve into other aspects. > > This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an= > LLDP TLV, a URL suffix specification, an X.509 certificate extension= > and a means to sign and verify the descriptions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-12 > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-12 > > > 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 > --bxT3PkKaciVSOkJ4DPVTded7TH3s3wSkR-- --7I86Xpp3DogNUdQ8e6rmHsfh1JgaHhAXH 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 iQEcBAEBCAAGBQJZ2MGDAAoJEIe2a0bZ0nozX+AH/RTf4RXDp5BY4hDLADDt5NYA D1eOwvGVKRIWTG1+7KDcyM7/HJIeirIhhVoJi3nNRQRN+WCNLYJJX09qV5zH837A gMA2QbxG2Zm4ChVCMctku1T4fdFURM25yfCJuCQDFyWH0u4qvtPObVfrvlYXZ2sd AtHgb2vzjGTM2s8tKSyFr9Fd3Ze76UuV9zWy2gcamPGHJt/+0W7oK3VSTErTyHw0 UpgGVjynHSyxlz5llDt2q48y0TwnsJ4FkdiDZQs8sgyo77pMGydgqGPvyU3okVu5 6ABe2xgVXV5mkMdBEteO9NAE0UhNxfmZX6qw+2/TU4g4M8z1etRDa/8z/IbXdCA= =x0yV -----END PGP SIGNATURE----- --7I86Xpp3DogNUdQ8e6rmHsfh1JgaHhAXH-- From nobody Sat Oct 7 08:31: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 6498D13492C for ; Sat, 7 Oct 2017 08:31:28 -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 12ZcG5cg6OLh for ; Sat, 7 Oct 2017 08:31:26 -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 6603413490F for ; Sat, 7 Oct 2017 08:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17359; q=dns/txt; s=iport; t=1507390285; x=1508599885; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Jw29bhEsAypwOzldGhO0QTmFa4FSE1HrxyM5+XltZs8=; b=SLisRvQwOTWMRT5dqDWlhTpghY2I0M1BMlFupbsqfo8u5XlkJBFZQt42 hiJDzqcfyjwbw3UISM6nMcrovQl6EzGGCA1i0ywSiXoSVz4o51GdqNI9q 6Gi3wXWoWbXAgF4Y2s75c2Q8tg8haTm7Zsnm09g9s4FS8m+YwTaEhYhR0 o=; X-Files: signature.asc : 481 X-IronPort-AV: E=Sophos;i="5.42,489,1500940800"; d="asc'?scan'208,217";a="655302229" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Oct 2017 15:31:23 +0000 Received: from [10.61.106.132] (dhcp-10-61-106-132.cisco.com [10.61.106.132]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v97FVNgV027429; Sat, 7 Oct 2017 15:31:23 GMT To: "M. Ranganathan" , Steven Rich Cc: opsawg@ietf.org References: <7B1589B4-15E4-4793-8A28-965021EBE6CB@cisco.com> From: Eliot Lear Message-ID: <500d4240-6a3e-eb97-8e44-4a4c26335669@cisco.com> Date: Sat, 7 Oct 2017 17:31:23 +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="a5Lc1sfPW4rpncwuo66g4cV3WMAGONIbV" Archived-At: Subject: Re: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:31:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a5Lc1sfPW4rpncwuo66g4cV3WMAGONIbV Content-Type: multipart/mixed; boundary="wGLwLNeSHIhJnAFMnGBVXFCQKnjRbrRku"; protected-headers="v1" From: Eliot Lear To: "M. Ranganathan" , Steven Rich Cc: opsawg@ietf.org Message-ID: <500d4240-6a3e-eb97-8e44-4a4c26335669@cisco.com> Subject: Re: [OPSAWG] MUD : Default ACLs for DHCP . Time and DNS. References: <7B1589B4-15E4-4793-8A28-965021EBE6CB@cisco.com> In-Reply-To: --wGLwLNeSHIhJnAFMnGBVXFCQKnjRbrRku Content-Type: multipart/alternative; boundary="------------B533455BC6BBCE1001C72E68" Content-Language: en-US This is a multi-part message in MIME format. --------------B533455BC6BBCE1001C72E68 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ranga, I apologize- I thought I had answered this note.=C2=A0 I'm going to top p= ost because the theme of your note is pretty consistent: it essentially asks, what happens if we want to decompose the MUD controller into two?=C2= =A0 I don't see anything particularly wrong with the idea, but that's not where we are today.=C2=A0 There may be many ways one wishes to decompose = a MUD controller, that being one of them.=C2=A0 I think that's fine follow-= on work as well.=C2=A0 We're leaving plenty of meat on the bone. Eliot On 10/4/17 5:58 PM, M. Ranganathan wrote: > Hello, > > Architecturally, there are four functional blocks: > > MUD file server : Serves MUD files. This is an optional component. MUD > files could be directly bundled with the device itself if is-supported > flag is False > > MUD Controller: Transmits the mud file and auxiliary information (such > as the local address of the default network services) to the MUD > policy server. Manages the cache (retrieves policy files from the MUD > file server periodically and supplies them to the MUD policy server). > For example, this functionality may be implemented in an enhanced DHCP > server or as a cloud resident caching service. > > MUD policy server: Resolves MUD ACLs and installs them on switch (e.g. > as a set of Flow rules). The MUD policy server could be a NETCONF or > SDN controller managing multiple switches. > > ACL / SDN capable switch. > > > If my terminology is wrong, please correct. > > > Looking through section 3 (comments in line) > > The MUD Policy Server may support caching retrieved MUD files. If > it does, then the operator may choose to enable, tune, test, and > monitor this functionality as well. Details about caching MUD > files as well as each task above will be covered later in this > document. > > Does the MUD policy server need to do this? If "is-supported" is True t= hen the MUD Controller may do cache management as well (?).=20 > The goal of MUD is to enable the near-automatic management of > device segmentation for the class of devices which have MUD > support.=20 > > That is, we want to automatically map devices with different sensitivit= ies to different network segments. That is not necessarily the only goal.= One could=20 > limit the behavior of specific devices without introducing the notion o= f network segments. > 1. Able to "see" a MUD URI > > 2. Able to retrieve a MUD file > > 3. Able to map a specific device (for example via a MAC id) to a MUD fi= le that has been retrieved from the cloud. > > Does section 3.4 (Testing) belong in section 3?=20 > Cache management could be important because a manufacturer could update= the MUD file. So at least when a device boots, if is-supported is True t= hen=20 > a new copy of the file should be retrieved.=20 > Good work on the draft! > > Regards, > > Ranga.=C2=A0 (Affiliation: NIST / Advanced Networking Technologies Divi= sion) > > > On Tue, Oct 3, 2017 at 12:52 PM, Steven Rich > wrote: > > >> On Oct 3, 2017, at 12:40 , M. Ranganathan > > wrote: >> >> MUD suggests that devices should always have access to DHCP and >> DNS. However, I don't know how to communicate this information to >> the MUD controller so that appropriate ACLs can be installed when >> a device comes up. A logical place to put this would be in the >> request sent out by the DHCP server to the MUD controller when it >> gets the OPTIONS 161 from the device. Would this be the way this >> is envisioned to work?=C2=A0 >> >> Would it be worthwhile documenting this interaction (in followup >> work). > > I and Thorsten are trying to capture some of these notions in > > =C2=A0 > https://tools.ietf.org/html/draft-srich-opsawg-mud-net-lifecycle-01= > > > although your particular case isn=E2=80=99t covered explicitly (I=E2= =80=99ll add > that).=C2=A0 Do you mind reading section 3.3 =E2=80=9CNetwork Devic= e > Configuration=E2=80=9D there and seeing if the wording is helpful?=C2= =A0 The > draft is not complete, and as always, feedback is appreciated. > > Thanks, > sjr > >> >> Thanks. >> >> --=20 >> M. Ranganathan >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > > > > --=20 > M. Ranganathan > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------B533455BC6BBCE1001C72E68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Ranga,

I apologize- I thought I had answered this note.=C2=A0 I'm going t= o top post because the theme of your note is pretty consistent: it essentially asks, what happens if we want to decompose the MUD controller into two?=C2=A0 I don't see anything particularly wrong = with the idea, but that's not where we are today.=C2=A0 There may be man= y ways one wishes to decompose a MUD controller, that being one of them.=C2=A0 I think that's fine follow-on work as well.=C2=A0 We're= leaving plenty of meat on the bone.

Eliot


On 10/4/17 5:58 PM, M. Ranganathan wrote:
Hello,

Architecturally, there are four functional blocks:

MUD file server : Serves MUD files. This is an optional component. MUD files could be directly bundled with the device itself if is-supported flag is False

MUD Controller: Transmits the mud file and auxiliary information (such as the local address of the default network services) to the MUD policy server. Manages the cache (retrieves policy files from the MUD file server periodically and supplies them to the MUD policy server). For example, this functionality may be implemented in an enhanced DHCP server or as a cloud resident caching service.

MUD policy server: Resolves MUD ACLs and installs them on switch (e.g. as a set of Flow rules). The MUD policy server could be a NETCONF or SDN controller managing multiple switches.

ACL / SDN capable switch.


If my terminology is wrong, please correct.


Looking through section 3 (comments in line)

    The MUD Policy Server may support caching retrieved MUD files.  If
   it does, then the operator may choose to enable, tune, test, and
   monitor this functionality as well.  Details about caching MUD
   files as well as each task above will be covered later in this
   document.


Does the MUD policy server nee=
d to do this? If "is-supported" is True then the MUD Controller may do ca=
che management as well (?).=20

   The goal of MUD is to enable the near-automatic management of
   device segmentation for the class of devices which have MUD
   support.=20


That is, we want to automatica=
lly map devices with different sensitivities to different network segment=
s. That is not necessarily the only goal. One could=20

limit the behavior of specific=
 devices without introducing the notion of network segments.

   1. Able to "see" a MUD URI

   2. Able to retrieve a MUD file


3. Able to map a specific devi=
ce (for example via a MAC id) to a MUD file that has been retrieved from =
the cloud.


Does section 3.4 (Testing) bel=
ong in section 3?=20


              
Cache management could be impo=
rtant because a manufacturer could update the MUD file. So at least when =
a device boots, if is-supported is True then=20


              
a new copy of the file should =
be retrieved.=20


            

            Good work on the draft! 

            

          

          Regards,

          

        

        Ranga.=C2=A0 (Affiliation: NIST / Advanced Networking Technologie=
s
        Division)

        

      

      


        
On Tue, Oct 3, 2017 at 12:52 PM, Steve=
n
          Rich <srich@cisco.com<=
/a>>
          wrote:

          

            


              

                  

                    
                    

                    

                      

                        
MUD suggests that devices should always
                          have access to DHCP and DNS. However, I don't
                          know how to communicate this information to
                          the MUD controller so that appropriate ACLs
                          can be installed when a device comes up. A
                          logical place to put this would be in the
                          request sent out by the DHCP server to the MUD
                          controller when it gets the OPTIONS 161 from
                          the device. Would this be the way this is
                          envisioned to work?=C2=A0 

                          

                        

                        Would it be worthwhile documenting this
                        interaction (in followup work).

                      

                    

                  

                  


                  

                
                
I and Thorsten are trying to capture some of these
                  notions in

                


                

                
=C2=A0 https://to=
ols.ietf.org/html/draft-srich-opsawg-mud-net-lifecycle-01
                


                

                
although your particular case isn=E2=80=99t covered
                  explicitly (I=E2=80=99ll add that).=C2=A0 Do you mind r=
eading
                  section 3.3 =E2=80=9CNetwork Device Configuration=E2=80=
=9D there and
                  seeing if the wording is helpful?=C2=A0 The draft is no=
t
                  complete, and as always, feedback is appreciated.
=

                


                

                
Thanks,

                
sjr

                

                

                  

                    

                      


                      

                      
Thanks.

                          

                      
                          

                            


                              -- 

                              
M.
                                Ranganathan

                              

                            

                          

                        

                    
                        ____________________________________________=
___

                        OPSAWG mailing list

                        OPSAWG@ietf.org
                        http=
s://www.ietf.org/mailman/listinfo/opsawg

                      

                

              

              

            

          

        

        

        

        

        -- 

        
M.
          Ranganathan

        

      

      

      

      

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


    

    

  


--------------B533455BC6BBCE1001C72E68--

--wGLwLNeSHIhJnAFMnGBVXFCQKnjRbrRku--

--a5Lc1sfPW4rpncwuo66g4cV3WMAGONIbV
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

iQEcBAEBCAAGBQJZ2PNLAAoJEIe2a0bZ0nozi1kIAM3Vss/Vwg4vyKV2GnlzODIV
kHCVdWC3oxLcHSz4Pnzv5YZGpd5abp0HHyaCrTDlHAnd7KopJI7FbiNYBuh00ZPq
75WMBnjZqmlUsAYYdUbor8MmzNnHXtW4nE8brS3/HHaFZJ4VVhGGp4hl3CExBf7u
fF7kELViEcMzV2xMQMgXqDx57Bfz01ks8V6pAjJ7K/1SeK9FsIS2+lG7T8/Pf2yM
tI/sDtY2obZRhPzIy2hLJoKFi8dB90RiKiUBe94X8RRcMVhh6ET2VAz1KMXGzROK
Yuft5K27hDv3e7tx9G/zqyi/i6tD3llAV0R8xqk1Zs4Kt5S0wczJJcUoNtebopY=
=q+PA
-----END PGP SIGNATURE-----

--a5Lc1sfPW4rpncwuo66g4cV3WMAGONIbV--


From nobody Mon Oct  9 05:55: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 B5AEC13422F for ; Mon,  9 Oct 2017 05:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 kxVPJOhcYVkx for ; Mon,  9 Oct 2017 05:55:08 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0325612ECEC for ; Mon,  9 Oct 2017 05:55:07 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id f4so23194976wme.0 for ; Mon, 09 Oct 2017 05:55:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=L11sUaosKw679wPg+HCPjuONaEvWbJ6hDIwYoPhIt3U=; b=d8JDXaFDsxk0bzKboTn8aPjzK3732QgYCUQZKUkwThiDG4C/g6Jg+eBca37JeKTb4m 1qg4Q73DDP5Of7T2+hzANKF13mh2x4JSXdG8VA+cgKO+aYbB+qm04PIU/y0blrjzOPeP 7oQAClKalYxUT8Apho1gEPfoRNTiFdAjqQWrgDvUJXyIFYzksWr4Lk+0JZCb3yYsmhe4 gKTHLCnFJX3lb1cL7GI2AcIDVrNPw1bb9DzrMVezMkk5uy8UzzmFCmaMnAfmgEw2Y8Ne WeUQfLzthBUDZkTOoXSOOuOQwxg3Yuu/076Nz8WKFs0Sl5NofschIvcXPxuEpufB//mt LWcA==
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=L11sUaosKw679wPg+HCPjuONaEvWbJ6hDIwYoPhIt3U=; b=dD1q78txrwW1x4tiydNgf7ANnbjXOgU2QrZIdHCVJ1oLlV/+tYAV3qUhczpFC7Js2u cR5Gtsk00x2CY5vopY3WgsfJ/GRCWGAruKgfjHbA3/leSrUFe5MQJGD6D0E4lLeqEX5+ pdM1y9pa5lt3AbE7a+ccc9UBhgAHaSdYVZBTB2xzw1G5yJbih2D2optGrdgzUX834fyz eQTzC018Hiw6HRiimvsmOZZX4M7bopIggNYxIaxxCUGmLmMVIkV8as9m/B09tytbkD1f v6/G8LGdrQlkYahGZQp03GHGGY/83G0AVf6BR6MeGyxSUi8DxOY1O7mq/jnzB9xn38fJ kqdg==
X-Gm-Message-State: AMCzsaV9Y54clPGfvUep5zz6jc1D1AMDKZJwWzY7lzFVpxZR8jiwfewV MATkjrVEooZ64NgMfcGkqaP5mvOKT5DY7LiH++HYICmF
X-Google-Smtp-Source: AOwi7QBVYY1WRWPmHnw94wDg6rDRooI+ag9Mxv1du6RFluvyxgGejfGbDbDxfQ4h9NMoT2ooiWMdYhRqCYnMyb3iajs=
X-Received: by 10.223.136.85 with SMTP id e21mr7997091wre.37.1507553706000; Mon, 09 Oct 2017 05:55:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.160.205 with HTTP; Mon, 9 Oct 2017 05:54:25 -0700 (PDT)
From: "M. Ranganathan" 
Date: Mon, 9 Oct 2017 08:54:25 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1149253820450f055b1cb38b"
Archived-At: 
Subject: [OPSAWG] draft-ietf-opsawg-mud-12: MUD Draft : Identifying the Router.
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, 09 Oct 2017 12:55:10 -0000

--001a1149253820450f055b1cb38b
Content-Type: text/plain; charset="UTF-8"

Hello,

I am implementing MUD using an external controller. i.e. a cloud resident
controller that could potentially control several "home" routers. I need
some way of communicating the address of the LAN router to the controller
but I can't figure out where this is specified. I would have expected a
parameter similar to  "urn:ietf:params:mud:router" (i.e. in the same
fashion as DNS, NTP and DHCP are specified) but I could not find it.

I must have missed something. Could the author(s) please help clarifying
this.

Thanks in advance,

Ranga.

-- 
M. Ranganathan

--001a1149253820450f055b1cb38b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

I am implementing MUD u=
sing an external controller. i.e. a cloud resident controller that could po=
tentially control several "home" routers. I need some way of comm=
unicating the address of the LAN router to the controller but I can't f=
igure out where this is specified. I would have expected a parameter simila=
r to=C2=A0 "urn:ietf:params:mud:router" (i.e. in the same fashion=
 as DNS, NTP and DHCP are specified) but I could not find it.

=
I must have missed something. Could the author(s) please help clarifying th=
is. 

Thanks in advance,

Ranga.

-- 
M. Ranganathan<=
br>




--001a1149253820450f055b1cb38b--


From nobody Mon Oct  9 06: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 A00EC134234 for ; Mon,  9 Oct 2017 06:01:45 -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 PotG2IJFjzuH for ; Mon,  9 Oct 2017 06:01:44 -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 F27A1134525 for ; Mon,  9 Oct 2017 06:01:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5394; q=dns/txt; s=iport; t=1507554074; x=1508763674; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bw618VClqDZ2uYIGrWo0mATH01D1a3uEnJppo+EZEy0=; b=hPeV6eqP4hd/PLNjaBkj9xOSzDTqn80OzuEQR/sxhvSgf9sKHWSMwyQ8 Kv/soUlBW9DAHysYCrYobYyZg5NxsKc0c7YaWPLsiHKRPzYucGAyGRM0D sg5ojf4rHPLg11pc+QIQopezntIr/G5mXQ+smCSd0V4nx0CFpaKRjyQzo 8=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAACQcttZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEFuJ4N6ih90kEQrkHCFP4ISBwMYAQqESU8ChHQYAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBIUsQCwsEFCoCAicwBgEMBgIBAYokCBCnUoInJ4sGAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBDgoFgy2FaIJ+iBeCYQEEihiOQIhdhDyCIY4KghS?= =?us-ascii?q?BcYN+g1qHLpVagTkfOIEOMiEIHRVJhx8+NolqAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,500,1500940800";  d="asc'?scan'208,217";a="655342848"
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; 09 Oct 2017 13:01:12 +0000
Received: from [10.61.211.60] ([10.61.211.60]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v99D1BNH027456; Mon, 9 Oct 2017 13:01:11 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References: 
From: Eliot Lear 
Message-ID: 
Date: Mon, 9 Oct 2017 15:01:12 +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="JIaOtgS6WLOoREW6WhBPQxiKHEugBL1CC"
Archived-At: 
Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-12: MUD Draft : Identifying the Router.
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, 09 Oct 2017 13:01:46 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--JIaOtgS6WLOoREW6WhBPQxiKHEugBL1CC
Content-Type: multipart/mixed; boundary="QXHGwrEnn0qSsValNrcDVmVVNWq5HGTri";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" , opsawg@ietf.org
Message-ID: 
Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-12: MUD Draft : Identifying the
 Router.
References: 
In-Reply-To: 

--QXHGwrEnn0qSsValNrcDVmVVNWq5HGTri
Content-Type: multipart/alternative;
 boundary="------------36754A32349EDD30718175D7"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------36754A32349EDD30718175D7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ranga,


On 10/9/17 2:54 PM, M. Ranganathan wrote:
> Hello,
>
> I am implementing MUD using an external controller. i.e. a cloud
> resident controller that could potentially control several "home"
> routers. I need some way of communicating the address of the LAN
> router to the controller but I can't figure out where this is
> specified. I would have expected a parameter similar to=C2=A0
> "urn:ietf:params:mud:router" (i.e. in the same fashion as DNS, NTP and
> DHCP are specified) but I could not find it.
>
> I must have missed something. Could the author(s) please help
> clarifying this.
>

Not quite clear to me what you want to do with the parameter.=C2=A0 Can y=
ou
explain?

Eliot

> Thanks in advance,
>
> Ranga.
>
> --=20
> M. Ranganathan
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


--------------36754A32349EDD30718175D7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Ranga,

    

    
On 10/9/17 2:54 PM, M. Ranganathan
      wrote:

    

    

      
      

        

          

            
Hello,

              

            

            I am implementing MUD using an external controller. i.e. a
            cloud resident controller that could potentially control
            several "home" routers. I need some way of communicating the
            address of the LAN router to the controller but I can't
            figure out where this is specified. I would have expected a
            parameter similar to=C2=A0 "urn:ietf:params:mud:router" (i.e.=
 in
            the same fashion as DNS, NTP and DHCP are specified) but I
            could not find it.

            

          

          I must have missed something. Could the author(s) please help
          clarifying this. 

          

        

      

    

    

    Not quite clear to me what you want to do with the parameter.=C2=A0 C=
an
    you explain?

    

    Eliot

    

    

      

        
Thanks in advance,

          

        

        Ranga.

        

          

            

              

                


                  -- 

                  
M. Ranganathan

                  

                

              

            

          

        

      

      

      

      

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


    

    

  


--------------36754A32349EDD30718175D7--

--QXHGwrEnn0qSsValNrcDVmVVNWq5HGTri--

--JIaOtgS6WLOoREW6WhBPQxiKHEugBL1CC
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

iQEcBAEBCAAGBQJZ23MYAAoJEIe2a0bZ0nozeWEH/1jUUf5PzbHSHHVBc1pCBwat
TPsHlE7L5CvsQE5ciW9QzfXbotRYXQ4QsjICpL+B+KpauvikKnzEOEbalxf7q2MJ
/7O1HHnZEXcrIHb3N6ky2fUdfhrkfb01brCnGLZ9UWa+JL6WT2rWnvVcjPPKPUJo
SqEinUTGMGnjpxN7bo4iJKeV+MGuw4HQtyW5j/zT7Lyxw39fsOtl0XN8/hrei3W5
UVM+oUsV3eWCME0c4TIR89LFJ0QWG6ibhQlkqWjl+hZwGpLDySiltyODtD1N2Tyc
gpFyP29oypKX0Kik0ypd7nREgiRT1g1oIU6StuOKaEaw9uG5HyhQDM/MVPBPNF8=
=D9Fr
-----END PGP SIGNATURE-----

--JIaOtgS6WLOoREW6WhBPQxiKHEugBL1CC--


From nobody Mon Oct  9 07:29:59 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 702F8133054 for ; Mon,  9 Oct 2017 07:29:58 -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 jfKD95Z9P5Xp for ; Mon,  9 Oct 2017 07:29:56 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58A6132930 for ; Mon,  9 Oct 2017 07:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3372; q=dns/txt; s=iport; t=1507559396; x=1508768996; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=s9/Vq9YLqel/oG/9Ca9ahIA073qEsj3QPY/ur38Y540=; b=fhmnT/Y0WZFCsuCPd+co6Jt1p4b1/Rhgh9MtpnBJmT8LbTSYs94ETQIZ StZs3IOwrDKA1eROnYiKynJFGpQA5rCO7Vt1GDBG5Z33ytv1dPC1rlrM7 34IGNDt2J7lrdo5u60t2jDTJ2UQrdOwfxpt0ORFW2kZiMEXhQnmsp/Mb2 8=;
X-IronPort-AV: E=Sophos;i="5.42,500,1500940800"; d="scan'208";a="308454000"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2017 14:29:56 +0000
Received: from [10.150.55.66] (dhcp-10-150-55-66.cisco.com [10.150.55.66]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v99ETt6d001661; Mon, 9 Oct 2017 14:29:55 GMT
To: Eliot Lear 
Cc: opsawg@ietf.org
References: <150737739036.11112.718690273314652329@ietfa.amsl.com> <9bad5899-c16b-04bc-2287-50f90d0c3b07@cisco.com>
From: Joe Clarke 
Organization: Cisco
Message-ID: <9e24e8a5-b2ba-2163-4244-a9be40d4c138@cisco.com>
Date: Mon, 9 Oct 2017 10:29:55 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <9bad5899-c16b-04bc-2287-50f90d0c3b07@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-12.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, 09 Oct 2017 14:29:58 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/7/17 07:58, Eliot Lear wrote:
> This version is intended to address all outstanding issues based on
> last call.  That includes the following:
> 
> o  Correct examples based on ACL model changes. o  Change ordering
> nodes. o  Additional explanatory text around systeminfo. o  Change
> ordering in examples. o  Make it VERY VERY VERY VERY clear that
> these are recommendations, not mandates. o  DHCP -> NTP in some of
> the intro text. o  Remove masa-server o  "Things" to "network
> elements" in a few key places. o  Reference to JSON YANG RFC
> added.

Hey, Eliot.  Thanks for addressing the majority of comments.  I've
read through this latest draft, and I have a couple more:

You have a typo in section 2:

"Furthermore, only or "accept" or "drop" actions SHOULD be included."

You have an unnecessary "or" in there.

===

In the example in Section 8, the cl0-todev rule still lists the
directory as "from-device".  I think it should be "to-device" unless I
misunderstand the purpose of the direction.

Joe

> 
> Eliot
> 
> 
> On 10/7/17 1:56 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-12.txt Pages           : 55 Date
>> : 2017-10-07
>> 
>> Abstract: This memo specifies a component-based architecture for
>> manufacturer usage descriptions (MUD).  The goal of MUD is to
>> provide a means for Things to signal to the network what sort of
>> access and network functionality they require to properly
>> function.  The initial focus is on access control.  Later work
>> can delve into other aspects.
>> 
>> This memo specifies two YANG modules, IPv4 and IPv6 DHCP options,
>> an LLDP TLV, a URL suffix specification, an X.509 certificate
>> extension and a means to sign and verify the descriptions.
>> 
>> 
>> The IETF datatracker status page for this draft is: 
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>> 
>> There are also htmlized versions available at: 
>> https://tools.ietf.org/html/draft-ietf-opsawg-mud-12 
>> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-12
>> 
>> A diff from the previous version is available at: 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-12
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at: 
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________ 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/hTPhwUCWduH4QAKCRBvaI+K/hTP
h9aqAJ9vf6Q8Fh89rTQUygy1PTxjKPFBCgCggFHDKFQF/jEUgx4EhE99H26/fs4=
=Ftd6
-----END PGP SIGNATURE-----


From nobody Mon Oct  9 10:46: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 4F7A31344F8 for ; Mon,  9 Oct 2017 10:46:28 -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 Rq8EGgYkPymc for ; Mon,  9 Oct 2017 10:46:26 -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 7ED4D134622 for ; Mon,  9 Oct 2017 10:46:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12049; q=dns/txt; s=iport; t=1507571185; x=1508780785; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=+v9X0HPy2rik/k2Q7nAVxnyudvN591bdb/+ei6dpImA=; b=ahT/Sf6bFY6F9v5eLQQjpbGIxzioI9ofZuTcUs0N9eKuRUWmAFWNJJ3i J6yLYz1B/rDx5D2r3zePOWVeenJI78ltpYFjloHAcXqlvFObhplpzPQri pKQ3R1TwYre7cXu4aofdt1qC6JCo7qMQWuTQPhfaOShOm7fk2B4m8aICL o=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.42,501,1500940800";  d="asc'?scan'208,217";a="655349050"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2017 17:46:23 +0000
Received: from [10.61.211.60] ([10.61.211.60]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v99HkMQv005416; Mon, 9 Oct 2017 17:46:23 GMT
To: Joe Clarke 
Cc: opsawg@ietf.org
References: <150737739036.11112.718690273314652329@ietfa.amsl.com> <9bad5899-c16b-04bc-2287-50f90d0c3b07@cisco.com> <9e24e8a5-b2ba-2163-4244-a9be40d4c138@cisco.com>
From: Eliot Lear 
Message-ID: 
Date: Mon, 9 Oct 2017 19:46:23 +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: <9e24e8a5-b2ba-2163-4244-a9be40d4c138@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mLG7Af6GA0RXHBf5Xl4sfPTentNqGO8kC"
Archived-At: 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-12.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, 09 Oct 2017 17:46:28 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mLG7Af6GA0RXHBf5Xl4sfPTentNqGO8kC
Content-Type: multipart/mixed; boundary="L1Ub03EWSglsvkvxtdekQTNX3jP1g4gFi";
 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-12.txt
References: <150737739036.11112.718690273314652329@ietfa.amsl.com>
 <9bad5899-c16b-04bc-2287-50f90d0c3b07@cisco.com>
 <9e24e8a5-b2ba-2163-4244-a9be40d4c138@cisco.com>
In-Reply-To: <9e24e8a5-b2ba-2163-4244-a9be40d4c138@cisco.com>

--L1Ub03EWSglsvkvxtdekQTNX3jP1g4gFi
Content-Type: multipart/alternative;
 boundary="------------73B675C42973AE75A3528B80"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------73B675C42973AE75A3528B80
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Joe,

On 10/9/17 4:29 PM, Joe Clarke wrote:
> On 10/7/17 07:58, Eliot Lear wrote:
> > This version is intended to address all outstanding issues based on
> > last call.=C2=A0 That includes the following:
>
> > o=C2=A0 Correct examples based on ACL model changes. o=C2=A0 Change o=
rdering
> > nodes. o=C2=A0 Additional explanatory text around systeminfo. o=C2=A0=
 Change
> > ordering in examples. o=C2=A0 Make it VERY VERY VERY VERY clear that
> > these are recommendations, not mandates. o=C2=A0 DHCP -> NTP in some =
of
> > the intro text. o=C2=A0 Remove masa-server o=C2=A0 "Things" to "netwo=
rk
> > elements" in a few key places. o=C2=A0 Reference to JSON YANG RFC
> > added.
>
> Hey, Eliot.=C2=A0 Thanks for addressing the majority of comments.=C2=A0=
 I've
> read through this latest draft, and I have a couple more:
>
> You have a typo in section 2:
>
> "Furthermore, only or "accept" or "drop" actions SHOULD be included."
>
> You have an unnecessary "or" in there.

Nuked the extra "or" in my copy.

>
> =3D=3D=3D
>
> In the example in Section 8, the cl0-todev rule still lists the
> directory as "from-device".=C2=A0 I think it should be "to-device" unle=
ss I
> misunderstand the purpose of the direction.

I think you misunderstand something.=C2=A0 "direction-initiated" is the T=
CP
connection direction, not packet flow.

Eliot

>
> Joe
>
>
> > Eliot
>
>
> > On 10/7/17 1:56 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=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-12.txt Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 55 Date
> >> : 2017-10-07
> >>
> >> Abstract: This memo specifies a component-based architecture for
> >> manufacturer usage descriptions (MUD).=C2=A0 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 focus 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.
> >>
> >>
> >> 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-12
> >> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-12
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-mud-12
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at
> >> tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________ 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
>
>
>


--------------73B675C42973AE75A3528B80
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Hi Joe,

    

    On 10/9/17 4:29 PM, Joe Clarke wrote:

    
On 10/7/17 07:58, Eliot Lear wrote:

      > This version is intended to address all outstanding issues
      based on

      > last call.=C2=A0 That includes the following:

      

      > o=C2=A0 Correct examples based on ACL model changes. o=C2=A0 C=
hange
      ordering

      > nodes. o=C2=A0 Additional explanatory text around systeminfo. =
o=C2=A0
      Change

      > ordering in examples. o=C2=A0 Make it VERY VERY VERY VERY clea=
r
      that

      > these are recommendations, not mandates. o=C2=A0 DHCP -> NT=
P in
      some of

      > the intro text. o=C2=A0 Remove masa-server o=C2=A0 "Things" to=
 "network

      > elements" in a few key places. o=C2=A0 Reference to JSON YANG =
RFC

      > added.

      

      Hey, Eliot.=C2=A0 Thanks for addressing the majority of comments.=C2=
=A0 I've

      read through this latest draft, and I have a couple more:

      

      You have a typo in section 2:

      

      "Furthermore, only or "accept" or "drop" actions SHOULD be
      included."

      

      You have an unnecessary "or" in there.

    

    

    Nuked the extra "or" in my copy.

    

    


      =3D=3D=3D

      

      In the example in Section 8, the cl0-todev rule still lists the
=

      directory as "from-device".=C2=A0 I think it should be "to-device"
      unless I

      misunderstand the purpose of the direction.

    

    

    I think you misunderstand something.=C2=A0 "direction-initiated" is t=
he
    TCP connection direction, not packet flow.

    

    Eliot

    

    


      Joe

      

      

      > Eliot

      

      

      > On 10/7/17 1:56 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-12.txt Pages=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 55 Date

      >> : 2017-10-07

      >>

      >> Abstract: This memo specifies a component-based
      architecture for

      >> manufacturer usage descriptions (MUD).=C2=A0 The goal of M=
UD
      is to

      >> provide a means for Things to signal to the network what
      sort of

      >> access and network functionality they require to properly<=
br>
      >> function.=C2=A0 The initial focus 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.

      >>

      >>

      >> 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-12 

      >>
      https://datatracker.ietf.org/do=
c/html/draft-ietf-opsawg-mud-12

      >>

      >> A diff from the previous version is available at: 

      >>
      https://www.ietf.org/rfcdiff?url2=3D=
draft-ietf-opsawg-mud-12

      >>

      >>

      >> Please note that it may take a couple of minutes from the
      time of

      >> submission until the htmlized version and diff are
      available at

      >> tools.ietf.org.

      >>

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

      >>

      >> _______________________________________________ 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;


    

  


--------------73B675C42973AE75A3528B80--

--L1Ub03EWSglsvkvxtdekQTNX3jP1g4gFi--

--mLG7Af6GA0RXHBf5Xl4sfPTentNqGO8kC
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

iQEcBAEBCAAGBQJZ27XwAAoJEIe2a0bZ0nozeLoH/igCLvHTJF+YY6emZ3oYIcoZ
EgR8IjcTSp0gIEEPjPbTbFtw16/iGggItZjrkDU5JcDcBF3w6PLhU8axKzkUMmfQ
RX3MjTuSY87TpEUJwCx248mFtYofwTwrZfLHgDyITKhul1CAeR2/Y05ZxGilctCv
HW9rVLRlrc+F0hc7RARl8EPocBKKX3CaPK4rJpGL8DoRF3BwQTdFU7p0Succ2C0S
9YoAYN2bF/ImZjpulHd0XrXHqCRPHcqzIVWEL/9m24/5mRxv3xEata6jsyt0D8lw
roXAQSLJZH4XMXISqYVaSw77//45bpSiXN3kv1oz7xUaaa7/KWOgxyhVTOKbovY=
=BXbX
-----END PGP SIGNATURE-----

--mLG7Af6GA0RXHBf5Xl4sfPTentNqGO8kC--


From nobody Mon Oct  9 11:08:43 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 E16831346F8 for ; Mon,  9 Oct 2017 11:08:41 -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_H4=-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 c66eelJILgM4 for ; Mon,  9 Oct 2017 11:08:40 -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 18E0313463A for ; Mon,  9 Oct 2017 11:08:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=716; q=dns/txt; s=iport; t=1507572520; x=1508782120; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NC937gNj2pjcR9fiAgeDw2MXqF1vLcItzwH/0AI4Wr4=; b=LoTl/tKBLkWzbl1A10YqciivKTurGSRsJiZlOugU4t3l8MNxQgAYs+EE 20OdtSX5gUqnbXf06FZtl3JVDzDYJjggh5+o5L7TlfIy1NwhUs3eXAJD7 dv64m0vZnBwOyrUOE7b+xW8SoUowLKlQWi6AsVRyd3lQUzonj9C8ZTW+U c=;
X-IronPort-AV: E=Sophos;i="5.42,501,1500940800"; d="scan'208";a="14639091"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2017 18:08:39 +0000
Received: from [10.150.55.66] (dhcp-10-150-55-66.cisco.com [10.150.55.66]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v99I8dR0027944; Mon, 9 Oct 2017 18:08:39 GMT
To: Eliot Lear 
Cc: opsawg@ietf.org
References: <150737739036.11112.718690273314652329@ietfa.amsl.com> <9bad5899-c16b-04bc-2287-50f90d0c3b07@cisco.com> <9e24e8a5-b2ba-2163-4244-a9be40d4c138@cisco.com> 
From: Joe Clarke 
Organization: Cisco
Message-ID: <89ce3fee-574d-6f05-c9f8-98ee2503be71@cisco.com>
Date: Mon, 9 Oct 2017 14:08:39 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-12.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, 09 Oct 2017 18:08:42 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/9/17 13:46, Eliot Lear wrote:
>> In the example in Section 8, the cl0-todev rule still lists the 
>> directory as "from-device".  I think it should be "to-device"
>> unless I misunderstand the purpose of the direction.
> 
> I think you misunderstand something.  "direction-initiated" is the
> TCP connection direction, not packet flow.

Yes, I did misread.  That makes sense.  The device initiates the
tcp/443 in this case.

Thanks, Eliot.

Joe
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWdu7IwAKCRBvaI+K/hTP
h4jkAJ4ghkxSQ4ECnWVBUsqpbfRVPS1iBQCdF/3PI06HE8P1HW9h1rnKH3OY8jo=
=Dbub
-----END PGP SIGNATURE-----


From nobody Mon Oct  9 11:11:46 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 B34EF13463A for ; Mon,  9 Oct 2017 11:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.121
X-Spam-Level: 
X-Spam-Status: No, score=-13.121 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 VhkYwXC32J9S for ; Mon,  9 Oct 2017 11:11:44 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EEA134737 for ; Mon,  9 Oct 2017 11:11:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=317; q=dns/txt; s=iport; t=1507572703; x=1508782303; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=T78IFIDO6oWeAY5TbM6KmsahsSj4Ldhvspvwu/aA58I=; b=cP+AxUsWS92agqGLpOdgj4Dbv0peLto7lMXjWZPRybWQG17JcIyrn91Z 9XXCBmPcynrXjxqOHYSbfKs61hDszdkcLnsBlKNYsNWn52G2Pe5jBKQoC NyppgCvYZrvxppxWDWC8+7Om9PCiem+Pt9L5UeJfDIqtfJFYgIB3RvsRz s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAQB9u9tZ/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg12BUoQhmhGaNwqJdkMUAQIBAQEBAQEBax0LhUKBCwImAl8NCAE?= =?us-ascii?q?BiiynIIIniyIBAQEHAiaBDoIfggKBUYFqK4sVgmEFoTWBbZJ6gXsBiWGHLpVag?= =?us-ascii?q?Tk2IYEOUyUViAIkiiABAQE?=
X-IronPort-AV: E=Sophos;i="5.42,501,1500940800"; d="scan'208";a="14642886"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Oct 2017 18:11:43 +0000
Received: from [10.150.55.66] (dhcp-10-150-55-66.cisco.com [10.150.55.66]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v99IBgxu014312 for ; Mon, 9 Oct 2017 18:11:43 GMT
To: "opsawg@ietf.org" 
From: Joe Clarke 
Organization: Cisco
Message-ID: 
Date: Mon, 9 Oct 2017 14:11:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [OPSAWG] Consensus on MUD draft
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, 09 Oct 2017 18:11:45 -0000

On behalf of the chairs, I am calling consensus on
draft-ietf-opsawg-mud-12.  The authors have incorporated all substantive
feedback, and there has been numerous calls for support of the work as
well as discussions and actions on implementation and tooling.

This document will move forward to the IESG.

Joe


From nobody Mon Oct  9 19:59: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 926A81323B4; Mon,  9 Oct 2017 19:59:31 -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 qSJ-0YvtHlIB; Mon,  9 Oct 2017 19:59: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 455EB132153; Mon,  9 Oct 2017 19:59:29 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQF61278; Tue, 10 Oct 2017 02:59:27 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 10 Oct 2017 03:59:26 +0100
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.11]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 10 Oct 2017 10:59:15 +0800
From: Tianran Zhou 
To: Tianran Zhou , "opsawg@ietf.org" 
CC: "opsawg-chairs@ietf.org" 
Thread-Topic: WG LC for draft-ietf-opsawg-capwap-alt-tunnel-10
Thread-Index: AdMx1mdmlA5ckKCRRgOkkH52TiYS4gPnOxKg
Date: Tue, 10 Oct 2017 02:59:15 +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.0A020206.59DC378F.009B, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.5.11, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c398ebfeb14d328c0b2a74da5ea630fa
Archived-At: 
Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-capwap-alt-tunnel-10
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, 10 Oct 2017 02:59:31 -0000

Hi WG,

This call is concluded without objection on the revision.
Let's move forward to IESG.

Thanks,
Tianran

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran Zhou
> Sent: Wednesday, September 20, 2017 2:05 PM
> To: opsawg@ietf.org
> Cc: opsawg-chairs@ietf.org
> Subject: [OPSAWG] WG LC for draft-ietf-opsawg-capwap-alt-tunnel-10
>=20
> Dear OPSAWG,
>=20
> The following draft was sent to IESG, but received some critical comments=
.
>=20
> Alternate Tunnel Encapsulation for Data Frames in CAPWAP
> https://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-10
>=20
> Now the authors have addressed all the comments, and received confirmatio=
n
> from the Security DIR reviewer.
> https://datatracker.ietf.org/doc/review-ietf-opsawg-capwap-alt-tunnel-
> 09-secdir-early-meadows-2017-08-10/
>=20
> This is a notice to start a two-week OPSAWG WG last call review for the
> document.
> Please read the above draft and send any issues, comments, or corrections
> to this mailing list.
> Please indicate your support or concerns by Wednesday Oct 4, 2017.
>=20
> Please note that the authors decided to change the document type to
> Experimental, as stated below:
> 1.3.  History of the document
>    This document was started to accommodate Service Provider's need of a
>    more flexible deployment mode with alternative tunnels [RFC7494].
>    Experiments and tests have been done for this alt-tunnel network
>    infrastructure.  However important, the deployment of relevant
>    technology is yet to complete.  This experimental document is
>    intended to serve as a historical reference for any future work as to
>    the operational and deployment requirements.
>=20
> Thanks,
> Tianran, as co-chair
>=20
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


From nobody Tue Oct 10 07:39: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 6970E134535 for ; Tue, 10 Oct 2017 07:38:11 -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=unavailable 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 dIkcbNVnq42I for ; Tue, 10 Oct 2017 07:38:00 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7410A134541 for ; Tue, 10 Oct 2017 07:37:44 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id m72so5836545wmc.1 for ; Tue, 10 Oct 2017 07:37:44 -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=5Wuo7wcNaP/9BRaUJc2DS0damHej+B2rVT+186rqnTs=; b=aex4BKEurCA4e9MxRfA7VCFF4o6jcvqQMFlTUVGLWLLxwmdtulmfam1YQ++eZdVZqs SL3tHoXDmJ9oy1vKopn/31iSUzvwuL8kn9hMG0FiRlM/NqPO313bbpVcd9QE61YKNNIC 70DFnQuZM/iWbdHeTCRiQfIBCb6lIxNt1I3yYG3E3cIgiNIOuwW7NExtbj0QABlRIQni +jF0dqssoZ+/rqsas82goY7md1CSEcPUhmtdOSEd5U12e52A0gjx9v96U5ph1Dzj2JY6 qTvSnxxaNyesvUdbx2VMphwMHsoOn897eD1Jw0X12e23b16DBk1X7MyN6bpNQZ/j5LQ4 Ysfg==
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=5Wuo7wcNaP/9BRaUJc2DS0damHej+B2rVT+186rqnTs=; b=f2tgmds6/P2dw2tlyH/42Ibay7YK6DtjGW7fMpxH7MhPaWB20NU6sHD0i15XKxZMDc UeuVkrLJUh0QKhiIpPIzCmt+LhalZ0T+2u/Uw0f2k7CDao1rw6Ftn5t/wR3+Fzq2X2cl pipun4THfietfMKfMoKzcFr2oyio2s5/aUlxw5Tt1zn5WPuzIrnw4LfM/1pJ4PybkrzV NBXNT+8+2VygmM71iE0LhpP+g3DAHPswVyq38bsZSSX/yfiJGjaRvKg2MoPwpvbsDP0H 8Y+DY/dEEQ876+K+QZQabP8UMvFwaPmVJygkZDXQsWed3Ra5iQT/yXieleStNSGQsNZA ReLA==
X-Gm-Message-State: AMCzsaWC0jofn7HgQHo4d8OERbXFRLqPrmiNFf2FbkNIhQo3l4R1Ndik Lg67f90SFJXHUpEna1/YP/1owf6+Vj4K/gJIoCw=
X-Google-Smtp-Source: AOwi7QBb/zhEnrWOvURviLDQ952D0La1pCoqAPP6kj6ByoISgDoyk9k4ZNgREYYeFOTYH7FbFvoKDL7Kxd9NsHrRXP4=
X-Received: by 10.28.63.134 with SMTP id m128mr12534225wma.137.1507646262876;  Tue, 10 Oct 2017 07:37:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.160.205 with HTTP; Tue, 10 Oct 2017 07:37:02 -0700 (PDT)
In-Reply-To: 
References:  
From: "M. Ranganathan" 
Date: Tue, 10 Oct 2017 10:37:02 -0400
Message-ID: 
To: Eliot Lear 
Cc: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1148be06f2205d055b323f2a"
Archived-At: 
Subject: Re: [OPSAWG] draft-ietf-opsawg-mud-12: MUD Draft : Identifying the Router.
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, 10 Oct 2017 14:38:11 -0000

--001a1148be06f2205d055b323f2a
Content-Type: text/plain; charset="UTF-8"

Hi Eliot,


On Mon, Oct 9, 2017 at 9:01 AM, Eliot Lear  wrote:

> Hi Ranga,
>
> On 10/9/17 2:54 PM, M. Ranganathan wrote:
>
> Hello,
>
> I am implementing MUD using an external controller. i.e. a cloud resident
> controller that could potentially control several "home" routers. I need
> some way of communicating the address of the LAN router to the controller
> but I can't figure out where this is specified. I would have expected a
> parameter similar to  "urn:ietf:params:mud:router" (i.e. in the same
> fashion as DNS, NTP and DHCP are specified) but I could not find it.
>
> I must have missed something. Could the author(s) please help clarifying
> this.
>
>
> Not quite clear to me what you want to do with the parameter.  Can you
> explain?
>
> Eliot
>

After some thought I concluded that the parameter is not necessary.

Thanks,

Ranga

>
> Thanks in advance,
>
> Ranga.
>
> --
> M. Ranganathan
>
>
> _______________________________________________
> OPSAWG mailing listOPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg
>
>
>


-- 
M. Ranganathan

--001a1148be06f2205d055b323f2a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Hi Eliot,


=

On Mon, Oct 9, 2017 a=
t 9:01 AM, Eliot Lear <lear@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Ranga,

    

    
On 10/9/17 2:54 PM,=
 M. Ranganathan
      wrote:

    

    

     =20
      

        

          

            
Hello,

              

            

            I am implementing MUD using an external controller. i.e. a
            cloud resident controller that could potentially control
            several "home" routers. I need some way of communicat=
ing the
            address of the LAN router to the controller but I can't
            figure out where this is specified. I would have expected a
            parameter similar to=C2=A0 "urn:ietf:params:mud:router&quo=
t; (i.e. in
            the same fashion as DNS, NTP and DHCP are specified) but I
            could not find it.

            

          

          I must have missed something. Could the author(s) please help
          clarifying this. 

          

        

      

    

    

    Not quite clear to me what you want to do with the parameter.=C2=A0 Can
    you explain?

    

    Eliot

After some thought I co=
ncluded that the parameter is not necessary.

Thanks,
<=
br>
Ranga 

    

    

      

        
Thanks in advance,

          

        

        Ranga.

        

          

            

              

                


                  -- 

                  
M. Ra=
nganathan

                  

                

              

            

          

        

      

      

      

      

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


    

    

  






-- 
M. Ranganathan




--001a1148be06f2205d055b323f2a--


From nobody Wed Oct 11 19:17: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 E24EE1342FB for ; Wed, 11 Oct 2017 19:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 x1jMsrdJ2lGY for ; Wed, 11 Oct 2017 19:16:57 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F12133039 for ; Wed, 11 Oct 2017 19:16:57 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id b189so9046558wmd.4 for ; Wed, 11 Oct 2017 19:16:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=tKBusRVzL6cY0BdeI7SszFs660vYIefmehXcBeUnQW8=; b=dJ41gsOAzjIhSajgEDrwzvcSnuIbZZxV62+nedupp518q1RaS2NxWkIlxdzPJq1VOk MuL2QINxCE2+EhJcNMsPV1vHQ9XJl1dpn46H4VCLLu6gxGk87Sb/svqDWss1WkVMCP4l 6MQlKPJsokZ5ZNnwLzO+xCX89WHMVeD42bWgoCEtr7LhKvkCG4n/M8BDWKNK2AHV4lRT WRdL3uqG9qTESUCpG06qjEXZXTQMndqaGnLqzovO8HtHjn85QH7wrxn6vWlI9SlFXmed S3l7OlktNA65RDiGnPbz731X1OinqwJpxY9s7lruTSLg3iEn7igf1djDR069ZDgzNc2d qVPQ==
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=tKBusRVzL6cY0BdeI7SszFs660vYIefmehXcBeUnQW8=; b=TBxXYHwKzFEA1emQAbMC2s77VbGnJ1UF81CeKCkZYh59hAdXk0h9rNPzYv39JJ+oPF pR3ezCTG1l03eoHECSc/ugsr9urGLqA/IsvckRpZqZ/VPOIz/F3kib/vfCi3BODGFoia vNHYe0IklsvmlZrMe/rUrM7plaXOrvGoUOogX7D7aIFGper5gcKht39ypF5o0/zfL5hZ oPpPZiLKGOWv5CYhzBp3RXGs9/w5Cpjqy0BCPZWoNNBuYmh4Pks33f0nSRvNdMnDd2eG YghiY4TYKIooKYC4jNAFz8q2SJnbbRNBfk5FYtxTHGl6JnrIltvMlYTxGBtBlmXBMlF8 1AEg==
X-Gm-Message-State: AMCzsaV/vctLJpFYC+z8yQCMcBAwKQamstMc6gbOe2x42zZKS4ihlJ07 MHNdaN2LwVwfM091ZSrJzv6pmmvryBwQbmRiNTzJmg==
X-Google-Smtp-Source: AOwi7QDUzFeWE1pzpZaIZ+RoBhfkT8hIHew+9EZRMxVk/bp5nJlVvs7Jr4cF6ouhJWws20Mwbt6SVWSxRkCLPT+fACs=
X-Received: by 10.28.146.20 with SMTP id u20mr599375wmd.49.1507774615222; Wed, 11 Oct 2017 19:16:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Wed, 11 Oct 2017 19:16:14 -0700 (PDT)
From: "M. Ranganathan" 
Date: Wed, 11 Oct 2017 22:16:14 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a11442fbc577d6a055b50222d"
Archived-At: 
Subject: [OPSAWG] Understanding MUD : Controller and my-controller
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, 12 Oct 2017 02:16:59 -0000

--001a11442fbc577d6a055b50222d
Content-Type: text/plain; charset="UTF-8"

Hello,

I am reading through previous discussion on these topics and am still not
quite "getting it". So I request some explanation from the authors. My
understanding is as follows:

controllers : this is a place holder for things like DNS and DHCP where the
address of the server is not known a-priori.

my-controller - has me quite confused.  Here's the text from the latest
draft:

   "my-controller:  Devices associated with the MUD URL of a device that
      the administrator admits."

So my understanding on this is it allows the manufacturer to supply
access control rules which reference devices with the SAME MUD URL.

So you can, for example say how peer devices from this manufacturer
can interact. (?)

On the other hand, it is called "my-controller" so I am wondering
whether this interpretation

is the intended one.

Very confused. Would appreciate some clarification.

Regards,

Ranga.,
-- 
M. Ranganathan

--001a11442fbc577d6a055b50222d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

I am reading through pr=
evious discussion on these topics and am still not quite "getting it&q=
uot;. So I request some explanation from the authors. My understanding is a=
s follows:

controllers : this is a place holder for things lik=
e DNS and DHCP where the address of the server is not known a-priori. 
<=
br>
my-controller - has me quite confused.=C2=A0 Here's the text f=
rom the latest draft:

   "my-contr=
oller:  Devices associated with the MUD URL of a device that
      the administrator admits." 

So my understanding on this is it allows the manufacturer to supply <=
br>access control rules which reference devices with the SAME MUD URL.
<=
/pre>
So you can, for example say how peer devi=
ces from this manufacturer can interact. (?)

On the other hand, it is called "my-controller" so I =
am wondering whether this interpretation
is the intended one.
Very confused. W=
ould appreciate some clarification.
=

Regards,

Ranga.,
-- 
M. Ranganathan




--001a11442fbc577d6a055b50222d--


From nobody Thu Oct 12 00:51: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 02CD7132F3F for ; Thu, 12 Oct 2017 00:51:45 -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 mhC84eSaw-tQ for ; Thu, 12 Oct 2017 00:51:44 -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 5C1DB132F2E for ; Thu, 12 Oct 2017 00:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5348; q=dns/txt; s=iport; t=1507794703; x=1509004303; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=y6aFG7xD6Xotv6tO59ao3uHeRkphIYv7gmFXWJ7/jVg=; b=DuUG+fZmFgzu3gKRA0i6SB0N3cVvKh7m8xsMmnjpo94dwgkZ1Q8pmbrx NnMQe0lSF3Oehifyfg8a8ihWkKg/BvqBo3T9j6YsZpz92eRFPYKeydDNB /fpCsxa0php7HWfUfZgH6E8xGJiAo3FI6GSJ/3VTeDMG2aOThl7nP6uDg A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQCKHt9Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhS+EIYsTkDCQcIU/ghIHA4U7AoUnFgECAQEBAQEBAWsohR4BBSN?= =?us-ascii?q?PFwsEFCoCAlcGAQwIAQGKGqk6gicnixMBAQEBAQEBAQIBAQEBAQEBAQEBAQ4Pg?= =?us-ascii?q?y2FbYJ/hG+DKYJhAQSKHAaXIIQ8giGODIQHh1qHLoctjjiBOSYKJ4EOMiEIHRW?= =?us-ascii?q?FXoIKPosiAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,365,1503360000";  d="asc'?scan'208,217";a="656310222"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2017 07:51:39 +0000
Received: from [10.61.111.29] (dhcp-10-61-111-29.cisco.com [10.61.111.29]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9C7pcDO012748; Thu, 12 Oct 2017 07:51:38 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References: 
From: Eliot Lear 
Message-ID: <5771bafe-d2f4-ca0b-d96d-2b6f43aa22a0@cisco.com>
Date: Thu, 12 Oct 2017 09:51:41 +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="CD8MmverBI5SVQPa9O06FffgHrR3GX2Af"
Archived-At: 
Subject: Re: [OPSAWG] Understanding MUD : Controller and my-controller
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, 12 Oct 2017 07:51:45 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CD8MmverBI5SVQPa9O06FffgHrR3GX2Af
Content-Type: multipart/mixed; boundary="tOL00kFRjcHVhngqwmvM00cn3gXjIj8db";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" , opsawg@ietf.org
Message-ID: <5771bafe-d2f4-ca0b-d96d-2b6f43aa22a0@cisco.com>
Subject: Re: [OPSAWG] Understanding MUD : Controller and my-controller
References: 
In-Reply-To: 

--tOL00kFRjcHVhngqwmvM00cn3gXjIj8db
Content-Type: multipart/alternative;
 boundary="------------7774F29268F796F5BECFFF2A"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------7774F29268F796F5BECFFF2A
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ranga,


On 10/12/17 4:16 AM, M. Ranganathan wrote:
> Hello,
>
> I am reading through previous discussion on these topics and am still
> not quite "getting it". So I request some explanation from the
> authors. My understanding is as follows:
>
> controllers : this is a place holder for things like DNS and DHCP
> where the address of the server is not known a-priori.
>
> my-controller - has me quite confused.=C2=A0 Here's the text from the
> latest draft:
>
>    "my-controller:  Devices associated with the MUD URL of a device tha=
t
>       the administrator admits."=20
>
> So my understanding on this is it allows the manufacturer to supply=20
> access control rules which reference devices with the SAME MUD URL.
> So you can, for example say how peer devices from this manufacturer can=
 interact. (?)

The way I like to look at it is this:

Peer devices =3D "manufacturer" or "same-manufacturer", and it is the
manufacturer of the device that specifies class admittance by default.=C2=
=A0
More intended as many-to-many.=C2=A0 "controller" and "my-controller" are=

more focused on a one-to-many relationship where class admittance is
handled by the administrator.

Does that help?

Eliot


--------------7774F29268F796F5BECFFF2A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Ranga,

    

    

    
On 10/12/17 4:16 AM, M. Ranganathan
      wrote:

    

    

      
      

        

          

            
Hello,

              

            

            I am reading through previous discussion on these topics and
            am still not quite "getting it". So I request some
            explanation from the authors. My understanding is as
            follows:

            

          

          controllers : this is a place holder for things like DNS and
          DHCP where the address of the server is not known a-priori. 
          

        

        my-controller - has me quite confused.=C2=A0 Here's the text from=
 the
        latest draft:

        

        
   "my-controller:  Devices associat=
ed with the MUD URL of a device that
      the administrator admits."=20



        
So my understanding on this is it al=
lows the manufacturer to supply=20
access control rules which reference devices with the SAME MUD URL.


        
So you can, for example say how peer=
 devices from this manufacturer can interact. (?)


      

    

    

    The way I like to look at it is this:

    

    Peer devices =3D "manufacturer" or "same-manufacturer", and it is the=

    manufacturer of the device that specifies class admittance by
    default.=C2=A0 More intended as many-to-many.=C2=A0 "controller" and
    "my-controller" are more focused on a one-to-many relationship where
    class admittance is handled by the administrator.

    

    Does that help?

    

    Eliot

    

  


--------------7774F29268F796F5BECFFF2A--

--tOL00kFRjcHVhngqwmvM00cn3gXjIj8db--

--CD8MmverBI5SVQPa9O06FffgHrR3GX2Af
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

iQEcBAEBCAAGBQJZ3x8NAAoJEIe2a0bZ0nozCGgIAK+0zV7Q05vjTY8jts/g9ASj
AKK+oXu6iaNUViZosyQ8vTD9G8stFltEwJB/HygZxxqYpRYgFTSIYsbhotEJL8gD
0x1CFbkRZ3LXTgUQjxwUofUdqQGVuFVbxvvqvIgLutM31xkUTsIcyIIInfdfPHXu
qpkPWr76iAGwd2Cc+o7G+tew1M+ad6jKzqxFbDCJs/5Rjh3rFZ27gS3R2F/9Dfsc
e2FrW+JJkWq9VLeeP3dCjUbJPPvDQlQhMmmEm6WBEEBAMTw1ckPHEU2HbmH4+J8N
T0+9K5D95xXHsD4tNLD4jv9GDPRX4dYSqR/4QrTj6sHYv76sOdu7R8YVPrwrwQM=
=M4H8
-----END PGP SIGNATURE-----

--CD8MmverBI5SVQPa9O06FffgHrR3GX2Af--


From nobody Thu Oct 12 07:02:22 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 B95731344D2; Thu, 12 Oct 2017 07:02:20 -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.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150781694071.16824.16882705066948798700@ietfa.amsl.com>
Date: Thu, 12 Oct 2017 07:02:20 -0700
Archived-At: 
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-06.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, 12 Oct 2017 14:02:21 -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-06.txt
	Pages           : 78
	Date            : 2017-10-12

Abstract:
   For the sake of network automation and the need for programming
   Network Address Translation (NAT) function in particular, a data
   model for configuring and managing the NAT is essential.  This
   document defines a YANG module for the NAT function.

   NAT44, Network Address and Protocol Translation from IPv6 Clients to
   IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit
   Address Mappings for Stateless IP/ICMP Translation (SIIT EAM), 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-06
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat-yang-06


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

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


From nobody Thu Oct 12 07:13: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 23A8F1344F3 for ; Thu, 12 Oct 2017 07:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.398
X-Spam-Level: 
X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 KFrhT3rregXL for ; Thu, 12 Oct 2017 07:13:23 -0700 (PDT)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA7513451A for ; Thu, 12 Oct 2017 07:13:22 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 98C7E180352; Thu, 12 Oct 2017 16:13:21 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 71F151A0068; Thu, 12 Oct 2017 16:13:21 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Thu, 12 Oct 2017 16:13:19 +0200
From: 
To: "opsawg@ietf.org" 
CC: Qin Wu , Senthil Sivakumar , Suresh Vinapamula , JACQUENET Christian IMT/OLN 
Thread-Topic: New Version Notification for draft-ietf-opsawg-nat-yang-06.txt
Thread-Index: AQHTQ2K5oECyfHfAiUGvFia9FzuBL6LgP3JQ
Date: Thu, 12 Oct 2017 14:13:19 +0000
Message-ID: 
References: <150781694088.16824.7345333598884165729.idtracker@ietfa.amsl.com>
In-Reply-To: <150781694088.16824.7345333598884165729.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.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-nat-yang-06.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, 12 Oct 2017 14:13:32 -0000

RGVhciBhbGwsIA0KDQpUaGUgbmV3IHZlcnNpb24gZml4ZXMgc29tZSBjb3NtZXRpYyBpc3N1ZXMg
KG1haW5seSwgaW5kZW50YXRpb24gb2YgdGhlIFlBTkcgbW9kdWxlKSBhbmQgcG9pbnRzIHRvIFlB
TkcxLjEgUkZDIGFzIHBlciBhIGNvbW1lbnQgcmVjZWl2ZWQgZnJvbSBNYWhlc2ggSmV0aGFuYW5k
YW5pLiANCg0KV2UgYXJlIHdhaXRpbmcgZm9yIHRoZSB5YW5nIGRvY3RvcnMgcmV2aWV3LiANCg0K
Q2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGlu
dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10N
Cj4gRW52b3nDqcKgOiBqZXVkaSAxMiBvY3RvYnJlIDIwMTcgMTY6MDINCj4gw4DCoDogUWluIFd1
OyBTZW50aGlsIFNpdmFrdW1hcjsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgU3VyZXNoDQo+
IFZpbmFwYW11bGE7IEpBQ1FVRU5FVCBDaHJpc3RpYW4gSU1UL09MTg0KPiBPYmpldMKgOiBOZXcg
VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLTA2LnR4
dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQt
eWFuZy0wNi50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNb2hhbWVk
IEJvdWNhZGFpciBhbmQgcG9zdGVkIHRvIHRoZQ0KPiBJRVRGIHJlcG9zaXRvcnkuDQo+IA0KPiBO
YW1lOgkJZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmcNCj4gUmV2aXNpb246CTA2DQo+IFRpdGxl
OgkJQSBZQU5HIERhdGEgTW9kZWwgZm9yIE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdGlvbiAoTkFU
KQ0KPiBhbmQgTmV0d29yayBQcmVmaXggVHJhbnNsYXRpb24gKE5QVCkNCj4gRG9jdW1lbnQgZGF0
ZToJMjAxNy0xMC0xMQ0KPiBHcm91cDoJCW9wc2F3Zw0KPiBQYWdlczoJCTc4DQo+IFVSTDogICAg
ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1v
cHNhd2ctDQo+IG5hdC15YW5nLTA2LnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LQ0KPiB5YW5nLw0KPiBI
dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3Bz
YXdnLW5hdC15YW5nLTA2DQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLQ0KPiBuYXQteWFuZy0wNg0KPiBEaWZm
OiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt
b3BzYXdnLW5hdC0NCj4geWFuZy0wNg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIEZvciB0aGUgc2Fr
ZSBvZiBuZXR3b3JrIGF1dG9tYXRpb24gYW5kIHRoZSBuZWVkIGZvciBwcm9ncmFtbWluZw0KPiAg
ICBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRpb24gKE5BVCkgZnVuY3Rpb24gaW4gcGFydGljdWxh
ciwgYSBkYXRhDQo+ICAgIG1vZGVsIGZvciBjb25maWd1cmluZyBhbmQgbWFuYWdpbmcgdGhlIE5B
VCBpcyBlc3NlbnRpYWwuICBUaGlzDQo+ICAgIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIG1vZHVs
ZSBmb3IgdGhlIE5BVCBmdW5jdGlvbi4NCj4gDQo+ICAgIE5BVDQ0LCBOZXR3b3JrIEFkZHJlc3Mg
YW5kIFByb3RvY29sIFRyYW5zbGF0aW9uIGZyb20gSVB2NiBDbGllbnRzIHRvDQo+ICAgIElQdjQg
U2VydmVycyAoTkFUNjQpLCBDdXN0b21lci1zaWRlIHRyYW5zTEFUb3IgKENMQVQpLCBFeHBsaWNp
dA0KPiAgICBBZGRyZXNzIE1hcHBpbmdzIGZvciBTdGF0ZWxlc3MgSVAvSUNNUCBUcmFuc2xhdGlv
biAoU0lJVCBFQU0pLCBhbmQNCj4gICAgSVB2NiBOZXR3b3JrIFByZWZpeCBUcmFuc2xhdGlvbiAo
TlBUdjYpIGFyZSBjb3ZlcmVkIGluIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiANCj4gDQo+IA0KPiBQ
bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg
dGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk
aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNy
ZXRhcmlhdA0KDQo=


From nobody Thu Oct 12 09:17:51 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 AB84C1332CE for ; Thu, 12 Oct 2017 09:17:49 -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 u86_3joE-UPD for ; Thu, 12 Oct 2017 09:17:48 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB23E124F57 for ; Thu, 12 Oct 2017 09:17:47 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id t69so14636405wmt.2 for ; Thu, 12 Oct 2017 09:17:47 -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=RGhQAiKMs5g/hK1Lj+MvJfYGBpaFL0jycFA6RNr8PIE=; b=cDp21VJrznv5BkPcC3YxBiltNym1yMs3DQFVsu/MC5v5Ew3o+uHbOi8x7EO44MuDn5 lmUzZXRlTS8LIlqMwR/ybMzfuTuKReOLR3BWxFYUwDJdC25fHe1bxizZDvC1ZflIfFlj uhwIoLG640ddW6yDz4zBcXiYJjGp0f589amp0qJ9/IZblSVaUDBAM2M93envJ1tfunV3 UjhqsRH4vTQWtTT6i5qmw/3t+ZKbL+/ZxkcL/tol1HKttNbOrfbXf4XKI/hpDEW5ZoPH v0TTCbyEm2/6eRgZd/QJP5V5bN8YSkARp1vlFeNr2yR3wecPsq2fUkFRMDKX35o5B2Ha 1S1w==
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=RGhQAiKMs5g/hK1Lj+MvJfYGBpaFL0jycFA6RNr8PIE=; b=hUDCHYtYIl3uiQ+JVrbEGftMLl0ohd/sA0A0Epk4iCGfCZv1OTYYRCp4qvGqgTMIdg dHF6rljHxZAjpI6zSci3pjt2Ueot99lOvKQAcewzVa3JfLK7Vy3OsTqRMu9s95wDjzxV a/IjE07T/cRmUU+xF3w1+xYo1O0828/8KVBSeTTXdgN+/z7+E/PS+IjWMRSmigFxAoEF L62YNmVzsHhHGvX4NLQBfJXUK6RAb04mvyKJHCIZA5p7qVxKRNmtWibQznDy5YdOTdK4 alTWdJltH8repwy5+HUqIkEY3Ee8DTousQ5heC068qNONKJ+oUERn5MueIKsdpkVUMoW jW4Q==
X-Gm-Message-State: AMCzsaX0csvik4CQTBV3g0xmyFRqyRhSISH+eV2IB+B5vZjEoVStUpQd ljcsKBHo8l6+YJ9RFsNeRovDmYT/5FSBMuR8YXQ=
X-Google-Smtp-Source: AOwi7QBPB8i2p2ieDGX41XSg/CFmGlMJTmrvjYMOMC7aHFtriJtc4Ae8yR3JOIMBRNSvH/85NgDpiALOiOzWRItlA8w=
X-Received: by 10.223.131.226 with SMTP id 89mr2790744wre.227.1507825066218; Thu, 12 Oct 2017 09:17:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Thu, 12 Oct 2017 09:17:03 -0700 (PDT)
In-Reply-To: <5771bafe-d2f4-ca0b-d96d-2b6f43aa22a0@cisco.com>
References:  <5771bafe-d2f4-ca0b-d96d-2b6f43aa22a0@cisco.com>
From: "M. Ranganathan" 
Date: Thu, 12 Oct 2017 12:17:03 -0400
Message-ID: 
To: Eliot Lear 
Cc: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0d1fc274d158055b5be16f"
Archived-At: 
Subject: Re: [OPSAWG] Understanding MUD : Controller and my-controller
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, 12 Oct 2017 16:17:50 -0000

--94eb2c0d1fc274d158055b5be16f
Content-Type: text/plain; charset="UTF-8"

Hi Eliot,

On Thu, Oct 12, 2017 at 3:51 AM, Eliot Lear  wrote:

> Hi Ranga,
>
> On 10/12/17 4:16 AM, M. Ranganathan wrote:
>
> Hello,
>
> I am reading through previous discussion on these topics and am still not
> quite "getting it". So I request some explanation from the authors. My
> understanding is as follows:
>
> controllers : this is a place holder for things like DNS and DHCP where
> the address of the server is not known a-priori.
>
> my-controller - has me quite confused.  Here's the text from the latest
> draft:
>
>    "my-controller:  Devices associated with the MUD URL of a device that
>       the administrator admits."
>
>
> So my understanding on this is it allows the manufacturer to supply
> access control rules which reference devices with the SAME MUD URL.
>
> So you can, for example say how peer devices from this manufacturer can interact. (?)
>
>
> The way I like to look at it is this:
>
> Peer devices = "manufacturer" or "same-manufacturer", and it is the
> manufacturer of the device that specifies class admittance by default.
> More intended as many-to-many.  "controller" and "my-controller" are more
> focused on a one-to-many relationship where class admittance is handled by
> the administrator.
>
> Does that help?
>
> Eliot
>

Thanks. That sorted some confusion out but I am still wondering why, for
example, BOTH "controller" and "my-controller" need to exist in the
specification.

Regards,

Ranga



-- 
M. Ranganathan

--94eb2c0d1fc274d158055b5be16f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Eliot,

On Thu, Oct 12, 2017 at 3:51 AM, Eliot Lear =
<lear@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Hi Ranga,

    

    

    
On 10/12/17 4:16 A=
M, M. Ranganathan
      wrote:

    

    

     =20
      

        

          

            
Hello,

              

            

            I am reading through previous discussion on these topics and
            am still not quite "getting it". So I request some
            explanation from the authors. My understanding is as
            follows:

            

          

          controllers : this is a place holder for things like DNS and
          DHCP where the address of the server is not known a-priori. 

          

        

        my-controller - has me quite confused.=C2=A0 Here's the text fr=
om the
        latest draft:

        

        
   "my-cont=
roller:  Devices associated with the MUD URL of a device that
      the administrator admits."=20



        
So my understand=
ing on this is it allows the manufacturer to supply=20
access control rules which reference devices with the SAME MUD URL.


        
So you can, for =
example say how peer devices from this manufacturer can interact. (?)


      

    

    

    The way I like to look at it is this:

    

    Peer devices =3D "manufacturer" or "same-manufacturer&qu=
ot;, and it is the
    manufacturer of the device that specifies class admittance by
    default.=C2=A0 More intended as many-to-many.=C2=A0 "controller&qu=
ot; and
    "my-controller" are more focused on a one-to-many relationshi=
p where
    class admittance is handled by the administrator.

    

    Does that help?

    

    Eliot

Thanks. T=
hat sorted some confusion out but I am still wondering why, for example, BO=
TH "controller" and "my-controller" need to exist in th=
e specification.

Regards,

Ranga 



-- 
M. Ranganathan




--94eb2c0d1fc274d158055b5be16f--


From nobody Thu Oct 12 09:55: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 CF57613454C for ; Thu, 12 Oct 2017 09:55:47 -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 Wkf12ap4EyWu for ; Thu, 12 Oct 2017 09:55: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 EA997124F57 for ; Thu, 12 Oct 2017 09:55:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4168; q=dns/txt; s=iport; t=1507827342; x=1509036942; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=H1PYyNWsKGQBiAGpXs6yUL5zSE61a+weG5+ZXgF/HX0=; b=hCWUcVb2DoH546qmW963kYB17mSZo4uN3OBG8vRU+pAE8awKBaeeA9b0 IYhBfb5c6+AO9bmBoqdgvdhH6w4omGTxwxZtZtuyOvSq1Mi8UoSROvjP9 L4+n+FzH73AvYNXjj7QDcTHwzAB03uASBWDPbL47xhkph0zlYGyC7Bksr g=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQDwnd9Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhS+EIYsTkDGQcIdRBwOFOwKFABUBAgEBAQEBAQFrKIUeAQUjVhA?= =?us-ascii?q?LBAETKgICVwYNCAEBihqrHIInJ4sSAQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+DL?= =?us-ascii?q?YVtgn+IGIJhBYoihySPfoQ8giGODYtihy6Va4E5NSKBDjIhCB0VhV6CCj6MDQE?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.43,366,1503360000";  d="asc'?scan'208,217";a="697984314"
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; 12 Oct 2017 16:55:39 +0000
Received: from [10.61.87.1] (ams3-vpn-dhcp5890.cisco.com [10.61.87.1]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9CGtdJh031678; Thu, 12 Oct 2017 16:55:39 GMT
To: "M. Ranganathan" 
Cc: opsawg@ietf.org
References:  <5771bafe-d2f4-ca0b-d96d-2b6f43aa22a0@cisco.com> 
From: Eliot Lear 
Message-ID: 
Date: Thu, 12 Oct 2017 18:55:41 +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="Be2lxKtCp6EGvj1p6Q0EUM993tCRDTR74"
Archived-At: 
Subject: Re: [OPSAWG] Understanding MUD : Controller and my-controller
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, 12 Oct 2017 16:55:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Be2lxKtCp6EGvj1p6Q0EUM993tCRDTR74
Content-Type: multipart/mixed; boundary="j38dCobbR9FVUqMJPAofjos3w1UrrMh26";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" 
Cc: opsawg@ietf.org
Message-ID: 
Subject: Re: [OPSAWG] Understanding MUD : Controller and my-controller
References: 
 <5771bafe-d2f4-ca0b-d96d-2b6f43aa22a0@cisco.com>
 
In-Reply-To: 

--j38dCobbR9FVUqMJPAofjos3w1UrrMh26
Content-Type: multipart/alternative;
 boundary="------------401553262BAF20AC0B1ACE98"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------401553262BAF20AC0B1ACE98
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 10/12/17 6:17 PM, M. Ranganathan wrote:
>
> Thanks. That sorted some confusion out but I am still wondering why,
> for example, BOTH "controller" and "my-controller" need to exist in
> the specification.

"my-controller" has an inferred name, if you will, of the current MUD
URL, and no other name is required.=C2=A0 And so administrators populate =
the
field for each device that hits the network.=C2=A0 "controller" takes a
name.=C2=A0 And so the idea is that if you a manufacturer have many devic=
es
that might all use the same controller, you can specify that name, and
the administrator only needs to populate the class once.=C2=A0 Some
governance required, of course.

Eliot

--------------401553262BAF20AC0B1ACE98
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    

    
On 10/12/17 6:17 PM, M. Ranganathan
      wrote:

    

    

      
      


        

          

            
Thanks. That sorted some confusion out but I am still
              wondering why, for example, BOTH "controller" and
              "my-controller" need to exist in the specification.

            

          

        

      

    

    

    "my-controller" has an inferred name, if you will, of the current
    MUD URL, and no other name is required.=C2=A0 And so administrators
    populate the field for each device that hits the network.=C2=A0
    "controller" takes a name.=C2=A0 And so the idea is that if you a
    manufacturer have many devices that might all use the same
    controller, you can specify that name, and the administrator only
    needs to populate the class once.=C2=A0 Some governance required, of
    course.

    

    Eliot

  


--------------401553262BAF20AC0B1ACE98--

--j38dCobbR9FVUqMJPAofjos3w1UrrMh26--

--Be2lxKtCp6EGvj1p6Q0EUM993tCRDTR74
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

iQEcBAEBCAAGBQJZ356OAAoJEIe2a0bZ0nozTWsIAINtExmmmx0Fwa9MvD4qge4i
5gHv0IR3jOueamr+ccoIidkhGBAdUchU6w1/E+6lgbYIUclN5qZxht7ffY78TAYd
KjWHtW9ngqpjsePBgkZNhk/R+7Jex6d3hGKgJBQiHLpnQGAyiQEt6iFdb24eChbW
9JdEs0qqmeVYynBOLS4A7mfhyIglaAvnLpgAK+NoqjgGgrY4G62vIXPiKofWS7Bv
9mK0YgM1HbTYpOHwPlzdmbeE02esze8+PccpWt/IL/Oiw/e7zjSrqjFflH/CYLSO
p6H45/IVgwKU2iObBXhDW9pmemmfaHoAfSIJejBuymoeeQuQxt/Bpob9uH4jN1s=
=moG9
-----END PGP SIGNATURE-----

--Be2lxKtCp6EGvj1p6Q0EUM993tCRDTR74--


From nobody Thu Oct 12 10:17:23 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 AE8A713453E; Thu, 12 Oct 2017 10:17:16 -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 6wLEYd2DzlNo; Thu, 12 Oct 2017 10:17:13 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B57132F8F; Thu, 12 Oct 2017 10:17:13 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9CHH9uu007497; Thu, 12 Oct 2017 18:17:09 +0100
Received: from 950129200 (62.192.112.87.dyn.plus.net [87.112.192.62]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9CHH83l007487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Oct 2017 18:17:09 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'David Sinicrope'" , 
Cc: , , 
References: <34AB742F-0243-4CF5-8151-281BCA3BB7CF@ericsson.com>
In-Reply-To: <34AB742F-0243-4CF5-8151-281BCA3BB7CF@ericsson.com>
Date: Thu, 12 Oct 2017 18:17:09 +0100
Message-ID: <084b01d3437d$f0327d10$d0977730$@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: AQH6yLgqAmxoV+gANNp34JDHXIfw+6KP4Qig
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23392.001
X-TM-AS-Result: No--19.055-10.0-31-10
X-imss-scan-details: No--19.055-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wvHkpkyUphL9TJDl9FKHbrm638ZUY6gSdyVU OOkPF4hbBGHPy9PpDUh4J+F+nqIUSNUEA09P1mY/c+QhWKJM04NhjS00Z2+WLU/N5GQtssoC3L0 SnaIVb7hfwxjJhS3GbIGrQg5kz5SoYiS5IMZgPcONZ7kc4Uq+40Crr/LkAQ461OTz8YWsg5SYpu G7kpoKR8e2xTNP7U64dWrZ6C3jAGitGUuyWCB/KsOD5TU1KZy5pi5i27frSFOPIPPVLx5Rtg5Zz UX+YJzfFaT/zntCzjAlYI1Qi7KVJ3KQyUwGFiMJLlyW+UelYWOvrpPfLE66xskHbDtTC/XboVrE FxmlTIDGyuuboE0RzhaXhJtxdMk6vhi/DX1QMrVfxqgX6occnS/6e8w1Q13caHlOtIny1duEwws x2IAcGXiUD2NbzXTfDcQPubYoXm8Ibkdf1w8uOwRH1Nr7oERdUbJBJIpagZISrvYaoiE5utwg9v uv5fWjVNsNnenqm1j+Cn7eSAAUb3lvnAE/MQ9TNcoW2wO1ntMTcFr9nQa5pLcRfEgMfP0ZRBgjL K9tEuomcMZYQXkjI7Vi+9nmDeeSh6jbn8Vo0UuzI1v7J4hECg0YtI32OoC94aROJEypr9yJNKc+ hzWyykFwgX31JHjy2qF6wZK5j6YqPRzvSBurD1gowyUWHgGdhV0srjoqtx8Z+8e2ctEi28IxU1Z PgJH8XLrL2FfTeyzQkvFqSOg/cm6NplOOXbk0MIiU395I8H1A8JZETQujwpUyTIJurbdhYksMJ9 ygbgVwpFGcff4EArMYIQhZtaCqZSU6HajahM6eAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt
Archived-At: 
Subject: Re: [OPSAWG] [RTG-DIR] RtgDir Review: draft-ietf-opsawg-service-model-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: Thu, 12 Oct 2017 17:17:17 -0000

Thanks David,

> Abstract: "... used within the IETF...". Wouldn't the document serve =
better to
> describe how the models could/are used by the industry including =
within SDN?
> Several of these models are used by other SDOs for their work in e.g., =
providing
> network architecture, equipment requirements, orchestration, OAM and
> management to support and provide the service. I would think that the =
matter
> of how these are used by the IETF would be much to narrow a view.

The IETF does not, I think, strive to speak for other SDOs. While it can =
speak for a slice of the industry, it is only that slice that =
participates at the IETF. So what we do best is describe what we have =
built.

Of course, if other SDOs like what we have done, they can reference it.

> Intro para 3, last sentences - This text dates itself. It would =
suffice to note that
> the models may be used in these environments regardless of the time =
frame.=20
> (e.g., drop =E2=80=9Ceventually)

Hmmm, you reviewed -03? So this would be the last sentence of para 4.
You are right that this could become dated.
Don't mind making that change.

> Intro para 5 last sentence - customer - Provider Interface needs a =
forward
> reference or brief definition. =E2=80=A8

Perhaps we should say "through the interface between the customer and =
the provider."  There is nothing clever here. Just that there is an =
interface.

> Intro para 6. - "described to" or "subscribed to"? =E2=80=A8

We meant "described to". Is there a problem with describing a service to =
a customer?

> Intro para 6 - does it describe the service or the attributes of the =
service. I'm not sure
> a service model describes the service operation.  Add the words =
"attributes of the" =E2=80=A8

You added the word "operation".
How would you describe a service except through the attributes of that =
service. But "describing the attributes" conveys (to me) something less =
than describing the service.

> Sec 1, para 4 - =E2=80=9C... within the IETF...=E2=80=9D but the =
document also discusses the MEF. Need
> to make statement more general. =E2=80=A8

Weeeeeell, two brief paragraphs in a 22 page document hardly makes MEF =
the focus of this work. I think the paragraph you quote from accurately =
describes this document.

> Definition of Network Operator - change to read "... other network =
services."
> Not sure other non-network services are intended. =E2=80=A8

The text reads...
|   Network Operator:  This term is used to refer to the company that
|     owns and operates one or more networks that provide Internet
|     connectivity services and/or other services.

Not sure where you found "other non-network services.=20

> Definition of Customer: suggest change =E2=80=9Cpurchases=E2=80=9D to =
=E2=80=9Csubscribes=E2=80=9D

The principal two definitions of "subscribe" are:

| to pledge, as by signing an agreement, to give or pay money as a
| contribution, gift, or investment=20

...and...

| to give or pay money in fulfillment of such a pledge.=20

That'll be "purchase" :-)

> Definition of Customer: Excludes residential customer... why?

I read and re-read. I don't find that exclusion.

But it is reasonable to infer that residential customers are peripheral =
to the discussion. The type of service purchased by a residential =
customer is very simple, but is still covered by the discussion as it is =
only a scaled down version of some types of serviced purchased by =
commercial organisations.

> Definition of Service: - Would help to give titles of RFCs, but may =
not be
> aligned with conventions.

Hmmm, no, I think the way this is presented is the normal IETF way.

> Definition of Data Model: Refers to information model and =
relationships
> between managed objects.  Should it be just objects?

The definition of Data Model quoted from RFC 3444 only has meaning when =
presented with the definition of Information Model. And, of course, we =
can't change the quoted text.

> Definition of Service model - in IETF it's a data model. In other =
groups? E.g., ITU? It
> could be an information model.

You may be right. I don't know. Personally, I might be interested in =
finding out, but surely it is not the job of the IETF to attempt to =
interpret and document other SDO's views?

> Definition of Customer Service Model: Not sure example of order =
fulfillment
> system illustrates a human.  Is there a better example of a human =
consumer?

I don't see the problem. An order fulfillment system in network =
management often (usually) has a human interface so that actions can be =
confirmed. Do you have any suggestions?

> Definition of Service model - "... a portable way". Portable way? or =
do
> you mean more agnostic to deployment architecture and equipment?

Yes, that is the usual meaning. We can spell it out.

> Last para just before section 3. - while a service model as a whole =
may not be
> intended to be sent to network devices, parts of it may be sent to =
network
> equipment. This could be clarified.

I think you are saying that one model may contain modules used in other =
models.

> Sec 3, 2nd para - =E2=80=9C... choice for whoever specifies the =
model.=E2=80=9D And the next
> sentence notes the IETF. Is the choice that of the organization where =
the
> model is specified, the individuals specifying the model or some =
combination
> of both?

The "whoever" is individuals or SDOs. However, individuals participating =
in the IETF use the mechanisms adopted by the IETF.

> Sec 3, para 1&2 - these two paragraphs don=E2=80=99t add to the =
discussion and
> distract from para 3 where the actual discussion starts.

Unless there is a big problem here, we like the text.

> Sec 3, para 3, last sentence - =E2=80=9C... direct human =
interaction...=E2=80=9D. This crosses
> from implementation to business process and should be noted. Add a
> sentence to the effect of =E2=80=9CWhere direct human interaction =
comes into
> play, interface interactions may become realized via business =
practices
> and must account for some margin of error, thus raising the priority =
for
> automated, deterministic interfaces.=E2=80=9D

That works.

> Figure 1 -move figure to the definition of customer service model

Added forward reference.

> Sec 3, para 8, last sentence - distinction of modules and models. Good
> description of modules, but needs to be contrasted vs models.

The description of "module" is provided by using the term "model". Are =
you proposing we should also add a definition of "model" using the term =
"module"? Wouldn't that just be saying the same thing only backwards.

> Sec 3, para 7 =E2=80=93=E2=80=9C The practicality=E2=80=A6=E2=80=9D  =
these last two paragraphs highlight a=20
> debate and the different points of view. This is different from the =
=E2=80=9Cbig
> picture=E2=80=9D usage description in the paragraphs above. =
Subsections (e.g.,=20
> =E2=80=9CThe Big Picture=E2=80=9D and =E2=80=9CPractically =
Speaking=E2=80=9D) would help call out the
> transition in thinking & flow.

OK

> Sec 4, heading or para 1, 1st sentence - =E2=80=9CSDN=E2=80=9D has =
been spelled out
> previously in the introduction but given the elementary level of
> explanation here, e.g., =E2=80=9Ccontroller=E2=80=9D, it may be worth =
spelling it out again.

OK

> Sec 4, para 2, 1st sentence - remove the =E2=80=9CBut=E2=80=9D or =
clarify what the statement
> is contradicting or juxtaposing.

OK

> Sec 4, para 2, 2nd sentence =E2=80=9C That is,=E2=80=A6=E2=80=9D - =
This statement should be clarified.=20
> Inherently the technology available to deliver a service will =
influence the
> functions that a customer can request. E.g., an Ethernet connectivity =
service
> will be defined in terms of MAC addresses, etc. I think the point =
trying to be=20
> made here is that the underlying technology specific details should =
not, or to
> the lowest extent possible, be reflected in customer service requests. =
E.g.,=20
> one should not have to specify switch or router ids, IP addresses or =
MAC
> addresses for a TV service. =E2=80=A8See section 7 of the document

I think you are mistaken. A customer can request *anything*. However, =
the service provider may not be able to deliver it :-)

But I see what you mean about this text.

OLD
   But a customer's service request is (or should be) technology-
   agnostic.  That is, the technology that the network operator has
   available to deliver the service should not influence the behavior
   and functions that a customer requests.  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.
NEW
   A customer's service request is (or should be) technology-
   agnostic.  That is, a customer is unware of the technology that the
   network operator has available to deliver the service and so the=20
   customer does not make requests specific to the underlying=20
   technology, but is limited to making requests specific to the
   service that is to be delivered.  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.
END

> Sec 4, para 2 & 3 - wouldn=E2=80=99t this point about a =
Service/Network split be true
> outside of the SDN context as well? Why would this be limited to SDN?

The discussion is limited to SDN simply because we're inside Section 4 =
("Service Models in an SDN Context").

> Sec 4, Figure 3 - could the figure show an orchestrator interacting
> directly to a network element?=20

That is possible, but surely a distraction and a dangerous diversion =
into debates about the architecture of an SDN system.
Apart from completeness, does it add anything to the document?

> Sec 5, bullet 1 - In the terminology section, =
=E2=80=9CService=E2=80=9D is defined as a connectivity
> service. For purposes of this document then it should not be confused =
with
> higher layer services. The =E2=80=9Ccustomer=E2=80=9D for this =
definition *is* aware of technology
> specific parameters and constraints of the connectivity service they =
are subscribing
> to. The cause of the confusion, and this is an age old problem, is =
that =E2=80=9Cservice=E2=80=9D is a
> recursive term. That is, a consumer/client of one level of service =
(e.g., Ethernet
> connectivity) is the provider/server of another (e.g., Internet =
access) for higher
> layer use (e.g., TV service) =E2=80=A8Modeling methods (G.805) have =
been established to
> describe the client/server relationship.

I agree with a lot of this. But you need to be careful talking about =
"technology of the service". Yes, the service is technology-specific =
(e.g., give me an Ethernet connection from here to there"), but, no, the =
service is technology-agnostic (don't care if this is native Ethernet, =
EoMPLS, EoATM, or whatever, and don't care whether OSPF, ISIS, BGP, or =
widgetFlow is used to set up the service).

That said, not sure what you are asking for.

> Sec 5, bullet 2 - =E2=80=9Ccompletely=E2=80=9D -> might want to tone =
this down a bit, to=20
> accommodate exceptions noted elsewhere in the document. While kept
> to a minimum, network operation is not *completely* out of scope when
> discussing service between a customer and network operator. E.g., Part
> of a service could be routing of the connect to avoid geopolitical =
borders.
> (Noted on the very next page) another example is, Fault notification =
and
> protection mechanisms may be discussed. =E2=80=A8The statement here =
seems to
> contradict the definition of Customer Service Model in the terminology
> section where it states that =E2=80=9CExcept where specific technology =
details
> (such as encapsulations, or mechanisms applied on access links) are =
directly
> pertinent to the customer, customer service models are technology =
agnostic
> so that the customer does not have influence over or knowledge of how =
the
> network operator engineers the service.=E2=80=9D =E2=80=A8Perhaps use =
=E2=80=9Cnormally=E2=80=9D vs
> =E2=80=9Ccompletely=E2=80=9D

OK2

> Sec 5, bullet 2 - providing detail about how the service is offered =
could
> actually be considered a security vulnerability.

OK

> Sec 5, bullet 4 - give some examples of =E2=80=9Ccommercial =
terms=E2=80=9D.

OK

> Sec 5, bullet 5 - give an example of the =E2=80=9Cfine grained =
details=E2=80=9D

We already have "how services are allowed to vary, by how much, and how =
often"

> Sec 6.2 list of drafts - will these works in progress be stable or
> final before publication?

I suspect they will still be works in progress, but who can tell the =
wonders of the IETF process.

> Sec 6.4, para 2,3rd sentence - the statement on it being impractical =
to
> fit IETF models into MEF models seems a bit broad. Has anyone looked
> into this?=20

Oh yes. :-) Some energy was expended looking at LSO.

Well, we have "may be impractical" so the door is open.

Thanks again,
Adrian


From nobody Thu Oct 12 10:20:26 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 1FE3413453E; Thu, 12 Oct 2017 10:20:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joseph Salowey 
To: 
Cc: opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-service-model-explained.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150782881408.16793.934516939914088050@ietfa.amsl.com>
Date: Thu, 12 Oct 2017 10:20:14 -0700
Archived-At: 
Subject: [OPSAWG] Secdir telechat review of draft-ietf-opsawg-service-model-explained-04
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, 12 Oct 2017 17:20:14 -0000

Reviewer: Joseph Salowey
Review result: Ready

Document revision addressed my comments.  


From nobody Thu Oct 12 14:43:08 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 CD70F13219F; Thu, 12 Oct 2017 14:43:01 -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.63.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150784458181.16735.3220154591032271755@ietfa.amsl.com>
Date: Thu, 12 Oct 2017 14:43:01 -0700
Archived-At: 
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-service-model-explained-05.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, 12 Oct 2017 21:43:02 -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-05.txt
	Pages           : 23
	Date            : 2017-10-12

Abstract:
   The IETF has produced many modules in the YANG modeling language.
   The majority of these modules are used to construct data models to
   model devices or monolithic functions.

   A small number of YANG modules have been defined to model services
   (for example, the Layer 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 modules 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-05
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-model-explained-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-model-explained-05


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

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


From nobody Thu Oct 12 15:49:07 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 81E9A133245 for ; Thu, 12 Oct 2017 15:49:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level: 
X-Spam-Status: No, score=-2.697 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, WEIRD_PORT=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 c6S3tRqPyhxY for ; Thu, 12 Oct 2017 15:49:04 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 3F0E8132D96 for ; Thu, 12 Oct 2017 15:49:04 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id u138so17213296wmu.4 for ; Thu, 12 Oct 2017 15:49:04 -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=XAJqL2vZ5PvRRhf7QVYuoJ9nB9oW8d8eVn9cQwybobw=; b=l5NiBax/ZgDCm+avn75fToH5foJKMJBLq7QeDH/cBQxUszQPtG3OHzFn0NB9U0wDnt rYJbhD/va0PMxXH4vhD9ljuLOUIOdKeg1LOpn4myaIaOD2QBF+Vwme58iyzjSJWH38VT pKlI7E54Zryw7v+AbCJkPjsNzFUkmwm4wV8m28jIqcoTl0SkmqEEkg6BX9lP+WZ4Fwc5 WuG1GAbcbt0lO1rellvmuRVHNWi8C8qYr24VPdudY2RaMPQMNDdOjDhmsvtU53B2p/kt lb4QDvL49z9dD+21IYQ4pTlQUUHv3PJzq8w5l/hjMv2WIdioVKvSard48/nI18ILJJUb RrxA==
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=XAJqL2vZ5PvRRhf7QVYuoJ9nB9oW8d8eVn9cQwybobw=; b=nr6MimBlPqe4qbNjgjHKfEi+Yb+w9e7ZTEI4mLLsB5Xs3QUSaJLYqyYbnjQCuAfUnf rnHBMuHNCm06Zcx0NWnb4V8qGy6pMw77dDliW2thIxEQsFT6TsKaTRay8XAqBeGjri6D VWMPQZefhceLVLAsM/GIHeASlujDg4GHuymOYY2i6Rm0Xo3tz0K/aE/uue2z9EDZSKmC 8uow0Oi4b93DzDQCVcmDiouofOte3fytQhJqjMG03JHTvPLMwlZJZd333uofOYW8VAiZ nTmm7Su8spe7Hx1DR2LsaNLKbKkdiytJPNSM+0YeEYVubE7X02tUJ/N2ujSxs6/of89w g4ig==
X-Gm-Message-State: AMCzsaWY9lRZmXwgAL6o0vuvI2vKqEsMaI+gKuM7HAq1OCG9DEzt//6y oVHEvhalJIJ8przaLOlkyzAlRSPLBUtL1HF9u26rdg==
X-Google-Smtp-Source: AOwi7QAh30JwFKzL0dMEDvP/SGQrhJ27vdevb9I4POArzlXgUAzJ9qbxU/HYlpkq/A305F36HdZ27PQTqg8sB6NOe8Y=
X-Received: by 10.223.150.116 with SMTP id c49mr2977710wra.246.1507848542546;  Thu, 12 Oct 2017 15:49:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Thu, 12 Oct 2017 15:48:21 -0700 (PDT)
In-Reply-To: 
References:  <5771bafe-d2f4-ca0b-d96d-2b6f43aa22a0@cisco.com>  
From: "M. Ranganathan" 
Date: Thu, 12 Oct 2017 18:48:21 -0400
Message-ID: 
To: Eliot Lear 
Cc: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1147d4acc0eef5055b6158f3"
Archived-At: 
Subject: Re: [OPSAWG] Understanding MUD : Controller and my-controller
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, 12 Oct 2017 22:49:06 -0000

--001a1147d4acc0eef5055b6158f3
Content-Type: text/plain; charset="UTF-8"

Hi Eliot,

On Thu, Oct 12, 2017 at 12:55 PM, Eliot Lear  wrote:

>
>
> On 10/12/17 6:17 PM, M. Ranganathan wrote:
>
>
> Thanks. That sorted some confusion out but I am still wondering why, for
> example, BOTH "controller" and "my-controller" need to exist in the
> specification.
>
>
> "my-controller" has an inferred name, if you will, of the current MUD URL,
> and no other name is required.  And so administrators populate the field
> for each device that hits the network.  "controller" takes a name.  And so
> the idea is that if you a manufacturer have many devices that might all use
> the same controller, you can specify that name, and the administrator only
> needs to populate the class once.  Some governance required, of course.
>
> Eliot
>


So this is a way of supporting late binding and indirection. To verify my
understanding, here is a small example (generated by entering parameters
into mudmaker). Lets say I have a MUD file with

 "controller": "https://foo.bar.com/.well-known/mud/v1/thermometerv1"

Lets say we have a MUD file with a mud URL of

 "mud-url": "https://foo.bar.com/.well-known/mud/v1/thermometerv1"

Also, we have the following ACLs specified:

 {
              "rule-name": "ent0-todev",
              "matches": {
                "ietf-mud:mud-acl": {
                  "controller":
"https://foo.bar.com/.well-known/mud/v1/thermometerv1"
                },
                "ipv4-acl": {
                  "protocol": 6,
                  "source-port-range": {
                    "lower-port": 9000,
                    "upper-port": 9000
                  }
                },
                "tcp-acl": {
                  "ietf-mud:direction-initiated": "from-device"
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            },
            {
              "rule-name": "myctl0-todev",
              "matches": {
                "ietf-mud:mud-acl": {
                  "my-controller": [
                    null
                  ]
                },
                "ipv4-acl": {
                  "protocol": 6,
                  "source-port-range": {
                    "lower-port": 800,
                    "upper-port": 800
                  }
                },
                "tcp-acl": {
                  "ietf-mud:direction-initiated": "from-device"
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }

Now lets say the controller

"https://foo.bar.com/.well-known/mud/v1/thermometerv1"

Maps to a set of hosts [host1.nist.gov , host2.nist.gov]. The way in
which this mapping gets established is out of scope.

The first ACL says the IOT device can receive packets from port
host1.nist.gov:9000 and host2.nist.gov:9000.

The second rule says the IOT device can receive packets from
host1.nist.gov:800 and host1.nist.gov:800

Is that the right way to interpret this?

Thanks for your patience in explaining this to me. Perhaps you could
consider adding an example to flesh this out (?) (just a suggestion).

Regards,

Ranga





-- 
M. Ranganathan

--001a1147d4acc0eef5055b6158f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Eliot,

On Thu, Oct 12, 2017 at 12:55 PM, Eliot Lear <lear@cisco.com=
> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 10/12/17 =
6:17 PM, M. Ranganathan
      wrote:

    

    

     =20
      


        

          

            
Thanks. That sorted some confusion out but I am still
              wondering why, for example, BOTH "controller" and
              "my-controller" need to exist in the specification.=


            

          

        

      

    

    

    "my-controller" has an inferred name, if you will, of the cur=
rent
    MUD URL, and no other name is required.=C2=A0 And so administrators
    populate the field for each device that hits the network.=C2=A0
    "controller" takes a name.=C2=A0 And so the idea is that if y=
ou a
    manufacturer have many devices that might all use the same
    controller, you can specify that name, and the administrator only
    needs to populate the class once.=C2=A0 Some governance required, of
    course.

    

    Eliot


So th=
is is a way of supporting late binding and indirection. To verify my unders=
tanding, here is a small example (generated by entering parameters into mud=
maker). Lets say I have a MUD file with 
 "controller": &=
quot;https=
://foo.bar.com/.well-known/mud/v1/thermometerv1"
 
Lets say we have a MUD file with a mud URL of 
 "mud-url"=
;: "h=
ttps://foo.bar.com/.well-known/mud/v1/thermometerv1"

=

Also, we have the following ACLs specified:

 {
              "rule-name": "ent0-todev",
              "matches": {
                "ietf-mud:mud-acl": {
                  "controller": "https://foo.bar.com/.well-known/mud/v=
1/thermometerv1"
                },
                "ipv4-acl": {
                  "protocol": 6,
                  "source-port-range": {
                    "lower-port": 9000,
                    "upper-port": 9000
                  }
                },
                "tcp-acl": {
                  "ietf-mud:direction-initiated": "from-devi=
ce"
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            },
            {
              "rule-name": "myctl0-todev",
              "matches": {
                "ietf-mud:mud-acl": {
                  "my-controller": [
                    null
                  ]
                },
                "ipv4-acl": {
                  "protocol": 6,
                  "source-port-range": {
                    "lower-port": 800,
                    "upper-port": 800
                  }
                },
                "tcp-acl": {
                  "ietf-mud:direction-initiated": "from-devi=
ce"
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }

Now lets say the controller 

"https://foo.bar=
.com/.well-known/mud/v1/thermometerv1"

Maps to a=
 set of hosts [host1.nist.gov , host2.nist.gov]. The way in which this map=
ping gets established is out of scope.

The first ACL says the IOT de=
vice can receive packets from port h=
ost1.nist.gov:9000 and host2.nis=
t.gov:9000. 

The second rule says the IOT device can receive pac=
kets from host1.nist.gov:800 and =
host1.nist.gov:800

<=
pre>Is that the right way to interpret this?

Thanks for y=
our patience in explaining this to me. Perhaps you could consider adding an=
 example to flesh this out (?) (just a suggestion).

Regar=
ds,

Ranga




-- 
M. Ranganath=
an




--001a1147d4acc0eef5055b6158f3--


From nobody Thu Oct 12 19:10:50 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 8C6E8133343 for ; Thu, 12 Oct 2017 19:10:48 -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 tigITCftLtiZ for ; Thu, 12 Oct 2017 19:10:46 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535B4133075 for ; Thu, 12 Oct 2017 19:10:46 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id l68so17804210wmd.5 for ; Thu, 12 Oct 2017 19:10:46 -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=BiwXwD6SZ1Yh185rr6nMqzk8NeYi08FAVrleLDv+utE=; b=T+YdhgfNweci6KmmVRbdXDksMmWPuH765wb794gkQNFj+BlgKkDTRSvQ0xS7ZdVOEU EtNwSzFWb43Fyn26GtS0hZkJtlty+JqYecf/7oSBZVgcp7ipridSQgLDDNbiQQT/T37A FZnR6S95dLQxgw7iVaVtEOw9gG27QTGb7LPVA2k/H4880XNC0XBRTAdAnHnFgcTh982T GVMuC6tqeus/teied1A1sdmKOYYKbGSHDMeMnCY1UzMK2vMyEAifhdynJWM2xLKGgKVv pFLi0fD0gBAGn/L+GAMYeTkmv7GeciajGtKb2/ZWMmopUk3JZ5kVCZZ+Db5cV0J3l9IS pbQQ==
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=BiwXwD6SZ1Yh185rr6nMqzk8NeYi08FAVrleLDv+utE=; b=aIyvmVeB0Ckc7OxSrsKr1Fk/yp3gyNmrYDW76D+aDWcfGSn5G1O3dWE3lcZJZKfpFv wAgMQXPfQHrucroeDjpF3u5Ts4LBjy25EXuCAf99i4Fex1ygWcACVc856H5zKQ6dDFDk kvswMZ5eHTQrAyRiChhVLlN2Ao5avgOPo5oQKx2XpX/s4XZ1IswwtZJkjIuWT7lecMdE KudWRorvsx2c72cK2MnIOINXsl8K3LYqW0dnnR18dhOIKNNcnlNjNez5vha4YOxfc/Lk HMefUGAITQjVMewlr5eea+s9ZmhfRVBJE3YTKmmbqzs0MDaVpwX5QBGEZgPAutrucxAA Qekw==
X-Gm-Message-State: AMCzsaXlM3IDvIIxsAteJqfnMQNAOt9vi+WQpZfixsylnKdBnkLoMrI0 mTLriYN9kzGKJRrtvKYdl1ekHJ9wi7u2xCBNoPA=
X-Google-Smtp-Source: AOwi7QBOdxtyuoL3s5L973K2m83+aTeg0pwVWT4YdDdnK607xoHob7ncFnqxiFae396MXP+8THoCNNilQrFiyBv6Pn8=
X-Received: by 10.223.150.116 with SMTP id c49mr3207477wra.246.1507860644704;  Thu, 12 Oct 2017 19:10:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Thu, 12 Oct 2017 19:10:04 -0700 (PDT)
In-Reply-To: 
References:  <5771bafe-d2f4-ca0b-d96d-2b6f43aa22a0@cisco.com>   
From: "M. Ranganathan" 
Date: Thu, 12 Oct 2017 22:10:04 -0400
Message-ID: 
To: Eliot Lear 
Cc: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1147d4ac1938a6055b642ac4"
Archived-At: 
Subject: Re: [OPSAWG] Understanding MUD : Controller and my-controller
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, 13 Oct 2017 02:10:48 -0000

--001a1147d4ac1938a6055b642ac4
Content-Type: text/plain; charset="UTF-8"

Hi Eliot,


On Thu, Oct 12, 2017 at 6:48 PM, M. Ranganathan  wrote:

> Hi Eliot,
>
> On Thu, Oct 12, 2017 at 12:55 PM, Eliot Lear  wrote:
>
>>
>>
>> On 10/12/17 6:17 PM, M. Ranganathan wrote:
>>
>>
>> Thanks. That sorted some confusion out but I am still wondering why, for
>> example, BOTH "controller" and "my-controller" need to exist in the
>> specification.
>>
>>
>> "my-controller" has an inferred name, if you will, of the current MUD
>> URL, and no other name is required.  And so administrators populate the
>> field for each device that hits the network.  "controller" takes a name.
>> And so the idea is that if you a manufacturer have many devices that might
>> all use the same controller, you can specify that name, and the
>> administrator only needs to populate the class once.  Some governance
>> required, of course.
>>
>> Eliot
>>
>
>

I think I understand the purpose of the "controller" field based on your
mail here:

https://www.ietf.org/mail-archive/web/opsawg/current/msg04748.html

Here is my interpretation:

Is the following an accurate set of statements ?

A "controller" a host or set of hosts that referenced by a URN. It is a
means of referring to hosts in the MUD file that are not known a-prior by
the device manufacturer. Well known URNs are defined for well known
services such as DNS, NTP and DHCP but arbitrary URLs are allowed to refer
to classes of hosts which can be bound actual hostnames during device
deployment.  A controller referenced by a MUD url, could, for example be
used as a registration server for devices that all share the same behavior.
The utility of such a controller would be that network administrators could
track registrations of all devices that share the same MUD URL. The empty
node "my-controller" refers to the (device registration) controller
referenced by the MUD URL of the MUD file.

Please verify if I have understood things correctly.

What makes this a bit confusing is that the term "controller" is overloaded
IMHO because we also talk about MUD controllers -- which is a different
thing entirely ( or at least so I think ).

Thank you very much for your help in understanding this.

Regards,

Ranga.




-- 
M. Ranganathan

--001a1147d4ac1938a6055b642ac4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Eliot,

On Thu, Oct 12, 2017 at 6:48 PM, M. Ranganathan=
 <mranga@gmail.com> wrote:
Hi Eliot,

On Thu, Oct 12=
, 2017 at 12:55 PM, Eliot Lear <lear@cisco.com> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 10/12/17 6:17 PM, M. Ranganathan
      wrote:

    

    

     =20
      


        

          

            
Thanks. That sorted some confusion out but I am still
              wondering why, for example, BOTH "controller" and
              "my-controller" need to exist in the specification.=


            

          

        

      

    

    

    "my-controller" has an inferred name, if you will, of the cur=
rent
    MUD URL, and no other name is required.=C2=A0 And so administrators
    populate the field for each device that hits the network.=C2=A0
    "controller" takes a name.=C2=A0 And so the idea is that if y=
ou a
    manufacturer have many devices that might all use the same
    controller, you can specify that name, and the administrator only
    needs to populate the class once.=C2=A0 Some governance required, of
    course.

    

    Eliot



I think I u=
nderstand the purpose of the "controller" field based on your mai=
l here:


Here is my interp=
retation:

Is the following an accurate set of stat=
ements ?

A "controller" a host or se=
t of hosts that referenced by a URN. It is a means of referring to hosts in=
 the MUD file that are not known a-prior by the device manufacturer. Well k=
nown URNs are defined for well known services such as DNS, NTP and DHCP but=
 arbitrary URLs are allowed to refer to classes of hosts which can be bound=
 actual hostnames during device deployment.=C2=A0 A controller referenced b=
y a MUD url, could, for example be used as a registration server for device=
s that all share the same behavior. The utility of such a controller would =
be that network administrators could track registrations of all devices tha=
t share the same MUD URL. The empty node "my-controller" refers t=
o the (device registration) controller referenced by the MUD URL of the MUD=
 file.

Please verify if I have understood things c=
orrectly.

What makes this a bit confusing is t=
hat the term "controller" is overloaded IMHO because we also talk=
 about MUD controllers -- which is a different thing entirely ( or at least=
 so I think ).

Thank you very much for your he=
lp in understanding this.

Regards,

<=
/div>
Ranga.




-- 
M. Ranganathan=





--001a1147d4ac1938a6055b642ac4--


From nobody Mon Oct 16 00:27: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 1D1F3134454 for ; Mon, 16 Oct 2017 00:27:11 -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 Z8FJC8kYtVgG for ; Mon, 16 Oct 2017 00:27:09 -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 7F0B3134450 for ; Mon, 16 Oct 2017 00:27:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQS31259; Mon, 16 Oct 2017 07:27:06 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 16 Oct 2017 08:26:43 +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; Mon, 16 Oct 2017 15:26:38 +0800
From: Tianran Zhou 
To: "opsawg@ietf.org" 
Thread-Topic: OPSAWG IETF 100 Slot Requests
Thread-Index: AdNGUBCEaXtr+jxWSYqGegKZbrfGSA==
Date: Mon, 16 Oct 2017 07:26:37 +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.59E45F4B.0005, 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: bb09ad33791c9439c08191a2be35b293
Archived-At: 
Subject: [OPSAWG] OPSAWG IETF 100 Slot Requests
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, 16 Oct 2017 07:27:11 -0000

Dear WG,

The IETF 100 Preliminary Agenda has been published,=20
https://datatracker.ietf.org/meeting/100/agenda.html

OPSAWG will meet 15:50-17:50 Tuesday Afternoon session II.
Please send a request to Chairs for the time slot.=20

Best Regards!
Tianran, co-chair


From nobody Mon Oct 16 03:24: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 C29201321CB for ; Mon, 16 Oct 2017 03:24:01 -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, 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 h9-qYUWSkgpQ for ; Mon, 16 Oct 2017 03:24:00 -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 BD482132F69 for ; Mon, 16 Oct 2017 03:23:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2874; q=dns/txt; s=iport; t=1508149439; x=1509359039; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=lvgahe/6BeYJwiwShmV29Bj8NhgmcM1JnhsGRIM/uD0=; b=GzyjGKyDGW0gdusNayP2K7wofWint395D8ZAPnunc7pTZKqy58ajk7Lf Kud1/bHYZwChkFdL/rPNX89NYzXw5AqUvRbeM+3+CM94lnU72PHbzbWLY Q+fVhXl0T8dDmbIOW5PjZVNtjiTjr+0V3nc/wCSR19Er/EXsemYKvqFxQ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAACyh+RZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N6ih90pmEQggQKGAuESU8ChRUYAQIBAQEBAQEBayiFHgI?= =?us-ascii?q?EAQEhDwEFNgkCEAsaAiMDAgInHxEGAQwGAgEBihkQqiGCJ4sxAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYEOgh+DWIFqK4J/gzKBG4NLgmEBBJFHkAGHX40MghRdhRm?= =?us-ascii?q?DWocyjg+HYIE5HziBWTQhCB0VHyqCZAmEWD42ilUBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,386,1503360000"; d="scan'208";a="656379278"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Oct 2017 10:23:57 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9GANvfS015968; Mon, 16 Oct 2017 10:23:57 GMT
To: mohamed.boucadair@orange.com, "opsawg@ietf.org" 
Cc: JACQUENET Christian IMT/OLN , Juergen Schoenwaelder 
References: <150781694088.16824.7345333598884165729.idtracker@ietfa.amsl.com> 
From: Benoit Claise 
Message-ID: <0554b9c0-9c8b-edb2-cd4d-09381bf86780@cisco.com>
Date: Mon, 16 Oct 2017 12:23:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-nat-yang-06.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, 16 Oct 2017 10:24:02 -0000

Dear all,

Historically, the MIB doctor reviews would happen during IETF LC.
Because YANG was new, we started early YANG doctor reviews. Those 
reviews don't have to occur in sequence, i.e. before the IETF LC starts. 
In fact, at some point in time in the future (when the YANG knowledge 
will be widely spread), the YANG doctor reviews will be triggered by the 
IETF LC.
Bottom line: if the OPSAWG chairs believe this document is ready, it can 
progress to IETF LC now.

Regards, Benoit.
> Dear all,
>
> The new version fixes some cosmetic issues (mainly, indentation of the YANG module) and points to YANG1.1 RFC as per a comment received from Mahesh Jethanandani.
>
> We are waiting for the yang doctors review.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Envoyé : jeudi 12 octobre 2017 16:02
>> À : Qin Wu; Senthil Sivakumar; BOUCADAIR Mohamed IMT/OLN; Suresh
>> Vinapamula; JACQUENET Christian IMT/OLN
>> Objet : New Version Notification for draft-ietf-opsawg-nat-yang-06.txt
>>
>>
>> A new version of I-D, draft-ietf-opsawg-nat-yang-06.txt
>> has been successfully submitted by Mohamed Boucadair and posted to the
>> IETF repository.
>>
>> Name:		draft-ietf-opsawg-nat-yang
>> Revision:	06
>> Title:		A YANG Data Model for Network Address Translation (NAT)
>> and Network Prefix Translation (NPT)
>> Document date:	2017-10-11
>> Group:		opsawg
>> Pages:		78
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-opsawg-
>> nat-yang-06.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-
>> yang/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-06
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
>> nat-yang-06
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat-
>> yang-06
>>
>> Abstract:
>>     For the sake of network automation and the need for programming
>>     Network Address Translation (NAT) function in particular, a data
>>     model for configuring and managing the NAT is essential.  This
>>     document defines a YANG module for the NAT function.
>>
>>     NAT44, Network Address and Protocol Translation from IPv6 Clients to
>>     IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit
>>     Address Mappings for Stateless IP/ICMP Translation (SIIT EAM), and
>>     IPv6 Network Prefix Translation (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 Tue Oct 17 07:50:15 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 1E52E132F6C for ; Tue, 17 Oct 2017 07:50:13 -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 GG5Zb7Sp6wom for ; Tue, 17 Oct 2017 07:50:11 -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 F2C36132F30 for ; Tue, 17 Oct 2017 07:50:10 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id D6EE11C01B9; Tue, 17 Oct 2017 16:50:09 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id AE7E118006F; Tue, 17 Oct 2017 16:50:09 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0361.001; Tue, 17 Oct 2017 16:50:06 +0200
From: 
To: Benoit Claise , "opsawg@ietf.org" 
CC: JACQUENET Christian IMT/OLN , "Juergen Schoenwaelder" 
Thread-Topic: [OPSAWG] New Version Notification for draft-ietf-opsawg-nat-yang-06.txt
Thread-Index: AQHTQ2K5oECyfHfAiUGvFia9FzuBL6LgP3JQgAXqAYCAAfr/oA==
Date: Tue, 17 Oct 2017 14:50:05 +0000
Message-ID: <105a1415-8296-455e-99c5-7f6724484d90@OPEXCLILM44.corporate.adroot.infra.ftgroup>
References: <150781694088.16824.7345333598884165729.idtracker@ietfa.amsl.com>  <0554b9c0-9c8b-edb2-cd4d-09381bf86780@cisco.com>
In-Reply-To: <0554b9c0-9c8b-edb2-cd4d-09381bf86780@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-nat-yang-06.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, 17 Oct 2017 14:50:13 -0000

SGkgQmVub2l0LCANCg0KVGhhbmsgeW91IGZvciB0aGlzIGNsYXJpZmljYXRpb24uIA0KDQpJZiBK
dWVyZ2VuIGlzIE9LIHRvIHByb3ZpZGUgaGlzIHJldmlldyBiZWZvcmUgdGhlIFdHTEMsIEkgd291
bGQgcHJlZmVyIHRvIGdvIHRoYXQgcGF0aC4gVGhhdCBpcywgd2FpdCBmb3IgaGlzIGVhcmx5IHJl
dmlldywgZml4IGFueSBjb21tZW50cyBmcm9tIEp1ZXJnZW4sIGFuZCB0aGVuIGdvIGZvciBhIGxh
c3QgY2FsbC4NCg0KT2J2aW91c2x5LCB0aGlzIGlzIG9ubHkgbXkgcHJlZmVyZW5jZSBhcyBhbiBl
ZGl0b3IuIEkgd2lsbCBkZWZlciB0byB0aGUgY2hhaXJzIHRvIGRlY2lkZS4NCg0KQ2hlZXJzLA0K
TWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEJlbm9pdCBDbGFp
c2UgW21haWx0bzpiY2xhaXNlQGNpc2NvLmNvbV0NCj4gRW52b3nDqcKgOiBsdW5kaSAxNiBvY3Rv
YnJlIDIwMTcgMTI6MjQNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgb3BzYXdn
QGlldGYub3JnDQo+IENjwqA6IEpBQ1FVRU5FVCBDaHJpc3RpYW4gSU1UL09MTjsgSnVlcmdlbiBT
Y2hvZW53YWVsZGVyDQo+IE9iamV0wqA6IFJlOiBbT1BTQVdHXSBOZXcgVmVyc2lvbiBOb3RpZmlj
YXRpb24gZm9yIGRyYWZ0LWlldGYtb3BzYXdnLW5hdC0NCj4geWFuZy0wNi50eHQNCj4gDQo+IERl
YXIgYWxsLA0KPiANCj4gSGlzdG9yaWNhbGx5LCB0aGUgTUlCIGRvY3RvciByZXZpZXdzIHdvdWxk
IGhhcHBlbiBkdXJpbmcgSUVURiBMQy4NCj4gQmVjYXVzZSBZQU5HIHdhcyBuZXcsIHdlIHN0YXJ0
ZWQgZWFybHkgWUFORyBkb2N0b3IgcmV2aWV3cy4gVGhvc2UNCj4gcmV2aWV3cyBkb24ndCBoYXZl
IHRvIG9jY3VyIGluIHNlcXVlbmNlLCBpLmUuIGJlZm9yZSB0aGUgSUVURiBMQyBzdGFydHMuDQo+
IEluIGZhY3QsIGF0IHNvbWUgcG9pbnQgaW4gdGltZSBpbiB0aGUgZnV0dXJlICh3aGVuIHRoZSBZ
QU5HIGtub3dsZWRnZQ0KPiB3aWxsIGJlIHdpZGVseSBzcHJlYWQpLCB0aGUgWUFORyBkb2N0b3Ig
cmV2aWV3cyB3aWxsIGJlIHRyaWdnZXJlZCBieSB0aGUNCj4gSUVURiBMQy4NCj4gQm90dG9tIGxp
bmU6IGlmIHRoZSBPUFNBV0cgY2hhaXJzIGJlbGlldmUgdGhpcyBkb2N1bWVudCBpcyByZWFkeSwg
aXQgY2FuDQo+IHByb2dyZXNzIHRvIElFVEYgTEMgbm93Lg0KPiANCj4gUmVnYXJkcywgQmVub2l0
Lg0KPiA+IERlYXIgYWxsLA0KPiA+DQo+ID4gVGhlIG5ldyB2ZXJzaW9uIGZpeGVzIHNvbWUgY29z
bWV0aWMgaXNzdWVzIChtYWlubHksIGluZGVudGF0aW9uIG9mIHRoZQ0KPiBZQU5HIG1vZHVsZSkg
YW5kIHBvaW50cyB0byBZQU5HMS4xIFJGQyBhcyBwZXIgYSBjb21tZW50IHJlY2VpdmVkIGZyb20N
Cj4gTWFoZXNoIEpldGhhbmFuZGFuaS4NCj4gPg0KPiA+IFdlIGFyZSB3YWl0aW5nIGZvciB0aGUg
eWFuZyBkb2N0b3JzIHJldmlldy4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+
PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGXCoDogaW50ZXJuZXQtZHJhZnRz
QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiA+PiBFbnZvecOp
wqA6IGpldWRpIDEyIG9jdG9icmUgMjAxNyAxNjowMg0KPiA+PiDDgMKgOiBRaW4gV3U7IFNlbnRo
aWwgU2l2YWt1bWFyOyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBTdXJlc2gNCj4gPj4gVmlu
YXBhbXVsYTsgSkFDUVVFTkVUIENocmlzdGlhbiBJTVQvT0xODQo+ID4+IE9iamV0wqA6IE5ldyBW
ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmctMDYudHh0
DQo+ID4+DQo+ID4+DQo+ID4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW9wc2F3
Zy1uYXQteWFuZy0wNi50eHQNCj4gPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi
eSBNb2hhbWVkIEJvdWNhZGFpciBhbmQgcG9zdGVkIHRvIHRoZQ0KPiA+PiBJRVRGIHJlcG9zaXRv
cnkuDQo+ID4+DQo+ID4+IE5hbWU6CQlkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZw0KPiA+PiBS
ZXZpc2lvbjoJMDYNCj4gPj4gVGl0bGU6CQlBIFlBTkcgRGF0YSBNb2RlbCBmb3IgTmV0d29yayBB
ZGRyZXNzIFRyYW5zbGF0aW9uIChOQVQpDQo+ID4+IGFuZCBOZXR3b3JrIFByZWZpeCBUcmFuc2xh
dGlvbiAoTlBUKQ0KPiA+PiBEb2N1bWVudCBkYXRlOgkyMDE3LTEwLTExDQo+ID4+IEdyb3VwOgkJ
b3BzYXdnDQo+ID4+IFBhZ2VzOgkJNzgNCj4gPj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3
LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wc2F3Zy0NCj4gPj4gbmF0LXlh
bmctMDYudHh0DQo+ID4+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1uYXQtDQo+ID4+IHlhbmcvDQo+ID4+IEh0bWxpemVk
OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctbmF0
LXlhbmctDQo+IDA2DQo+ID4+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtDQo+IG9wc2F3Zy0NCj4gPj4gbmF0LXlhbmctMDYN
Cj4gPj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k
cmFmdC1pZXRmLW9wc2F3Zy0NCj4gbmF0LQ0KPiA+PiB5YW5nLTA2DQo+ID4+DQo+ID4+IEFic3Ry
YWN0Og0KPiA+PiAgICAgRm9yIHRoZSBzYWtlIG9mIG5ldHdvcmsgYXV0b21hdGlvbiBhbmQgdGhl
IG5lZWQgZm9yIHByb2dyYW1taW5nDQo+ID4+ICAgICBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRp
b24gKE5BVCkgZnVuY3Rpb24gaW4gcGFydGljdWxhciwgYSBkYXRhDQo+ID4+ICAgICBtb2RlbCBm
b3IgY29uZmlndXJpbmcgYW5kIG1hbmFnaW5nIHRoZSBOQVQgaXMgZXNzZW50aWFsLiAgVGhpcw0K
PiA+PiAgICAgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgbW9kdWxlIGZvciB0aGUgTkFUIGZ1bmN0
aW9uLg0KPiA+Pg0KPiA+PiAgICAgTkFUNDQsIE5ldHdvcmsgQWRkcmVzcyBhbmQgUHJvdG9jb2wg
VHJhbnNsYXRpb24gZnJvbSBJUHY2IENsaWVudHMNCj4gdG8NCj4gPj4gICAgIElQdjQgU2VydmVy
cyAoTkFUNjQpLCBDdXN0b21lci1zaWRlIHRyYW5zTEFUb3IgKENMQVQpLCBFeHBsaWNpdA0KPiA+
PiAgICAgQWRkcmVzcyBNYXBwaW5ncyBmb3IgU3RhdGVsZXNzIElQL0lDTVAgVHJhbnNsYXRpb24g
KFNJSVQgRUFNKSwgYW5kDQo+ID4+ICAgICBJUHY2IE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0aW9u
IChOUFR2NikgYXJlIGNvdmVyZWQgaW4gdGhpcw0KPiBkb2N1bWVudC4NCj4gPj4NCj4gPj4NCj4g
Pj4NCj4gPj4NCj4gPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt
aW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPj4gc3VibWlzc2lvbg0KPiA+PiB1bnRpbCB0aGUg
aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn
Lg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT1BTQVdHIG1haWxpbmcgbGlzdA0K
PiA+IE9QU0FXR0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb3BzYXdnDQoNCg==


From nobody Tue Oct 17 08:17:50 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 4FC1513301C for ; Tue, 17 Oct 2017 08:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 HeFlyHkYntbZ for ; Tue, 17 Oct 2017 08:17:48 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 B19CA132D22 for ; Tue, 17 Oct 2017 08:17:47 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id l68so4651046wmd.5 for ; Tue, 17 Oct 2017 08:17:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=KuhzSz00TAkgfYPU7u/cDdeVri/Z3qQjlBmxU7tog5I=; b=etb9PYyy1LTWKkRCCOUkn9mcM9FE8Zu07qrRukkTodg7v6r+BZuu9Yi1Ej/exJV8gF Uw9q4HL8xPlf8A9ow9fjgPt0tksyJLnaOseNBeShodstO8PPPT/oitPVIOO2v2sU33TU 8kNwz+yeVMSFVgaemaXXasJWL+EomDO8emSCa7ZJaLRxHTPzBDEQNecwxz/cMTw3B0h4 Kaq00DkfR0TU8ke6aqylbr3izg/rrSq2KR4sdbmETtVe4PUtDAOxH9mf1Mb3wVQmHCFt v7RRzzF0wShielx+BgVWm0T/XUXR/x2VjOFSquWvNMace7VI+sv4o3umY4W3jApfMltK 8FeQ==
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=KuhzSz00TAkgfYPU7u/cDdeVri/Z3qQjlBmxU7tog5I=; b=YMRQFcQhs6nShjSVSC4efvBCec64+8+n1t1MW7kIyRrjOPTKDq/xSkfHacwDE8QJ+S gInx/KoMEszT4Goy6ewZoWtv6tAaojIFjoYFIGUSSpeKUgyvCiuVZT/QfqjBDcXZkCeH XYmZS8lPxJcv7yAvjxrLHLLCm+NZOAy9TGJOLsBLw6naQ+4/l75o3sbtwEgzI0yWn22S 6imrP7bjRc39evfSanb0niFMRxDH2u33RJiXIds/Ef55ezKK5y+1wKtE61hIPAehbFnR 8h3oCGBuxv1iGZeYqgOB7ZicI8gIxFjAcfFimkMuQ68xX9NzwDhCn4W12ON+5PY+gRd2 SYNg==
X-Gm-Message-State: AMCzsaWWIppkW1Dkqyll0K74DEVHRBUUYAj7iOoPF5j7s6W8uJgzUig7 8rLctc6ZYxA/L3y6iV4RUjx50MzgSPMQaTA4vNKoY/f+
X-Google-Smtp-Source: ABhQp+TRjkYj4UONgaRxVN6gvmj+q136Sh9xk2OTkzW7Ohjw0qlekPZFvpgOZ4079mflf+Uqn1WFFhS+QcBiy321mbs=
X-Received: by 10.28.69.91 with SMTP id s88mr3795660wma.19.1508253465829; Tue, 17 Oct 2017 08:17:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Tue, 17 Oct 2017 08:17:05 -0700 (PDT)
From: "M. Ranganathan" 
Date: Tue, 17 Oct 2017 11:17:05 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0723a60fe525055bbfa0cc"
Archived-At: 
Subject: [OPSAWG] problems with compiling ietf-access-control-list@2017-10-03.yang
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Oct 2017 15:17:49 -0000

--94eb2c0723a60fe525055bbfa0cc
Content-Type: text/plain; charset="UTF-8"

I ran into some issues when I tried compiling this module using
opendaylight yangtools. Here is my compile error :

 Failed to find leafref target: ../../../../../../acl/acl-name in module
ietf-access-control-list
(QNameModule{ns=urn:ietf:params:xml:ns:yang:ietf-access-control-list,
rev=2017-10-03})

I am quite new at YANG so it is entirely possible I did some mistake (if
so, any clues would be appreciated).

Thanks,

Ranga

-- 
M. Ranganathan

--94eb2c0723a60fe525055bbfa0cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I ran into some issues when I tried compiling th=
is module using opendaylight yangtools. Here is my compile error :

=
=C2=A0Failed to find leafref target: ../../../../../../acl/acl-name in modu=
le ietf-access-control-list (QNameModule{ns=3Durn:ietf:params:xml:ns:yang:i=
etf-access-control-list, rev=3D2017-10-03})

I am quite new at =
YANG so it is entirely possible I did some mistake (if so, any clues would =
be appreciated).

Thanks,

Ranga

-- 
M. Ranganathan




--94eb2c0723a60fe525055bbfa0cc--


From nobody Tue Oct 17 09:03: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 4DA261332CD for ; Tue, 17 Oct 2017 09:03:32 -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 YNUNeaxq1DbJ for ; Tue, 17 Oct 2017 09:03:30 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F51B1329B5 for ; Tue, 17 Oct 2017 09:03:30 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id q132so4944353wmd.2 for ; Tue, 17 Oct 2017 09:03:30 -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;  bh=5VcGb4oWuSNS/BxijdxFHJTShfvOj4rS1/0MHl13E24=; b=WiNOfFnuNhfRT5E74uXG7Q0izz78DB8NTyVT8Zi1wNi7x7bIAzRwGxXVmFnwc/UfQG +k/gKFf3q1XmwYZAn/0+uy1n5Xiq/a0D/BzNIcM6jYJec9z7e7I44z1CCSqeVH6pCRU7 hmTqITb3PntdwsrcblVbOwiV8ciK+v8HCjiMtgOQro96d5R1Lvx/eaugqYXhslPYy+nw pqJIuYc6xdEGQK4dtqKH6J445bJQSAg60SsoE40U9ADRuZJ+2brgXOvNXcFzlJz/Gi4e Xp3Ha1cFbJIRWlhhxMoh8JH6r0ln7+fRL+Y6Whwf6r8B1oL0GZDBV8i9yvE09JMVL0kr VuBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5VcGb4oWuSNS/BxijdxFHJTShfvOj4rS1/0MHl13E24=; b=YNWlyi9Gwzzwm6F/qi4YvvEuAzXSDkZ/i8rodihhJKp3XJX/TzNUew2qvpY/OYIfYF Fy6UaSjfFwOBc3sBqOuiiH786DGyArLZRSIy6EQ5r23kEBhfEZm7zC+q/PDwF8XMiPSC qDiN6amI3pwFzKZoG6qnX3xgLmj/mJ/WY57yywVCyQUF6xA6g+lidtRE+zfjWPBdcIh0 bEV7x3UafBzguVrAeiyMb0CYRIK2djA+9HIjSbe76G42eMcQZJV1VMEaJzBiUW/rdA7P ZkGzODlSMOm1rtcGhF/qbszS2k8Ta9Su5wEncaPcMKXldgPhw9syE5FeMjnBmL+7dGxA RFXA==
X-Gm-Message-State: AMCzsaVbtIInuY07ZIdegPQDys15/4YdUKqTNoQetbtLaA4NeeBc9+rE LiH/7Zzayxr5Ur8072doouAq8QJySdOZKuRvnUNUkidm
X-Google-Smtp-Source: ABhQp+SC+yRpgB7r1+xnZ0Mg3ius1GqXm2LxeiZdMfDLTSL6EMg66bz66bDZzEXO7CM8RGCy0VzDFGTDXIbHfyFCR00=
X-Received: by 10.28.232.80 with SMTP id f77mr4517197wmh.1.1508256207881; Tue, 17 Oct 2017 09:03:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Tue, 17 Oct 2017 09:02:47 -0700 (PDT)
In-Reply-To: 
References: 
From: "M. Ranganathan" 
Date: Tue, 17 Oct 2017 12:02:47 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1146580e804a2d055bc04359"
Archived-At: 
Subject: Re: [OPSAWG] problems with compiling ietf-access-control-list@2017-10-03.yang
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Oct 2017 16:03:32 -0000

--001a1146580e804a2d055bc04359
Content-Type: text/plain; charset="UTF-8"

Hello all,


On Tue, Oct 17, 2017 at 11:17 AM, M. Ranganathan  wrote:

> I ran into some issues when I tried compiling this module using
> opendaylight yangtools. Here is my compile error :
>
>  Failed to find leafref target: ../../../../../../acl/acl-name in module
> ietf-access-control-list (QNameModule{ns=urn:ietf:params:xml:ns:yang:ietf-access-control-list,
> rev=2017-10-03})
>
> I am quite new at YANG so it is entirely possible I did some mistake (if
> so, any clues would be appreciated).
>
> Thanks,
>
> Ranga
>
> --
> M. Ranganathan
>



I am not sure if this is the correct thing to be doing as I am quite new to
YANG -- so my mail here may mislead others who are likewise quite new to
YANG.

Anyway, I was able to correct this problem by making the following change:



Here is the diff

@@ -291,7 +291,7 @@ module ietf-access-control-list {

         leaf set-name {
           type leafref {
-            path "/access-lists/acl/acl-name";
+            path "../../../../../../acl/acl-name";
           }
           description
             "Reference to the ACL set name applied on ingress";
@@ -299,7 +299,7 @@ module ietf-access-control-list {

         leaf type {
           type leafref {
-            path "/access-lists/acl/acl-type";
+            path "../../../../../../acl/acl-type";
           }
           description
             "Reference to the ACL set type applied on ingress";
@@ -312,7 +312,7 @@ module ietf-access-control-list {
             "List of access list entries(ACE)";
           leaf rule-name {
             type leafref {
-              path "/access-lists/acl/aces/ace/rule-name";
+              path "../../../../../../../acl/aces/ace/rule-name";
             }
             description
               "The ace rule-name";

=============================================================



Here is the changed portion of the file after applying the diff:




grouping interface-acl {
    description
      "Grouping for per-interface ingress ACL data";

    container acl-sets {
      description
        "Enclosing container the list of ingress ACLs on the
         interface";

      list acl-set {
        key "set-name type";
        ordered-by user;
        description
          "List of ingress ACLs on the interface";

        leaf set-name {
          type leafref {
            path "/access-lists/acl/acl-name";
          }
          description
            "Reference to the ACL set name applied on ingress";
        }

        leaf type {
          type leafref {
            path "/access-lists/acl/acl-type";
          }
          description
            "Reference to the ACL set type applied on ingress";
        }

        list ace {
          if-feature "interface-stats or interface-acl-aggregate";
          key "rule-name";
          description
            "List of access list entries(ACE)";
          leaf rule-name {
            type leafref {
              path "/access-lists/acl/aces/ace/rule-name";
            }
            description
              "The ace rule-name";
          }
          uses acl-counters;
        }
      }
    }
  }


Take with a grain of salt. I could be way off mark here.



Thanks,

Ranga








-- 
M. Ranganathan

--001a1146580e804a2d055bc04359
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGRpdiBkaXI9Imx0ciI+SGVsbG8gYWxsLDxicj48YnI+PGRpdj48ZGl2IGNsYXNzPSJnbWFpbF9l
eHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIE9jdCAxNywgMjAxNyBh
dCAxMToxNyBBTSwgTS4gUmFuZ2FuYXRoYW4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJt
YWlsdG86bXJhbmdhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1yYW5nYUBnbWFpbC5jb208
L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg
c3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdi
KDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0ibHRyIj48ZGl2PjxkaXY+
SSByYW4gaW50byBzb21lIGlzc3VlcyB3aGVuIEkgdHJpZWQgY29tcGlsaW5nIHRoaXMgbW9kdWxl
IHVzaW5nIG9wZW5kYXlsaWdodCB5YW5ndG9vbHMuIEhlcmUgaXMgbXkgY29tcGlsZSBlcnJvciA6
PGJyPjxicj7CoEZhaWxlZCB0byBmaW5kIGxlYWZyZWYgdGFyZ2V0OiAuLi8uLi8uLi8uLi8uLi8u
Li9hY2wvYWNsLW5hbWUgaW4gbW9kdWxlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCAoUU5hbWVN
b2R1bGV7bnM9dXJuOmlldGY6PHdicj5wYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi08d2JyPmFjY2Vz
cy1jb250cm9sLWxpc3QsIHJldj0yMDE3LTEwLTAzfSk8YnI+PGJyPjwvZGl2PkkgYW0gcXVpdGUg
bmV3IGF0IFlBTkcgc28gaXQgaXMgZW50aXJlbHkgcG9zc2libGUgSSBkaWQgc29tZSBtaXN0YWtl
IChpZiBzbywgYW55IGNsdWVzIHdvdWxkIGJlIGFwcHJlY2lhdGVkKS48YnI+PGJyPjwvZGl2Pjxk
aXY+VGhhbmtzLDxicj48YnI+PC9kaXY+PGRpdj5SYW5nYTxzcGFuIGNsYXNzPSJnbWFpbC1IT0Vu
WmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij48YnI+PC9mb250Pjwvc3Bhbj48L2Rpdj48c3BhbiBj
bGFzcz0iZ21haWwtSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGRpdj48ZGl2PjxkaXY+
PGRpdj48ZGl2PjxkaXY+PGRpdj48YnI+LS0gPGJyPjxkaXYgY2xhc3M9ImdtYWlsLW1fMzkxOTA1
NzA4MzMxNjI3MDc3OWdtYWlsX3NpZ25hdHVyZSI+TS4gUmFuZ2FuYXRoYW48YnI+PC9kaXY+PC9k
aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9mb250Pjwvc3Bhbj48L2Rp
dj48L2Jsb2NrcXVvdGU+PGJyPjxicj48YnI+SSBhbSBub3Qgc3VyZSBpZiB0aGlzIGlzIHRoZSBj
b3JyZWN0IHRoaW5nIHRvIGJlIGRvaW5nIGFzIEkgYW0gcXVpdGUgbmV3DQogdG8gWUFORyAtLSBz
byBteSBtYWlsIGhlcmUgbWF5IG1pc2xlYWQgb3RoZXJzIHdobyBhcmUgbGlrZXdpc2UgcXVpdGUg
DQpuZXcgdG8gWUFORy48YnI+PGJyPjxkaXY+QW55d2F5LCBJIHdhcyBhYmxlIHRvIGNvcnJlY3Qg
dGhpcyBwcm9ibGVtIGJ5IG1ha2luZyB0aGUgZm9sbG93aW5nIGNoYW5nZTo8YnI+PGJyPjxicj48
YnI+PC9kaXY+PGRpdj5IZXJlIGlzIHRoZSBkaWZmPGJyPjxicj5AQCAtMjkxLDcgKzI5MSw3IEBA
IG1vZHVsZSBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3Qgezxicj7CoDxicj7CoMKgwqDCoMKgwqDC
oMKgIGxlYWYgc2V0LW5hbWUgezxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCB0eXBlIGxlYWZyZWYg
ezxicj4twqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwYXRoICZxdW90Oy9hY2Nlc3MtbGlzdHMvYWNs
L2FjbC1uYW1lJnF1b3Q7Ozxicj4rwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwYXRoICZxdW90Oy4u
Ly4uLy4uLy4uLy4uLy4uL2FjbC9hY2wtbmFtZSZxdW90Ozs8YnI+wqDCoMKgwqDCoMKgwqDCoMKg
wqAgfTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCBkZXNjcmlwdGlvbjxicj7CoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgJnF1b3Q7UmVmZXJlbmNlIHRvIHRoZSBBQ0wgc2V0IG5hbWUgYXBwbGllZCBv
biBpbmdyZXNzJnF1b3Q7Ozxicj5AQCAtMjk5LDcgKzI5OSw3IEBAIG1vZHVsZSBpZXRmLWFjY2Vz
cy1jb250cm9sLWxpc3Qgezxicj7CoDxicj7CoMKgwqDCoMKgwqDCoMKgIGxlYWYgdHlwZSB7PGJy
PsKgwqDCoMKgwqDCoMKgwqDCoMKgIHR5cGUgbGVhZnJlZiB7PGJyPi3CoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIHBhdGggJnF1b3Q7L2FjY2Vzcy1saXN0cy9hY2wvYWNsLXR5cGUmcXVvdDs7PGJyPivC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHBhdGggJnF1b3Q7Li4vLi4vLi4vLi4vLi4vLi4vYWNsL2Fj
bC10eXBlJnF1b3Q7Ozxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoCB9PGJyPsKgwqDCoMKgwqDCoMKg
wqDCoMKgIGRlc2NyaXB0aW9uPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAmcXVvdDtSZWZl
cmVuY2UgdG8gdGhlIEFDTCBzZXQgdHlwZSBhcHBsaWVkIG9uIGluZ3Jlc3MmcXVvdDs7PGJyPkBA
IC0zMTIsNyArMzEyLDcgQEAgbW9kdWxlIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdCB7PGJyPsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAmcXVvdDtMaXN0IG9mIGFjY2VzcyBsaXN0IGVudHJpZXMo
QUNFKSZxdW90Ozs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqAgbGVhZiBydWxlLW5hbWUgezxicj7C
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdHlwZSBsZWFmcmVmIHs8YnI+LcKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHBhdGggJnF1b3Q7L2FjY2Vzcy1saXN0cy9hY2wvYWNlcy9hY2UvcnVsZS1u
YW1lJnF1b3Q7Ozxicj4rwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcGF0aCAmcXVvdDsuLi8u
Li8uLi8uLi8uLi8uLi8uLi9hY2wvYWNlcy9hY2UvcnVsZS1uYW1lJnF1b3Q7Ozxicj7CoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgfTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZGVzY3JpcHRp
b248YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAmcXVvdDtUaGUgYWNlIHJ1bGUtbmFt
ZSZxdW90Ozs8YnI+PC9kaXY+PGRpdj48YnI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj48YnI+PC9kaXY+PGRpdj48YnI+PGJy
PjwvZGl2PjxkaXY+SGVyZSBpcyB0aGUgY2hhbmdlZCBwb3J0aW9uIG9mIHRoZSBmaWxlIGFmdGVy
IGFwcGx5aW5nIHRoZSBkaWZmOjxicj48L2Rpdj48ZGl2Pjxicj48YnI+PC9kaXY+PGRpdj48YnI+
PGJyPmdyb3VwaW5nIGludGVyZmFjZS1hY2wgezxicj7CoMKgwqAgZGVzY3JpcHRpb248YnI+wqDC
oMKgwqDCoCAmcXVvdDtHcm91cGluZyBmb3IgcGVyLWludGVyZmFjZSBpbmdyZXNzIEFDTCBkYXRh
JnF1b3Q7Ozxicj48YnI+wqDCoMKgIGNvbnRhaW5lciBhY2wtc2V0cyB7PGJyPsKgwqDCoMKgwqAg
ZGVzY3JpcHRpb248YnI+wqDCoMKgwqDCoMKgwqAgJnF1b3Q7RW5jbG9zaW5nIGNvbnRhaW5lciB0
aGUgbGlzdCBvZiBpbmdyZXNzIEFDTHMgb24gdGhlPGJyPsKgwqDCoMKgwqDCoMKgwqAgaW50ZXJm
YWNlJnF1b3Q7Ozxicj48YnI+wqDCoMKgwqDCoCBsaXN0IGFjbC1zZXQgezxicj7CoMKgwqDCoMKg
wqDCoCBrZXkgJnF1b3Q7c2V0LW5hbWUgdHlwZSZxdW90Ozs8YnI+wqDCoMKgwqDCoMKgwqAgb3Jk
ZXJlZC1ieSB1c2VyOzxicj7CoMKgwqDCoMKgwqDCoCBkZXNjcmlwdGlvbjxicj7CoMKgwqDCoMKg
wqDCoMKgwqAgJnF1b3Q7TGlzdCBvZiBpbmdyZXNzIEFDTHMgb24gdGhlIGludGVyZmFjZSZxdW90
Ozs8YnI+PGJyPsKgwqDCoMKgwqDCoMKgIGxlYWYgc2V0LW5hbWUgezxicj7CoMKgwqDCoMKgwqDC
oMKgwqAgdHlwZSBsZWFmcmVmIHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwYXRoICZxdW90
Oy9hY2Nlc3MtbGlzdHMvYWNsL2FjbC1uYW1lJnF1b3Q7Ozxicj7CoMKgwqDCoMKgwqDCoMKgwqAg
fTxicj7CoMKgwqDCoMKgwqDCoMKgwqAgZGVzY3JpcHRpb248YnI+wqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCAmcXVvdDtSZWZlcmVuY2UgdG8gdGhlIEFDTCBzZXQgbmFtZSBhcHBsaWVkIG9uIGluZ3Jl
c3MmcXVvdDs7PGJyPsKgwqDCoMKgwqDCoMKgIH08YnI+PGJyPsKgwqDCoMKgwqDCoMKgIGxlYWYg
dHlwZSB7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoCB0eXBlIGxlYWZyZWYgezxicj7CoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHBhdGggJnF1b3Q7L2FjY2Vzcy1saXN0cy9hY2wvYWNsLXR5cGUmcXVvdDs7
PGJyPsKgwqDCoMKgwqDCoMKgwqDCoCB9PGJyPsKgwqDCoMKgwqDCoMKgwqDCoCBkZXNjcmlwdGlv
bjxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgICZxdW90O1JlZmVyZW5jZSB0byB0aGUgQUNMIHNl
dCB0eXBlIGFwcGxpZWQgb24gaW5ncmVzcyZxdW90Ozs8YnI+wqDCoMKgwqDCoMKgwqAgfTxicj48
YnI+wqDCoMKgwqDCoMKgwqAgbGlzdCBhY2Ugezxicj7CoMKgwqDCoMKgwqDCoMKgwqAgaWYtZmVh
dHVyZSAmcXVvdDtpbnRlcmZhY2Utc3RhdHMgb3IgaW50ZXJmYWNlLWFjbC1hZ2dyZWdhdGUmcXVv
dDs7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoCBrZXkgJnF1b3Q7cnVsZS1uYW1lJnF1b3Q7Ozxicj7C
oMKgwqDCoMKgwqDCoMKgwqAgZGVzY3JpcHRpb248YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAm
cXVvdDtMaXN0IG9mIGFjY2VzcyBsaXN0IGVudHJpZXMoQUNFKSZxdW90Ozs8YnI+wqDCoMKgwqDC
oMKgwqDCoMKgIGxlYWYgcnVsZS1uYW1lIHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0eXBl
IGxlYWZyZWYgezxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBwYXRoICZxdW90Oy9hY2Nl
c3MtbGlzdHMvYWNsL2FjZXMvYWNlL3J1bGUtbmFtZSZxdW90Ozs8YnI+wqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCB9PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZGVzY3JpcHRpb248YnI+wqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgJnF1b3Q7VGhlIGFjZSBydWxlLW5hbWUmcXVvdDs7PGJyPsKg
wqDCoMKgwqDCoMKgwqDCoCB9PGJyPsKgwqDCoMKgwqDCoMKgwqDCoCB1c2VzIGFjbC1jb3VudGVy
czs8YnI+wqDCoMKgwqDCoMKgwqAgfTxicj7CoMKgwqDCoMKgIH08YnI+wqDCoMKgIH08YnI+wqAg
fTxicj48YnI+PGJyPjwvZGl2PjxkaXY+VGFrZSB3aXRoIGEgZ3JhaW4gb2Ygc2FsdC4gSSBjb3Vs
ZCBiZSB3YXkgb2ZmIG1hcmsgaGVyZS48YnI+PGJyPjxicj48YnI+PC9kaXY+PGRpdj5UaGFua3Ms
PGJyPjxicj48L2Rpdj48ZGl2PlJhbmdhPGJyPjwvZGl2PjxkaXY+PGJyPjxicj48YnI+PGJyPjwv
ZGl2PjxkaXY+wqA8YnI+PC9kaXY+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJy
PjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSI+TS4gUmFuZ2FuYXRoYW48YnI+PC9kaXY+DQo8
L2Rpdj48L2Rpdj48L2Rpdj4NCg==
--001a1146580e804a2d055bc04359--


From nobody Tue Oct 17 10:20:14 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 E773F126B6E for ; Tue, 17 Oct 2017 10:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 o9LxRhkvSqup for ; Tue, 17 Oct 2017 10:20:04 -0700 (PDT)
Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 250B4133023 for ; Tue, 17 Oct 2017 10:20:04 -0700 (PDT)
Received: from localhost.localdomain (imgmt2.lax.icann.org [10.32.11.180]) by smtp01.icann.org (Postfix) with ESMTP id 481E1E0E25 for ; Tue, 17 Oct 2017 17:20:03 +0000 (UTC)
From: Marilia Hirano 
To: OPSAWG@ietf.org 
Message-Id: <20171017172004.250B4133023@ietfa.amsl.com>
Date: Tue, 17 Oct 2017 10:20:04 -0700 (PDT)
Archived-At: 
Subject: [OPSAWG] The 2017 IANA annual survey is coming
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, 17 Oct 2017 17:20:06 -0000

Dear valued customer,

We strive to continuously improve our delivery of the IANA functions.
We have engaged Ebiquity, an independent research firm to run our
2017 customer survey and Judy.Bromley@ebiquity.com will send you an
invitation to participate early next week.

Ebiquity is committed to protecting the confidentiality of all
respondents in line with the Code of Conduct of ESOMAR (a membership
organization representing the interests of the data, research and
insights profession at an international level).

We appreciate your time and helping us improve the delivery of the IANA
functions.

If you have any questions, please contact me at marilia.hirano@iana.org.

Yours faithfully,
Marilia Hirano
Manager, Continuous Improvement
ICANN


From nobody Tue Oct 17 11:00: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 5E1E8126B6E for ; Tue, 17 Oct 2017 11:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 cMcVXLhp_9HR for ; Tue, 17 Oct 2017 11:00:17 -0700 (PDT)
Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 47EED13301F for ; Tue, 17 Oct 2017 11:00:13 -0700 (PDT)
Received: from localhost.localdomain (imgmt2.lax.icann.org [10.32.11.180]) by smtp01.icann.org (Postfix) with ESMTP id 7434FE1558 for ; Tue, 17 Oct 2017 17:51:11 +0000 (UTC)
From: Marilia Hirano 
To: opsawg@ietf.org 
Message-Id: <20171017180013.47EED13301F@ietfa.amsl.com>
Date: Tue, 17 Oct 2017 11:00:13 -0700 (PDT)
Archived-At: 
Subject: [OPSAWG] The 2017 IANA annual survey is coming
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, 17 Oct 2017 18:00:18 -0000

Dear valued customer,

We strive to continuously improve our delivery of the IANA functions.
We have engaged Ebiquity, an independent research firm to run our
2017 customer survey and Judy.Bromley@ebiquity.com will send you an
invitation to participate early next week.

Ebiquity is committed to protecting the confidentiality of all
respondents in line with the Code of Conduct of ESOMAR (a membership
organization representing the interests of the data, research and
insights profession at an international level).

We appreciate your time and helping us improve the delivery of the IANA
functions.

If you have any questions, please contact me at marilia.hirano@iana.org.

Yours faithfully,
Marilia Hirano
Manager, Continuous Improvement
ICANN


From nobody Tue Oct 17 19:07: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 50D521270AE for ; Tue, 17 Oct 2017 19:07:29 -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_H4=-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 eKr4IgVUlNlw for ; Tue, 17 Oct 2017 19:07:27 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617B0126DD9 for ; Tue, 17 Oct 2017 19:07:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4297; q=dns/txt; s=iport; t=1508292447; x=1509502047; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=kgiXYdwP79HajNA9d9V1YIm+g7eRgz8FZSCDcEA+h4E=; b=FVpVMv1ZsGZOHmziDuysi00UWQcwflbO0xGiUB9EMdLEf4q2m+LQkuqe GndslxnbSGcyCK8HVKViJBXsDDeXPTRJHGMS3cJ3Q44JT1swqo8QmqvE+ oydyF1X7VCspJPUSzMP4s0qSVqO/SYhOQXMQVJOS+95E4IagRxzJLj596 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAQDXtuZZ/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbieDeoofjziBSwkkljMQggQKGAuESU8ChGw/GAECAQEBAQE?= =?us-ascii?q?BAWsohR4BAQQBASEPATsbCQIYAgImAgInMAYBDAYCAQGKGRCMT51ngieLOgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARsFgQ+CH4IHgVGCFQuCdYE9gzAYgxOCYQWRSJADlGu?= =?us-ascii?q?LZocylXCBOR84gVlVJRVJgmSCaIITJDaKbAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,393,1503360000"; d="scan'208";a="307256794"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Oct 2017 02:07:26 +0000
Received: from [10.82.221.231] (rtp-vpn3-1505.cisco.com [10.82.221.231]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9I27PHD006479; Wed, 18 Oct 2017 02:07:25 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References:  
From: Joe Clarke 
Organization: Cisco
Message-ID: 
Date: Tue, 17 Oct 2017 22:07:25 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
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] problems with compiling ietf-access-control-list@2017-10-03.yang
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Oct 2017 02:07:29 -0000

On 10/17/17 12:02, M. Ranganathan wrote:
> I am not sure if this is the correct thing to be doing as I am quite new
> to YANG -- so my mail here may mislead others who are likewise quite new
> to YANG.
> 
> Anyway, I was able to correct this problem by making the following change:

It seems the diff below is backwards.  That is, you removed the relative
XPaths and added a fully-qualified one?

I recently received some feedback from a YANG Doctor that unless you're
going one or two levels back, relative XPaths are fraught with issues.
You should use fully-qualified paths as they look cleaner and are easier
to grok.  Therefore, I think your change is a good one.

Of course, as we get YANG Doc feedback on this, I'm sure things like
this will shake out.

Joe

> 
> 
> 
> Here is the diff
> 
> @@ -291,7 +291,7 @@ module ietf-access-control-list {
>  
>          leaf set-name {
>            type leafref {
> -            path "/access-lists/acl/acl-name";
> +            path "../../../../../../acl/acl-name";
>            }
>            description
>              "Reference to the ACL set name applied on ingress";
> @@ -299,7 +299,7 @@ module ietf-access-control-list {
>  
>          leaf type {
>            type leafref {
> -            path "/access-lists/acl/acl-type";
> +            path "../../../../../../acl/acl-type";
>            }
>            description
>              "Reference to the ACL set type applied on ingress";
> @@ -312,7 +312,7 @@ module ietf-access-control-list {
>              "List of access list entries(ACE)";
>            leaf rule-name {
>              type leafref {
> -              path "/access-lists/acl/aces/ace/rule-name";
> +              path "../../../../../../../acl/aces/ace/rule-name";
>              }
>              description
>                "The ace rule-name";
> 
> =============================================================
> 
> 
> 
> Here is the changed portion of the file after applying the diff:
> 
> 
> 
> 
> grouping interface-acl {
>     description
>       "Grouping for per-interface ingress ACL data";
> 
>     container acl-sets {
>       description
>         "Enclosing container the list of ingress ACLs on the
>          interface";
> 
>       list acl-set {
>         key "set-name type";
>         ordered-by user;
>         description
>           "List of ingress ACLs on the interface";
> 
>         leaf set-name {
>           type leafref {
>             path "/access-lists/acl/acl-name";
>           }
>           description
>             "Reference to the ACL set name applied on ingress";
>         }
> 
>         leaf type {
>           type leafref {
>             path "/access-lists/acl/acl-type";
>           }
>           description
>             "Reference to the ACL set type applied on ingress";
>         }
> 
>         list ace {
>           if-feature "interface-stats or interface-acl-aggregate";
>           key "rule-name";
>           description
>             "List of access list entries(ACE)";
>           leaf rule-name {
>             type leafref {
>               path "/access-lists/acl/aces/ace/rule-name";
>             }
>             description
>               "The ace rule-name";
>           }
>           uses acl-counters;
>         }
>       }
>     }
>   }
> 
> 
> Take with a grain of salt. I could be way off mark here.
> 
> 
> 
> Thanks,
> 
> Ranga
> 
> 
> 
> 
>  
> 
> 
> 
> -- 
> M. Ranganathan
> 
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> 


From nobody Wed Oct 18 14:56: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 47B2513308D for ; Wed, 18 Oct 2017 14:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level: 
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 D7TEqinMfxsp for ; Wed, 18 Oct 2017 14:56:33 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F5B13292A for ; Wed, 18 Oct 2017 14:56:33 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id b189so12348748wmd.4 for ; Wed, 18 Oct 2017 14:56:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=jCvfx1l2qfNW9gydE1Ogg+OsquyNwyht9C/3UhozbZU=; b=bbwpj2SoMYbVbRqBetgy7v3pj4N45qwuVR/5+TEQ9m1knxCxGCuftHXqNoTBVj1784 ejnttxRHy36SPa4lkxPRvcBmQAoqYfM5mWpb7lTrLAgQLIa5h2DqB2DXWhNk6dD5RAza GlLNe0itCm+LFUY4tvVQa6y3CY0mBfOY/RQJkoC/CWHEn1/tO1tnNLMYoDeqfKcukiON g8cUVS608v0O2j0IJMmL0ZrlDpLsc03iV+BGTSO4q60mSwlpGtQu9FZe+MkkvVkliQQI gRbwHrrEkxN5JPfXhMB+57KfX/+P0OPwuhuWUudoU75dtZGnTWRPqswP11VBJ0kT1ke1 t+tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jCvfx1l2qfNW9gydE1Ogg+OsquyNwyht9C/3UhozbZU=; b=NmaU9BNL/xOa5cdC05pK02UUCjdmHsz9d6RPMe9Hmct0arkE5UzP4gfbrHE+hGzQHq 1jGU6VfEcsDNPO3kgVjj2DIYmm5Vg/pnqRS33EtccAPlFPZ6v5E351o5WqIMfSXlDLv9 vQZ3B/ZPLfX1aixvMAmao0GNx5GMy+JQx9qzBbGXPaHqy6FrMYCJJ+bsTg5rzyRUahiz 6EdxpsFT8kpU+VL3LX15iAcWoVoUygHxE3M8vZSwxzL4FBm1UhjDSLqiW/PlSAmwaP8L zjWV5aBEcMNu4nPgdJiPSbzQrhoE7UwuOQWgsJoLLlWuem5hHE/wSiXBpkmCrrh+o4rk sdyA==
X-Gm-Message-State: AMCzsaU4hdLKja9F4j9TlNgL4dj1fZB9hY/tHWhw2do9px1CxPkHysEH RcEqBYTi751rZR7m/KtoVhcvU9PaAbfQXBF2/ogIEQ==
X-Google-Smtp-Source: ABhQp+T9wEB74YzAcJ/sF4nM9ka2ZWkxO24YMHBkv72Fpj/aJV08luIpVASKj2g6lAMKnrgIvW33XxnBKqxry4Z9qkw=
X-Received: by 10.28.232.80 with SMTP id f77mr8386634wmh.1.1508363791235; Wed, 18 Oct 2017 14:56:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Wed, 18 Oct 2017 14:55:50 -0700 (PDT)
From: "M. Ranganathan" 
Date: Wed, 18 Oct 2017 17:55:50 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1146580ef7fd24055bd94f49"
Archived-At: 
Subject: [OPSAWG] MUD : ACE with BOTH controller and src-dnsname
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, 18 Oct 2017 21:56:34 -0000

--001a1146580ef7fd24055bd94f49
Content-Type: text/plain; charset="UTF-8"

This is a made up example.

Is the following ACE valid for MUD?

     "matches": {
                "ietf-mud:mud-acl": {
                  "controller": "urn:ietf:params:mud:dns"
                },
                "ipv4-acl": {
                  "ietf-acldns:src-dnsname": "www.nist.gov",
                  "protocol": 6,
                  "source-port-range": {
                    "lower-port": 53,
                    "upper-port": 53
                  }
                },
                "tcp-acl": {
                  "ietf-mud:direction-initiated": "from-device"
                }
              }

This ACL has both a controller AND dns-name ACL.

Presumably the controller would take precedence and the dnsname must be
ignored (?)

Thank you in advance for your clarification.

Ranga



-- 
M. Ranganathan

--001a1146580ef7fd24055bd94f49
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGRpdiBkaXI9Imx0ciI+PGRpdj48ZGl2PjxkaXY+PGRpdj5UaGlzIGlzIGEgbWFkZSB1cCBleGFt
cGxlLiA8YnI+PGJyPklzIHRoZSBmb2xsb3dpbmcgQUNFIHZhbGlkIGZvciBNVUQ/PGJyPjxicj7C
oMKgwqDCoCAmcXVvdDttYXRjaGVzJnF1b3Q7OiB7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCAmcXVvdDtpZXRmLW11ZDptdWQtYWNsJnF1b3Q7OiB7PGJyPsKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgJnF1b3Q7Y29udHJvbGxlciZxdW90OzogJnF1b3Q7dXJuOmll
dGY6cGFyYW1zOm11ZDpkbnMmcXVvdDs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IH0sPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAmcXVvdDtpcHY0LWFjbCZxdW90
Ozogezxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICZxdW90O2lldGYtYWNs
ZG5zOnNyYy1kbnNuYW1lJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwOi8vd3d3Lm5pc3QuZ292
Ij53d3cubmlzdC5nb3Y8L2E+JnF1b3Q7LDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgICZxdW90O3Byb3RvY29sJnF1b3Q7OiA2LDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgICZxdW90O3NvdXJjZS1wb3J0LXJhbmdlJnF1b3Q7OiB7PGJyPsKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICZxdW90O2xvd2VyLXBvcnQmcXVvdDs6IDUz
LDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAmcXVvdDt1cHBlci1w
b3J0JnF1b3Q7OiA1Mzxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH08YnI+
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0sPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCAmcXVvdDt0Y3AtYWNsJnF1b3Q7OiB7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgJnF1b3Q7aWV0Zi1tdWQ6ZGlyZWN0aW9uLWluaXRpYXRlZCZxdW90Ozog
JnF1b3Q7ZnJvbS1kZXZpY2UmcXVvdDs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IH08YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfTxicj48YnI+PC9kaXY+VGhpcyBBQ0wg
aGFzIGJvdGggYSBjb250cm9sbGVyIEFORCBkbnMtbmFtZSBBQ0wuPGJyPjxicj48L2Rpdj5QcmVz
dW1hYmx5IHRoZSBjb250cm9sbGVyIHdvdWxkIHRha2UgcHJlY2VkZW5jZSBhbmQgdGhlIGRuc25h
bWUgbXVzdCBiZSBpZ25vcmVkICg/KTxicj48YnI+PC9kaXY+VGhhbmsgeW91IGluIGFkdmFuY2Ug
Zm9yIHlvdXIgY2xhcmlmaWNhdGlvbi48YnI+PGJyPjwvZGl2PlJhbmdhPGJyPjxkaXY+PGRpdj48
YnI+PGJyIGNsZWFyPSJhbGwiPjxkaXY+PGRpdj48ZGl2Pjxicj4tLSA8YnI+PGRpdiBjbGFzcz0i
Z21haWxfc2lnbmF0dXJlIj5NLiBSYW5nYW5hdGhhbjxicj48L2Rpdj4NCjwvZGl2PjwvZGl2Pjwv
ZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pg0K
--001a1146580ef7fd24055bd94f49--


From nobody Wed Oct 18 15:20:36 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 C702513433C for ; Wed, 18 Oct 2017 15:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 nSg0lz5QHWlZ for ; Wed, 18 Oct 2017 15:20:33 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 F2A131320B5 for ; Wed, 18 Oct 2017 15:20:32 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id b189so12426038wmd.4 for ; Wed, 18 Oct 2017 15:20:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=fdnKXNi0g4tvlshluCzHD5OTMDuD7ihlSSRCRJjB2lo=; b=LpVpijBiERS1YxqMOK9KNsH1eQb3uO4xd1cWh4Z5OUglA+cNGleCZNJEdQy5WhU3iH I83zGaFxP3waz6hlIBPilqzyH8jRhFbKcPKBoy14wVOA+yMi9laxQLA8rfIB9F25Ivd4 DNMrntNf0q1C/Ct8gtVzN11TAA1zQ6hrOk78tsXQ5ReMm78OkqMX2CUMDIPFqaIunp6k XCgQiWNPOnH8gI9yJBW4iKtOgUqQvmcLUkcqtaL2NpeDByv1vCw9HUzd3vDmd6KwgvRw 22tYEPzLyQoqxLl86SG0IuvB2zvyXRPple8pXkBF5tSALzgHknxlSZc857h2BzqfLhfN jpSg==
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=fdnKXNi0g4tvlshluCzHD5OTMDuD7ihlSSRCRJjB2lo=; b=pwG039DuKmIElg2pyhY2/L3vFlR8M7a/YTjv1dgYQ7zX1KWHkEKceRFB84Y3cUnEUa p+gQdqntAWD3oQ1f9fAgoxl1Rxo0ywCB4HLV4wg1iGY7r8tanB6rwUGY4UBPq4jmAQHA dRM5IqjYD69elk5EmiZ7XiF6Wo55t/78ZbO3e4T8VugO7zEv6PM9xE2QkMZiR0zkFzJZ d33gkDal88OTLpi9iR4NIQQhY6sGpZlBCz2mUL7AcyHgZjmrrZ4so+uRxCRNtA+yFfX1 Kq84Di9kh8rfb0yjQldsRK5vkaDG/aqro7/jdpKl29uFRYgUAKnzeJ1OMc73P0sJqq/w 4RQQ==
X-Gm-Message-State: AMCzsaVweplLNE+OsBlPDar5g87eSxyV7IBA+0ZHB3i1u89mMR2uXPmw u2j0ihb9z9L2jYcwTSWceMqu4vqT6DHQvdlPVO0=
X-Google-Smtp-Source: ABhQp+SGwN1Ml6aLfMnPiHRAM7SnOUn26rwMCdv6I+bb+RuemIMyZ/Xq5HrSgQI5SthhbVRERoyIm9HzsrOgymVhjyc=
X-Received: by 10.28.232.80 with SMTP id f77mr8427048wmh.1.1508365231069; Wed, 18 Oct 2017 15:20:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Wed, 18 Oct 2017 15:19:50 -0700 (PDT)
From: "M. Ranganathan" 
Date: Wed, 18 Oct 2017 18:19:50 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1146580eca1e2e055bd9a5c9"
Archived-At: 
Subject: [OPSAWG] MUD: Why reserve names for "well-known" controllers
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, 18 Oct 2017 22:20:35 -0000

--001a1146580eca1e2e055bd9a5c9
Content-Type: text/plain; charset="UTF-8"

Hello MUD authors,

DNS and NTP have reserved URI names. However, it appears you need to
specify a full ACL for both of these. In that case, why reserve the name?
Is it just for clarity?

Thanks

-- 
M. Ranganathan

--001a1146580eca1e2e055bd9a5c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello MUD authors,

DNS and NTP have=
 reserved URI names. However, it appears you need to specify a full ACL for=
 both of these. In that case, why reserve the name? Is it just for clarity?=


Thanks

-- 
M. Ranganathan




--001a1146580eca1e2e055bd9a5c9--


From nobody Wed Oct 18 15:27: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 DD9C11321A1 for ; Wed, 18 Oct 2017 15:27:43 -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 JP_w-L6iW6oK for ; Wed, 18 Oct 2017 15:27:42 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172F013292A for ; Wed, 18 Oct 2017 15:27:42 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id l68so12829155wmd.5 for ; Wed, 18 Oct 2017 15:27:42 -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;  bh=taZ6aF71WAnJNQ76mOUDhsp4u3vKqWR7U1UPLolkZhA=; b=BjabdbX2Dg0CdQeh72Z8X/0wvoELIhdYgR05PodC+CaNw2Air+ri9csJfNDKnLb4on dFAWJDc6AWkt+V3wBpUsKRxhPu3ILN3uJC41FG90gIaqCuwYqpJc/czYCK7F1QjXN+ch CW2He9YaUr/n/rLeWsk38VlRuOAFqY8+pS31LXNsmS1fiai0kfYeFtAZ1gJZANgzcdup lpt35FZxkru+b1TRO7vxnKYFlrINbv2bV9oKM7xX7wtJNwvYp/M3+R12zExx6VtYQ2tC Knq1ahG/ExNrLSMyz+RmyfpQVJD/wDaU1e3iyKvdbgZji7QgK+pNKg/osTIj0RmaYTe3 4ebA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=taZ6aF71WAnJNQ76mOUDhsp4u3vKqWR7U1UPLolkZhA=; b=QOjw79rdpY+RYYiTPHOHVCwmQr8tHMYV1n+yL+kqKN4HIrbU6OuB1DVTjo6Hj95aSA 884waEhIoT3MyCeMsB+CKFFWHBjzzQNLpvo30Gx+nPY1Kz12OR5lOL0gKvUxlXpdtKd2 5tvEh0zTaWye/zza0f4CnWy6EH2ByJWBcOrnZKa0Two7AYzvuUrTXMTqPZFMc55bfKjV 5rdbC6EDg/3PdhnjK3N5MTdZkYCidZDcVuaN5hxszutABucvXQacspc8ln1pI46zMg2I +kDjgEudYLZHlOt8TwFB/h7oFjLWQcm7mWnggzZXYsF2CH8RQAfz6liVAQZmuVx7o/3O 9mFw==
X-Gm-Message-State: AMCzsaU0YbPb6rMqGKdr4DKWBw2dEma/HwRnxzJprBzOirROlXdeXC7V eQICBlTJjv3cFF9mlnmB/Jm1+tJV8XrtVzwP11s=
X-Google-Smtp-Source: ABhQp+S6hTIPiOt0smHcjGSboqGsHYJDwgAgTdqbTVDOcM9uj8RQb++Qf1N494lQs5ysik96M/bF28/Ae6C/vs+Az7k=
X-Received: by 10.28.232.80 with SMTP id f77mr8438851wmh.1.1508365660361; Wed, 18 Oct 2017 15:27:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Wed, 18 Oct 2017 15:26:59 -0700 (PDT)
In-Reply-To: 
References: 
From: "M. Ranganathan" 
Date: Wed, 18 Oct 2017 18:26:59 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1146580e60984e055bd9bf4c"
Archived-At: 
Subject: Re: [OPSAWG] MUD : ACE with BOTH controller and src-dnsname
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, 18 Oct 2017 22:27:44 -0000

--001a1146580e60984e055bd9bf4c
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 18, 2017 at 5:55 PM, M. Ranganathan  wrote:

> This is a made up example.
>
> Is the following ACE valid for MUD?
>
>      "matches": {
>                 "ietf-mud:mud-acl": {
>                   "controller": "urn:ietf:params:mud:dns"
>                 },
>                 "ipv4-acl": {
>                   "ietf-acldns:src-dnsname": "www.nist.gov",
>                   "protocol": 6,
>                   "source-port-range": {
>                     "lower-port": 53,
>                     "upper-port": 53
>                   }
>                 },
>                 "tcp-acl": {
>                   "ietf-mud:direction-initiated": "from-device"
>                 }
>               }
>
> This ACL has both a controller AND dns-name ACL.
>
> Presumably the controller would take precedence and the dnsname must be
> ignored (?)
>
> Thank you in advance for your clarification.
>
> Ranga
>
>
>

A third alternative would be to take the UNION of the two.

Thanks,

>
> --
> M. Ranganathan
>



-- 
M. Ranganathan

--001a1146580e60984e055bd9bf4c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGRpdiBkaXI9Imx0ciI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFz
cz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgT2N0IDE4LCAyMDE3IGF0IDU6NTUgUE0sIE0uIFJhbmdh
bmF0aGFuIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1yYW5nYUBnbWFpbC5j
b20iIHRhcmdldD0iX2JsYW5rIj5tcmFuZ2FAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdyb3Rl
Ojxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg
LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGRp
cj0ibHRyIj48ZGl2PjxkaXY+PGRpdj48ZGl2PlRoaXMgaXMgYSBtYWRlIHVwIGV4YW1wbGUuIDxi
cj48YnI+SXMgdGhlIGZvbGxvd2luZyBBQ0UgdmFsaWQgZm9yIE1VRD88YnI+PGJyPsKgwqDCoMKg
ICZxdW90O21hdGNoZXMmcXVvdDs6IHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
ICZxdW90O2lldGYtbXVkOm11ZC1hY2wmcXVvdDs6IHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCAmcXVvdDtjb250cm9sbGVyJnF1b3Q7OiAmcXVvdDt1cm46aWV0ZjpwYXJh
bXM6bXVkOmRucyZxdW90Ozxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfSw8YnI+
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICZxdW90O2lwdjQtYWNsJnF1b3Q7OiB7PGJy
PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgJnF1b3Q7aWV0Zi1hY2xkbnM6c3Jj
LWRuc25hbWUmcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHA6Ly93d3cubmlzdC5nb3YiIHRhcmdl
dD0iX2JsYW5rIj53d3cubmlzdC5nb3Y8L2E+JnF1b3Q7LDxicj7CoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgICZxdW90O3Byb3RvY29sJnF1b3Q7OiA2LDxicj7CoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgICZxdW90O3NvdXJjZS1wb3J0LXJhbmdlJnF1b3Q7OiB7PGJy
PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICZxdW90O2xvd2VyLXBvcnQm
cXVvdDs6IDUzLDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAmcXVv
dDt1cHBlci1wb3J0JnF1b3Q7OiA1Mzxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIH08YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0sPGJyPsKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCAmcXVvdDt0Y3AtYWNsJnF1b3Q7OiB7PGJyPsKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgJnF1b3Q7aWV0Zi1tdWQ6ZGlyZWN0aW9uLWluaXRpYXRl
ZCZxdW90Ozx3YnI+OiAmcXVvdDtmcm9tLWRldmljZSZxdW90Ozxicj7CoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgfTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9PGJyPjxicj48
L2Rpdj5UaGlzIEFDTCBoYXMgYm90aCBhIGNvbnRyb2xsZXIgQU5EIGRucy1uYW1lIEFDTC48YnI+
PGJyPjwvZGl2PlByZXN1bWFibHkgdGhlIGNvbnRyb2xsZXIgd291bGQgdGFrZSBwcmVjZWRlbmNl
IGFuZCB0aGUgZG5zbmFtZSBtdXN0IGJlIGlnbm9yZWQgKD8pPGJyPjxicj48L2Rpdj5UaGFuayB5
b3UgaW4gYWR2YW5jZSBmb3IgeW91ciBjbGFyaWZpY2F0aW9uLjxicj48YnI+PC9kaXY+UmFuZ2E8
c3BhbiBjbGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPjxkaXY+PGRpdj48
YnI+PGJyIGNsZWFyPSJhbGwiPjwvZGl2PjwvZGl2PjwvZm9udD48L3NwYW4+PC9kaXY+PC9ibG9j
a3F1b3RlPjxkaXY+PGJyPjxicj48L2Rpdj48ZGl2PkEgdGhpcmQgYWx0ZXJuYXRpdmUgd291bGQg
YmUgdG8gdGFrZSB0aGUgVU5JT04gb2YgdGhlIHR3by48YnI+PGJyPjwvZGl2PjxkaXY+VGhhbmtz
LCA8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu
OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+
PGRpdiBkaXI9Imx0ciI+PHNwYW4gY2xhc3M9IkhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4ODgi
PjxkaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48YnI+LS0gPGJyPjxkaXYgY2xhc3M9Im1fNDYxODEz
MTgxODQzNjE3ODA4MGdtYWlsX3NpZ25hdHVyZSI+TS4gUmFuZ2FuYXRoYW48YnI+PC9kaXY+DQo8
L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj48ZGl2IGNsYXNzPSJn
bWFpbF9zaWduYXR1cmUiIGRhdGEtc21hcnRtYWlsPSJnbWFpbF9zaWduYXR1cmUiPk0uIFJhbmdh
bmF0aGFuPGJyPjwvZGl2Pg0KPC9kaXY+PC9kaXY+DQo=
--001a1146580e60984e055bd9bf4c--


From nobody Wed Oct 18 18:08: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 8DC5813314B for ; Wed, 18 Oct 2017 18:08:42 -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 NjLSRZccfzOe for ; Wed, 18 Oct 2017 18:08:40 -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 18669132351 for ; Wed, 18 Oct 2017 18:08:39 -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 DYA19909; Thu, 19 Oct 2017 01:08:37 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 19 Oct 2017 02:08:36 +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; Thu, 19 Oct 2017 09:08:29 +0800
From: Tianran Zhou 
To: "mohamed.boucadair@orange.com" , "Benoit Claise" , "opsawg@ietf.org" 
CC: JACQUENET Christian IMT/OLN 
Thread-Topic: [OPSAWG] New Version Notification for draft-ietf-opsawg-nat-yang-06.txt
Thread-Index: AQHTQ2K5oECyfHfAiUGvFia9FzuBL6LgP3JQgAWFa4CAAdyxgIACxHLw
Date: Thu, 19 Oct 2017 01:08:29 +0000
Message-ID: 
References: <150781694088.16824.7345333598884165729.idtracker@ietfa.amsl.com>  <0554b9c0-9c8b-edb2-cd4d-09381bf86780@cisco.com> <105a1415-8296-455e-99c5-7f6724484d90@OPEXCLILM44.corporate.adroot.infra.ftgroup>
In-Reply-To: <105a1415-8296-455e-99c5-7f6724484d90@OPEXCLILM44.corporate.adroot.infra.ftgroup>
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.0A0B0204.59E7FB16.004C, 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: 71c717dbf2e6807379954e90582bbd37
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-nat-yang-06.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, 19 Oct 2017 01:08:42 -0000

V2UgaGF2ZSBhcHBsaWVkIHRoZSBZQU5HIGRvY3RvciBlYXJseSByZXZpZXcuIEFuZCBpdCdzIGJl
dHRlciB0byBwcmVzZW50IGN1cnJlbnQgc3RhdHVzIG9mIHRoZSBkcmFmdCBvbiB0aGUgY29taW5n
IG1lZXRpbmcuDQpTbyB0aGF0IHdlIGNhbiBnZXQgYW5vdGhlciByb3VuZCByZXZpc2lvbiBiZWZv
cmUgdGhlIGxhc3QgY2FsbC4NCg0KUmVnYXJkcywNClRpYW5yYW4NCg0KPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPUFNBV0cgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gU2Vu
dDogVHVlc2RheSwgT2N0b2JlciAxNywgMjAxNyAxMDo1MCBQTQ0KPiBUbzogQmVub2l0IENsYWlz
ZTsgb3BzYXdnQGlldGYub3JnDQo+IENjOiBKQUNRVUVORVQgQ2hyaXN0aWFuIElNVC9PTE4NCj4g
U3ViamVjdDogUmU6IFtPUFNBV0ddIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJh
ZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmctMDYudHh0DQo+IA0KPiBIaSBCZW5vaXQsDQo+IA0KPiBU
aGFuayB5b3UgZm9yIHRoaXMgY2xhcmlmaWNhdGlvbi4NCj4gDQo+IElmIEp1ZXJnZW4gaXMgT0sg
dG8gcHJvdmlkZSBoaXMgcmV2aWV3IGJlZm9yZSB0aGUgV0dMQywgSSB3b3VsZCBwcmVmZXIgdG8N
Cj4gZ28gdGhhdCBwYXRoLiBUaGF0IGlzLCB3YWl0IGZvciBoaXMgZWFybHkgcmV2aWV3LCBmaXgg
YW55IGNvbW1lbnRzIGZyb20NCj4gSnVlcmdlbiwgYW5kIHRoZW4gZ28gZm9yIGEgbGFzdCBjYWxs
Lg0KPiANCj4gT2J2aW91c2x5LCB0aGlzIGlzIG9ubHkgbXkgcHJlZmVyZW5jZSBhcyBhbiBlZGl0
b3IuIEkgd2lsbCBkZWZlciB0byB0aGUNCj4gY2hhaXJzIHRvIGRlY2lkZS4NCj4gDQo+IENoZWVy
cywNCj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERlwqA6
IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2NvLmNvbV0gRW52b3nDqcKgOiBsdW5k
aSAxNg0KPiA+IG9jdG9icmUgMjAxNyAxMjoyNCDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQv
T0xOOyBvcHNhd2dAaWV0Zi5vcmcgQ2PCoDoNCj4gPiBKQUNRVUVORVQgQ2hyaXN0aWFuIElNVC9P
TE47IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBPYmpldMKgOiBSZToNCj4gPiBbT1BTQVdHXSBOZXcg
VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb3BzYXdnLW5hdC0NCj4gPiB5YW5n
LTA2LnR4dA0KPiA+DQo+ID4gRGVhciBhbGwsDQo+ID4NCj4gPiBIaXN0b3JpY2FsbHksIHRoZSBN
SUIgZG9jdG9yIHJldmlld3Mgd291bGQgaGFwcGVuIGR1cmluZyBJRVRGIExDLg0KPiA+IEJlY2F1
c2UgWUFORyB3YXMgbmV3LCB3ZSBzdGFydGVkIGVhcmx5IFlBTkcgZG9jdG9yIHJldmlld3MuIFRo
b3NlDQo+ID4gcmV2aWV3cyBkb24ndCBoYXZlIHRvIG9jY3VyIGluIHNlcXVlbmNlLCBpLmUuIGJl
Zm9yZSB0aGUgSUVURiBMQyBzdGFydHMuDQo+ID4gSW4gZmFjdCwgYXQgc29tZSBwb2ludCBpbiB0
aW1lIGluIHRoZSBmdXR1cmUgKHdoZW4gdGhlIFlBTkcga25vd2xlZGdlDQo+ID4gd2lsbCBiZSB3
aWRlbHkgc3ByZWFkKSwgdGhlIFlBTkcgZG9jdG9yIHJldmlld3Mgd2lsbCBiZSB0cmlnZ2VyZWQg
YnkNCj4gPiB0aGUgSUVURiBMQy4NCj4gPiBCb3R0b20gbGluZTogaWYgdGhlIE9QU0FXRyBjaGFp
cnMgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IGlzIHJlYWR5LCBpdA0KPiA+IGNhbiBwcm9ncmVzcyB0
byBJRVRGIExDIG5vdy4NCj4gPg0KPiA+IFJlZ2FyZHMsIEJlbm9pdC4NCj4gPiA+IERlYXIgYWxs
LA0KPiA+ID4NCj4gPiA+IFRoZSBuZXcgdmVyc2lvbiBmaXhlcyBzb21lIGNvc21ldGljIGlzc3Vl
cyAobWFpbmx5LCBpbmRlbnRhdGlvbiBvZg0KPiA+ID4gdGhlDQo+ID4gWUFORyBtb2R1bGUpIGFu
ZCBwb2ludHMgdG8gWUFORzEuMSBSRkMgYXMgcGVyIGEgY29tbWVudCByZWNlaXZlZCBmcm9tDQo+
ID4gTWFoZXNoIEpldGhhbmFuZGFuaS4NCj4gPiA+DQo+ID4gPiBXZSBhcmUgd2FpdGluZyBmb3Ig
dGhlIHlhbmcgZG9jdG9ycyByZXZpZXcuDQo+ID4gPg0KPiA+ID4gQ2hlZXJzLA0KPiA+ID4gTWVk
DQo+ID4gPg0KPiA+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ID4+IERlwqA6
IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y
Z10NCj4gPiA+PiBFbnZvecOpwqA6IGpldWRpIDEyIG9jdG9icmUgMjAxNyAxNjowMiDDgMKgOiBR
aW4gV3U7IFNlbnRoaWwgU2l2YWt1bWFyOw0KPiA+ID4+IEJPVUNBREFJUiBNb2hhbWVkIElNVC9P
TE47IFN1cmVzaCBWaW5hcGFtdWxhOyBKQUNRVUVORVQgQ2hyaXN0aWFuDQo+ID4gPj4gSU1UL09M
TiBPYmpldMKgOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gPj4gZHJhZnQtaWV0
Zi1vcHNhd2ctbmF0LXlhbmctMDYudHh0DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IEEgbmV3IHZl
cnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wNi50eHQgaGFzIGJlZW4N
Cj4gPiA+PiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1vaGFtZWQgQm91Y2FkYWlyIGFuZCBw
b3N0ZWQgdG8gdGhlIElFVEYNCj4gPiA+PiByZXBvc2l0b3J5Lg0KPiA+ID4+DQo+ID4gPj4gTmFt
ZToJCWRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nDQo+ID4gPj4gUmV2aXNpb246CTA2DQo+ID4g
Pj4gVGl0bGU6CQlBIFlBTkcgRGF0YSBNb2RlbCBmb3IgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0
aW9uIChOQVQpDQo+ID4gPj4gYW5kIE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0aW9uIChOUFQpDQo+
ID4gPj4gRG9jdW1lbnQgZGF0ZToJMjAxNy0xMC0xMQ0KPiA+ID4+IEdyb3VwOgkJb3BzYXdnDQo+
ID4gPj4gUGFnZXM6CQk3OA0KPiA+ID4+IFVSTDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50
ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb3BzYXdnLQ0KPiA+ID4+IG5hdC15YW5nLTA2LnR4dA0K
PiA+ID4+IFN0YXR1czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt
aWV0Zi1vcHNhd2ctbmF0LQ0KPiA+ID4+IHlhbmcvDQo+ID4gPj4gSHRtbGl6ZWQ6DQo+IGh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0NCj4gPiAw
Ng0KPiA+ID4+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9odG1sL2RyYWZ0LWlldGYtDQo+ID4gb3BzYXdnLQ0KPiA+ID4+IG5hdC15YW5nLTA2DQo+ID4g
Pj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm
dC1pZXRmLW9wc2F3Zy0NCj4gPiBuYXQtDQo+ID4gPj4geWFuZy0wNg0KPiA+ID4+DQo+ID4gPj4g
QWJzdHJhY3Q6DQo+ID4gPj4gICAgIEZvciB0aGUgc2FrZSBvZiBuZXR3b3JrIGF1dG9tYXRpb24g
YW5kIHRoZSBuZWVkIGZvciBwcm9ncmFtbWluZw0KPiA+ID4+ICAgICBOZXR3b3JrIEFkZHJlc3Mg
VHJhbnNsYXRpb24gKE5BVCkgZnVuY3Rpb24gaW4gcGFydGljdWxhciwgYSBkYXRhDQo+ID4gPj4g
ICAgIG1vZGVsIGZvciBjb25maWd1cmluZyBhbmQgbWFuYWdpbmcgdGhlIE5BVCBpcyBlc3NlbnRp
YWwuICBUaGlzDQo+ID4gPj4gICAgIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIG1vZHVsZSBmb3Ig
dGhlIE5BVCBmdW5jdGlvbi4NCj4gPiA+Pg0KPiA+ID4+ICAgICBOQVQ0NCwgTmV0d29yayBBZGRy
ZXNzIGFuZCBQcm90b2NvbCBUcmFuc2xhdGlvbiBmcm9tIElQdjYNCj4gPiA+PiBDbGllbnRzDQo+
ID4gdG8NCj4gPiA+PiAgICAgSVB2NCBTZXJ2ZXJzIChOQVQ2NCksIEN1c3RvbWVyLXNpZGUgdHJh
bnNMQVRvciAoQ0xBVCksIEV4cGxpY2l0DQo+ID4gPj4gICAgIEFkZHJlc3MgTWFwcGluZ3MgZm9y
IFN0YXRlbGVzcyBJUC9JQ01QIFRyYW5zbGF0aW9uIChTSUlUIEVBTSksIGFuZA0KPiA+ID4+ICAg
ICBJUHY2IE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0aW9uIChOUFR2NikgYXJlIGNvdmVyZWQgaW4g
dGhpcw0KPiA+IGRvY3VtZW50Lg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4g
Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g
dGhlIHRpbWUgb2YNCj4gPiA+PiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u
IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPiA+PiB0b29scy5pZXRmLm9yZy4NCj4gPiA+
Pg0KPiA+ID4+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4gPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT1BTQVdHIG1haWxpbmcgbGlzdA0K
PiA+ID4gT1BTQVdHQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29wc2F3Zw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4gT1BTQVdHIG1haWxpbmcgbGlzdA0KPiBPUFNBV0dAaWV0Zi5vcmcN
Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg==


From nobody Thu Oct 19 02:41:42 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 564141348BD; Thu, 19 Oct 2017 02:41:35 -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.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150840609532.18951.2211394851243863603@ietfa.amsl.com>
Date: Thu, 19 Oct 2017 02:41:35 -0700
Archived-At: 
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-bgp-community-03.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, 19 Oct 2017 09:41:35 -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           : Export BGP community information in IP Flow Information Export (IPFIX)
        Authors         : Zhenqiang Li
                          Rong Gu
                          Jie Dong
	Filename        : draft-ietf-opsawg-ipfix-bgp-community-03.txt
	Pages           : 17
	Date            : 2017-10-19

Abstract:
   This draft updates RFC7012 IPFIX information model by introducing
   several information elements to enable IPFIX to export the BGP
   community information, including BGP standard community defined in
   RFC1997, BGP extended community defined in RFC4360, and BGP large
   community defined in RFC8092.  Network traffic flow information can
   then be accumulated and analysed at the granularity specified by the
   BGP communities, which is suitable for and needed by some traffic
   optimization applications located in IPFIX collector, SDN controller
   or PCE (Path Computation Element).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-03
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-bgp-community-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-bgp-community-03


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

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


From nobody Thu Oct 19 07:29: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 038691342E1 for ; Thu, 19 Oct 2017 07:29:31 -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 HwLXk06BrNKC for ; Thu, 19 Oct 2017 07:29:29 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 593241320D9 for ; Thu, 19 Oct 2017 07:29:29 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id j14so8547386wre.8 for ; Thu, 19 Oct 2017 07:29:29 -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;  bh=bb81/q2ddJLO2ba/vwLjlggsWz6CS9MnT19R4D51G/E=; b=nTLhngxxncS/sWynZoZsUKVYHSzUtJpzmW3/5Iq03ZnUYgbK7wY57Xt24+74Jdm7Ks LZyQouLNh4VwErzb5znYx5LP8Zehw0EvefwQbNxNalgz7PA/EE/QJ3aZPLNMPt1iMTk0 oCXZoZU+CK5RgGp6dUAz1V4LThb1jLAbtZs3CPa70lcDdS3wUzyGjnVFa1s3dzAIIKdC T3/6gNRuz89USs9DbiA8W3qekek2x66m9DfFzEvg9ivyFsc4zUnIk+1Sfd+zGEi8COAH Eqk7ejUb5gG2Fh1lYVqlfws2o0esj8dwTBCELjnbNpuXSeklQYzbiyaf3So7bUnaJn/m sRrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=bb81/q2ddJLO2ba/vwLjlggsWz6CS9MnT19R4D51G/E=; b=r+bgkwwIMrEERpFEu5LxIrIPqnGFZavzKmr2kRwcPudq6VdvV/OHmZa/L7KxoAyMbs hq561XjMTMcqqvwhqNpKGlzEMn2ihK7Mo3fISZYEe3yx7WQMmGpRuxS9qB6FXbyXxobn nwbY4XOFGwsKpi4qpV3Tm/Tfsq9n5FNwXEPhyvsoAI2yUXsmwuTHDKXiutdXzi9cD7m+ WN3gfoSWwBkrOhrg6CVN3Z6QUGcoXX1C3bu2NTx7BV/rB3XFjw32C9mgBTVm/gV9XUi4 xtI6yXvG0aSj4Vui0i0QuJMTtBo5ZxYRzV0nFA1+mfF7KIaWHJNfRglEG5XAEPVlnKX+ 1jVg==
X-Gm-Message-State: AMCzsaUW1Yv037DtsUaASgp9nSwRvERl4bsbHxXKh7fBUt3BkKQyevgT cPGHSI8jRUCnjGn2/BTs00CNi02MyN71EMj33SoNLg==
X-Google-Smtp-Source: ABhQp+QdTr11nFNBi4e1IFoV8y1C0fhaoNXwToZPWpCXYqV8eP0lfh0VhNtd8sKguGoOLSQZiPtzQajSdqHg+uddA4o=
X-Received: by 10.223.148.38 with SMTP id 35mr1949781wrq.49.1508423367306; Thu, 19 Oct 2017 07:29:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Thu, 19 Oct 2017 07:28:46 -0700 (PDT)
In-Reply-To: 
References: 
From: "M. Ranganathan" 
Date: Thu, 19 Oct 2017 10:28:46 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a114cb408fab36e055be72e3a"
Archived-At: 
Subject: Re: [OPSAWG] MUD: Why reserve names for "well-known" controllers
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, 19 Oct 2017 14:29:31 -0000

--001a114cb408fab36e055be72e3a
Content-Type: text/plain; charset="UTF-8"

Hello,



On Wed, Oct 18, 2017 at 6:19 PM, M. Ranganathan  wrote:

> Hello MUD authors,
>
> DNS and NTP have reserved URI names. However, it appears you need to
> specify a full ACL for both of these. In that case, why reserve the name?
> Is it just for clarity?
>
> Thanks
>
> --
> M. Ranganathan
>

On thinking things through carefully, I concluded that indeed it is
necessary to use a reserved URI for DNS  server. This is because SAME name
resolution has to be applied both by the device and the MUD controller.
This URI identifies the DNS  server used by the IOT device so that the MUD
controller may apply the same name resolution to the DNS ACLs that it
installs.

I am not clear in my mind about why this should be the case for NTP server
i.e. why do we reserve a special URN for NTP server? Why is it not just a
"controller" like every other one?

Thank you in advance for your clarifications.

Regards,

Ranga


-- 
M. Ranganathan

--001a114cb408fab36e055be72e3a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,



On Wed, Oct 18, 2017 at 6:19 PM, M. Ranganathan <mranga@g=
mail.com> wrote:
Hello MUD authors,

DNS a=
nd NTP have reserved URI names. However, it appears you need to specify a f=
ull ACL for both of these. In that case, why reserve the name? Is it just f=
or clarity?

Thanks

-- 
M. Ranganathan





On thinking things through carefully, I=20
concluded that indeed it is necessary to use a reserved URI for DNS=C2=A0=
=20
server. This is because SAME name resolution has to be applied both by the =
device=20
and the MUD controller. This URI identifies the DNS=C2=A0 server used
 by the IOT device so that the MUD controller may apply the same name=20
resolution to the DNS ACLs that it installs.

I
 am not clear in my mind about why this should be the case for NTP=20
server i.e. why do we reserve a special URN for NTP server? Why is it=20
not just a "controller" like every other one?

T=
hank you in advance for your clarifications.

Regards,
=

Ranga 


-- 
M. Ranganathan




--001a114cb408fab36e055be72e3a--


From nobody Thu Oct 19 13:44: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 D3FC6133091 for ; Thu, 19 Oct 2017 13:44:04 -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 3sqRFAIiilzB for ; Thu, 19 Oct 2017 13:44:03 -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 4AF8F132D89 for ; Thu, 19 Oct 2017 13:44:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2418; q=dns/txt; s=iport; t=1508445843; x=1509655443; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=HXwmy8fnDOF/ti0FxD8rxpuA1J/TTiZ7gMjuiHyNZr0=; b=EAtwjBM3gWcN+Fr5TNV1WF8Mc8LxfzHYzWKxl0UNbG6veQpFie2dYUHZ oLriEgDXC7ufcepalztR2YS2lwgeTV16z3rYWlz+kuOmYF0ddi9/tcS7W hZqc+UYnXaim0NNAuSFiTC1Sdsm6J0f3d0eHVLex6q/Ld7nln8MiCXWtr 0=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAADFDelZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhTGEIYofdJBFljOCFAcDhTsChUoYAQIBAQEBAQEBayiFHgEFI2Y?= =?us-ascii?q?LGCoCAlcGAQwIAQGKHKtDgieLIQEBAQEBAQQBAQEBAQEBEg+DL4VtgwOEb4Mqg?= =?us-ascii?q?mEFkUuQCIQ/giGOD4IUhXaDXIczlXSBOR84gVs0IQgdFYMuhGA+i0QBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,403,1503360000";  d="asc'?scan'208";a="656452679"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2017 20:44:01 +0000
Received: from [10.61.111.156] (dhcp-10-61-111-156.cisco.com [10.61.111.156]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9JKi1uQ027868;  Thu, 19 Oct 2017 20:44:01 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References:  
From: Eliot Lear 
Message-ID: <7c58847e-ef53-97f9-d19c-418f18dde23c@cisco.com>
Date: Thu, 19 Oct 2017 22:44:01 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vxv2082tmwX3TW5DG5kw6sSh6XSeunjpi"
Archived-At: 
Subject: Re: [OPSAWG] MUD: Why reserve names for "well-known" controllers
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, 19 Oct 2017 20:44:05 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vxv2082tmwX3TW5DG5kw6sSh6XSeunjpi
Content-Type: multipart/mixed; boundary="d4mimXGaU7dQVKo1xdpMvBnT4AopRJka0";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" , opsawg@ietf.org
Message-ID: <7c58847e-ef53-97f9-d19c-418f18dde23c@cisco.com>
Subject: Re: [OPSAWG] MUD: Why reserve names for "well-known" controllers
References: 
 
In-Reply-To: 

--d4mimXGaU7dQVKo1xdpMvBnT4AopRJka0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Ranga,

Sorry I've been quiet for a few days.=C2=A0 I'll have more to say later.=C2=
=A0
Please see below.


On 10/19/17 4:28 PM, M. Ranganathan wrote:
>
> I am not clear in my mind about why this should be the case for NTP ser=
ver
> i.e. why do we reserve a special URN for NTP server? Why is it not just=
 a
> "controller" like every other one?
>

The base assumption we had was that everyone needs name resolution and
time.=C2=A0 Also, if you standardize these names, it's easy for
implementations to simply fill in the values, if they happen to know
them.=C2=A0 So for instance, during install of your controller, you might=

simply ask, =E2=80=9CShould I include the local NTP servers I found in my=

ntp.conf files and DNS servers I found in /etc/resolve.conf?=E2=80=9D

Eliot


--d4mimXGaU7dQVKo1xdpMvBnT4AopRJka0--

--vxv2082tmwX3TW5DG5kw6sSh6XSeunjpi
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

iQEcBAEBCAAGBQJZ6Q6RAAoJEIe2a0bZ0nozXpYH/RNSZr5KlvxdBfMefsAGEncI
lbMajU2eEX9w684PznMefD8+8qhC/2ZtxLtM05amwP5p0ygsSlGbiBubISiUpmMb
k7I0Rrzpa2YvaGaAhAOmaROMQemfa/HZCH/QMfFBya3QPyFWs5CWczUKaZ++GFhU
f0qaAPe3G/xpCIGVbwbX25O5sTuM+qto6/Go38mAa+RUepkuj4kQKwMG+jF2rAII
iMhoFjwHYLXTU8u9RJx+L1j2lTEWVA6452sG2oK8e/GonKEFQab4crnKgeJpxvH7
WyfoS67nG5HF5VxJzUokpNjV3L5n7Vp5j9IL5/exMAhyDfjTCauD8/27gZ7UUgI=
=Cpxn
-----END PGP SIGNATURE-----

--vxv2082tmwX3TW5DG5kw6sSh6XSeunjpi--


From nobody Thu Oct 19 13:48:50 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 684ED133011 for ; Thu, 19 Oct 2017 13:48:49 -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 xK7giHs0PIZj for ; Thu, 19 Oct 2017 13:48:48 -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 F2149132D89 for ; Thu, 19 Oct 2017 13:48:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2882; q=dns/txt; s=iport; t=1508446128; x=1509655728; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=MRf7DGKPqU6dECavCT0WKfTYP6KQOItyr0egu5f6pwc=; b=it26aCzxEDjxNVooi8H9+XODyPYfyTGfUJtZ94x4Mgg6z7/IZBPwLDpM HzjXNgAelyGqhELFrrUHX221xxfxdjn0Ns3oVPT9PowAAdnaoAzNMhY5T hNcy91nvlD8ib3YWQaeoZZmRtlZjMZsQO733P72bBGBJkccVqnc5JpVdB Y=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADnDulZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N6ih90kEWWM4IUBwMbhSAChUoYAQIBAQEBAQEBayiFHgE?= =?us-ascii?q?FI2YLGCoCAlcGAQwIAQGKHKtAgieLIQEBAQEBAQEDAQEBAQEBARIPgy+FbYMDi?= =?us-ascii?q?BmCYQWRS5AIhD+CIY4Pi2aHM5V0gTkfOIFbNCEIHRWDLQmEWD42iw4BAQE?=
X-IronPort-AV: E=Sophos;i="5.43,403,1503360000";  d="asc'?scan'208";a="656452732"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2017 20:48:45 +0000
Received: from [10.61.111.156] (dhcp-10-61-111-156.cisco.com [10.61.111.156]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9JKmjsw028747;  Thu, 19 Oct 2017 20:48:45 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References: 
From: Eliot Lear 
Message-ID: <4fba34f2-efdd-99e6-dd53-06011fbbd864@cisco.com>
Date: Thu, 19 Oct 2017 22:48:45 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EmhAOUD0WRBgh9b4veE6iCQxcDNSAOop4"
Archived-At: 
Subject: Re: [OPSAWG] MUD : ACE with BOTH controller and src-dnsname
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, 19 Oct 2017 20:48:49 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EmhAOUD0WRBgh9b4veE6iCQxcDNSAOop4
Content-Type: multipart/mixed; boundary="lWhEEqONV33WMd5t8vs6kUrPrVctpB0ib";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" , opsawg@ietf.org
Message-ID: <4fba34f2-efdd-99e6-dd53-06011fbbd864@cisco.com>
Subject: Re: [OPSAWG] MUD : ACE with BOTH controller and src-dnsname
References: 
In-Reply-To: 

--lWhEEqONV33WMd5t8vs6kUrPrVctpB0ib
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Ranga,


On 10/18/17 11:55 PM, M. Ranganathan wrote:
> This is a made up example.
>
> Is the following ACE valid for MUD?
>
>      "matches": {
>                 "ietf-mud:mud-acl": {
>                   "controller": "urn:ietf:params:mud:dns"
>                 },
>                 "ipv4-acl": {
>                   "ietf-acldns:src-dnsname": "www.nist.gov",
>                   "protocol": 6,
>                   "source-port-range": {
>                     "lower-port": 53,
>                     "upper-port": 53
>                   }
>                 },
>                 "tcp-acl": {
>                   "ietf-mud:direction-initiated": "from-device"
>                 }
>               }
>
> This ACL has both a controller AND dns-name ACL.
>
> Presumably the controller would take precedence and the dnsname must be=

> ignored (?)
> Thank you in advance for your clarification.

No, I don't think it would make sense to write that.=C2=A0 The way ACEs a=
re
normally interpretted, and this is all based on the ACL model, is that
they are ANDed.=C2=A0 It's likely also to confuse a controller.=C2=A0 I c=
ould see
a pretty good argument for making an explicit statement about warning
against that in the text.=C2=A0 If the chairs and the WG don't mind, I wi=
ll
add that in my working copy.

Eliot



--lWhEEqONV33WMd5t8vs6kUrPrVctpB0ib--

--EmhAOUD0WRBgh9b4veE6iCQxcDNSAOop4
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

iQEcBAEBCAAGBQJZ6Q+tAAoJEIe2a0bZ0nozS50H/jYtw/I2wVkBptMmBf3VG8pK
0FLypwBCgh6/4S8tveeU6ahrfXF2fvf6VHmX13QRlFu4A2a0zqMQRFywxTa7L3CY
j9kBSJdf8v1ld9j7A6j57TwkIcCuFOxHr47hYFrMI6XSJZk7lGVBpm/uJn9TdnPb
pyzrqbTGnFG9jZwf0F0iJyMhs1dbQyfke0fs/S/+zCvsl6bkSSQ0TIe4leuE6y89
lnXfp+JX/I/9+oQYeO/wxxmr35ZtXKA8Xbz794tov8EKUHP/zCzbK5h/sPoRO4U5
RGSmzuc2xl9QzWtM4EHLHcTROYvLJwMFH3kDEAQFxZUlvjKKbQghuRVIZTCxzjs=
=PXUJ
-----END PGP SIGNATURE-----

--EmhAOUD0WRBgh9b4veE6iCQxcDNSAOop4--


From nobody Thu Oct 19 17:48:41 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 10C4F13292A for ; Thu, 19 Oct 2017 17:48:39 -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 Us2qIfCoifEO for ; Thu, 19 Oct 2017 17:48:37 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 09B591320B5 for ; Thu, 19 Oct 2017 17:48:37 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id w105so621445wrc.0 for ; Thu, 19 Oct 2017 17:48: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=00fKpd8Fii56e1ogxsHl4KFn8wcGk6RAjESW4ZvlpPQ=; b=pWacHkGynO6Ys0oVROfeZ8w4OHneYeikgB6Tvmb0GfvzVUYShD6/Yrw7XLmATL8HWd yj9O71uZTbHp3hgXBR/79u/ZQ6fs0jpVtDS2o903DfbsaGzbktKBeAauGGdsGvVptrr9 rtRNlf5V+Zd32fRawACSA8Im4zKCoecQ8N0u2f3Yvd0xdLM4bmy8T7N844T8Y+STDRYJ y6gV8ytxmqP33fmxUZAdhX5tGQ+jCyd8NugUTK635YmuVmsQt/KNGDqgseV6r7c3TZad KIMlmYEBYNLT8yebQxwDuOEGdgJOAM6SejX7iZ9nmcymdHttkafdm8rdwaIJkraf/ZQI aoYw==
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=00fKpd8Fii56e1ogxsHl4KFn8wcGk6RAjESW4ZvlpPQ=; b=lVGZh8bJ/72kIV4XlzTm0e3+CUxZGN0cRnpj1CIy/33mloOosXsPVfVfyyHgaqThPj WsugC2rI+tDtjg4BfqyFWLp8NGHvCef6IL3GzP1L3hc+485z3qqFSDg0ZJo319+LLKEv D2MDpGAgLqz2arhajNM3AMI66NF/7Uop481P7a5+al8J8w1lkAYBSQOm13PWD1kAHZf0 p2I7j4UfqFjIqT4ujMMvKkuOvUWGEZM40mw+fGjfXhEPd7Z1bSPQcXFsZVELQDA2vHKI Utj8ewa6yNoVrEQLjn4xQrTK8uzkDkB/ySOwkicVmxa7BobhAll4WhKEBsgBA/Ljnz6z feBA==
X-Gm-Message-State: AMCzsaVVMv+IcTGNgvHWvpAjunDF4wS/EYMFwR5J1kW80w1CXblVuEKB t28BcUcvEo8JyJDaArmJZDxwTHHvzF6SAQzBKW0=
X-Google-Smtp-Source: ABhQp+RePH19RE8hxJHycE90Ms8tdeEz4fKgTsi8sm5hEqdK2G1Fby5mPZmFQb0iIOS3bCzmoCMNVutT+DY+tOEv/BU=
X-Received: by 10.223.201.8 with SMTP id m8mr3156872wrh.37.1508460515355; Thu, 19 Oct 2017 17:48:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Thu, 19 Oct 2017 17:47:54 -0700 (PDT)
In-Reply-To: <7c58847e-ef53-97f9-d19c-418f18dde23c@cisco.com>
References:   <7c58847e-ef53-97f9-d19c-418f18dde23c@cisco.com>
From: "M. Ranganathan" 
Date: Thu, 19 Oct 2017 20:47:54 -0400
Message-ID: 
To: Eliot Lear 
Cc: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="089e083103cc2cf412055befd522"
Archived-At: 
Subject: Re: [OPSAWG] MUD: Why reserve names for "well-known" controllers
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, 20 Oct 2017 00:48:39 -0000

--089e083103cc2cf412055befd522
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Eliot,

On Thu, Oct 19, 2017 at 4:44 PM, Eliot Lear  wrote:

> Hi Ranga,
>
> Sorry I've been quiet for a few days.  I'll have more to say later.
> Please see below.
>
>
> On 10/19/17 4:28 PM, M. Ranganathan wrote:
> >
> > I am not clear in my mind about why this should be the case for NTP
> server
> > i.e. why do we reserve a special URN for NTP server? Why is it not just=
 a
> > "controller" like every other one?
> >
>
> The base assumption we had was that everyone needs name resolution and
> time.  Also, if you standardize these names, it's easy for
> implementations to simply fill in the values, if they happen to know
> them.  So for instance, during install of your controller, you might
> simply ask, =E2=80=9CShould I include the local NTP servers I found in my
> ntp.conf files and DNS servers I found in /etc/resolve.conf?=E2=80=9D
>
> Eliot
>
>
I thought the motivation in specifying a well-known URI for DNS is that the
IOT device should do the SAME name resolution as the entity that installs
the ACLs and for this to happen we need to specify that they both use the
same DNS server.

Scenario: Perhaps the manufacturer would like the IOT devices to use HIS
name server - not necessarily what is returned by  dhcp when the IOT device
goes to get it's IP address assigned. That is the device gets a server
address of the desired name server somehow when it connects to its
controller. This would be a guard against DNS spoofing. The mud controller
needs to be able to install ACLs that allow the device to talk to the DNS
server - hence the idea of a URI mapping made sense because, the entity
that installs the ACLs (i.e. the Mud controller) should use the SAME name
resolver to result in the same name resolution.

The draft also says - LAN local DHCP and DNS should always be allowed.
These are allowed by default. The mechanism to communicate these to the MUD
controller is not specified in the draft.

Still not clear about the need to make NTP a "well known URI" but I'll
assume this is for convenience.




--=20
M. Ranganathan

--089e083103cc2cf412055befd522
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Eliot,

On Thu, Oct 19, 2017 at 4:44 PM, Eliot Lear =
<lear@cisco.com&=
gt; wrote:
Hi Ranga,



Sorry I've been quiet for a few days.=C2=A0 I'll have more to say l=
ater.=C2=A0

Please see below.





On 10/19/17 4:28 PM, M. Ranganathan wrote:

>

> I am not clear in my mind about why this should be the case for NTP se=
rver

> i.e. why do we reserve a special URN for NTP server? Why is it not jus=
t a

> "controller" like every other one?

>



The base assumption we had was that everyone needs name resolution a=
nd

time.=C2=A0 Also, if you standardize these names, it's easy for

implementations to simply fill in the values, if they happen to know

them.=C2=A0 So for instance, during install of your controller, you might
simply ask, =E2=80=9CShould I include the local NTP servers I found in my
ntp.conf files and DNS servers I found in /etc/resolve.conf?=E2=80=9D



Eliot





I thought the motivation in specifying a well-k=
nown URI for DNS is that the IOT device should do the SAME name resolution =
as the entity that installs the ACLs and for this to happen we need to spec=
ify that they both use the same DNS server. 

Scenario: Perhaps the manufactur=
er would like the IOT devices to use HIS name server - not necessarily what=
 is returned by=C2=A0 dhcp when the IOT device goes to get it's IP addr=
ess assigned. That is the device gets a server address of the desired name =
server somehow when it connects to its controller. This would be a guard ag=
ainst DNS spoofing. The mud controller needs to be able to install ACLs tha=
t allow the device to talk to the DNS server - hence the idea of a URI mapp=
ing made sense because, the entity that installs the ACLs (i.e. the Mud con=
troller) should use the SAME name resolver to result in the same name resol=
ution. 

The draft also says - LAN local DHCP and DNS should always be allowed=
. These are allowed by default. The mechanism to communicate these to the M=
UD controller is not specified in the draft. 

Still not clear about the need =
to make NTP a "well known URI" but I'll assume this is for co=
nvenience.




-- 
=

M. Rangan=
athan




--089e083103cc2cf412055befd522--


From nobody Thu Oct 19 22:03: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 94C04132397 for ; Thu, 19 Oct 2017 22:03:02 -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 rNICX2ZOw47i for ; Thu, 19 Oct 2017 22:03:01 -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 3D1CF1270AB for ; Thu, 19 Oct 2017 22:03:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2956; q=dns/txt; s=iport; t=1508475781; x=1509685381; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=QNNuzpG9WnyCEgx5yeD0yAGvLlqh8Mlet+uOXwxh3Dc=; b=AUCrlbwqcIHpX4MkZ9NdnC23K1get+YRjQIuQhlYmHgwvhxZHS4RU07m iWACMJPgY0CCylAjjO1VStTJsBjkTc8zpMBr/NdVkmiH4OJZFSRJbiaLl 6c7pe8xcGKNH6Z6DbgXy2grz+w48WsBi2pSb8Qee09+kacA1N8OQgQTAD A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAAAUg+lZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhTGEIYofdJBFljOCFAcDhTsChUoYAQIBAQEBAQEBayiFHQEBAQE?= =?us-ascii?q?CASNWEAsYKgICVwYNCAEBihQIqxGCJ4sgAQEBAQEBAQEBAQEBAQEBAQESD4Mvh?= =?us-ascii?q?W2DA4RvgyqCYQWKJYcmkAiEP4Ihjg+LZoczlXSBOR84gVs0IQgdFYMuhGA+iw8?= =?us-ascii?q?BAQE?=
X-IronPort-AV: E=Sophos;i="5.43,405,1503360000";  d="asc'?scan'208";a="655555332"
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; 20 Oct 2017 05:02:59 +0000
Received: from [10.61.111.156] (dhcp-10-61-111-156.cisco.com [10.61.111.156]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9K52w1K007365;  Fri, 20 Oct 2017 05:02:58 GMT
To: "M. Ranganathan" 
Cc: opsawg@ietf.org
References:   <7c58847e-ef53-97f9-d19c-418f18dde23c@cisco.com> 
From: Eliot Lear 
Message-ID: 
Date: Fri, 20 Oct 2017 07:02:58 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="stq26uj9Bf1AO4NdF4naQUjajbpme6DBP"
Archived-At: 
Subject: Re: [OPSAWG] MUD: Why reserve names for "well-known" controllers
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, 20 Oct 2017 05:03:02 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--stq26uj9Bf1AO4NdF4naQUjajbpme6DBP
Content-Type: multipart/mixed; boundary="HeXaqcHr4vF7DJQ5mBGFTC8idOveGiCQH";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" 
Cc: opsawg@ietf.org
Message-ID: 
Subject: Re: [OPSAWG] MUD: Why reserve names for "well-known" controllers
References: 
 
 <7c58847e-ef53-97f9-d19c-418f18dde23c@cisco.com>
 
In-Reply-To: 

--HeXaqcHr4vF7DJQ5mBGFTC8idOveGiCQH
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US



On 10/20/17 2:47 AM, M. Ranganathan wrote:
>
> Scenario: Perhaps the manufacturer would like the IOT devices to use HI=
S
> name server - not necessarily what is returned by  dhcp when the IOT de=
vice
> goes to get it's IP address assigned. That is the device gets a server
> address of the desired name server somehow when it connects to its
> controller. This would be a guard against DNS spoofing. The mud control=
ler
> needs to be able to install ACLs that allow the device to talk to the D=
NS
> server - hence the idea of a URI mapping made sense because, the entity=

> that installs the ACLs (i.e. the Mud controller) should use the SAME na=
me
> resolver to result in the same name resolution.

In this case, you can treat DNS as any other service and just use a DNS
ACL with something like DOH.

>
> The draft also says - LAN local DHCP and DNS should always be allowed.
> These are allowed by default. The mechanism to communicate these to the=
 MUD
> controller is not specified in the draft.
s/DHCP/NTP, and yes, that is stated that they are to be allowed by
default.=C2=A0 It is the responsibility of the controller to instantiate
appropriate ACLs to allow for that.

Eliot


--HeXaqcHr4vF7DJQ5mBGFTC8idOveGiCQH--

--stq26uj9Bf1AO4NdF4naQUjajbpme6DBP
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

iQEcBAEBCAAGBQJZ6YOCAAoJEIe2a0bZ0noz9AgH/0xYnmumlmkNS5TKqxnxh7E1
2vikbLiC0YkL9lGnoUos11D2/VlI4WFvADoZJBgevZXYJAmg7pA/hi7cZ8ZbwsUZ
8+XjdIOKoapVK2/Ea48LHR1GvZ9oCJ9maayECyBgNtiiaS3MoNtDhR7ES4J/t0ew
sxpMJXUNeY5WASpsUBDIqwH6L8vvedlfcQ2hArY15tZB/oLk3Rem0AE3FuUVFvj/
ai0jrfx15yC71a7BxTbJfjcZMhZddYpbI4Xo6nLi5nKULEPEa72T1L8ScyTbvw3j
iSOClr63PcxMSBwuqmGqIvQfkenOz4BCQEnXhDv86Qv4yzAXE31phQF85Krj1Ww=
=ulwc
-----END PGP SIGNATURE-----

--stq26uj9Bf1AO4NdF4naQUjajbpme6DBP--


From nobody Fri Oct 20 00:56:58 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 A52B11201F8; Fri, 20 Oct 2017 00:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.113
X-Spam-Level: 
X-Spam-Status: No, score=-1.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8YeViwuwPOy; Fri, 20 Oct 2017 00:56:55 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253078.outbound.protection.outlook.com [40.92.253.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF4912008A; Fri, 20 Oct 2017 00:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wsypSOmCi+pvNM6OFbXdcLaB5GYHdA9aYeyvfZqB3es=; b=M8/tKCTmPzhJQdx8w9MmviBQ9w4kudusMzsJDKMvZ1RFYP4osERZIymp2gw4s4P3X5bRIEXNvnifcUvw7TTFrXAboTkqqKLuUUPc74xDrmf9PqK5WGEeuC00P9SGZryUGVq+lyIyHNAVbZ59WxRvoD/9b+VNkgEVr07U/QnSXN2KwrdB80gu4DjSntyOoqsjUL+caALUS/m6QvHb2Kf/dgzH/v57n4CkwIgqL4vHGEeMXduKa96aomLAnZTjkLsSPvyB75hZxi72zD2uI5YYZIBpmbQQm1ZRR70OQGUUNDjLJOoYcTDMjp7SL7rPqNG9OP/fgQwNf///Hu4NnDUwUg==
Received: from HK2APC01FT051.eop-APC01.prod.protection.outlook.com (10.152.248.56) by HK2APC01HT207.eop-APC01.prod.protection.outlook.com (10.152.249.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.77.10; Fri, 20 Oct 2017 07:56:49 +0000
Received: from HK2PR0601MB1492.apcprd06.prod.outlook.com (10.152.248.57) by HK2APC01FT051.mail.protection.outlook.com (10.152.248.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.77.10 via Frontend Transport; Fri, 20 Oct 2017 07:56:49 +0000
Received: from HK2PR0601MB1492.apcprd06.prod.outlook.com ([fe80::5d60:24e5:3859:5091]) by HK2PR0601MB1492.apcprd06.prod.outlook.com ([fe80::5d60:24e5:3859:5091%13]) with mapi id 15.20.0077.019; Fri, 20 Oct 2017 07:56:49 +0000
From: li zhenqiang 
To: "opsawg@ietf.org" , opsawg-chairs 
Thread-Topic: WGLC request for draft-ietf-opsawg-ipfix-bgp-community-03.txt
Thread-Index: AQHTSXj7CQZMWHWVIES5ODba8dCuHA==
Date: Fri, 20 Oct 2017 07:56:49 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:702AAD3196D9C50CB87E2A196937E1A7967D6E9DC47D3240A288C25877FE2FC6; UpperCasedChecksum:46D25772A153B93BDCC09AA97969563C4F85A15AB22114782A605A0B3D1C8D73; SizeAsReceived:6995; Count:44
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [1z27VVImUdkhIdCUeQljNJZAzJkFynDHHpcC1pU6IaE=]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HK2APC01HT207; 6:WD9mAkDDtnrL9ML0IRRWZH3vXXbmOOJj7340DXdalBoZzuhs2Nhtcsv/UsRObHoNMj4OhkMRNlMD1wuNz0B8IXMtooFcSqnAjQGlOPuhoZqKHy5hA9N5OQH4MTuiuc2T6835/riEpzAwobLwtnFjLk6Or0aR4DSq/PGV0J5ZeXATEeoQTtjXKetrqRWBiqmt/EnP5qd5xSM+qKm6foLizoL/W6AtKSomrwHagnAW/sLjWBiLfvgqwElhnJhUY18uTQhRUAt7IOZPZhzvJH3umkbZK7XzNPukeLbKCR5ISsGDwhbR8ysNwPlCpJ+0Z4cvwt0rWlEs+sOCQp5AKVrbvQ==; 5:ptC36dPw1wdHqrUF7q27YMA1XSNOg4bUZb9rsfsqHSDQE8XTF78+tJDUqjHWiWuzqllS1xqbCjDqtdl1Bl2s1itrbGZ421rQ3hUWQy/EIEU9/1xo4BQ1wm8MLMIPJyFfvQIIte7nKyrlGoKL5mafpw==; 24:o4BMyJW+MCOb6FFeBtGlItlMN77ShNXaYTNzGHgLa36mtEIJvMqFAHmVO3qE9ModSIuGt3SXtwg3BDNxwya2SP3sKZ+WgNbHKAftdi1jvhU=; 7:LujE2nBGphi6hrcMCqkMVcfEZDteT8pe0BzTnHz9VZmZodOly8Nr3cVzpa0ufBZ4eq2hqPb555ixJajmqQJ9U2g9tQwMR45HIZr9THUQSxny/h/dbGCWiGthCghxWdqsFMz36DsWvQuSfHCTqrhBs9UExGcWHOd5g02q2l5BNa4aVjSQ8+o9rQNNuucBCIr2yRpnixqD8fu7J8c1vF+RCkCQgEdfNDnIy0+LEp4JveU=
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: a57172d4-1e67-434b-041a-08d517901d8d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:HK2APC01HT207; 
x-ms-traffictypediagnostic: HK2APC01HT207:
x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(131327999870524)(194151415913766); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:HK2APC01HT207; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HK2APC01HT207; 
x-forefront-prvs: 0466CA5A45
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT207; H:HK2PR0601MB1492.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB14929AD1C16A0FF46D811415FC430HK2PR0601MB1492_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 07:56:49.7553 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT207
Archived-At: 
Subject: [OPSAWG] WGLC request for draft-ietf-opsawg-ipfix-bgp-community-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: Fri, 20 Oct 2017 07:56:56 -0000

--_000_HK2PR0601MB14929AD1C16A0FF46D811415FC430HK2PR0601MB1492_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

RGVhciBXRyBDaGFpcnMgYW5kIGFsbCwNCg0KSSB1cGRhdGVkIHRoZSBmb2xsb3dpbmcgZHJhZnQg
YWNjb3JkaW5nIHRvIHRoZSBjb21tZW50cyByZWNlaXZlZCBmcm9tIHRoZSBsaXN0IGFuZCB0aGUg
UHJhaGEgbWVldGluZy4gVGhlIHB1cnBvc2UgdG8gaW50cm9kdWNlIG5ldyBJRXMgaW4gSVBGSVgg
aXMgZXhwbGFpbmVkIG1vcmUgY2xlYXJseSBpbiB0aGUgaW50cm9kdWNhdGlvbiBwYXJ0IGFuZCBl
bXBoZXNpemVkIGluIHRoZSBhYnN0cmFjdCBwYXJ0LiBXZSBjaGFuZ2VkIG9uZSBzZWN0aW9uIHRp
dGxlIGZyb20gIE1lc3NhZ2UgTGVuZ3RoIENvbnNpZGVyYXRpb25zIHRvICBPcGVyYXRpb25hbCBD
b25zaWRlcmF0aW9ucywgYW5kIGV4cGxhaW5lZCwgYXQgcHJlc2VudCBmb3IgdGhlIGZpZWxkIG5l
dHdvcmssIG9uZSBJUEZJWCBtZXNzYWdlIGhhcyBlbm91Z2ggc3BhY2UgdG8gZml0IGFsbCB0aGUg
Y29tbXVuaXR5IGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gYSBzcGVjaWZpYyB0cmFmZmljIGZsb3cg
Lg0KDQpTaW5jZSBubyBtb3JlIHRlY2huaWNhbCBpc3N1ZXMgcmVtYWluIHRvIGJlIHNvbHZlZCwg
YXMgcmVxdWVzdGVkIGluIHRoZSBQcmFoYSBtZWV0aW5nLCB3ZSB0aGluayB0aGlzIGRvYyBpcyBy
ZWFkeSB0byBkbyBXR0xDLiBUaGFuayB5b3UgdmVyeSBtdWNoLg0KDQoNCk5hbWU6IGRyYWZ0LWll
dGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkNClJldmlzaW9uOiAwMw0KVGl0bGU6IEV4cG9y
dCBCR1AgY29tbXVuaXR5IGluZm9ybWF0aW9uIGluIElQIEZsb3cgSW5mb3JtYXRpb24gRXhwb3J0
IChJUEZJWCkNCkRvY3VtZW50IGRhdGU6IDIwMTctMTAtMTcNCkdyb3VwOiBvcHNhd2cNClBhZ2Vz
OiAxNw0KVVJMOiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0
Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMy50eHQNClN0YXR1czogaHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0
eS8NCkh0bWxpemVkOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vcHNh
d2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMw0KSHRtbGl6ZWQ6IGh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0w
Mw0KRGlmZjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3Bz
YXdnLWlwZml4LWJncC1jb21tdW5pdHktMDMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRyYWZ0IHVw
ZGF0ZXMgUkZDNzAxMiBJUEZJWCBpbmZvcm1hdGlvbiBtb2RlbCBieSBpbnRyb2R1Y2luZw0KICAg
c2V2ZXJhbCBpbmZvcm1hdGlvbiBlbGVtZW50cyB0byBlbmFibGUgSVBGSVggdG8gZXhwb3J0IHRo
ZSBCR1ANCiAgIGNvbW11bml0eSBpbmZvcm1hdGlvbiwgaW5jbHVkaW5nIEJHUCBzdGFuZGFyZCBj
b21tdW5pdHkgZGVmaW5lZCBpbg0KICAgUkZDMTk5NywgQkdQIGV4dGVuZGVkIGNvbW11bml0eSBk
ZWZpbmVkIGluIFJGQzQzNjAsIGFuZCBCR1AgbGFyZ2UNCiAgIGNvbW11bml0eSBkZWZpbmVkIGlu
IFJGQzgwOTIuICBOZXR3b3JrIHRyYWZmaWMgZmxvdyBpbmZvcm1hdGlvbiBjYW4NCiAgIHRoZW4g
YmUgYWNjdW11bGF0ZWQgYW5kIGFuYWx5c2VkIGF0IHRoZSBncmFudWxhcml0eSBzcGVjaWZpZWQg
YnkgdGhlDQogICBCR1AgY29tbXVuaXRpZXMsIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBhbmQgbmVl
ZGVkIGJ5IHNvbWUgdHJhZmZpYw0KICAgb3B0aW1pemF0aW9uIGFwcGxpY2F0aW9ucyBsb2NhdGVk
IGluIElQRklYIGNvbGxlY3RvciwgU0ROIGNvbnRyb2xsZXINCiAgIG9yIFBDRSAoUGF0aCBDb21w
dXRhdGlvbiBFbGVtZW50KS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmxp
X3poZW5xaWFuZ0Bob3RtYWlsLmNvbQ0K

--_000_HK2PR0601MB14929AD1C16A0FF46D811415FC430HK2PR0601MB1492_
Content-Type: text/html; charset="gb2312"
Content-ID: 
Content-Transfer-Encoding: quoted-printable








Dear WG Chairs and all,







I updated the following draft according to the comments received from =
the list and the Praha meeting. The purpose to introduce new IEs in IPFIX i=
s explained more clearly in the introducation part and emphesized in the ab=
stract part. We changed one section
 title from  Message Length Considerations to  Operational=
 Considerations,
 and explained, at present for the field network, one IPFIX message has eno=
ugh space to fit all the community information related to a specific traffi=
c flow .







Since no more technical issues remain to be solved, as requested in th=
e Praha meeting, we think this doc is ready to do WGLC. Thank you very much=
.














Name: draft-ietf-opsawg-ipfix-bgp-community


Revision: 03


Title: Export BGP community information in IP Flow Information Expo=
rt (IPFIX)


Document date: 2017-10-17


Group: opsawg


Pages: 17



Status: h=
ttps://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/<=
/div>

Htmlized: ht=
tps://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-03


Diff:  


Abstract:


   This draft updates RFC7012 IPFIX information model by =
introducing


   several information elements to enable IPFIX to export=
 the BGP


   community information, including BGP standard communit=
y defined in


   RFC1997, BGP extended community defined in RFC4360, an=
d BGP large


   community defined in RFC8092.  Network traffic fl=
ow information can


   then be accumulated and analysed at the granularity sp=
ecified by the


   BGP communities, which is suitable for and needed by s=
ome traffic


   optimization applications located in IPFIX collector, =
SDN controller


   or PCE (Path Computation Element).















li_zhenqiang@hotmail.com








--_000_HK2PR0601MB14929AD1C16A0FF46D811415FC430HK2PR0601MB1492_--


From nobody Fri Oct 20 17:28:02 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 50A4F1344F5; Fri, 20 Oct 2017 17:24:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: opsawg@ietf.org, warren@kumari.net
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150854546132.20809.2923586754960159266.idtracker@ietfa.amsl.com>
Date: Fri, 20 Oct 2017 17:24:21 -0700
Archived-At: 
Subject: [OPSAWG] opsawg - Requested session has been scheduled for IETF 100
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: Sat, 21 Oct 2017 00:24:21 -0000

Dear Joe Clarke,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

opsawg Session 1 (2:00:00)
    Tuesday, Afternoon Session II 1550-1750
    Room Name: Canning size: 250
    ---------------------------------------------
    

Special Note: Joint session with OPSAREA


Request Information:


---------------------------------------------------------
Working Group Name: Operations and Management Area Working Group
Area Name: Operations and Management Area
Session Requester: Joe Clarke

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: nvo3 ippm
 Second Priority: idr detnet



People who must be present:
  Benoit Claise
  Warren Kumari
  Joe Clarke
  Tianran Zhou
  Ignas Bagdonas

Resources Requested:

Special Requests:
  PLEASE NOTE: Combined OpsAWG / OpsAREA
---------------------------------------------------------


From nobody Sat Oct 21 05:53: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 4800D130EF3 for ; Sat, 21 Oct 2017 05:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.373
X-Spam-Level: 
X-Spam-Status: No, score=-1.373 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, REPTO_QUOTE_YAHOO=0.646, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 ciJt-FCihn86 for ; Sat, 21 Oct 2017 05:53:29 -0700 (PDT)
Received: from sonic309-40.consmr.mail.bf2.yahoo.com (sonic309-40.consmr.mail.bf2.yahoo.com [74.6.129.214]) (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 022D6133054 for ; Sat, 21 Oct 2017 05:53:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1508590407; bh=qlaOs0DaxaemD5GnBEZcMJ/WBq/bADJDzp3edqd6Gws=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=dUNu5+42X1/MSIL2HqcQ+7F9fb7mR5M/IPf5UvasfVSdRnoau4DxFtybRyGL2tqF6hyohAxVHplnkzjvUMtRucP0GIGEQh5jLhwMwyG54sPrZKUWXjNQV+U4sTO/K+JW7G4puU5IcgY5PQSjGkLKuzd/dLbWggBlvNPrUrOeXlJKz2pqgq3UaS2A4gBswS5Zr4jHE5on6WK2/toJqY32CvxwhhUst9VUgf+WJnPLkV4Z17nBNaNle1Pwv+Tv4OOGIYW5QD0vYjG8aj5y0lf0y8Oa32PJlslMk60/uYHO57RG+tXUvY3SwqF2pR+cQljd1w4h6I9OwxQ14lJiJBXklg==
X-YMail-OSG: .jwcSA8VM1mFOS55QtyMUlsaoKdU6owvXY7VDq4x1kJsNTlF3adzfVZsIgKisDm Yr1u1J1VTxEe65JbO20Fq6XwKOsV_Ilt1fI5LOJP86dQuIbB2ubIluIOZb3gE0jmENvrs78N4e2o auAFOP507Ep339IFYiMwh1b0j5Ky5xirx3EX0W4vqJCa68iMpdYEisCzX2ZRAgSvNJ2jx1WfYqJq w9MW_J9c1YGOrLAQrWqnm0mf40QasCoyv.d3uMGDFe6bqwGoXZRdk9RWVv3qZeV1MYe3WICnCr4b 6_e4I1jRo2Odh081gohGwY6ZsDfHKki2QsAiTCCB0iEjWPcpVkpD_aVbgeWQkVbXS64kgUmiMGXZ mEKtSip7ykrA2ipD06YnhvFDsqtibkioJVO._BkGkRtsNgogZapDKmXrroiCbLg5SYznkQ97U72q taoUvjlosPb1LA9clSsBEMHBXiynrfGIREICLs_yJQRswaFPhkz8oklbyMvku3w5X83NAFtbwI29 0x03ZGI0Glc.CouFh
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Sat, 21 Oct 2017 12:53:27 +0000
Date: Sat, 21 Oct 2017 12:49:26 +0000 (UTC)
From: shah zahidur 
Reply-To: "shah_zahidur@yahoo.com" 
To: "agenda@ietf.org" ,  "jclarke@cisco.com" ,  "opsawg-chairs@ietf.org" 
Cc: "opsawg@ietf.org" 
Message-ID: <1484051659.1704652.1508590166336@mail.yahoo.com>
In-Reply-To: <150854546132.20809.2923586754960159266.idtracker@ietfa.amsl.com>
References: <150854546132.20809.2923586754960159266.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1704651_606256627.1508590166333"
X-Mailer: WebService/1.1.10801 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/5.16.3; Android/4.4.2; H50; H50; H50; H50; 4.59; 1280x720; )
Archived-At: 
Subject: Re: [OPSAWG] opsawg - Requested session has been scheduled for IETF 100
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Oct 2017 12:53:30 -0000

------=_Part_1704651_606256627.1508590166333
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,
I would lluike to attend this session.
RegardsShah Zahidur Rahman

Sent from Yahoo Mail on Android=20
=20
  On Sat, Oct 21, 2017 at 6:29 AM, IETF Secretariat wrote:=
   Dear Joe Clarke,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.=20

opsawg Session 1 (2:00:00)
=C2=A0 =C2=A0 Tuesday, Afternoon Session II 1550-1750
=C2=A0 =C2=A0 Room Name: Canning size: 250
=C2=A0 =C2=A0 ---------------------------------------------
=C2=A0 =C2=A0=20

Special Note: Joint session with OPSAREA


Request Information:


---------------------------------------------------------
Working Group Name: Operations and Management Area Working Group
Area Name: Operations and Management Area
Session Requester: Joe Clarke

Number of Sessions: 1
Length of Session(s):=C2=A0 2 Hours
Number of Attendees: 100
Conflicts to Avoid:=20
 First Priority: nvo3 ippm
 Second Priority: idr detnet



People who must be present:
=C2=A0 Benoit Claise
=C2=A0 Warren Kumari
=C2=A0 Joe Clarke
=C2=A0 Tianran Zhou
=C2=A0 Ignas Bagdonas

Resources Requested:

Special Requests:
=C2=A0 PLEASE NOTE: Combined OpsAWG / OpsAREA
---------------------------------------------------------

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

------=_Part_1704651_606256627.1508590166333
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I would lluike to attend this=
 session.

Regards
 
 <=
blockquote style=3D"margin: 0 0 20px 0;"> 
 
On Sat, Oct 21, 2017 at 6:29 AM, IETF=
 Secretariat
<agenda@ietf.org> wrote:
 
 
 
Dear Joe Clarke,
The session(s) that you have requested have been sc=
heduled.
Below is the scheduled session informati=
on followed by
the original request. 

opsawg Session 1 (2:00:00)
    Tuesday, Afternoon Session II 1550-1750
    Room Name: Canning size: 250
    ------------------------------------------=
---
    

=

Special Note: Joint session with OPSAREA


Reques=
t Information:


-------------------------------------------------------=
--
Working Group Name: Operations and Management =
Area Working Group
Area Name: Operations and Mana=
gement Area
Session Requester: Joe Clarke

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 100
Conflicts to Avoid=
: 
 First Priority: nvo3 ippm
 Second Priority: idr detnet

<=
div dir=3D"ltr">

Peopl=
e who must be present:
  Benoit Claise
  Warren Kumari
  =
Joe Clarke
  Tianran Zhou
  Ignas Bagdonas

Resources Requested:

Special Requests:
  PLEASE NOTE: Co=
mbined OpsAWG / OpsAREA
-------------------------=
--------------------------------

_______________________________________________
OPSAWG mailing list

------=_Part_1704651_606256627.1508590166333--


From nobody Sat Oct 21 08:02: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 6EBD0126D3F; Sat, 21 Oct 2017 08:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level: 
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[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 UL3p69jx-w-A; Sat, 21 Oct 2017 08:02:51 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::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 BA5AB124B18; Sat, 21 Oct 2017 08:02:51 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1e5vIX-0007Y8-Gc; Sat, 21 Oct 2017 15:02:49 +0000
Date: Sat, 21 Oct 2017 08:02:48 -0700
Message-ID: 
From: Randy Bush 
To: shah zahidur 
Cc: opsawg-chairs@ietf.org, opsawg 
In-Reply-To: <1484051659.1704652.1508590166336@mail.yahoo.com>
References: <150854546132.20809.2923586754960159266.idtracker@ietfa.amsl.com> <1484051659.1704652.1508590166336@mail.yahoo.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Archived-At: 
Subject: Re: [OPSAWG] opsawg - Requested session has been scheduled for IETF 100
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Oct 2017 15:02:52 -0000

> I would lluike to attend this session.

will you be in s'pore or do you need help with remote participation?

randy


From nobody Mon Oct 23 15:02:59 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 9290E13A2B8 for ; Mon, 23 Oct 2017 15:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 AVAOmygaLSds for ; Mon, 23 Oct 2017 15:02:56 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 04D5B1399D2 for ; Mon, 23 Oct 2017 15:02:56 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id q124so12173182wmb.0 for ; Mon, 23 Oct 2017 15:02:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=USoMSPAIaw99GsdD94az6xRCt1PQLrqxVuNSne0O6lA=; b=P0V/w6Ggozu0Gy2I43Uz7hn6ErniJX2VEw3qxrRiRUw7hdbOwCXh87Soz0lYbOrilC VNfpph9ui+D/H+cfW3asJZcumU+6GQRIXh57WVlnFku114zk2Piow5wEJlGzGMFJ43GW KAUQKbNtC7FCmBpzgAFH+s6//c7ohCHIKLwSXOZ8W8YXp7j3tRvHVAgxfVVFz4y0z24F G6IWgEM6nnIzB38ZGyBmF87Cs4rLOBV2Y73ekJWUPsKGvAPYpprxTd2SjqsbW4yzSOVF 7wwGNV890hBy2jB7u0RdHYe1fwMOoXivDqz+tbalrq6HYpmPoScdB7CLpQeDQyKectcF u6tg==
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=USoMSPAIaw99GsdD94az6xRCt1PQLrqxVuNSne0O6lA=; b=lXIB40E5Z6hHtVemMmctZmt1no3jRcy4DMc+hEMUjaEEHFW3eaVHfnYnfGbBy0JtGW 5Wr1Alibus/+nReHA+rmF0kYw/GK5k0Mhv5HX1Z8vnxGlCVF0Q3yYVX7TfoDpZiiVcdt jdHmdF0hlkmdngUkAEpZXzXfOVNKIkm5Aq6YllU556FP6bXo1Ozekn08stqImXJQ+h/Y lYeOjJFuTDArcicc9AAsfFOVXMEVEe5+nZp9Obw5CR9/eRDytfhDYYwfgvJ8G4aFAYv3 JSp4qD4ZFwkxNgtwotYq/rPnZvWCJaSIaWN23utO/fkcjZJPr+NE2s7xev5f7KhQXIFr TO/A==
X-Gm-Message-State: AMCzsaWQaHjUoeFjmfhypop8MrYu5E4ZIJv3RnUJuqJVIMQ99reDFbwg 7ppBGjo+6+W3/aWUDrBNIOU/oQQ9wrZu9oUedSQ01g==
X-Google-Smtp-Source: ABhQp+RZv5Xr67LL4zZV2q+Uqz/DQlD9O5u6SJ4/HQzQSFx/FvVkPQgE0FolJhrUXa7hQXuGJCiwgNXXaFNR5PsSw0A=
X-Received: by 10.28.113.71 with SMTP id m68mr4720831wmc.1.1508796174211; Mon, 23 Oct 2017 15:02:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.143 with HTTP; Mon, 23 Oct 2017 15:02:13 -0700 (PDT)
From: "M. Ranganathan" 
Date: Mon, 23 Oct 2017 18:02:13 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a11478b0c00a540055c3dfcf2"
Archived-At: 
Subject: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 23 Oct 2017 22:02:57 -0000

--001a11478b0c00a540055c3dfcf2
Content-Type: text/plain; charset="UTF-8"

Hello,

I am wondering about the utility of the actions part of the ACE.

In the latest MUD draft, I see "Appendix B : Default MUD nodes" where it is
suggested that one could, for example, set up to drop packets to the DNS
server by setting actions


               "actions": {
                   "forwarding": "drop"
                 }

But this is only because there is a notion of default access in MUD which assume
the IOT device isallowed to access DNS and NTP by default, which now has to
be overriden by a "drop" action.

This goes aginst the basic MUD working principle that everything is
denied unless explictly
stated.

I am just voicing an opinon here :

Perhaps it would be less confusing if NTP and DNS were not given any
special treatment.
It really does not save much by way of length of the MUD file to
explicitly state rules
for them


Perhaps it is a bit late to suggest this but may I suggest removing
the idea of default
permit access to DNS and NTP. It would simplify some things.

Thanks,

Regards,

Ranga.











-- 
M. Ranganathan

--001a11478b0c00a540055c3dfcf2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

I am wondering about th=
e utility of the actions part of the ACE.

In the latest MUD dr=
aft, I see "Appendix B : Default MUD nodes" where it is suggested=
 that one could, for example, set up to drop packets to the DNS server by s=
etting actions 


             =
  "actions": {
                   "forwarding": "drop"
                 }

But this is only because there is a notio=
n of default access in MUD which assume
the IOT device isallowed to acce=
ss DNS and NTP by default, which now has to 
be overriden by a "dro=
p" action.

This goes aginst the basic MUD workin=
g principle that everything is denied unless explictly  
stated.
I am just voicing an opinon here : 

Perhaps it would be l=
ess confusing if NTP and DNS were not given any special treatment.
It re=
ally does not save much by way of length of the MUD file to explicitly stat=
e rules
for them

Perhaps it is a bit late to sugge=
st this but may I suggest removing the idea of default 
permit access to=
 DNS and NTP. It would simplify some things.

Thanks,<=
br>
Regards, 

Ranga.










-- 
M. Ranganathan




--001a11478b0c00a540055c3dfcf2--


From nobody Mon Oct 23 15:38:07 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 7C10C13AAC7 for ; Mon, 23 Oct 2017 15:38:06 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kzq2Ralcjhjq for ; Mon, 23 Oct 2017 15:38:04 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 40C4A1395ED for ; Mon, 23 Oct 2017 15:38:04 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id z55so12817831wrz.1 for ; Mon, 23 Oct 2017 15:38:04 -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 :content-transfer-encoding; bh=BDV42iFJgQt5aGI1FMX3AZYpTqsatx0jG98THC8NF9s=; b=B+EmXmOWmV2Yt5XfHLPRGpFzeGlxgk38OKyM5V58QZ0jX1RJszYCcbgOqMqwxxVanF FsoehvIswbjOwPpSX9jSYkwQIqyoQeVF1+ihGrQwtASIm2yXaU785tztod6cMF7lD+2v Z7+rfyMZ/s18bBam5Bz3WU7aPXnWjGNGmuW3YB/xdQciNyx2QkpuLyKrr0kNtmV3wIEw Jt8YJ+Z7d6Jo3zjR4RyKXibvmd9svNyhBbLJi+fUElXnOVEK14KB2mZ+dCmSvUuoMidb dzpA+FbKuSE3k+h0RMhFnX80nDXxL/4AoxvZf0+owdLH7MW/U6wiyk5JcGW8rDr8GMu7 61hg==
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 :content-transfer-encoding; bh=BDV42iFJgQt5aGI1FMX3AZYpTqsatx0jG98THC8NF9s=; b=c0vPobTscrEC2zHhZP/XK6bm0hFWvLGI1Vrhj1bTcQyQHRaFEm8ymXgsOcSg+cO8tG k5dmxpmToaW2VIigjosy3ReZZ/wUvtfa/OxNV90xrhCG5AOwFI2OqDN8biVZ8e4kgLcS 5UwDB3mVvPH0DETcqD2EFUPGX8gige9n1smPZric0mNZGj4bDYs4Iqgh1l1AEdSFAJjk 3MExvgZQUkOuyeXEXlEBufeepw1bpQxS3B1lZEoZvm/EymYhJn70ORvlubCPRJbXVRh8 YN5dozTkmvtRPh22oc3l6RZip2MUa37zz046oAlj/dBtyJ/qE58iLXDsuY8P5N/4d5HM uuOw==
X-Gm-Message-State: AMCzsaVyoCyAEQJ8PSMv8Iv42OYPeD/hRrqmBzpiZa24CmTT6XobFhhu 0jXt5lhpPTOhZZnRPMzY7v/vIaM/l+88l+ZfQLKyOSw5Ykw=
X-Google-Smtp-Source: ABhQp+TjQa4b6swnd9OlQsjMx3/vq5bA7zKkuKPSwOK4O0d2OKWyDQZTFgR7NBsHeWhCYnuSRtZC/5DX+W/sMTgm/HE=
X-Received: by 10.223.151.198 with SMTP id t6mr13090969wrb.2.1508798282533; Mon, 23 Oct 2017 15:38:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.187.12 with HTTP; Mon, 23 Oct 2017 15:37:21 -0700 (PDT)
From: Warren Kumari 
Date: Mon, 23 Oct 2017 18:37:21 -0400
Message-ID: 
To: draft-ietf-opsawg-mud@ietf.org,  "opsawg-chairs@ietf.org" , opsawg@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [OPSAWG] AD review of: draft-ietf-opsawg-mud.
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, 23 Oct 2017 22:38:06 -0000

First, sorry for the delay in reviewing this -- I'm recovering from
pneumonia and so it took longer than it should have.

I do have a few comments that I=E2=80=99d like addressed
before I start IETF LC =E2=80=94 addressing these now will avoid
issues later in the process.

I believe that all my comments are editorial, and should be easy fixes.
Please explicitly let me know once you've posted a new version, just
to make sure it doesn't slip through the cracks.

Warren.

-------

1.  Introduction
  The Internet has largely been constructed on general purpose
  computers; those devices that may be used for a purpose that is
[O] computers;
[P] computers:
[R] punctuation
  specified by those who buy the device.

  ...
  Let us then posit a group of objects that are
  specifically NOT general purpose computers.  These devices have a
  purpose to their use.  By definition, therefore, all other purposes

[O] purpose to their use.
[P] specific purpose to their use.
[R] clarity / continuity with previous
  are NOT intended.
  ...

  We use the notion of "manufacturer" loosely in this context, to
  simply mean the entity or organization that will state how a device

[O] context, to simply mean
[P] context to refer to
[R] clarity and grammar
  is intended to be used.
  ...

  The key points are that the device itself is expected
  to serve a limited purpose, and that there may exist an organization
  in the supply chain of that device that will take responsibility for
  informing the network about that purpose.
  The intent MUD is to solve for the following problems:

[O] intent MUD
[P] intent of MUD
[R] grammar

  In this specification we describe each of these building blocks and
  how they are intended to be used together.  However, they may also be
  used separately, independent of this specification by local

[O] independent of this specification
[P] independent of this specification,
[R] grammar
  deployments for their own purposes.


1.1.  What MUD doesn't do
  ...
  How they are instantiated
  locally will depend on many factors, and is ultimately up to the

[O] factors,
[P] factors
[R] grammar
  local network administrator, who must decide what is appropriate in a
  given circumstances.

1.2.  A Simple Example
  A light bulb is intended to light a room.  It may be remotely
  controlled through the network; and it may make use of a rendezvous

[O] network;
[P] network,
[R] grammar

  service of some form that an app on smart phone accesses.


1.3.  Determining Intended Use
  ...
  Profiling systems that make use of heuristics to
  identify types of systems have existed for years as well.
  A Thing could just as easily tell the network what sort of protection

[O] protection
[R] protection? Or access?

  it requires without going into what sort of system it is.

1.4.  Finding A Policy: The MUD URL
  ...
  The IEEE has developed [IEEE8021AR] that provides a
  certificate-based approach to communicate device characteristics,
  which itself relies on [RFC5280].
  [C]: "that provides" or "which provides"?

  ...
  In these cases, manufacturers may be able to map those
  identifies to particular MUD URLs (or even the files themselves).

[O] indentifies
[P] indentifiers
[R] I think this is what was meant. Or perhaps identities?


1.5.  Types of Policies
  ...
  For example:
     Allow access to devices of the same manufacturer
     Allow access to and from controllers via COAP

[O] via COAP
[R] Please expand COAP, it's not well known.

  To add a bit more depth that should not be a stretch of anyone's
  imagination, one could also make use of port-based access lists.

[O] that should not be a stretch of anyone's imagination
[R] I don't think this phrase makes sense in this context, or at least
it sounded odd to me.

 ...
  While the policy examples given here focus on access control, this is
  not intended to be the sole focus.  By structuring the model
  described in this document with clear extension points, so that other

[O] , so that other
[P], other
[R] readability
  descriptions could be included.

...
  The "manufacturer" classes can be easily specified by the
  manufacturer, whereas controller classes are initially envisioned to
  be specified by the administrator.
  Because manufacturers do not know who will be using their devices, it
  is important for functionality referenced in usage descriptions to be
  relatively ubiquitous, and mature.  For these reasons only a limited

[O] ubiquitous, and mature
[P] ubiquitous and mature
[R] grammar
  subset YANG-based configuration of is permitted in a MUD file.

1.6.  Terminology
  ...
  After it has processed a MUD file it may

[O] After it has processed a MUD file it may
[P] After it has processed a MUD file, it may
[R] grammar
     direct changes to relevant network elements.

 ...

1.7.  The Manufacturer Usage Description Architecture
  With these components laid out we now have the basis for an
  archicture.  This leads us to ASCII art.

[O] archicture
[P] architecture
[R] spelling / typo.
  ...

  The web site is typically run by or on behalf of the manufacturer.
  Its domain name is that of the authority found in the MUD URL.  For
  legacy cases where Things cannot emit a URL, if the switch is able to
  determine the appropriate URL, it may proxy it, the trivial cases
  being a map between some registered Thing or port and a URL.

[O] the trivial cases
  being a map between some registered Thing or port and a URL.
[R] cannot parse this part of the sentence.
   ...

  Communication within those systems and from those systems to
  network elements is beyond the scope of this memo.

[O] memo
[P] document -- either is allowed, this is just a pet peeve of mine,
so I always point it out. Feel free to ignore :-)


2.  The MUD Model and Semantic Meaning
  ...

  To provide the widest possible deployability, publishers of MUD files
  SHOULD make use of the abstractions in this memo and avoid the use of

[O] memo
[P] document - as above :-p Also, is 'deployability' a real word now?
MW doesn't seems to think so, nor does OE.
...


  Furthermore, only or "accept" or "drop" actions SHOULD be included.

[O] only or
[P] only
[R] either we are missing a word before =E2=80=9Cor,=E2=80=9D or or is not =
needed


3.4.  is-supported
  This boolean is an indication from the manufacturer to the network
  administrator as to whether or not the Thing is supported.  In this
  context a Thing is said to NOT be supported if the manufacturer
  intends never to issue an update to the Thing or never update the MUD
  file.  A MUD controller MAY still peridocally check for updates.

[O] peridocally
[P] periodically
[R] spelling


----

Thanks again,
W


--=20
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf


From nobody Tue Oct 24 04:46:50 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 4644B13F3B5; Tue, 24 Oct 2017 04:46:48 -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 0O62k5EU1Ktv; Tue, 24 Oct 2017 04:46:45 -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 AF05913F5BF; Tue, 24 Oct 2017 04:46:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21685; q=dns/txt; s=iport; t=1508845605; x=1510055205; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Qd+1j3LHwDhHIMoHLpr0ly0Us4rkFDGz4Jw/7CBclD4=; b=m8aTTBqTYp3eHw6Kq1aw9vq4sdteKqJO24+EnfXbs/QGvnLphhCF4YkU bS1Pykyr0CgCtRvn00AXwPdZw1npH6Juu+2FcG8qtMAp4aZYr9F/b7Z0U Tou/Yndu0mkMaQx5PMhiTheGac/C7fRO7vwY5EszgI9nK4o5pxmWU+uC1 I=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuAQDzJu9Z/xbLJq1TChoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJvgkKEIYsTkE2QeIVSggEHA4U7AoUhFQECAQEBAQEBAWsohR4BBAE?= =?us-ascii?q?jWwsLEjACAkkOBgEMCAEBihQIpzGCJyaKfQEBAQEBAQEDAQEBAQEBAQEBAQEOD?= =?us-ascii?q?4MugTWECymCLlOESREEgzuCYQEEiiqHJocjiHqEQYIjhBuJdoIVhXqDXYc4hzK?= =?us-ascii?q?Cc4tagTk1IoFbNCEIHRWDLoJWBAEcgWk+iSmCRAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,427,1503360000";  d="asc'?scan'208,217";a="655648996"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 11:46:42 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9OBkfQt024765; Tue, 24 Oct 2017 11:46:41 GMT
To: Warren Kumari , draft-ietf-opsawg-mud@ietf.org, "opsawg-chairs@ietf.org" , opsawg@ietf.org
References: 
From: Eliot Lear 
Message-ID: <4fa65c18-80b5-5a7b-0c7a-9cc08e98769e@cisco.com>
Date: Tue, 24 Oct 2017 13:46:41 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HtBH6uOC03fbgHGthNXflt1wb90s0afen"
Archived-At: 
Subject: Re: [OPSAWG] AD review of: draft-ietf-opsawg-mud.
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, 24 Oct 2017 11:46:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HtBH6uOC03fbgHGthNXflt1wb90s0afen
Content-Type: multipart/mixed; boundary="FaQSMGfJqkGPEVgDIO7jd2kOmVj14qlxp";
 protected-headers="v1"
From: Eliot Lear 
To: Warren Kumari , draft-ietf-opsawg-mud@ietf.org,
 "opsawg-chairs@ietf.org" , opsawg@ietf.org
Message-ID: <4fa65c18-80b5-5a7b-0c7a-9cc08e98769e@cisco.com>
Subject: Re: AD review of: draft-ietf-opsawg-mud.
References: 
In-Reply-To: 

--FaQSMGfJqkGPEVgDIO7jd2kOmVj14qlxp
Content-Type: multipart/alternative;
 boundary="------------76F8BA767357E1C87F3331F4"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------76F8BA767357E1C87F3331F4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[this time to the wg and chairs]

Warren,

Thanks for your review, and I'm sorry to hear of your illness.


On 10/24/17 12:37 AM, Warren Kumari wrote:

> First, sorry for the delay in reviewing this -- I'm recovering from
> pneumonia and so it took longer than it should have.
>
> I do have a few comments that I=E2=80=99d like addressed
> before I start IETF LC =E2=80=94 addressing these now will avoid
> issues later in the process.
>
> I believe that all my comments are editorial, and should be easy fixes.=

> Please explicitly let me know once you've posted a new version, just
> to make sure it doesn't slip through the cracks.
>
> Warren.
>
> -------
>
> 1.  Introduction
>   The Internet has largely been constructed on general purpose
>   computers; those devices that may be used for a purpose that is
> [O] computers;
> [P] computers:
> [R] punctuation
>   specified by those who buy the device.

I think actually ",", but I'll let the RPC sort us on that one=20

>   ...
>   Let us then posit a group of objects that are
>   specifically NOT general purpose computers.  These devices have a
>   purpose to their use.  By definition, therefore, all other purposes
>
> [O] purpose to their use.
> [P] specific purpose to their use.
> [R] clarity / continuity with previous
>   are NOT intended.

Clarified as follows:

> These devices
> have a specific purpose.=C2=A0 By definition, therefore, all other
> uses are NOT intended.
>   ...
>
>   We use the notion of "manufacturer" loosely in this context, to
>   simply mean the entity or organization that will state how a device
>
> [O] context, to simply mean
> [P] context to refer to
> [R] clarity and grammar
>   is intended to be used.
>   ...

ok

>   The key points are that the device itself is expected
>   to serve a limited purpose, and that there may exist an organization
>   in the supply chain of that device that will take responsibility for
>   informing the network about that purpose.
>   The intent MUD is to solve for the following problems:
>
> [O] intent MUD
> [P] intent of MUD
> [R] grammar

Right.

>   In this specification we describe each of these building blocks and
>   how they are intended to be used together.  However, they may also be=

>   used separately, independent of this specification by local
>
> [O] independent of this specification
> [P] independent of this specification,
> [R] grammar
>   deployments for their own purposes.

Ok.

> 1.1.  What MUD doesn't do
>   ...
>   How they are instantiated
>   locally will depend on many factors, and is ultimately up to the
>
> [O] factors,
> [P] factors
> [R] grammar
>   local network administrator, who must decide what is appropriate in a=

>   given circumstances.

Right.=C2=A0 That and tense correction.

> 1.2.  A Simple Example
>   A light bulb is intended to light a room.  It may be remotely
>   controlled through the network; and it may make use of a rendezvous
>
> [O] network;
> [P] network,
> [R] grammar

Yup.

>   service of some form that an app on smart phone accesses.
>
>
> 1.3.  Determining Intended Use
>   ...
>   Profiling systems that make use of heuristics to
>   identify types of systems have existed for years as well.
>   A Thing could just as easily tell the network what sort of protection=

>
> [O] protection
> [R] protection? Or access?
>
>   it requires without going into what sort of system it is.

Access is better.

> 1.4.  Finding A Policy: The MUD URL
>   ...
>   The IEEE has developed [IEEE8021AR] that provides a
>   certificate-based approach to communicate device characteristics,
>   which itself relies on [RFC5280].
>   [C]: "that provides" or "which provides"?
>
>   ...
>   In these cases, manufacturers may be able to map those
>   identifies to particular MUD URLs (or even the files themselves).
>
> [O] indentifies
> [P] indentifiers
> [R] I think this is what was meant. Or perhaps identities?

I like identifiers.=C2=A0 More specific.

> 1.5.  Types of Policies
>   ...
>   For example:
>      Allow access to devices of the same manufacturer
>      Allow access to and from controllers via COAP
>
> [O] via COAP
> [R] Please expand COAP, it's not well known.

Ok

>   To add a bit more depth that should not be a stretch of anyone's
>   imagination, one could also make use of port-based access lists.
>
> [O] that should not be a stretch of anyone's imagination
> [R] I don't think this phrase makes sense in this context, or at least
> it sounded odd to me.

Trimmed.

>  ...
>   While the policy examples given here focus on access control, this is=

>   not intended to be the sole focus.  By structuring the model
>   described in this document with clear extension points, so that other=

>
> [O] , so that other
> [P], other
> [R] readability

Right.

>   descriptions could be included.
>
> ...
>   The "manufacturer" classes can be easily specified by the
>   manufacturer, whereas controller classes are initially envisioned to
>   be specified by the administrator.
>   Because manufacturers do not know who will be using their devices, it=

>   is important for functionality referenced in usage descriptions to be=

>   relatively ubiquitous, and mature.  For these reasons only a limited
>
> [O] ubiquitous, and mature
> [P] ubiquitous and mature
> [R] grammar

yep

>   subset YANG-based configuration of is permitted in a MUD file.
>
> 1.6.  Terminology
>   ...
>   After it has processed a MUD file it may
>
> [O] After it has processed a MUD file it may
> [P] After it has processed a MUD file, it may
> [R] grammar
>      direct changes to relevant network elements.

ok

>  ...
>
> 1.7.  The Manufacturer Usage Description Architecture
>   With these components laid out we now have the basis for an
>   archicture.  This leads us to ASCII art.
>
> [O] archicture
> [P] architecture
> [R] spelling / typo.

doh.=C2=A0 (so to speak).

>   ...
>
>   The web site is typically run by or on behalf of the manufacturer.
>   Its domain name is that of the authority found in the MUD URL.  For
>   legacy cases where Things cannot emit a URL, if the switch is able to=

>   determine the appropriate URL, it may proxy it, the trivial cases
>   being a map between some registered Thing or port and a URL.
>
> [O] the trivial cases
>   being a map between some registered Thing or port and a URL.
> [R] cannot parse this part of the sentence.

Fixed as follows:

> For
> legacy cases where Things cannot emit a URL, if the switch is able to
> determine the appropriate URL, it may proxy it, the trivial cases
> being a=C2=A0=C2=A0 =C2=A0hardcoded MUD-URL on a switch port, or a mapp=
ing from some
> available identifier such as an L2 address or certificate hash to a
> MUD-URL.
>    ...
>
>   Communication within those systems and from those systems to
>   network elements is beyond the scope of this memo.
>
> [O] memo
> [P] document -- either is allowed, this is just a pet peeve of mine,
> so I always point it out. Feel free to ignore=20

I'm of the memo era.

> 2.  The MUD Model and Semantic Meaning
>   ...
>
>   To provide the widest possible deployability, publishers of MUD files=

>   SHOULD make use of the abstractions in this memo and avoid the use of=

>
> [O] memo
> [P] document - as above  Also, is 'deployability' a real word now?
> MW doesn't seems to think so, nor does OE.
> ...

Going for deployment.

>   Furthermore, only or "accept" or "drop" actions SHOULD be included.
>
> [O] only or
> [P] only
> [R] either we are missing a word before =E2=80=9Cor,=E2=80=9D or or is =
not needed

Right.

> 3.4.  is-supported
>   This boolean is an indication from the manufacturer to the network
>   administrator as to whether or not the Thing is supported.  In this
>   context a Thing is said to NOT be supported if the manufacturer
>   intends never to issue an update to the Thing or never update the MUD=

>   file.  A MUD controller MAY still peridocally check for updates.
>
> [O] peridocally
> [P] periodically
> [R] spelling

Corrected.

Chicken soup for you.

Eliot


--------------76F8BA767357E1C87F3331F4
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    

    

    

      
[this time to the wg and chairs]

Warren,

Thanks for your review, and I'm sorry to hear of your illness.


On 10/24/17 12:37 AM, Warren Kumari wrote:


      

        
First, sorry for the delay in reviewing this -- I'=
m recovering from
pneumonia and so it took longer than it should have.

I do have a few comments that I=E2=80=99d like addressed
before I start IETF LC =E2=80=94 addressing these now will avoid
issues later in the process.

I believe that all my comments are editorial, and should be easy fixes.
Please explicitly let me know once you've posted a new version, just
to make sure it doesn't slip through the cracks.

Warren.

-------

1.  Introduction
  The Internet has largely been constructed on general purpose
  computers; those devices that may be used for a purpose that is
[O] computers;
[P] computers:
[R] punctuation
  specified by those who buy the device.


      

      
I think actually ",", but I'll let the RPC sort us o=
n that one 


      

        
  ...
  Let us then posit a group of objects that are
  specifically NOT general purpose computers.  These devices have a
  purpose to their use.  By definition, therefore, all other purposes

[O] purpose to their use.
[P] specific purpose to their use.
[R] clarity / continuity with previous
  are NOT intended.


      

      
Clarified as follows:


      

        
These devices
have a specific purpose.=C2=A0 By definition, therefore, all other
uses are NOT intended.


      

      

        
  ...

  We use the notion of "manufacturer" loosely in this context, to
  simply mean the entity or organization that will state how a device

[O] context, to simply mean
[P] context to refer to
[R] clarity and grammar
  is intended to be used.
  ...


      

      
ok


      

        
  The key points are that the device itself is exp=
ected
  to serve a limited purpose, and that there may exist an organization
  in the supply chain of that device that will take responsibility for
  informing the network about that purpose.
  The intent MUD is to solve for the following problems:

[O] intent MUD
[P] intent of MUD
[R] grammar


      

      
Right.



      

        
  In this specification we describe each of these =
building blocks and
  how they are intended to be used together.  However, they may also be
  used separately, independent of this specification by local

[O] independent of this specification
[P] independent of this specification,
[R] grammar
  deployments for their own purposes.


      

      
Ok.


      

        
1.1.  What MUD doesn't do
  ...
  How they are instantiated
  locally will depend on many factors, and is ultimately up to the

[O] factors,
[P] factors
[R] grammar
  local network administrator, who must decide what is appropriate in a
  given circumstances.


      

      
Right.=C2=A0 That and tense correction.



      

        
1.2.  A Simple Example
  A light bulb is intended to light a room.  It may be remotely
  controlled through the network; and it may make use of a rendezvous

[O] network;
[P] network,
[R] grammar


      

      
Yup.



      

        
  service of some form that an app on smart phone =
accesses.


1.3.  Determining Intended Use
  ...
  Profiling systems that make use of heuristics to
  identify types of systems have existed for years as well.
  A Thing could just as easily tell the network what sort of protection

[O] protection
[R] protection? Or access?

  it requires without going into what sort of system it is.


      

      
Access is better.



      

        
1.4.  Finding A Policy: The MUD URL
  ...
  The IEEE has developed [IEEE8021AR] that provides a
  certificate-based approach to communicate device characteristics,
  which itself relies on [RFC5280].
  [C]: "that provides" or "which provides"?

  ...
  In these cases, manufacturers may be able to map those
  identifies to particular MUD URLs (or even the files themselves).

[O] indentifies
[P] indentifiers
[R] I think this is what was meant. Or perhaps identities?


      

      
I like identifiers.=C2=A0 More specific.



      

        
1.5.  Types of Policies
  ...
  For example:
     Allow access to devices of the same manufacturer
     Allow access to and from controllers via COAP

[O] via COAP
[R] Please expand COAP, it's not well known.


      

      
Ok


      

        
  To add a bit more depth that should not be a str=
etch of anyone's
  imagination, one could also make use of port-based access lists.

[O] that should not be a stretch of anyone's imagination
[R] I don't think this phrase makes sense in this context, or at least
it sounded odd to me.


      

      
Trimmed.


      

        
 ...
  While the policy examples given here focus on access control, this is
  not intended to be the sole focus.  By structuring the model
  described in this document with clear extension points, so that other

[O] , so that other
[P], other
[R] readability


      

      
Right.


      

        
  descriptions could be included.

=2E..
  The "manufacturer" classes can be easily specified by the
  manufacturer, whereas controller classes are initially envisioned to
  be specified by the administrator.
  Because manufacturers do not know who will be using their devices, it
  is important for functionality referenced in usage descriptions to be
  relatively ubiquitous, and mature.  For these reasons only a limited

[O] ubiquitous, and mature
[P] ubiquitous and mature
[R] grammar


      

      
yep


      

        
  subset YANG-based configuration of is permitted =
in a MUD file.

1.6.  Terminology
  ...
  After it has processed a MUD file it may

[O] After it has processed a MUD file it may
[P] After it has processed a MUD file, it may
[R] grammar
     direct changes to relevant network elements.


      

      
ok


      

        
 ...

1.7.  The Manufacturer Usage Description Architecture
  With these components laid out we now have the basis for an
  archicture.  This leads us to ASCII art.

[O] archicture
[P] architecture
[R] spelling / typo.


      

      
doh.=C2=A0 (so to speak).


      

        
  ...

  The web site is typically run by or on behalf of the manufacturer.
  Its domain name is that of the authority found in the MUD URL.  For
  legacy cases where Things cannot emit a URL, if the switch is able to
  determine the appropriate URL, it may proxy it, the trivial cases
  being a map between some registered Thing or port and a URL.

[O] the trivial cases
  being a map between some registered Thing or port and a URL.
[R] cannot parse this part of the sentence.


      

      
Fixed as follows:



      

        
For
legacy cases where Things cannot emit a URL, if the switch is able to
determine the appropriate URL, it may proxy it, the trivial cases
being a=C2=A0=C2=A0 =C2=A0hardcoded MUD-URL on a switch port, or a mappin=
g from some
available identifier such as an L2 address or certificate hash to a
MUD-URL.


      

      

        
   ...

  Communication within those systems and from those systems to
  network elements is beyond the scope of this memo.

[O] memo
[P] document -- either is allowed, this is just a pet peeve of mine,
so I always point it out. Feel free to ignore 


      

      
I'm of the memo era.



      

        
2.  The MUD Model and Semantic Meaning
  ...

  To provide the widest possible deployability, publishers of MUD files
  SHOULD make use of the abstractions in this memo and avoid the use of

[O] memo
[P] document - as above  Also, is 'deployability' a real word now?
MW doesn't seems to think so, nor does OE.
=2E..


      

      
Going for deployment.


      

        
  Furthermore, only or "accept" or "drop" actions SHOULD be included.

[O] only or
[P] only
[R] either we are missing a word before =E2=80=9Cor,=E2=80=9D or or is no=
t needed


      

      
Right.


      

        
3.4.  is-supported
  This boolean is an indication from the manufacturer to the network
  administrator as to whether or not the Thing is supported.  In this
  context a Thing is said to NOT be supported if the manufacturer
  intends never to issue an update to the Thing or never update the MUD
  file.  A MUD controller MAY still peridocally check for updates.

[O] peridocally
[P] periodically
[R] spelling


      

      
Corrected.

Chicken soup for you.

Eliot


    

  


--------------76F8BA767357E1C87F3331F4--

--FaQSMGfJqkGPEVgDIO7jd2kOmVj14qlxp--

--HtBH6uOC03fbgHGthNXflt1wb90s0afen
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

iQEcBAEBCAAGBQJZ7ygiAAoJEIe2a0bZ0nozcTcIAKHXZQf9+pTuPzLC8Zj+O0R2
tcn9rSR2BCKnQBf+9rU6VFvCEb8QUPTzI6GN4OO49VzRz+S2qMXCsraZyrMnUiYG
IqdA6chCBODB3hpGss1xJe7OMJieVRVrfqD7Xq3SnaPd/pUlp9sRIV2V4ezRtFiY
eLhCQqndwfgCNyAba3t4eF9e6dtrErOZho51tMTKuMlR5pYzWQPDOUXQMYCEBOs9
oL7YiEQL1B+dB+Zf5Vaa7eAELxaxXaJtTa5OmLII50uEfGdHiDGxnjKGr+Ac9qnH
vNxtsjfTJHLX3DBR2Kas7eWo53AsQrhFLzutJQDhSppJNLMdkIkOeBLdqICkM0c=
=HWcV
-----END PGP SIGNATURE-----

--HtBH6uOC03fbgHGthNXflt1wb90s0afen--


From nobody Tue Oct 24 04:49: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 C9F4913F701 for ; Tue, 24 Oct 2017 04:49:08 -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 5TWwMxj-SuVU for ; Tue, 24 Oct 2017 04:49:07 -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 884B513F6FB for ; Tue, 24 Oct 2017 04:49:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7196; q=dns/txt; s=iport; t=1508845746; x=1510055346; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=HEH94z+An0P58IR7Xp5A+ZDiFTLsKJmz6bhS/nFz+5I=; b=dDkgZFC5YsDsfpe0tARtSPhx5FAq+SqbjfmLzpZj+MoXq9wB0CV0gg9s qPPTjXb6OKGh5f5NiWsEzYRUlokI3SdtiR94xoWlowWMyzT5CtRnNO53H Msy3pGX1TQG8XGc/1PBI6Bu4TFuah+IPqinMXjjdFRuIoeO9+rSLTHUQd E=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAABXKO9Z/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N6ih90kE2QeIVCghEHAxgBCoRJTwKFHhgBAgEBAQEBAQF?= =?us-ascii?q?rKIUeAQEBAwEBIUsbCxgqAgInMAYBDAYCAQGKHBCnIIInJop9AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARAKBYMuhUApgwGEb4MqgmEFihQQiRmFNoh6hEGCI44RhAmHY4c?= =?us-ascii?q?4lX+BOR84gVs0IQgdFUmCZIRhPjaLNwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,427,1503360000";  d="asc'?scan'208,217";a="698217938"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 11:48:40 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9OBmek8002040; Tue, 24 Oct 2017 11:48:40 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References: 
From: Eliot Lear 
Message-ID: 
Date: Tue, 24 Oct 2017 13:48:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rGQfxNbteKmx9XgMC0nE8pVQ4VFwpjT9P"
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 11:49:09 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--rGQfxNbteKmx9XgMC0nE8pVQ4VFwpjT9P
Content-Type: multipart/mixed; boundary="xN0uVvt0cNlT6dxO3hPGciH9G4NJHrE3C";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" , opsawg@ietf.org
Message-ID: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
References: 
In-Reply-To: 

--xN0uVvt0cNlT6dxO3hPGciH9G4NJHrE3C
Content-Type: multipart/alternative;
 boundary="------------AE9E2A228C79BDAF04281B01"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------AE9E2A228C79BDAF04281B01
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I want to confirm this with the WG and the chairs.=C2=A0 I'm okay removin=
g
this if others are as well.=C2=A0 It's past WGLC and I am about to post -=
13.=C2=A0
Objections?

On 10/24/17 12:02 AM, M. Ranganathan wrote:
> Hello,
>
> I am wondering about the utility of the actions part of the ACE.
>
> In the latest MUD draft, I see "Appendix B : Default MUD nodes" where
> it is suggested that one could, for example, set up to drop packets to
> the DNS server by setting actions
>
>
>                "actions": {
>                    "forwarding": "drop"
>                  }
>
> But this is only because there is a notion of default access in MUD
> which assume the IOT device isallowed to access DNS and NTP by
> default, which now has to be overriden by a "drop" action.
> This goes aginst the basic MUD working principle that everything is
> denied unless explictly stated.
> I am just voicing an opinon here : Perhaps it would be less confusing
> if NTP and DNS were not given any special treatment. It really does
> not save much by way of length of the MUD file to explicitly state
> rules for them
> Perhaps it is a bit late to suggest this but may I suggest removing
> the idea of default permit access to DNS and NTP. It would simplify
> some things.
> Thanks,
> Regards,
> Ranga.
>
>
>
>
>
> --=20
> M. Ranganathan
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


--------------AE9E2A228C79BDAF04281B01
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    I want to confirm this with the WG and the chairs.=C2=A0 I'm okay
    removing this if others are as well.=C2=A0 It's past WGLC and I am ab=
out
    to post -13.=C2=A0 Objections?

    

    
On 10/24/17 12:02 AM, M. Ranganathan
      wrote:

    

    

      
      

        

          
Hello,

            

          

          
I am wondering about the utility of the actions part of
            the ACE.

            

          

          In the latest MUD draft, I see "Appendix B : Default MUD
          nodes" where it is suggested that one could, for example, set
          up to drop packets to the DNS server by setting actions 

        

        

        

        
               "actions": {
                   "forwarding": "drop"
                 }



        
But this is only because there is a notion of default access =
in MUD which assume
the IOT device isallowed to access DNS and NTP by default, which now has =
to=20
be overriden by a "drop" action.



        
This goes aginst the basic MUD working principle that everyth=
ing is denied unless explictly =20
stated.


        
I am just voicing an opinon here :=20

Perhaps it would be less confusing if NTP and DNS were not given any spec=
ial treatment.
It really does not save much by way of length of the MUD file to explicit=
ly state rules
for them


        

Perhaps it is a bit late to suggest this but may I suggest removing the i=
dea of default=20
permit access to DNS and NTP. It would simplify some things.



        
Thanks,



        
Regards,=20



        
Ranga.


        




        

        



        



        

        

        

          

            

              


                -- 

                
M. Ranganathan

                

              

            

          

        

      

      

      

      

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


    

    

  


--------------AE9E2A228C79BDAF04281B01--

--xN0uVvt0cNlT6dxO3hPGciH9G4NJHrE3C--

--rGQfxNbteKmx9XgMC0nE8pVQ4VFwpjT9P
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

iQEcBAEBCAAGBQJZ7yiZAAoJEIe2a0bZ0nozklAH/jLAji8qPA7NYNNxDXsucGmu
JMF734akK8wsUtQAaJ2A9k4bHeg+EINdJIugx965psbLYTiM+htZW9KPuDxNbFlU
y/n3nQJp9tm6UCxxstkgvHHZkXCiCvy1BijdZGpSU6S4flFJdhGfr7lBNkk5FgB7
trbT1WYSQvASXesaITA1NGYfp18fRM55qWpgyC33/KRMojOxEGGU7ciVQEfETx6o
WYBVkoz6+m5vBj0HaMrJlvF6egrd73CBaaHpOug7YdoAKOPHvfU9pNrxodLnr/Qe
GTKZ5ynyTMQIyTq/EiPucIY5V+q/1l2eHT7HOM88lPprxweFVF2KPcjpztchBRI=
=Vfme
-----END PGP SIGNATURE-----

--rGQfxNbteKmx9XgMC0nE8pVQ4VFwpjT9P--


From nobody Tue Oct 24 05:48:23 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 A431513F756 for ; Tue, 24 Oct 2017 05:48:21 -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 Sd5GPcaXhkUI for ; Tue, 24 Oct 2017 05:48:17 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC3913F72E for ; Tue, 24 Oct 2017 05:48:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2058; q=dns/txt; s=iport; t=1508849297; x=1510058897; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=L7TuB7y/U5HbaieP+P/Oa8zgWUOBcuRKtQp+r4+qkiI=; b=lpYKxO4Bc5SpdvSCq3zCTiM5R8u1uXZAuS7vZ6egym60afWdgqBOkNIE SyJHjQIZWRe+8SVXL3YuNS8nG3dFl37AnjTHgoj3qoshKEHoww3NPSoyd XGdp+bnKN0IsxurxsuydqPG5knldbUNuPTTEEqhNrbDqHR6JnaodnbmnL g=;
X-IronPort-AV: E=Sophos;i="5.43,427,1503360000"; d="scan'208";a="20785299"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 12:48:17 +0000
Received: from [10.118.87.88] (rtp-jclarke-nitro7.cisco.com [10.118.87.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v9OCmGqf024751; Tue, 24 Oct 2017 12:48:16 GMT
To: Eliot Lear , "M. Ranganathan" , opsawg@ietf.org
References:  
From: Joe Clarke 
Organization: Cisco
Message-ID: <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com>
Date: Tue, 24 Oct 2017 08:48:19 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 12:48:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/24/17 07:48, Eliot Lear wrote:
> I want to confirm this with the WG and the chairs.  I'm okay
> removing this if others are as well.  It's past WGLC and I am about
> to post -13. Objections?

This seems better for security and clarity with respect to other MUD
elements.  But does this break any current implementations?

Joe

> 
> On 10/24/17 12:02 AM, M. Ranganathan wrote:
>> Hello,
>> 
>> I am wondering about the utility of the actions part of the ACE.
>> 
>> In the latest MUD draft, I see "Appendix B : Default MUD nodes"
>> where it is suggested that one could, for example, set up to drop
>> packets to the DNS server by setting actions
>> 
>> 
>> "actions": { "forwarding": "drop" }
>> 
>> But this is only because there is a notion of default access in
>> MUD which assume the IOT device isallowed to access DNS and NTP
>> by default, which now has to be overriden by a "drop" action. 
>> This goes aginst the basic MUD working principle that everything
>> is denied unless explictly stated. I am just voicing an opinon
>> here : Perhaps it would be less confusing if NTP and DNS were not
>> given any special treatment. It really does not save much by way
>> of length of the MUD file to explicitly state rules for them 
>> Perhaps it is a bit late to suggest this but may I suggest
>> removing the idea of default permit access to DNS and NTP. It
>> would simplify some things. Thanks, Regards, Ranga.
>> 
>> 
>> 
>> 
>> 
>> -- M. Ranganathan
>> 
>> 
>> _______________________________________________ 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/hTPhwUCWe82kQAKCRBvaI+K/hTP
h3OqAKCadr2ODxshWc7bo9gW/QycPgqCuACeL2R0U9iChi1CO3Kg0gQXiu3SqD8=
=sCr9
-----END PGP SIGNATURE-----


From nobody Tue Oct 24 06:28: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 463E513F5F6 for ; Tue, 24 Oct 2017 06:28:45 -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 M6vqNS2gke5u for ; Tue, 24 Oct 2017 06:28:43 -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 6BDB213D0B6 for ; Tue, 24 Oct 2017 06:28:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7639; q=dns/txt; s=iport; t=1508851722; x=1510061322; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=P5zFHhnttafu4rOd+Ddi6gmWdVxYG+rIxKsLS+I34O4=; b=e2jKOjpaPWu3xme+oqubwT9rdj/JTjTIRhITfZIiX+BQytWlqW69xu1q 0Bm/VzmqD3luWla/XakJp57FdAZ1E8KkEQINNpN3RHmJ1c+FJdjITFH7C ufaOZj6HBFPQAhcIDPpetVKLGs8IuplfsHQLHmCwDQuOs254TwO+64ZO2 A=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.43,427,1503360000";  d="asc'?scan'208,217";a="656555390"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 13:28:40 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9ODSeT2026562; Tue, 24 Oct 2017 13:28:40 GMT
To: Joe Clarke , "M. Ranganathan" , opsawg@ietf.org
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com>
From: Eliot Lear 
Message-ID: <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com>
Date: Tue, 24 Oct 2017 15:28:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ea6SAR7daiEf3BVnbCBoDspiUNgpK7kfo"
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 13:28:45 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Ea6SAR7daiEf3BVnbCBoDspiUNgpK7kfo
Content-Type: multipart/mixed; boundary="uTtqoE3b2CKUFgvj25WN86xjm7UWoqV0j";
 protected-headers="v1"
From: Eliot Lear 
To: Joe Clarke , "M. Ranganathan" ,
 opsawg@ietf.org
Message-ID: <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com>
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
References: 
 
 <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com>
In-Reply-To: <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com>

--uTtqoE3b2CKUFgvj25WN86xjm7UWoqV0j
Content-Type: multipart/alternative;
 boundary="------------909C524D4816DFE78FEC0E9E"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------909C524D4816DFE78FEC0E9E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 10/24/17 2:48 PM, Joe Clarke wrote:
> On 10/24/17 07:48, Eliot Lear wrote:
> > I want to confirm this with the WG and the chairs.=C2=A0 I'm okay
> > removing this if others are as well.=C2=A0 It's past WGLC and I am ab=
out
> > to post -13. Objections?
>
> This seems better for security and clarity with respect to other MUD
> elements.=C2=A0 But does this break any current implementations?

This is a draft.=C2=A0 The underlying model has changed, so this is small=

potatos.

Eliot

>
> Joe
>
>
> > On 10/24/17 12:02 AM, M. Ranganathan wrote:
> >> Hello,
> >>
> >> I am wondering about the utility of the actions part of the ACE.
> >>
> >> In the latest MUD draft, I see "Appendix B : Default MUD nodes"
> >> where it is suggested that one could, for example, set up to drop
> >> packets to the DNS server by setting actions
> >>
> >>
> >> "actions": { "forwarding": "drop" }
> >>
> >> But this is only because there is a notion of default access in
> >> MUD which assume the IOT device isallowed to access DNS and NTP
> >> by default, which now has to be overriden by a "drop" action.
> >> This goes aginst the basic MUD working principle that everything
> >> is denied unless explictly stated. I am just voicing an opinon
> >> here : Perhaps it would be less confusing if NTP and DNS were not
> >> given any special treatment. It really does not save much by way
> >> of length of the MUD file to explicitly state rules for them
> >> Perhaps it is a bit late to suggest this but may I suggest
> >> removing the idea of default permit access to DNS and NTP. It
> >> would simplify some things. Thanks, Regards, Ranga.
> >>
> >>
> >>
> >>
> >>
> >> -- M. Ranganathan
> >>
> >>
> >> _______________________________________________ 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
>
>
>


--------------909C524D4816DFE78FEC0E9E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    

    

    On 10/24/17 2:48 PM, Joe Clarke wrote:

    
On 10/24/17 07:48, Eliot Lear wrote:

      > I want to confirm this with the WG and the chairs.=C2=A0 I'm o=
kay

      > removing this if others are as well.=C2=A0 It's past WGLC and =
I am
      about

      > to post -13. Objections?

      

      This seems better for security and clarity with respect to other
      MUD

      elements.=C2=A0 But does this break any current implementations?
    

    

    This is a draft.=C2=A0 The underlying model has changed, so this is s=
mall
    potatos.

    

    Eliot

    

    


      Joe

      

      

      > On 10/24/17 12:02 AM, M. Ranganathan wrote:

      >> Hello,

      >>

      >> I am wondering about the utility of the actions part of
      the ACE.

      >>

      >> In the latest MUD draft, I see "Appendix B : Default MUD
      nodes"

      >> where it is suggested that one could, for example, set up
      to drop

      >> packets to the DNS server by setting actions

      >>

      >>

      >> "actions": { "forwarding": "drop" }

      >>

      >> But this is only because there is a notion of default
      access in

      >> MUD which assume the IOT device isallowed to access DNS
      and NTP

      >> by default, which now has to be overriden by a "drop"
      action. 

      >> This goes aginst the basic MUD working principle that
      everything

      >> is denied unless explictly stated. I am just voicing an
      opinon

      >> here : Perhaps it would be less confusing if NTP and DNS
      were not

      >> given any special treatment. It really does not save much
      by way

      >> of length of the MUD file to explicitly state rules for
      them 

      >> Perhaps it is a bit late to suggest this but may I
      suggest

      >> removing the idea of default permit access to DNS and
      NTP. It

      >> would simplify some things. Thanks, Regards, Ranga.

      >>

      >>

      >>

      >>

      >>

      >> -- M. Ranganathan

      >>

      >>

      >> _______________________________________________ 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;


    

  


--------------909C524D4816DFE78FEC0E9E--

--uTtqoE3b2CKUFgvj25WN86xjm7UWoqV0j--

--Ea6SAR7daiEf3BVnbCBoDspiUNgpK7kfo
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

iQEcBAEBCAAGBQJZ70AIAAoJEIe2a0bZ0nozq08IAJAGZa9INViYdFf6i7AlJpnT
Qr2Fn9PoALFoCjI+045XPaeGNzi9IQVW+4WFKPNjnT/TDfLcASVw5QJTzvLAbeOM
hDIVDCLzMQMNrVKesf0fbgol7h6YeG2nRxJ/M+gDOhVuNrBcXykAWTw1Ya8cP2Rr
bFBiq3Fqeir615mqF1n9S35RmyLQSsfzDySRIa7TV/gE0xmL5dDCqSf7HVBKTmeb
LQjRkCtZP9k6EluOKx9MavXLK3tKx1n+3tdyuDRWwJs4S/M7m+R+USqdQFtnAk7s
gTvd705NwwvkGDA3LtdYAgOB8Y2oVPn3DhPqe+0vqXhITPsZBjL6m7bwAT3gVFU=
=KtfK
-----END PGP SIGNATURE-----

--Ea6SAR7daiEf3BVnbCBoDspiUNgpK7kfo--


From nobody Tue Oct 24 06:38: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 B5FD313F507 for ; Tue, 24 Oct 2017 06:38:09 -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_H4=-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 DMtgidPNijM7 for ; Tue, 24 Oct 2017 06:38:02 -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 B152213F465 for ; Tue, 24 Oct 2017 06:38:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=996; q=dns/txt; s=iport; t=1508852281; x=1510061881; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=AW6sevq1K5cyvuikLSI+wUqe3L2dqwFkeo439pQ5dhI=; b=BgpI9wS44wr9wygpg8udQKoCsaEsnIRFsfhrKVPbYWeEY+yywGG0N/fN 7CLLQL9wsn8rAVNZ5CEZcKE5ZPkj14DzGflOkQ3lN/Mn1v2A5LmjGz/nD irpHfDJ5IwcG97ExJLr6fgoI6C9TtEV1Whk8wvc0Qmr0kkoOJBMMbBSU7 s=;
X-IronPort-AV: E=Sophos;i="5.43,427,1503360000"; d="scan'208";a="21330719"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 13:38:01 +0000
Received: from [10.118.87.88] (rtp-jclarke-nitro7.cisco.com [10.118.87.88]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v9ODc0nN008883; Tue, 24 Oct 2017 13:38:00 GMT
To: Eliot Lear , "M. Ranganathan" , opsawg@ietf.org
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com> <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com>
From: Joe Clarke 
Organization: Cisco
Message-ID: <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com>
Date: Tue, 24 Oct 2017 09:38:00 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 13:38:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/24/17 09:28, Eliot Lear wrote:
> 
> 
> On 10/24/17 2:48 PM, Joe Clarke wrote:
>> On 10/24/17 07:48, Eliot Lear wrote:
>>> I want to confirm this with the WG and the chairs.  I'm okay 
>>> removing this if others are as well.  It's past WGLC and I am
>>> about to post -13. Objections?
>> 
>> This seems better for security and clarity with respect to other
>> MUD elements.  But does this break any current implementations?
> 
> This is a draft.  The underlying model has changed, so this is
> small potatos.

I understand.  I was just trying to be pedantic as I know that people
are working on MUD quite actively.  As I said, I like the idea, and I
think it makes sense to change now versus errata down the line.

Joe
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWe9CNgAKCRBvaI+K/hTP
h1k3AKCjF9nvmxpgPo6gUwqvnUwR65GnZwCdEUEiDHIWaY3qtYx9zCg/kyQwgTM=
=D/Ls
-----END PGP SIGNATURE-----


From nobody Tue Oct 24 07:15:07 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 1952513F7C6 for ; Tue, 24 Oct 2017 07:15:06 -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 1nm51mzdudf8 for ; Tue, 24 Oct 2017 07:15:04 -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 E7C3313F3D1 for ; Tue, 24 Oct 2017 07:15:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6396; q=dns/txt; s=iport; t=1508854504; x=1510064104; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=uMFwONsZiAOUJ396nV0xaVVHv7XeBxPo2MzOQx6n01I=; b=ip7YqtX6xUI7WBtYFqsVMygOhaBo9fsAtjlKyIR54FkPim226h2K+Dsq JDyAupGR8gJ1ZSFbULSe3xvnCxH8bwK+5cPj6HBcSA7Q3ljFj+XwXU9uA Z8bfKeEjvcO6JeF0lPdZ39MIqtO/XYp9gc1WXaspNMMiITBqOtnYMRPEk c=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.43,428,1503360000";  d="asc'?scan'208,217";a="656556205"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 14:15:02 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9OEF13U021785; Tue, 24 Oct 2017 14:15:01 GMT
To: Joe Clarke , "M. Ranganathan" , opsawg@ietf.org
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com> <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com> <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com>
From: Eliot Lear 
Message-ID: <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>
Date: Tue, 24 Oct 2017 16:15:01 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g1reElPxNFRmr6Ks2EEf3EhAb2kMannXe"
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 14:15:06 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--g1reElPxNFRmr6Ks2EEf3EhAb2kMannXe
Content-Type: multipart/mixed; boundary="4xt3uiNHDvhS3mmr4chFBanaxFCnN5T9L";
 protected-headers="v1"
From: Eliot Lear 
To: Joe Clarke , "M. Ranganathan" ,
 opsawg@ietf.org
Message-ID: <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
References: 
 
 <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com>
 <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com>
 <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com>
In-Reply-To: <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com>

--4xt3uiNHDvhS3mmr4chFBanaxFCnN5T9L
Content-Type: multipart/alternative;
 boundary="------------89E2A59D7A3CB76FA45F9B64"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------89E2A59D7A3CB76FA45F9B64
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Joe,

In talking with a few more people, I'm coming to conclude we should
leave things as is.=C2=A0 Here's the issue: MOST but probably not ALL
manufacturers will need access to DNS.=C2=A0 They will nearly ALL specify=

that need, and they may ALL do so in different ways.=C2=A0 That will
translate into more management overhead for the enterprise network
administrator.=C2=A0 It is better to have the standard implied classes.=C2=
=A0 The
only question is whether or not to give manufacturers the means to turn
that access off.=C2=A0 From a device threat surface standpoint, this is
relatively small potatoes, although it's something. After all, since
MOST devices will require access to name service, most devices would
ALREADY be exposed.=C2=A0 From a name server perspective, they already ha=
ve
to be well hardened.=C2=A0 A similar argument can be made for NTP.

Thus let's leave things alone.

Eliot

On 10/24/17 3:38 PM, Joe Clarke wrote:
> On 10/24/17 09:28, Eliot Lear wrote:
>
>
> > On 10/24/17 2:48 PM, Joe Clarke wrote:
> >> On 10/24/17 07:48, Eliot Lear wrote:
> >>> I want to confirm this with the WG and the chairs.=C2=A0 I'm okay
> >>> removing this if others are as well.=C2=A0 It's past WGLC and I am
> >>> about to post -13. Objections?
> >>
> >> This seems better for security and clarity with respect to other
> >> MUD elements.=C2=A0 But does this break any current implementations?=

>
> > This is a draft.=C2=A0 The underlying model has changed, so this is
> > small potatos.
>
> I understand.=C2=A0 I was just trying to be pedantic as I know that peo=
ple
> are working on MUD quite actively.=C2=A0 As I said, I like the idea, an=
d I
> think it makes sense to change now versus errata down the line.
>
> Joe
>


--------------89E2A59D7A3CB76FA45F9B64
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Joe,

    

    In talking with a few more people, I'm coming to conclude we should
    leave things as is.=C2=A0 Here's the issue: MOST but probably not ALL=

    manufacturers will need access to DNS.=C2=A0 They will nearly ALL spe=
cify
    that need, and they may ALL do so in different ways.=C2=A0 That will
    translate into more management overhead for the enterprise network
    administrator.=C2=A0 It is better to have the standard implied classe=
s.=C2=A0
    The only question is whether or not to give manufacturers the means
    to turn that access off.=C2=A0 From a device threat surface standpoin=
t,
    this is relatively small potatoes, although it's something. After
    all, since MOST devices will require access to name service, most
    devices would ALREADY be exposed.=C2=A0 From a name server perspectiv=
e,
    they already have to be well hardened.=C2=A0 A similar argument can b=
e
    made for NTP.

    

    Thus let's leave things alone.

    

    Eliot

    

    On 10/24/17 3:38 PM, Joe Clarke wrote:

    
On 10/24/17 09:28, Eliot Lear wrote:

      

      

      > On 10/24/17 2:48 PM, Joe Clarke wrote:

      >> On 10/24/17 07:48, Eliot Lear wrote:

      >>> I want to confirm this with the WG and the chairs.=C2=A0=

      I'm okay 

      >>> removing this if others are as well.=C2=A0 It's past W=
GLC
      and I am

      >>> about to post -13. Objections?

      >>

      >> This seems better for security and clarity with respect
      to other

      >> MUD elements.=C2=A0 But does this break any current
      implementations?

      

      > This is a draft.=C2=A0 The underlying model has changed, so th=
is
      is

      > small potatos.

      

      I understand.=C2=A0 I was just trying to be pedantic as I know that=

      people

      are working on MUD quite actively.=C2=A0 As I said, I like the idea=
,
      and I

      think it makes sense to change now versus errata down the line.
=

      

      Joe

    

    &=
gt;


    

  


--------------89E2A59D7A3CB76FA45F9B64--

--4xt3uiNHDvhS3mmr4chFBanaxFCnN5T9L--

--g1reElPxNFRmr6Ks2EEf3EhAb2kMannXe
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

iQEcBAEBCAAGBQJZ70rmAAoJEIe2a0bZ0nozrSkH/RRHd0LGEiPK/n4eDSvl4Y1K
HRy1O6XShu2O4GIeNtN8a/aAzKVZXADiz21gNHPs+wujK6/4AdEMaiopqCk1q61e
YKj2jUUBbuBDxv5T4YWZxn9liSf63M86F6y0XbAyK6WRhh/ajI4lO8auSrUdA60V
+vORLmQP5iE+Jzzz0u8SwEoCUykabTe6BpL8X76qDZ6NH127LLZSE/dkxHxlc0Nf
rpR9r5wnZSWp/EYJEgoNDfxRYPGvHtLr5RWXfimUk+rOJHWaEXQhQvEALIAkyM2U
39sQWjQDU83Z15TsF6nV8d0WoDQRAaMOMAT1FcVm+aTP2a0Yey8o4IWzuEKQQ8w=
=KOtz
-----END PGP SIGNATURE-----

--g1reElPxNFRmr6Ks2EEf3EhAb2kMannXe--


From nobody Tue Oct 24 07:30: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 3C5CD13F7EB for ; Tue, 24 Oct 2017 07:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 YK12OZWI6Ka2 for ; Tue, 24 Oct 2017 07:30:43 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48B113F7E6 for ; Tue, 24 Oct 2017 07:30:42 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id u138so16115447wmu.5 for ; Tue, 24 Oct 2017 07:30:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=K33YoGGDqVoqo1AVi4OV0WAGSoj8lrvo1Bd2/0VRsFs=; b=fGiCmh+evBKXu5v+dj/kEGsOy0BC+GecZJ+95tv5V+HG/CEaG3LWS/HA7m/D6CTJYV vCby8pQeOR0GQurM0WxKYEVCg/6yaGKMWliEt82ya40nIe8HqHxKtaXnFjWWFC2wbRdc lSX9tfEggb25ymqJiViBluaDswu7rLT4fh8a3pWSQibnKzX4ZbK2s4kQYz0N9+w+MdOs RXYmtFS2DvgLzHbK8jY8IPKiRBy53D3/CWEfre5Z2RJN5C7ml5/R+VCRwoTz68jBZxAZ sBoesEoCptYmO05TVIFOjxRY1+FJW0PMFwbWK7J7ACrFy7x6ynEmAhRaikRQBUk6gGqw iGHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=K33YoGGDqVoqo1AVi4OV0WAGSoj8lrvo1Bd2/0VRsFs=; b=NBzDdzW/Qygcfexo/4ReWcHrXPhh0pj7kHdYTucmZQ1VV4UOtaTOMdxe3bic5IAtMN mta6hTV69TshLLjnOMBI8NCGWo/7PDxq82HKn8cePI8ZL9yY5ekYvxnGxARJ3TaoKaNi yo3JY3KVm7pmp/a9VA0dAmxVj7PLrvpfR+Y9mGjjI5JVQWUbQyIQfuoreK0HdzNpuqHr wbMt/t9V6w38RvVlLeGRRinIJ/YK+30FCnz4P/+5KlFBSX1EUkoAAoga13WXPm1/OMTo kN++IR5qh5iBa866PlPoGwcCpj6eJaEK8u0KqamIAxsd/ydiXbKfl54xtu5KS7zrar9L YWiQ==
X-Gm-Message-State: AMCzsaV3UL3vh97JKd8g/7q7trnBBA2RPOW0UQ/GbWBdvaUya7DsTbKg qUB2NK7/iuTilScGq8sBjSqv7TUeyAI7CiZshT8jSg==
X-Google-Smtp-Source: ABhQp+TDaY3db9SlRsGs4EwacU1iZUrodoCuCZw8RhKeyouJHLp4XiF5BxEXXoMdbvc3d+QkUQZDCcuXMUhdtwdGuSI=
X-Received: by 10.28.26.138 with SMTP id a132mr8697750wma.124.1508855440745; Tue, 24 Oct 2017 07:30:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.187.12 with HTTP; Tue, 24 Oct 2017 07:29:59 -0700 (PDT)
In-Reply-To: <4fa65c18-80b5-5a7b-0c7a-9cc08e98769e@cisco.com>
References:  <4fa65c18-80b5-5a7b-0c7a-9cc08e98769e@cisco.com>
From: Warren Kumari 
Date: Tue, 24 Oct 2017 10:29:59 -0400
Message-ID: 
To: Eliot Lear 
Cc: draft-ietf-opsawg-mud@ietf.org,  "opsawg-chairs@ietf.org" , opsawg@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [OPSAWG] AD review of: draft-ietf-opsawg-mud.
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, 24 Oct 2017 14:30:45 -0000

On Tue, Oct 24, 2017 at 7:46 AM, Eliot Lear  wrote:
> [this time to the wg and chairs]
>
> Warren,
>
> Thanks for your review, and I'm sorry to hear of your illness.

Thanks; antibiotics are a wonderful invention, finally on the mend...

>
>
> On 10/24/17 12:37 AM, Warren Kumari wrote:
>
> First, sorry for the delay in reviewing this -- I'm recovering from
> pneumonia and so it took longer than it should have.
>
> I do have a few comments that I=E2=80=99d like addressed
> before I start IETF LC =E2=80=94 addressing these now will avoid
> issues later in the process.
>
> I believe that all my comments are editorial, and should be easy fixes.
> Please explicitly let me know once you've posted a new version, just
> to make sure it doesn't slip through the cracks.
>
> Warren.
>
> -------
>
> 1.  Introduction
>   The Internet has largely been constructed on general purpose
>   computers; those devices that may be used for a purpose that is
> [O] computers;
> [P] computers:
> [R] punctuation
>   specified by those who buy the device.
>
> I think actually ",", but I'll let the RPC sort us on that one
>
>   ...
>   Let us then posit a group of objects that are
>   specifically NOT general purpose computers.  These devices have a
>   purpose to their use.  By definition, therefore, all other purposes
>
> [O] purpose to their use.
> [P] specific purpose to their use.
> [R] clarity / continuity with previous
>   are NOT intended.
>
> Clarified as follows:
>
> These devices
> have a specific purpose.  By definition, therefore, all other
> uses are NOT intended.
>
>   ...
>
>   We use the notion of "manufacturer" loosely in this context, to
>   simply mean the entity or organization that will state how a device
>
> [O] context, to simply mean
> [P] context to refer to
> [R] clarity and grammar
>   is intended to be used.
>   ...
>
> ok
>
>   The key points are that the device itself is expected
>   to serve a limited purpose, and that there may exist an organization
>   in the supply chain of that device that will take responsibility for
>   informing the network about that purpose.
>   The intent MUD is to solve for the following problems:
>
> [O] intent MUD
> [P] intent of MUD
> [R] grammar
>
> Right.
>
>   In this specification we describe each of these building blocks and
>   how they are intended to be used together.  However, they may also be
>   used separately, independent of this specification by local
>
> [O] independent of this specification
> [P] independent of this specification,
> [R] grammar
>   deployments for their own purposes.
>
> Ok.
>
> 1.1.  What MUD doesn't do
>   ...
>   How they are instantiated
>   locally will depend on many factors, and is ultimately up to the
>
> [O] factors,
> [P] factors
> [R] grammar
>   local network administrator, who must decide what is appropriate in a
>   given circumstances.
>
> Right.  That and tense correction.
>
> 1.2.  A Simple Example
>   A light bulb is intended to light a room.  It may be remotely
>   controlled through the network; and it may make use of a rendezvous
>
> [O] network;
> [P] network,
> [R] grammar
>
> Yup.
>
>   service of some form that an app on smart phone accesses.
>
>
> 1.3.  Determining Intended Use
>   ...
>   Profiling systems that make use of heuristics to
>   identify types of systems have existed for years as well.
>   A Thing could just as easily tell the network what sort of protection
>
> [O] protection
> [R] protection? Or access?
>
>   it requires without going into what sort of system it is.
>
> Access is better.
>
> 1.4.  Finding A Policy: The MUD URL
>   ...
>   The IEEE has developed [IEEE8021AR] that provides a
>   certificate-based approach to communicate device characteristics,
>   which itself relies on [RFC5280].
>   [C]: "that provides" or "which provides"?
>
>   ...
>   In these cases, manufacturers may be able to map those
>   identifies to particular MUD URLs (or even the files themselves).
>
> [O] indentifies
> [P] indentifiers
> [R] I think this is what was meant. Or perhaps identities?
>
> I like identifiers.  More specific.
>
> 1.5.  Types of Policies
>   ...
>   For example:
>      Allow access to devices of the same manufacturer
>      Allow access to and from controllers via COAP
>
> [O] via COAP
> [R] Please expand COAP, it's not well known.
>
> Ok
>
>   To add a bit more depth that should not be a stretch of anyone's
>   imagination, one could also make use of port-based access lists.
>
> [O] that should not be a stretch of anyone's imagination
> [R] I don't think this phrase makes sense in this context, or at least
> it sounded odd to me.
>
> Trimmed.
>
>  ...
>   While the policy examples given here focus on access control, this is
>   not intended to be the sole focus.  By structuring the model
>   described in this document with clear extension points, so that other
>
> [O] , so that other
> [P], other
> [R] readability
>
> Right.
>
>   descriptions could be included.
>
> ...
>   The "manufacturer" classes can be easily specified by the
>   manufacturer, whereas controller classes are initially envisioned to
>   be specified by the administrator.
>   Because manufacturers do not know who will be using their devices, it
>   is important for functionality referenced in usage descriptions to be
>   relatively ubiquitous, and mature.  For these reasons only a limited
>
> [O] ubiquitous, and mature
> [P] ubiquitous and mature
> [R] grammar
>
> yep
>
>   subset YANG-based configuration of is permitted in a MUD file.
>
> 1.6.  Terminology
>   ...
>   After it has processed a MUD file it may
>
> [O] After it has processed a MUD file it may
> [P] After it has processed a MUD file, it may
> [R] grammar
>      direct changes to relevant network elements.
>
> ok
>
>  ...
>
> 1.7.  The Manufacturer Usage Description Architecture
>   With these components laid out we now have the basis for an
>   archicture.  This leads us to ASCII art.
>
> [O] archicture
> [P] architecture
> [R] spelling / typo.
>
> doh.  (so to speak).
>
>   ...
>
>   The web site is typically run by or on behalf of the manufacturer.
>   Its domain name is that of the authority found in the MUD URL.  For
>   legacy cases where Things cannot emit a URL, if the switch is able to
>   determine the appropriate URL, it may proxy it, the trivial cases
>   being a map between some registered Thing or port and a URL.
>
> [O] the trivial cases
>   being a map between some registered Thing or port and a URL.
> [R] cannot parse this part of the sentence.
>
> Fixed as follows:
>
> For
> legacy cases where Things cannot emit a URL, if the switch is able to
> determine the appropriate URL, it may proxy it, the trivial cases
> being a    hardcoded MUD-URL on a switch port, or a mapping from some
> available identifier such as an L2 address or certificate hash to a
> MUD-URL.
>
>    ...
>
>   Communication within those systems and from those systems to
>   network elements is beyond the scope of this memo.
>
> [O] memo
> [P] document -- either is allowed, this is just a pet peeve of mine,
> so I always point it out. Feel free to ignore
>
> I'm of the memo era.

Heretic! Pistols at down!!!

Sometime I'll make a pretty graph to demonstrate the error of your
ways, but a quick grep through the RFCs < 100 shows that "note" was
the early winner:
Wombat:rfc-mirror wkumari$ cat  rfc??.txt  | grep -i note | grep -iv
"noted\|noting" | grep -iv "note that" |  wc -l
     169
Wombat:rfc-mirror wkumari$ cat  rfc??.txt  | grep -i document | grep
-iv documentation |  wc -l
      63
Wombat:rfc-mirror wkumari$ cat  rfc??.txt  | grep -i memo |  wc -l
      37

but that that quickly changed to "document", as all right thinking
people saw the error of their ways:
Wombat:rfc-mirror wkumari$ cat  rfc???.txt  | grep -i note | grep -iv
"noted\|noting" | grep -iv "note that" |  wc -l
    1635
Wombat:rfc-mirror wkumari$ cat  rfc???.txt  | grep -i document | grep
-iv documentation |  wc -l
    1950
Wombat:rfc-mirror wkumari$ cat  rfc???.txt  | grep -i memo |  wc -l
     961


"memo" was never a preferred option, other than amongst perverse few,
who did it merely to annoy....

:-P

W

P.S: Thanks for the quick edits, LC requested.


>
> 2.  The MUD Model and Semantic Meaning
>   ...
>
>   To provide the widest possible deployability, publishers of MUD files
>   SHOULD make use of the abstractions in this memo and avoid the use of
>
> [O] memo
> [P] document - as above  Also, is 'deployability' a real word now?
> MW doesn't seems to think so, nor does OE.
> ...
>
> Going for deployment.
>
>   Furthermore, only or "accept" or "drop" actions SHOULD be included.
>
> [O] only or
> [P] only
> [R] either we are missing a word before =E2=80=9Cor,=E2=80=9D or or is no=
t needed
>
> Right.
>
> 3.4.  is-supported
>   This boolean is an indication from the manufacturer to the network
>   administrator as to whether or not the Thing is supported.  In this
>   context a Thing is said to NOT be supported if the manufacturer
>   intends never to issue an update to the Thing or never update the MUD
>   file.  A MUD controller MAY still peridocally check for updates.
>
> [O] peridocally
> [P] periodically
> [R] spelling
>
> Corrected.
>
> Chicken soup for you.
>
> Eliot



--=20
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf


From nobody Tue Oct 24 07:51: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 0473C13DC3B; Tue, 24 Oct 2017 07:51:21 -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, 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 rHhJf1UM1a1L; Tue, 24 Oct 2017 07:51:18 -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 24F1113F529; Tue, 24 Oct 2017 07:50:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11791; q=dns/txt; s=iport; t=1508856648; x=1510066248; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=khvBTuR6IPqBjfZP37dwA2vVu+0ZbhFd9wO/e7GEPo4=; b=AUkiRhFKUwGnoajqpQ5cGAnV+gT1DW9k5N1yahssEHo6tjtKOwkLj8Su hLNfjk+p7YBxTi+DPdifUFOHy3UKVrb2BnWjXuiZm0nYt0tzyZeaXEAq4 3G/55OgfHOoEdqHyqujQdlpz26zUvDA37CcLytmBZ64wjxCtnXojzwyWG 0=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQB6Uu9Z/xbLJq1QChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUxJ4N6ixOQTZZKggEHA4U7AoUiFQECAQEBAQEBAWsohR0BAQE?= =?us-ascii?q?BAgEjVhALEgYqAgJJDgYNBgIBAYoUCKc2gieLIwEBAQEBAQEDAQEBAQEBARIPg?= =?us-ascii?q?y6BNYQLKYF0OlOESREEgzuCYQWKKocmkB2EQYIjjhGCFYV6g12HOYcygnOLWoE?= =?us-ascii?q?5NSKBWzQhCB0Vgy2CVwQBHIFpPjaJLYJEAQEB?=
X-IronPort-AV: E=Sophos;i="5.43,428,1503360000";  d="asc'?scan'208";a="655652177"
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; 24 Oct 2017 14:50:21 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9OEoLTW026528; Tue, 24 Oct 2017 14:50:21 GMT
To: Warren Kumari 
Cc: draft-ietf-opsawg-mud@ietf.org, "opsawg-chairs@ietf.org" , opsawg@ietf.org
References:  <4fa65c18-80b5-5a7b-0c7a-9cc08e98769e@cisco.com> 
From: Eliot Lear 
Message-ID: <0a864c32-a32c-f503-577a-395a4e50d5f7@cisco.com>
Date: Tue, 24 Oct 2017 16:50:20 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Gf4VVfMU8S2gHPLSPi2Dc1Tq88gX2XMHM"
Archived-At: 
Subject: Re: [OPSAWG] AD review of: draft-ietf-opsawg-mud.
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, 24 Oct 2017 14:51:21 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Gf4VVfMU8S2gHPLSPi2Dc1Tq88gX2XMHM
Content-Type: multipart/mixed; boundary="KXousE3uuWSfpIwh14XPfjX101s4RN4rG";
 protected-headers="v1"
From: Eliot Lear 
To: Warren Kumari 
Cc: draft-ietf-opsawg-mud@ietf.org,
 "opsawg-chairs@ietf.org" , opsawg@ietf.org
Message-ID: <0a864c32-a32c-f503-577a-395a4e50d5f7@cisco.com>
Subject: Re: AD review of: draft-ietf-opsawg-mud.
References: 
 <4fa65c18-80b5-5a7b-0c7a-9cc08e98769e@cisco.com>
 
In-Reply-To: 

--KXousE3uuWSfpIwh14XPfjX101s4RN4rG
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Wait! I haven't put the doc out yet!!


On 10/24/17 4:29 PM, Warren Kumari wrote:
> On Tue, Oct 24, 2017 at 7:46 AM, Eliot Lear  wrote:
>> [this time to the wg and chairs]
>>
>> Warren,
>>
>> Thanks for your review, and I'm sorry to hear of your illness.
> Thanks; antibiotics are a wonderful invention, finally on the mend...
>
>>
>> On 10/24/17 12:37 AM, Warren Kumari wrote:
>>
>> First, sorry for the delay in reviewing this -- I'm recovering from
>> pneumonia and so it took longer than it should have.
>>
>> I do have a few comments that I=E2=80=99d like addressed
>> before I start IETF LC =E2=80=94 addressing these now will avoid
>> issues later in the process.
>>
>> I believe that all my comments are editorial, and should be easy fixes=
=2E
>> Please explicitly let me know once you've posted a new version, just
>> to make sure it doesn't slip through the cracks.
>>
>> Warren.
>>
>> -------
>>
>> 1.  Introduction
>>   The Internet has largely been constructed on general purpose
>>   computers; those devices that may be used for a purpose that is
>> [O] computers;
>> [P] computers:
>> [R] punctuation
>>   specified by those who buy the device.
>>
>> I think actually ",", but I'll let the RPC sort us on that one
>>
>>   ...
>>   Let us then posit a group of objects that are
>>   specifically NOT general purpose computers.  These devices have a
>>   purpose to their use.  By definition, therefore, all other purposes
>>
>> [O] purpose to their use.
>> [P] specific purpose to their use.
>> [R] clarity / continuity with previous
>>   are NOT intended.
>>
>> Clarified as follows:
>>
>> These devices
>> have a specific purpose.  By definition, therefore, all other
>> uses are NOT intended.
>>
>>   ...
>>
>>   We use the notion of "manufacturer" loosely in this context, to
>>   simply mean the entity or organization that will state how a device
>>
>> [O] context, to simply mean
>> [P] context to refer to
>> [R] clarity and grammar
>>   is intended to be used.
>>   ...
>>
>> ok
>>
>>   The key points are that the device itself is expected
>>   to serve a limited purpose, and that there may exist an organization=

>>   in the supply chain of that device that will take responsibility for=

>>   informing the network about that purpose.
>>   The intent MUD is to solve for the following problems:
>>
>> [O] intent MUD
>> [P] intent of MUD
>> [R] grammar
>>
>> Right.
>>
>>   In this specification we describe each of these building blocks and
>>   how they are intended to be used together.  However, they may also b=
e
>>   used separately, independent of this specification by local
>>
>> [O] independent of this specification
>> [P] independent of this specification,
>> [R] grammar
>>   deployments for their own purposes.
>>
>> Ok.
>>
>> 1.1.  What MUD doesn't do
>>   ...
>>   How they are instantiated
>>   locally will depend on many factors, and is ultimately up to the
>>
>> [O] factors,
>> [P] factors
>> [R] grammar
>>   local network administrator, who must decide what is appropriate in =
a
>>   given circumstances.
>>
>> Right.  That and tense correction.
>>
>> 1.2.  A Simple Example
>>   A light bulb is intended to light a room.  It may be remotely
>>   controlled through the network; and it may make use of a rendezvous
>>
>> [O] network;
>> [P] network,
>> [R] grammar
>>
>> Yup.
>>
>>   service of some form that an app on smart phone accesses.
>>
>>
>> 1.3.  Determining Intended Use
>>   ...
>>   Profiling systems that make use of heuristics to
>>   identify types of systems have existed for years as well.
>>   A Thing could just as easily tell the network what sort of protectio=
n
>>
>> [O] protection
>> [R] protection? Or access?
>>
>>   it requires without going into what sort of system it is.
>>
>> Access is better.
>>
>> 1.4.  Finding A Policy: The MUD URL
>>   ...
>>   The IEEE has developed [IEEE8021AR] that provides a
>>   certificate-based approach to communicate device characteristics,
>>   which itself relies on [RFC5280].
>>   [C]: "that provides" or "which provides"?
>>
>>   ...
>>   In these cases, manufacturers may be able to map those
>>   identifies to particular MUD URLs (or even the files themselves).
>>
>> [O] indentifies
>> [P] indentifiers
>> [R] I think this is what was meant. Or perhaps identities?
>>
>> I like identifiers.  More specific.
>>
>> 1.5.  Types of Policies
>>   ...
>>   For example:
>>      Allow access to devices of the same manufacturer
>>      Allow access to and from controllers via COAP
>>
>> [O] via COAP
>> [R] Please expand COAP, it's not well known.
>>
>> Ok
>>
>>   To add a bit more depth that should not be a stretch of anyone's
>>   imagination, one could also make use of port-based access lists.
>>
>> [O] that should not be a stretch of anyone's imagination
>> [R] I don't think this phrase makes sense in this context, or at least=

>> it sounded odd to me.
>>
>> Trimmed.
>>
>>  ...
>>   While the policy examples given here focus on access control, this i=
s
>>   not intended to be the sole focus.  By structuring the model
>>   described in this document with clear extension points, so that othe=
r
>>
>> [O] , so that other
>> [P], other
>> [R] readability
>>
>> Right.
>>
>>   descriptions could be included.
>>
>> ...
>>   The "manufacturer" classes can be easily specified by the
>>   manufacturer, whereas controller classes are initially envisioned to=

>>   be specified by the administrator.
>>   Because manufacturers do not know who will be using their devices, i=
t
>>   is important for functionality referenced in usage descriptions to b=
e
>>   relatively ubiquitous, and mature.  For these reasons only a limited=

>>
>> [O] ubiquitous, and mature
>> [P] ubiquitous and mature
>> [R] grammar
>>
>> yep
>>
>>   subset YANG-based configuration of is permitted in a MUD file.
>>
>> 1.6.  Terminology
>>   ...
>>   After it has processed a MUD file it may
>>
>> [O] After it has processed a MUD file it may
>> [P] After it has processed a MUD file, it may
>> [R] grammar
>>      direct changes to relevant network elements.
>>
>> ok
>>
>>  ...
>>
>> 1.7.  The Manufacturer Usage Description Architecture
>>   With these components laid out we now have the basis for an
>>   archicture.  This leads us to ASCII art.
>>
>> [O] archicture
>> [P] architecture
>> [R] spelling / typo.
>>
>> doh.  (so to speak).
>>
>>   ...
>>
>>   The web site is typically run by or on behalf of the manufacturer.
>>   Its domain name is that of the authority found in the MUD URL.  For
>>   legacy cases where Things cannot emit a URL, if the switch is able t=
o
>>   determine the appropriate URL, it may proxy it, the trivial cases
>>   being a map between some registered Thing or port and a URL.
>>
>> [O] the trivial cases
>>   being a map between some registered Thing or port and a URL.
>> [R] cannot parse this part of the sentence.
>>
>> Fixed as follows:
>>
>> For
>> legacy cases where Things cannot emit a URL, if the switch is able to
>> determine the appropriate URL, it may proxy it, the trivial cases
>> being a    hardcoded MUD-URL on a switch port, or a mapping from some
>> available identifier such as an L2 address or certificate hash to a
>> MUD-URL.
>>
>>    ...
>>
>>   Communication within those systems and from those systems to
>>   network elements is beyond the scope of this memo.
>>
>> [O] memo
>> [P] document -- either is allowed, this is just a pet peeve of mine,
>> so I always point it out. Feel free to ignore
>>
>> I'm of the memo era.
> Heretic! Pistols at down!!!
>
> Sometime I'll make a pretty graph to demonstrate the error of your
> ways, but a quick grep through the RFCs < 100 shows that "note" was
> the early winner:
> Wombat:rfc-mirror wkumari$ cat  rfc??.txt  | grep -i note | grep -iv
> "noted\|noting" | grep -iv "note that" |  wc -l
>      169
> Wombat:rfc-mirror wkumari$ cat  rfc??.txt  | grep -i document | grep
> -iv documentation |  wc -l
>       63
> Wombat:rfc-mirror wkumari$ cat  rfc??.txt  | grep -i memo |  wc -l
>       37
>
> but that that quickly changed to "document", as all right thinking
> people saw the error of their ways:
> Wombat:rfc-mirror wkumari$ cat  rfc???.txt  | grep -i note | grep -iv
> "noted\|noting" | grep -iv "note that" |  wc -l
>     1635
> Wombat:rfc-mirror wkumari$ cat  rfc???.txt  | grep -i document | grep
> -iv documentation |  wc -l
>     1950
> Wombat:rfc-mirror wkumari$ cat  rfc???.txt  | grep -i memo |  wc -l
>      961
>
>
> "memo" was never a preferred option, other than amongst perverse few,
> who did it merely to annoy....
>
> :-P
>
> W
>
> P.S: Thanks for the quick edits, LC requested.
>
>
>> 2.  The MUD Model and Semantic Meaning
>>   ...
>>
>>   To provide the widest possible deployability, publishers of MUD file=
s
>>   SHOULD make use of the abstractions in this memo and avoid the use o=
f
>>
>> [O] memo
>> [P] document - as above  Also, is 'deployability' a real word now?
>> MW doesn't seems to think so, nor does OE.
>> ...
>>
>> Going for deployment.
>>
>>   Furthermore, only or "accept" or "drop" actions SHOULD be included.
>>
>> [O] only or
>> [P] only
>> [R] either we are missing a word before =E2=80=9Cor,=E2=80=9D or or is=
 not needed
>>
>> Right.
>>
>> 3.4.  is-supported
>>   This boolean is an indication from the manufacturer to the network
>>   administrator as to whether or not the Thing is supported.  In this
>>   context a Thing is said to NOT be supported if the manufacturer
>>   intends never to issue an update to the Thing or never update the MU=
D
>>   file.  A MUD controller MAY still peridocally check for updates.
>>
>> [O] peridocally
>> [P] periodically
>> [R] spelling
>>
>> Corrected.
>>
>> Chicken soup for you.
>>
>> Eliot
>
>



--KXousE3uuWSfpIwh14XPfjX101s4RN4rG--

--Gf4VVfMU8S2gHPLSPi2Dc1Tq88gX2XMHM
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

iQEcBAEBCAAGBQJZ71MtAAoJEIe2a0bZ0nozoa8IAL1z0BrvjnGN4cW83tbKk2JB
fX+ZIskgnakxvTI78pVKJUrGAtUvuDLxep+e4qz0jJW7GuasZjS0J2JoiYgO8awI
0PQ3UFkkSh3BbIAAsy3aSRyMfyl7I4qXlDQN5zQL6LhsXrmObKXyFGTKQO1DBVJx
rVuBzjr2R2akMZ3+Gy3xDOwUxjwwy58Vq5lXAZoN6FVRHKBtjRvDoJTY4z/ao9Fm
SrPcxcyFB7Q7ppXbWTWmiBBb4DohwFcXZW8e+0ns2+hOQV20615x0K7J2cGupntl
+6goQUeaG82tzGvAFDDaErKHd5V8zjQl7VFJX5kPm5jGGv6vIjQAXCkAF0j/hUk=
=g8Lq
-----END PGP SIGNATURE-----

--Gf4VVfMU8S2gHPLSPi2Dc1Tq88gX2XMHM--


From nobody Tue Oct 24 07:53: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 A38C7138BDB; Tue, 24 Oct 2017 07:52:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150885677464.25157.11620269192553296355@ietfa.amsl.com>
Date: Tue, 24 Oct 2017 07:52:54 -0700
Archived-At: 
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-13.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OPSA Working Group Mail List 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Oct 2017 14:52:54 -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-13.txt
	Pages           : 55
	Date            : 2017-10-24

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

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


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

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

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


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

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


From nobody Tue Oct 24 08:16: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 E5D0C138C11 for ; Tue, 24 Oct 2017 08:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 lOU32EDxqDdj for ; Tue, 24 Oct 2017 08:16:09 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7261C13F467 for ; Tue, 24 Oct 2017 08:16:09 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id j15so8905448wre.8 for ; Tue, 24 Oct 2017 08:16:09 -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=UoMlwXXPxqtxo3KRTKMe0Dg1Ue3ojSOG7x9LGLef3PE=; b=SZ30cEKH1lUbpvBxNXNKV/DpovLUyRK2+zxaKLNI8kWtgITsN17P4KRSyDyrypbWFR 5p1WT1VAws/BYQ9iq2G70HIFaXVAvVa0pQfY/c3h4SmfgKWktS5pfNWisbVyDA/F0rLR jPBLEG1wGeGvvEIATGAlKGM7Mir2+GngdooOsl4s5ochEcRJ20V4RCezsb4I+EG8DRvh QTldJEmvxjm/ikk4li5Ohw//7dIrsGPgmPeSH2uvtOekJKKTuMFpeO8enyO94Ql80n8C jmzqm3B2NlTbGWhKin0jGToR1bjQJXgM7tgMa71Q7M56TcmGp4BscdmAAv/e9kl7OeAm 4KPQ==
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=UoMlwXXPxqtxo3KRTKMe0Dg1Ue3ojSOG7x9LGLef3PE=; b=RRXz4eJW997wd9reZQ2svqBXohr/5Dgq9USO3aoYDuhlpGWBBmcATh3efN6570TJzj SEFd6TUq4g56lICqoAjFc7HKwZfqjVAGF6Oq0W0BjGCvO2Z/UaUQzKyCzdkbjdR84QQ8 wIWcQcm+SoczaIX2K8ij5PJ/uTWrL+l+LU6LW6XhBKfzNCAspkcdG127iBJ6+REEKfQG ExFfszWA7sUTTq3mql9eHZbWSyHn7xq+U+sK3okpFvi1PMwXUvTIPmr9FAca4NERaVIN WIfpJWgkzzEtZNs3k3LNRCYHi/j4Jg6EoT1aIec+nH1Ac0w0xRWhm8ZznNv/QpKQdyQL RFkg==
X-Gm-Message-State: AMCzsaV1bKTdPvg2mKUt9ojQeqO0sG5Yaj79fmGDQyZhJ1VXunWDnm/3 EeGRPRbDVGtpPf40bY78it49Dq7IQzlH7XUZ1qu/tQ==
X-Google-Smtp-Source: ABhQp+Q3l2Qw+PpLLWI98mJv3ChHBWMtr5wpHrZ57mLjjjzYFLYEFh84q/wekFt9kbfxJUSyJObZngKHNww19eojyew=
X-Received: by 10.223.150.116 with SMTP id c49mr13827568wra.246.1508858167745;  Tue, 24 Oct 2017 08:16:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Tue, 24 Oct 2017 08:15:27 -0700 (PDT)
In-Reply-To: <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com> <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com> <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com> <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>
From: "M. Ranganathan" 
Date: Tue, 24 Oct 2017 11:15:27 -0400
Message-ID: 
To: Eliot Lear 
Cc: Joe Clarke , opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1147d4ac1ae20d055c4c6b76"
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 15:16:12 -0000

--001a1147d4ac1ae20d055c4c6b76
Content-Type: text/plain; charset="UTF-8"

Hello Eliot, Joe,


On Tue, Oct 24, 2017 at 10:15 AM, Eliot Lear  wrote:

> Joe,
>
> In talking with a few more people, I'm coming to conclude we should leave
> things as is.  Here's the issue: MOST but probably not ALL manufacturers
> will need access to DNS.  They will nearly ALL specify that need, and they
> may ALL do so in different ways.  That will translate into more management
> overhead for the enterprise network administrator.  It is better to have
> the standard implied classes.  The only question is whether or not to give
> manufacturers the means to turn that access off.  From a device threat
> surface standpoint, this is relatively small potatoes, although it's
> something. After all, since MOST devices will require access to name
> service, most devices would ALREADY be exposed.  From a name server
> perspective, they already have to be well hardened.  A similar argument can
> be made for NTP.
>
> Thus let's leave things alone.
>
> Eliot
>

Hi Eliot,

In attempting to implement MUD I found a few things confusing:

-- There are standard implied classes with URIs "urn:ietf:params:mud:dns"
and "uri:ietf:params:mud:ntp".

-- There is default behavior associated with those classes. ( For example,
you talk to DNS on port 53, NTP on port 123.) If a MUD rule specifies
nothing (no ACEs) then these two classes exist invisibly as ALLOW rules.

-- The manufacturer can override the default behavior by specifying ACE
rules for the dns and ntp classes (e.g. by specifying ports that are
different than 53 and 123).  If I consider an implied MUD ACL list with the
two implied DNS and NTP rules in it, I need to override the rules in this
list using an ACE rule specified in the MUD file for these two services.

- The manufacturer can disable his device talking to dns and ntp services
altogether by specifying DENY rules. Why specify a default behavior and
multiple ways to override the default when the presumed reason is to save a
few lines in the ACL file.


The only convenience that the default seems to provide is a few lines in
the ACL file. For that, it sacrifices clarity.

>From an implementation perspective, it makes it messy to have to deal with
deny rules. If we are going to allow default and special classes wuch as
DNS and NTP, then may I suggest that the authors allow for no means to
override their behavior.

It is cleaner to have everything (including DNS and NTP) be handled
uniformly and in the same fashion within the otherwise unambiguous
framework of MUD.

Again, I do not mean to open any can of worms. I am just voicing an opinion
and I realize it is quite late in the game to campaign for changes.

Thank you all for reading.

Regards,

Ranga.





-- 
M. Ranganathan

--001a1147d4ac1ae20d055c4c6b76
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Eliot, Joe,

<=
br>
On Tue, Oct 24, 2017 at 10:15 AM, Eliot Lear =
<l=
ear@cisco.com> wrote:

 =20
   =20
 =20
  

    Joe,

    

    In talking with a few more people, I'm coming to conclude we should
    leave things as is.=C2=A0 Here's the issue: MOST but probably not A=
LL
    manufacturers will need access to DNS.=C2=A0 They will nearly ALL speci=
fy
    that need, and they may ALL do so in different ways.=C2=A0 That will
    translate into more management overhead for the enterprise network
    administrator.=C2=A0 It is better to have the standard implied classes.=
=C2=A0
    The only question is whether or not to give manufacturers the means
    to turn that access off.=C2=A0 From a device threat surface standpoint,
    this is relatively small potatoes, although it's something. After
    all, since MOST devices will require access to name service, most
    devices would ALREADY be exposed.=C2=A0 From a name server perspective,
    they already have to be well hardened.=C2=A0 A similar argument can be
    made for NTP.

    

    Thus let's leave things alone.

    

    Eliot

Hi Eliot,

In attempting to implement=
 MUD I found a few things confusing:

-- There are standar=
d implied classes with URIs "urn:ietf:params:mud:dns" and "u=
ri:ietf:params:mud:ntp".

-- There is default behavio=
r associated with those classes. ( For example, you talk to DNS on port 53,=
 NTP on port 123.) If a MUD rule specifies nothing (no ACEs) then these two=
 classes exist invisibly as ALLOW rules.

-- The manufactu=
rer can override the default behavior by specifying ACE rules for the dns a=
nd ntp classes (e.g. by specifying ports that are different than 53 and 123=
).=C2=A0 If I consider an implied MUD ACL list with the two implied DNS and=
 NTP rules in it, I need to override the rules in this list using an ACE ru=
le specified in the MUD file for these two services.

- Th=
e manufacturer can disable his device talking to dns and ntp services altog=
ether by specifying DENY rules. Why specify a default behavior and multiple=
 ways to override the default when the presumed reason is to save a few lin=
es in the ACL file.


The only convenience t=
hat the default seems to provide is a few lines in the ACL file. For that, =
it sacrifices clarity.=C2=A0 

From an implementation pers=
pective, it makes it messy to have to deal with deny rules. If we are going=
 to allow default and special classes wuch as DNS and NTP, then may I sugge=
st that the authors allow for no means to override their behavior.

<=
/div>
It is cleaner to have everything (including DNS and NTP) be handl=
ed uniformly and in the same fashion within the otherwise unambiguous frame=
work of MUD.

Again, I do not mean to open any can of worm=
s. I am just voicing an opinion and I realize it is quite late in the game =
to campaign for changes.

Thank you all for reading.
Regards,

Ranga.





-- 
M. Ranganathan




--001a1147d4ac1ae20d055c4c6b76--


From nobody Tue Oct 24 08:23: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 CE09C13F088 for ; Tue, 24 Oct 2017 08:23:39 -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 CzuARQRcVOqi for ; Tue, 24 Oct 2017 08:23:37 -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 C609713F529 for ; Tue, 24 Oct 2017 08:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17070; q=dns/txt; s=iport; t=1508858616; x=1510068216; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=mQ3Bnc3WPqHntiy3Ek8ID4DtJ9X2tB4AuA7Nn1+3sCc=; b=hfpEs5X0PaGdd9Fcr/1y1Ld9NxcHnDexq7oQsmf5es/X2fNaPgCFjUDu ygmeqE2nmJvYoSAvVWz9WKwDSJ4whR5cbDJzFz75ZSsn9KSxsv16vNQwc +HOpcnVRV7mTXThzYuwM6s8Njf+2DEBBu2yRQ76j1Pq+jaDwqpLVgOWNZ w=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.43,428,1503360000";  d="asc'?scan'208,217";a="655652697"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 15:23:35 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9OFNYNN003178; Tue, 24 Oct 2017 15:23:34 GMT
To: "M. Ranganathan" 
Cc: Joe Clarke , opsawg@ietf.org
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com> <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com> <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com> <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com> 
From: Eliot Lear 
Message-ID: <6255213d-b097-d0ca-67f7-91207960532e@cisco.com>
Date: Tue, 24 Oct 2017 17:23:34 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AjJrlkOqC5JDE3SkbkaVMfctG8FbeJslK"
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 15:23:40 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--AjJrlkOqC5JDE3SkbkaVMfctG8FbeJslK
Content-Type: multipart/mixed; boundary="Jjuw9IV5vq1S0fmwvDPDWMN6BUsfv9hjj";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" 
Cc: Joe Clarke , opsawg@ietf.org
Message-ID: <6255213d-b097-d0ca-67f7-91207960532e@cisco.com>
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
References: 
 
 <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com>
 <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com>
 <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com>
 <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>
 
In-Reply-To: 

--Jjuw9IV5vq1S0fmwvDPDWMN6BUsfv9hjj
Content-Type: multipart/alternative;
 boundary="------------DDB4E584264D01A2E9943585"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------DDB4E584264D01A2E9943585
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Ranga,

Let's step through these.


On 10/24/17 5:15 PM, M. Ranganathan wrote:
> Hello Eliot, Joe,
>
>
> On Tue, Oct 24, 2017 at 10:15 AM, Eliot Lear  > wrote:
>
>     Joe,
>
>     In talking with a few more people, I'm coming to conclude we
>     should leave things as is.=C2=A0 Here's the issue: MOST but probabl=
y
>     not ALL manufacturers will need access to DNS.=C2=A0 They will near=
ly
>     ALL specify that need, and they may ALL do so in different ways.=C2=
=A0
>     That will translate into more management overhead for the
>     enterprise network administrator.=C2=A0 It is better to have the
>     standard implied classes.=C2=A0 The only question is whether or not=
 to
>     give manufacturers the means to turn that access off.=C2=A0 From a
>     device threat surface standpoint, this is relatively small
>     potatoes, although it's something. After all, since MOST devices
>     will require access to name service, most devices would ALREADY be
>     exposed.=C2=A0 From a name server perspective, they already have to=
 be
>     well hardened.=C2=A0 A similar argument can be made for NTP.
>
>     Thus let's leave things alone.
>
>     Eliot
>
>
> Hi Eliot,
>
> In attempting to implement MUD I found a few things confusing:
>
> -- There are standard implied classes with URIs
> "urn:ietf:params:mud:dns" and "uri:ietf:params:mud:ntp".
>
> -- There is default behavior associated with those classes. ( For
> example, you talk to DNS on port 53, NTP on port 123.) If a MUD rule
> specifies nothing (no ACEs) then these two classes exist invisibly as
> ALLOW rules.

Yes.=C2=A0 Invisible=C2=A0 =3D default.=C2=A0 The key point is that if we=
 don't do this
then most vendors will end up doing their own thing, and this becomes a
management burden, and some are surely going to get them wrong, for that
matter.

>
> -- The manufacturer can override the default behavior by specifying
> ACE rules for the dns and ntp classes (e.g. by specifying ports that
> are different than 53 and 123).=C2=A0 If I consider an implied MUD ACL =
list
> with the two implied DNS and NTP rules in it, I need to override the
> rules in this list using an ACE rule specified in the MUD file for
> these two services.

Yes.

>
> - The manufacturer can disable his device talking to dns and ntp
> services altogether by specifying DENY rules. Why specify a default
> behavior and multiple ways to override the default when the presumed
> reason is to save a few lines in the ACL file.
>
That's not the sole reason.=C2=A0 There are multiple ways to implement th=
ese
rules, and it is best to have a single consistent way.=C2=A0 So for insta=
nce,
one could implement them as permitting communication to ALL devices on
UDP port 53.=C2=A0 One could implement them by stating that the name serv=
er
be admitted as "my-controller" on port 53.=C2=A0 One could create a
vendor-specific controller class such as
"https://vendor.example.com/resolvers" and permit that class on port
53.=C2=A0 And the challenge is that that class has to then be somehow
resolved.=C2=A0 Better to have it as a default to simplify simple cases f=
or
manufacturers and the network manager.=C2=A0 Yes, this requires a bit of
extra code in the MUD controller, but as a design decision, we should
place the pain on ourselves.=C2=A0 We can argue whether or not it is okay=
 to
override this default=E2=80=93 perhaps we shouldn't have that capability.=
=C2=A0 But
certainly the default should be there.
>
> The only convenience that the default seems to provide is a few lines
> in the ACL file. For that, it sacrifices clarity.=C2=A0
>
> From an implementation perspective, it makes it messy to have to deal
> with deny rules. If we are going to allow default and special classes
> wuch as DNS and NTP, then may I suggest that the authors allow for no
> means to override their behavior.

I would be Ok with that, and would be happy to take it as an IETF LC
comment.

>
> It is cleaner to have everything (including DNS and NTP) be handled
> uniformly and in the same fashion within the otherwise unambiguous
> framework of MUD.

But uniformity is precisely what we get with a default for common
services.=C2=A0 I would expect there would be more in the future to furth=
er
simplify things.=C2=A0 Thus the registry.

Eliot

>
> Again, I do not mean to open any can of worms. I am just voicing an
> opinion and I realize it is quite late in the game to campaign for
> changes.
>
> Thank you all for reading.
>
> Regards,
>
> Ranga.
>
>
>
>
>
> --=20
> M. Ranganathan


--------------DDB4E584264D01A2E9943585
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi Ranga,

    
Let's step through these.

    

    

    
On 10/24/17 5:15 PM, M. Ranganathan
      wrote:

    

    

      
      
Hello Eliot, Joe,

        

        

          


            
On Tue, Oct 24, 2017 at 10:15 AM,
              Eliot Lear <lear@cisco.com>
              wrote:

              

                
 Joe,

                  

                  In talking with a few more people, I'm coming to
                  conclude we should leave things as is.=C2=A0 Here's the=

                  issue: MOST but probably not ALL manufacturers will
                  need access to DNS.=C2=A0 They will nearly ALL specify =
that
                  need, and they may ALL do so in different ways.=C2=A0 T=
hat
                  will translate into more management overhead for the
                  enterprise network administrator.=C2=A0 It is better to=

                  have the standard implied classes.=C2=A0 The only quest=
ion
                  is whether or not to give manufacturers the means to
                  turn that access off.=C2=A0 From a device threat surfac=
e
                  standpoint, this is relatively small potatoes,
                  although it's something. After all, since MOST devices
                  will require access to name service, most devices
                  would ALREADY be exposed.=C2=A0 From a name server
                  perspective, they already have to be well hardened.=C2=A0=
 A
                  similar argument can be made for NTP.

                  

                  Thus let's leave things alone.

                      

                      Eliot

                  

              

              


              

              
Hi Eliot,

                

              

              
In attempting to implement MUD I found a few things
                confusing:

                

              

              
-- There are standard implied classes with URIs
                "urn:ietf:params:mud:dns" and "uri:ietf:params:mud:ntp".<=
br>
              

            

          

        

      

    

    

      

        

          

            

              


              

              
-- There is default behavior associated with those
                classes. ( For example, you talk to DNS on port 53, NTP
                on port 123.) If a MUD rule specifies nothing (no ACEs)
                then these two classes exist invisibly as ALLOW rules.
              

            

          

        

      

    

    

    Yes.=C2=A0 Invisible=C2=A0 =3D default.=C2=A0 The key point is that i=
f we don't do
    this then most vendors will end up doing their own thing, and this
    becomes a management burden, and some are surely going to get them
    wrong, for that matter.

    

    

      

        

          

            

              


              

              
-- The manufacturer can override the default behavior
                by specifying ACE rules for the dns and ntp classes
                (e.g. by specifying ports that are different than 53 and
                123).=C2=A0 If I consider an implied MUD ACL list with th=
e
                two implied DNS and NTP rules in it, I need to override
                the rules in this list using an ACE rule specified in
                the MUD file for these two services.

              

            

          

        

      

    

    

    Yes.

    

    

      

        

          

            

              


              

              
- The manufacturer can disable his device talking to
                dns and ntp services altogether by specifying DENY
                rules. Why specify a default behavior and multiple ways
                to override the default when the presumed reason is to
                save a few lines in the ACL file.

                

              

            

          

        

      

    

    That's not the sole reason.=C2=A0 There are multiple ways to implemen=
t
    these rules, and it is best to have a single consistent way.=C2=A0 So=
 for
    instance, one could implement them as permitting communication to
    ALL devices on UDP port 53.=C2=A0 One could implement them by stating=

    that the name server be admitted as "my-controller" on port 53.=C2=A0=
 One
    could create a vendor-specific controller class such as
    "https://vendor.example.com/resolvers" and permit that cl=
ass on port
    53.=C2=A0 And the challenge is that that class has to then be somehow=

    resolved.=C2=A0 Better to have it as a default to simplify simple cas=
es
    for manufacturers and the network manager.=C2=A0 Yes, this requires a=
 bit
    of extra code in the MUD controller, but as a design decision, we
    should place the pain on ourselves.=C2=A0 We can argue whether or not=
 it
    is okay to override this default=E2=80=93 perhaps we shouldn't have t=
hat
    capability.=C2=A0 But certainly the default should be there.

    

      

        

          

            

              


              

              
The only convenience that the default seems to
                provide is a few lines in the ACL file. For that, it
                sacrifices clarity.=C2=A0 

              

              


                From an implementation perspective, it makes it messy to
                have to deal with deny rules. If we are going to allow
                default and special classes wuch as DNS and NTP, then
                may I suggest that the authors allow for no means to
                override their behavior.

              

            

          

        

      

    

    

    I would be Ok with that, and would be happy to take it as an IETF LC
    comment.

    

    

      

        

          

            

              


              

              
It is cleaner to have everything (including DNS and
                NTP) be handled uniformly and in the same fashion within
                the otherwise unambiguous framework of MUD.

              

            

          

        

      

    

    

    But uniformity is precisely what we get with a default for common
    services.=C2=A0 I would expect there would be more in the future to
    further simplify things.=C2=A0 Thus the registry.

    

    Eliot

    

    

      

        

          

            

              


              

              
Again, I do not mean to open any can of worms. I am
                just voicing an opinion and I realize it is quite late
                in the game to campaign for changes.

                

              

              
Thank you all for reading.

                

              

              
Regards,

                

              

              
Ranga.

              

              


              

              


              

            

            

            

            

            -- 

            
M. Ranganathan

            

          

        

      

    

    

  


--------------DDB4E584264D01A2E9943585--

--Jjuw9IV5vq1S0fmwvDPDWMN6BUsfv9hjj--

--AjJrlkOqC5JDE3SkbkaVMfctG8FbeJslK
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

iQEcBAEBCAAGBQJZ71r2AAoJEIe2a0bZ0nozzAoH+wYF/lgJctB4hYJ3ub+1y9yA
8tf3SYURdldaCZzaePeBHeYq9+w/urFi8PvbNMWf4cYLJGAxlphG3GAQwMGtc3aD
TwXuwl44MI+5vt7P8nrBbHg4+LBBDx7bMiAwn9WIvhQfzB3RrjQ5ulRR2N+xm4Bm
cpowp2zcjA//WUOkS6HYx4TDz6JvjQ0fVsrYKJoHGy2wmTlpfKIgFFonLfH45wNZ
nLGWIoGSQji0aFezjx5/YR6Dj9/i0ADAZtg2iDtw1CR86o+WoFvhDYWf/1xUJiUD
Lg5kYcu8sYjTPMrRA/zH5lV9Zu1O2TSunisnTiaoxtFlRB5NxEFhBtgAbT9xdxE=
=/rix
-----END PGP SIGNATURE-----

--AjJrlkOqC5JDE3SkbkaVMfctG8FbeJslK--


From nobody Tue Oct 24 08:53: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 C78CC13F769 for ; Tue, 24 Oct 2017 08:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 fKuQbnPNt2jh for ; Tue, 24 Oct 2017 08:53:16 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3C713939B for ; Tue, 24 Oct 2017 08:53:15 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 87836F87; Tue, 24 Oct 2017 17:53:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id h0YpDrDIcpui; Tue, 24 Oct 2017 17:53:12 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 24 Oct 2017 17:53:14 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 734592010A; Tue, 24 Oct 2017 17:53:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eII-9e9Gau1I; Tue, 24 Oct 2017 17:53:13 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA86B200FC; Tue, 24 Oct 2017 17:53:13 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 365AB413ADFC; Tue, 24 Oct 2017 17:51:47 +0200 (CEST)
Date: Tue, 24 Oct 2017 17:51:47 +0200
From: Juergen Schoenwaelder 
To: Eliot Lear 
Cc: "M. Ranganathan" , opsawg@ietf.org
Message-ID: <20171024155147.luowaylud3argvca@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Eliot Lear , "M. Ranganathan" , opsawg@ietf.org
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com> <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com> <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com> <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>  <6255213d-b097-d0ca-67f7-91207960532e@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <6255213d-b097-d0ca-67f7-91207960532e@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 15:53:18 -0000

On Tue, Oct 24, 2017 at 05:23:34PM +0200, Eliot Lear wrote:

> > -- There is default behavior associated with those classes. ( For
> > example, you talk to DNS on port 53, NTP on port 123.) If a MUD rule
> > specifies nothing (no ACEs) then these two classes exist invisibly as
> > ALLOW rules.
> 
> Yes.  Invisible  = default.  The key point is that if we don't do this
> then most vendors will end up doing their own thing, and this becomes a
> management burden, and some are surely going to get them wrong, for that
> matter.

[...]

> > - The manufacturer can disable his device talking to dns and ntp
> > services altogether by specifying DENY rules. Why specify a default
> > behavior and multiple ways to override the default when the presumed
> > reason is to save a few lines in the ACL file.
> >
> That's not the sole reason.  There are multiple ways to implement these
> rules, and it is best to have a single consistent way.  So for instance,
> one could implement them as permitting communication to ALL devices on
> UDP port 53.  One could implement them by stating that the name server
> be admitted as "my-controller" on port 53.  One could create a
> vendor-specific controller class such as
> "https://vendor.example.com/resolvers" and permit that class on port
> 53.  And the challenge is that that class has to then be somehow
> resolved.  Better to have it as a default to simplify simple cases for
> manufacturers and the network manager.  Yes, this requires a bit of
> extra code in the MUD controller, but as a design decision, we should
> place the pain on ourselves.  We can argue whether or not it is okay to
> override this default– perhaps we shouldn't have that capability.  But
> certainly the default should be there.

What you describe seem to be different policies. Are you saying that
these different policies are bad or a huge management problem and
hence we hard-code a default policy that is considered "good" in most
situations? If you say removing the implied default rules results in a
management burden, what is the reasoning? That having different rules
for DNS (or NTP) would make debugging things more difficult? Given the
vendors likely put creative and interesting rules into MUD files
anyway, do two more rules matter?

Would it be an option to have Appendix B an template that vendors
SHOULD use if they want to allow access to DNS or NTP? Instead, of
hardwiring it in the spec, we tell vendors that 'if you want to open
up DNS and NTP, here is the suggested way to do this'.

I am just trying to understand the reasoning for hardwiring two
special cases.

/js

PS: Is there a logic how the rule names and acl names used in appendix
    B have been constructed? Does 'ent' mean something or is it a
    short form of 'entry'? Would v4-dns-in and v4-ntp-in be more
    descriptive than ent0-todev and ent1-todev and v4-dns-out and
    v4-ntp-out be more descriptive than ent0-frdev and ent1-frdev.
    Well, this might be to some extend subjective...

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Tue Oct 24 09:27:03 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 C0F7413946F; Tue, 24 Oct 2017 09:27:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
CC: draft-ietf-opsawg-mud@ietf.org, jclarke@cisco.com, opsawg-chairs@ietf.org,  Joe Clarke , opsawg@ietf.org, warren@kumari.net
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <150886242178.25125.5187583828381214457.idtracker@ietfa.amsl.com>
Date: Tue, 24 Oct 2017 09:27:01 -0700
Archived-At: 
Subject: [OPSAWG] Last Call:  (Manufacturer Usage Description Specification) to Proposed Standard
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, 24 Oct 2017 16:27:02 -0000

The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Manufacturer
Usage Description Specification'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-11-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


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

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




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2740/
   https://datatracker.ietf.org/ipr/2757/
   https://datatracker.ietf.org/ipr/2758/
   https://datatracker.ietf.org/ipr/2759/



The document contains these normative downward references.
See RFC 3967 for additional information: 
    draft-ietf-netmod-acl-model: Network Access Control List (ACL) YANG Data Model (None - IETF stream)




From nobody Tue Oct 24 09:43: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 D99AA13F817 for ; Tue, 24 Oct 2017 09:43:24 -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 N-tIEBQxNNao for ; Tue, 24 Oct 2017 09:43:23 -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 E56341394EB for ; Tue, 24 Oct 2017 09:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3887; q=dns/txt; s=iport; t=1508863403; x=1510073003; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=lSJhQwloDv9Anu/WDZXQwUFLb8TCcXdJ8OEW31NoK5Q=; b=XmHqxEpmB24Ty/wZP0gzZt0Dw+d5wS17I2wyopCVyVRm1ETik8Z4NSHW Sh+0yo3v5h2h5hBRJAY+tiQfTHPnkT4xy0Aaxo/0aUoXQv9T3f9OeWiZ8 IJv3qCMVbkOYE4dSkXssFrm45i7b9P9Nnpd/0/6cbL3tK6Svho95omTzS Q=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQB5bO9Z/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhTGEIYsTkE+YSwcDhTsChSMVAQIBAQEBAQEBayiFHQEBAQECASN?= =?us-ascii?q?bCwsYKgICVwYBDAgBAYoUCKgCgieLIQEBAQEBAQQBAQEBAQEBEg+DKgSFaYMBi?= =?us-ascii?q?BmCYQWKKpdDhEGCI44Ri2yHOZV/gTk1IoFbNCEIHRVJgmWCVgUcgWk+jCcBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,428,1503360000";  d="asc'?scan'208";a="656558183"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 16:43:20 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9OGhKad018316; Tue, 24 Oct 2017 16:43:20 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com> <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com> <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com> <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>  <6255213d-b097-d0ca-67f7-91207960532e@cisco.com> <20171024155147.luowaylud3argvca@elstar.local>
From: Eliot Lear 
Message-ID: 
Date: Tue, 24 Oct 2017 18:43:21 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171024155147.luowaylud3argvca@elstar.local>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Fx6C3kjA6pBNTQ8tArkOKhcBkbabI5SVC"
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 16:43:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Fx6C3kjA6pBNTQ8tArkOKhcBkbabI5SVC
Content-Type: multipart/mixed; boundary="01L2Gan4hofwSqnlUWlNCgokk27xD0Xmn";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" , opsawg@ietf.org
Message-ID: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
References: 
 
 <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com>
 <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com>
 <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com>
 <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>
 
 <6255213d-b097-d0ca-67f7-91207960532e@cisco.com>
 <20171024155147.luowaylud3argvca@elstar.local>
In-Reply-To: <20171024155147.luowaylud3argvca@elstar.local>

--01L2Gan4hofwSqnlUWlNCgokk27xD0Xmn
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Giid evening Juergen,


On 10/24/17 5:51 PM, Juergen Schoenwaelder wrote:
>
> What you describe seem to be different policies. Are you saying that
> these different policies are bad or a huge management problem and
> hence we hard-code a default policy that is considered "good" in most
> situations? If you say removing the implied default rules results in a
> management burden, what is the reasoning?=20

Here is a worst case scenario, Juergen: suppose you have 600 different
types of device on your network and each manufacturer has implemented
its own class for DNS support.=C2=A0 That would mean that the network
administrator would essentially have to populate 600 classes.=C2=A0 Bette=
r to
have a single class, given its commonality.=C2=A0 There are very few such=

common services on a network, but there are presumably one or two others
that will come to be, and thus the ability to extend this list over time.=


What Ranga is concerned about is the mechanism necessary for "deny".=C2=A0=
 I
very much doubt people will actually enter the block rules, and so I see
no problem simplifying to remove the "deny" text in the draft,
particularly because the DNS and NTP servers really need to be hardened
against attack already.=C2=A0 And while they will assuredly be broken int=
o
from time to time, at that point the attack surface is SOOOO wide that
these sorts of denies are unlikely to make a difference.

Make sense?

Eliot

> PS: Is there a logic how the rule names and acl names used in appendix
>     B have been constructed? Does 'ent' mean something or is it a
>     short form of 'entry'? Would v4-dns-in and v4-ntp-in be more
>     descriptive than ent0-todev and ent1-todev and v4-dns-out and
>     v4-ntp-out be more descriptive than ent0-frdev and ent1-frdev.
>     Well, this might be to some extend subjective...
>

The names are just names, but are chosen to be illustrative.

Eliot


--01L2Gan4hofwSqnlUWlNCgokk27xD0Xmn--

--Fx6C3kjA6pBNTQ8tArkOKhcBkbabI5SVC
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

iQEcBAEBCAAGBQJZ722pAAoJEIe2a0bZ0noz3xsIAM7W4My6RLPLX2Og9RLrmQc9
rGWoljbT4ZbwDepMo/H+ioPpuhzUt9ksBJQP15Mfn3jWXgTW3cwpT8E4cnAE7q59
rBfzqN58hoh/nuT4XZY5MvRGQd9w0sAvylnlEwm2aCUC/ad2BZXFD2pvJOgesBEq
xrdJ5mMWSibDZFqk4QTEC4txeTJ39xVAE+SUqNPed6or7Aqr+f5QVKUvfM3kI+IU
HEZ09UNMRysu6uYoaQpvE4Uir57ozVPu4Uwz+w5j2VaOsVzGaaQ8s7cNdjpLYQXf
gED2pceptTy6kNP48VjbchBDS7z4iN+8RjzbQvfXp3PUMNEpEGBDIcID/IPvc7Q=
=xOxr
-----END PGP SIGNATURE-----

--Fx6C3kjA6pBNTQ8tArkOKhcBkbabI5SVC--


From nobody Tue Oct 24 10:21:17 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 8441213955E for ; Tue, 24 Oct 2017 10:21:16 -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 wYzS5phTYf-Q for ; Tue, 24 Oct 2017 10:21:14 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 3352A138103 for ; Tue, 24 Oct 2017 10:21:14 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id r196so597821wmf.2 for ; Tue, 24 Oct 2017 10:21:14 -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=zH2EmFVXWX6gtDbZ6S+6YN+RWvjWLLlgtO3IEivsVjo=; b=HVfgfcGkXspXng/ucrz9iynleyBZwQwtkN/meNbRtBg6dj4VuV1BdXg5Pgs3ytdGYG FwMhwq9CStlFX8rvzo4Ps1d0YbnwU+Ag6ZIQdq6WjN/iVd+cQz0VBNxWeNYtbTKAKxeb x9q72Z/eSpaW+46ckCRv/cCV//3V4P6LGxmXh7pvF4g/Nl0Wj/4Loi4qCCYwYxrDONAf 5qlOem/bpDPa2+cWKyYaVtUiXK5dVszTOW70tJzUmrdFICuCI7025U3Rnwc463joW7dM H44di3jZ4RjvdoNxr9lpyBC5Bwa2QBRcgbkAUNLwmN58m7j5Rnkc7r9fmxmusb7pQJnj 8aHw==
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=zH2EmFVXWX6gtDbZ6S+6YN+RWvjWLLlgtO3IEivsVjo=; b=C8XwWCmYYkQqWGVj6Kaa6QfOX07S7AJQoP2cntASq6jlenmZOecNLteXL111AT2xLD VCpbZu53RB5risg+kVEG9WetrC4PkKkpYV6oiwwBVV45dfZ1D5b7mXFdBbKNYQAew+0/ 9MHtbWvHSJUHF6inYg1VIByvpQvfyo9y+u13tBO5AyxXhA4Davz733toZQQApM+H2feI X6ek1mXS1YhZ/1EJARLDsLIlAQdPv5tCuWXF7IuZ+DB234EU7Y6FH2qSJZHCmk0RYp4K Ychv0fCBzV97M7NE6kaUCYUAYgWNNQiO28NRL2HghflA4m3fateM+zRzJk6DzWK5MHo3 ZZ4Q==
X-Gm-Message-State: AMCzsaUUM45fQFT9HJPR2o7NrrM+D/EODl2HosjfgKyXNvf3abpuYbDS ezg2E06WbGD+3yJezQoh8l3F6WRxCnltkoqa3ss=
X-Google-Smtp-Source: ABhQp+SqgvdwLY4UuaxaAkjGFdZQtGcFFi4XR0Hgz+y7I2hwjgOLKMmX21eH1KY9cMCvfNiO5nPNotq4gB+oi56xZ7k=
X-Received: by 10.28.69.91 with SMTP id s88mr8651829wma.19.1508865672568; Tue, 24 Oct 2017 10:21:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Tue, 24 Oct 2017 10:20:31 -0700 (PDT)
In-Reply-To: 
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com> <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com> <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com> <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>  <6255213d-b097-d0ca-67f7-91207960532e@cisco.com> <20171024155147.luowaylud3argvca@elstar.local> 
From: "M. Ranganathan" 
Date: Tue, 24 Oct 2017 13:20:31 -0400
Message-ID: 
To: Eliot Lear 
Cc: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0723a66d6a80055c4e2a53"
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 17:21:16 -0000

--94eb2c0723a66d6a80055c4e2a53
Content-Type: text/plain; charset="UTF-8"

Hi Eliot,

Your comment brings up something that I believe needs some clarification:






> Better to
> have a single class, given its commonality.  There are very few such
> common services on a network, but there are presumably one or two others
> that will come to be, and thus the ability to extend this list over time.
>

I have a question about the scope of the class name to host address mapping:

A class URI "resolves" to a set of host addresses.

Are classes  globally scoped across all manufacturers (and devices) for a
given MUD controller? Or are they globally scoped (i.e. there is a global
registry of class name URI to host address list mapping similar to DNS)?

Perhaps some words about scoping can be put into the spec?


Thanks,

Ranga


>
> Eliot
>
>


-- 
M. Ranganathan

--94eb2c0723a66d6a80055c4e2a53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Eliot,

Your comment brings up somethi=
ng that I believe needs some clarification:
<=
br>
=



=C2=A0
Better to

have a single class, given its commonality.=C2=A0 There are very few such
common services on a network, but there are presumably one or two others
that will come to be, and thus the ability to extend this list over time.

I have a question about the scope of the=
 class name to host address mapping:

A class U=
RI "resolves" to a set of host addresses.

Are c=
lasses=C2=A0 globally scoped across all manufacturers (and devices) for a g=
iven MUD controller? Or are they globally scoped (i.e. there is a global re=
gistry of class name URI to host address list mapping similar to DNS)?
<=
br>
Perhaps some words about scoping can be put into the spec?


Thanks,

Ranga
=C2=A0

=


Eliot







-- 
M. Ranganathan




--94eb2c0723a66d6a80055c4e2a53--


From nobody Tue Oct 24 11:14: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 39A96137ED6 for ; Tue, 24 Oct 2017 11:14:46 -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 OuwNCAAcNKEy for ; Tue, 24 Oct 2017 11:14:44 -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 F1FAC13871A for ; Tue, 24 Oct 2017 11:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7581; q=dns/txt; s=iport; t=1508868884; x=1510078484; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=e8VrW1Ldj6sPSymt3wd8RXGaUT9x+9eiRtfO5yEo0cw=; b=A+q2OKTkFIYMYwtj9liDxBmjZH8vs0cnDNmTCn3PGFxTLLhw9vAe40h4 u3pRt62sHLr18l0hKcHFjTdq5RfwiWNdK3xezkuSWpBBXKUZzfvD0Y3U2 kro+hpV24XF1bMWFo1Y/ak9tHtun5N9dE0C9QB2mANilAHa9rXp8dIi9v U=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQCzge9Z/xbLJq1aGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhTGEIYsTkE+QeIVCghEHA4U7AoUhFwECAQEBAQEBAWsohR0BAQE?= =?us-ascii?q?BAgEjVgULCxgqAgJXBg0IAQGKFAioF4InJop9AQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBDg+DLoVpgwGIGYJhBZFQkB2EQYIjjhGLbIc5lX+BOSEDM4FbNCEIHRVJgmW?= =?us-ascii?q?EYD6MJwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.43,428,1503360000";  d="asc'?scan'208,217";a="656559438"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2017 18:14:41 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9OIEfhp024154; Tue, 24 Oct 2017 18:14:41 GMT
To: "M. Ranganathan" 
Cc: opsawg@ietf.org
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com> <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com> <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com> <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>  <6255213d-b097-d0ca-67f7-91207960532e@cisco.com> <20171024155147.luowaylud3argvca@elstar.local>  
From: Eliot Lear 
Message-ID: 
Date: Tue, 24 Oct 2017 20:14:42 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E3OpqAlcnCDJgokM88rf7gWC8QuR3lMAS"
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 24 Oct 2017 18:14:46 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--E3OpqAlcnCDJgokM88rf7gWC8QuR3lMAS
Content-Type: multipart/mixed; boundary="Hnt9af75EchDAt69lkJ3mlD6cwQ6piA84";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" 
Cc: opsawg@ietf.org
Message-ID: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
References: 
 
 <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com>
 <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com>
 <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com>
 <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>
 
 <6255213d-b097-d0ca-67f7-91207960532e@cisco.com>
 <20171024155147.luowaylud3argvca@elstar.local>
 
 
In-Reply-To: 

--Hnt9af75EchDAt69lkJ3mlD6cwQ6piA84
Content-Type: multipart/alternative;
 boundary="------------F5E8EF603256CCF8BD22E590"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------F5E8EF603256CCF8BD22E590
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 10/24/17 7:20 PM, M. Ranganathan wrote:
> Hi Eliot,
>
> Your comment brings up something that I believe needs some clarificatio=
n:
>
>
>
>
> =C2=A0
>
>     Better to
>     have a single class, given its commonality.=C2=A0 There are very fe=
w such
>     common services on a network, but there are presumably one or two
>     others
>     that will come to be, and thus the ability to extend this list
>     over time.
>
>
> I have a question about the scope of the class name to host address
> mapping:
>
> A class URI "resolves" to a set of host addresses.
>
> Are classes=C2=A0 globally scoped across all manufacturers (and devices=
)
> for a given MUD controller? Or are they globally scoped (i.e. there is
> a global registry of class name URI to host address list mapping
> similar to DNS)?

Yes.=C2=A0 That is the intent.=C2=A0 But only URNs are registered.

>
> Perhaps some words about scoping can be put into the spec?
>
>

I will take that as a last call comment if nobody objects.

Eliot

> Thanks,
>
> Ranga
> =C2=A0
>
>
>     Eliot
>
>
>
>
> --=20
> M. Ranganathan


--------------F5E8EF603256CCF8BD22E590
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    

    
On 10/24/17 7:20 PM, M. Ranganathan
      wrote:

    

    

      
      

        
Hi Eliot,

          

        

        Your comment brings up something that I believe needs some
        clarification:

        


          


            

            


            

            
=C2=A0

            
Better to

              have a single class, given its commonality.=C2=A0 There are=

              very few such

              common services on a network, but there are presumably one
              or two others

              that will come to be, and thus the ability to extend this
              list over time.

            

            


            

            
I have a question about the scope of the class name to
              host address mapping:

            

            


            

            
A class URI "resolves" to a set of host addresses.

              

            

            
Are classes=C2=A0 globally scoped across all manufacture=
rs
              (and devices) for a given MUD controller? Or are they
              globally scoped (i.e. there is a global registry of class
              name URI to host address list mapping similar to DNS)?

            

          

        

      

    

    

    Yes.=C2=A0 That is the intent.=C2=A0 But only URNs are registered.
    

    

      

        

          

            


            

            
Perhaps some words about scoping can be put into the
              spec?

            

            


            

            


            

          

        

      

    

    

    I will take that as a last call comment if nobody objects.

    

    Eliot

    

    

      

        

          

            
Thanks,

              

            

            
Ranga

            

          

          

            
=C2=A0

            

              

                  Eliot

                  

                

          

          

          

          

          -- 

          
M.
            Ranganathan

          

        

      

    

    

  


--------------F5E8EF603256CCF8BD22E590--

--Hnt9af75EchDAt69lkJ3mlD6cwQ6piA84--

--E3OpqAlcnCDJgokM88rf7gWC8QuR3lMAS
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

iQEcBAEBCAAGBQJZ74MSAAoJEIe2a0bZ0nozpbEH/1DQEZx5ibnInX3NQCuf7wNn
3p7dauPUKIcw2kqNZIW0JSAicusiefRYNlIQXoxKBUhZAbtKIEekZX0rlvymNOGZ
TfVyKCk3J6nCRoDdXguNPptflauwpPuoA/sizY3S7pajo0MYiGasggPcSDpBPJLR
UqifmurcjXogTSxaAi5z7+DK0LcqYjXplWf/lsOhm+NKhBtnWCl8RcrS3vRto1kv
gNlsk0FtKcsz4cJIXjh2ZvgtamiNhkgycCZt+chwrJLCLYiGCzY01pOaCePnomrO
SH2VsNu6zYDUNee+ZF9QJ4FxtJZIswHqAD+GcPxtxgxdBR15PjFmah0R7WbZa4M=
=JUwP
-----END PGP SIGNATURE-----

--E3OpqAlcnCDJgokM88rf7gWC8QuR3lMAS--


From nobody Wed Oct 25 06:39: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 CCEC81386DE for ; Wed, 25 Oct 2017 06:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 gekTad5tejnJ for ; Wed, 25 Oct 2017 06:39:49 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EFB213ACA2 for ; Wed, 25 Oct 2017 06:39:48 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id m72so15959260wmc.0 for ; Wed, 25 Oct 2017 06:39:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=Qone572fiQNHDQjChBG/ilhPgV4enH+n2wnV5Juh8DQ=; b=JHv2LHxGtMoNn5JTuftHLifFscL6gxZ4x1Kt4i4+khxXLgk4zT5jH6T0MEJIXtIySv UQAF5oUT+ewaMSGkrIdf638rcQ/TvGc6J/TQx4d5p7x+qEzZbtfJ6HiGt1t1kM5T7ICr jfxJ+Wrbi47a2wNntpvOGffZOxmSbDnpNpsrzOKdWY+nNXlfJsRPpf/1mFCmo3CkWDbc yGT2ojgrDSHVh9zZ+GurmndWQSpChbSZ2qsrsCw77O2X2tFlzqD8HhsmQi15mocvm67l KVbRrqERJC6RCXOq4YTgS9OnVjeWCMOKh17aeIElmqKfZyRM2aGQF9mxOUGoZwdbMp+f W73A==
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=Qone572fiQNHDQjChBG/ilhPgV4enH+n2wnV5Juh8DQ=; b=AYS/BEb4mpUEOPkmuIzB3jA2vXF41OVoLHrqvtliUsWqsPRuepXzEVxva7lsdZzEnQ 1sajY4Pw/hhir+yILyeRGkz7WPqsb+TB/umcveOeLNpKznhnOnepskA2mo1cgMpcpRSx n20MWm0mYwXdqRTZo+2Ny9xufO9VZKBVHpLAf4PFvkCs5fz7ImkHHAUX1ZGi0ag0ePOq YSYr05SOHaJBv47vWsE/2ZBFzqXGT/88X+y4vJWAfpd5epyuSDwRNPRVZMHl3D91Arnh ZCbmx4lYblzFb3NuCVoOeJ3Ah6+fS5cbwufBi5KQbCHb7CO95mbSPr4jH6niJGlmR0MW FhoA==
X-Gm-Message-State: AMCzsaW5r1ADHbfYKEiZwMza4hcv4P7yozi2iaGLs+kSqYP8iZb5B6AK 8j19zayD6+b2UTzlR4CtWDilnUSAegknukmro0UEgA==
X-Google-Smtp-Source: ABhQp+QoLoAnpCsjqSjhomAQh9Y8eLRd4CUQNXo3iMuqshHdtM5WQLeSOScv5eEsAKKjFkEP0GpZmvtfNj4HcaTQMAc=
X-Received: by 10.28.69.91 with SMTP id s88mr1847984wma.19.1508938786462; Wed, 25 Oct 2017 06:39:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Wed, 25 Oct 2017 06:39:05 -0700 (PDT)
From: "M. Ranganathan" 
Date: Wed, 25 Oct 2017 09:39:05 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0723a65ae373055c5f3026"
Archived-At: 
Subject: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 13:39:51 -0000

--94eb2c0723a65ae373055c5f3026
Content-Type: text/plain; charset="UTF-8"

Is it possible to modify the YANG model for ietf-acldns to explicitly
disallow "drop" ACE rules?
(i.e. only "forwarding":"accept" } not knowledgeable enough about YANG to
suggest the change).

It would also be convenient if there were a way to disallow both
controllers AND hostnames in a single ACL entry (for reasons of clarity)
but again I don't know how to state that in YANG.

Thanks,



-- 
M. Ranganathan

--94eb2c0723a65ae373055c5f3026
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Is it possible to modify the YANG model for ietf-acld=
ns to explicitly disallow "drop" ACE rules?
(i.e. o=
nly "forwarding":"accept" } not knowledgeable enough ab=
out YANG to suggest the change).

It would also be =
convenient if there were a way to disallow both controllers AND hostnames i=
n a single ACL entry (for reasons of clarity) but again I don't know ho=
w to state that in YANG.

Thanks,


-- 
M=
. Ranganathan




--94eb2c0723a65ae373055c5f3026--


From nobody Wed Oct 25 07:23: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 A5A4813AE08 for ; Wed, 25 Oct 2017 07:23:14 -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 aalBtcgbM9Pz for ; Wed, 25 Oct 2017 07:23:12 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0894A13ACA2 for ; Wed, 25 Oct 2017 07:23:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1240; q=dns/txt; s=iport; t=1508941392; x=1510150992; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7s98nnLZgZmHLW/3kgjeBHHPps3JIhQPbm5/a+JbWno=; b=AH5+GsLPEXCn4E9RF+RSQLeFhkdkXsJKR7GDE8ZmtOLlqIElQqnSuU8I k/QZLLRPqwiSw0Wm9iyBwC4uGryR0x/RsAETYfP0SFU/JENyowiry65DS 2gmTLA63ipqDSttI/h8jPVuDe0g2tn9eXl73TnXqtnIV32fnnoWFI2igv 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAgDXnfBZ/4YNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHg3OZKoFUJohLjW+CEQoYC4RJTwIahFNAFwECAQEBAQE?= =?us-ascii?q?BAWsohR0BAQEDAQEBIRE6CwULAgEIGAICJgICAh8GCxUQAgQOBYoIAw0IEKkpg?= =?us-ascii?q?ieHPg2DRAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CH4IHg2ILgnaCXoImAYM?= =?us-ascii?q?UL4IyBaE3PAKPfIR5kyaNDYU5gw4CERkBgTgBIAE2gVt6FUktAYI2SYQWdosLg?= =?us-ascii?q?REBAQE?=
X-IronPort-AV: E=Sophos;i="5.43,431,1503360000"; d="scan'208";a="315156626"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2017 14:23:10 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v9PENAVJ013927 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Oct 2017 14:23:10 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.1320.4; Wed, 25 Oct 2017 10:23:09 -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.1320.000; Wed, 25 Oct 2017 10:23:09 -0400
From: "Einar Nilsen-Nygaard (einarnn)" 
To: "M. Ranganathan" 
CC: "opsawg@ietf.org" 
Thread-Topic: [OPSAWG] MUD : ietf-acldns YANG model question.
Thread-Index: AQHTTZbBtXE74WLzFUmKLI3mXHHTnaL04XQA
Date: Wed, 25 Oct 2017 14:23:09 +0000
Message-ID: <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com>
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.3445.1.7)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.225.82]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 14:23:15 -0000

VGVjaG5pY2FsbHksIHlvdSBjb3VsZCBleHByZXNzIGJvdGggb2YgdGhlc2UgY29uc3RyYWludHMu
DQoNCkJ1dCB3aHkgd291bGQgd2Ugd2FudCB0byBkbyB0aGlzPyBPbmUgZGV2ZWxvcGVy4oCZcyBj
bGFyaXR5IG1heSBiZSBhbm90aGVy4oCZcyB2ZXJib3NpdHksIGFuZCB3aGF0IGlmIHNvbWVvbmUg
YWN0dWFsbHkgZG9lcyB3YW50IHRvIGRyb3AgY2VydGFpbiBETlMgcmVxdWVzdHM/DQoNCkNoZWVy
cywNCg0KRWluYXINCg0KPiBPbiAyNSBPY3QgMjAxNywgYXQgMTQ6MzksIE0uIFJhbmdhbmF0aGFu
IDxtcmFuZ2FAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IElzIGl0IHBvc3NpYmxlIHRvIG1vZGlm
eSB0aGUgWUFORyBtb2RlbCBmb3IgaWV0Zi1hY2xkbnMgdG8gZXhwbGljaXRseSBkaXNhbGxvdyAi
ZHJvcCIgQUNFIHJ1bGVzPw0KPiAoaS5lLiBvbmx5ICJmb3J3YXJkaW5nIjoiYWNjZXB0IiB9IG5v
dCBrbm93bGVkZ2VhYmxlIGVub3VnaCBhYm91dCBZQU5HIHRvIHN1Z2dlc3QgdGhlIGNoYW5nZSku
DQo+IA0KPiBJdCB3b3VsZCBhbHNvIGJlIGNvbnZlbmllbnQgaWYgdGhlcmUgd2VyZSBhIHdheSB0
byBkaXNhbGxvdyBib3RoIGNvbnRyb2xsZXJzIEFORCBob3N0bmFtZXMgaW4gYSBzaW5nbGUgQUNM
IGVudHJ5IChmb3IgcmVhc29ucyBvZiBjbGFyaXR5KSBidXQgYWdhaW4gSSBkb24ndCBrbm93IGhv
dyB0byBzdGF0ZSB0aGF0IGluIFlBTkcuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiANCj4gDQo+IC0t
IA0KPiBNLiBSYW5nYW5hdGhhbg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiBPUFNBV0cgbWFpbGluZyBsaXN0DQo+IE9QU0FXR0BpZXRmLm9yZw0K
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KDQo=


From nobody Wed Oct 25 07:31:51 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 7C4BE138726 for ; Wed, 25 Oct 2017 07:31:50 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 hytZJTZkTXfn for ; Wed, 25 Oct 2017 07:31:45 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FAEB138A4C for ; Wed, 25 Oct 2017 07:31:45 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id EFCE6F88; Wed, 25 Oct 2017 16:31:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id oM1T_msjbz_Q; Wed, 25 Oct 2017 16:31:43 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Oct 2017 16:31:43 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCD662010E; Wed, 25 Oct 2017 16:31:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A5v4PMmkIsR4; Wed, 25 Oct 2017 16:31:43 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B6262010B; Wed, 25 Oct 2017 16:31:43 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 31243413C71A; Wed, 25 Oct 2017 16:30:16 +0200 (CEST)
Date: Wed, 25 Oct 2017 16:30:16 +0200
From: Juergen Schoenwaelder 
To: "Einar Nilsen-Nygaard (einarnn)" 
Cc: "M. Ranganathan" , "opsawg@ietf.org" 
Message-ID: <20171025143016.le7le5gxoqpalhvc@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Einar Nilsen-Nygaard (einarnn)" , "M. Ranganathan" , "opsawg@ietf.org" 
References:  <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 14:31:50 -0000

RFC 7858 defines DNS over TLS and this uses port 853 over TCP. ;-)
It is generally risky to hard code things based on the assumption
that something never changes or is always needed.

/js

On Wed, Oct 25, 2017 at 02:23:09PM +0000, Einar Nilsen-Nygaard (einarnn) wrote:
> Technically, you could express both of these constraints.
> 
> But why would we want to do this? One developer’s clarity may be another’s verbosity, and what if someone actually does want to drop certain DNS requests?
> 
> Cheers,
> 
> Einar
> 
> > On 25 Oct 2017, at 14:39, M. Ranganathan  wrote:
> > 
> > Is it possible to modify the YANG model for ietf-acldns to explicitly disallow "drop" ACE rules?
> > (i.e. only "forwarding":"accept" } not knowledgeable enough about YANG to suggest the change).
> > 
> > It would also be convenient if there were a way to disallow both controllers AND hostnames in a single ACL entry (for reasons of clarity) but again I don't know how to state that in YANG.
> > 
> > Thanks,
> > 
> > 
> > 
> > -- 
> > M. Ranganathan
> > _______________________________________________
> > 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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Oct 25 07:45: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 958A5138713 for ; Wed, 25 Oct 2017 07:45:07 -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 e_gRtp-vJimM for ; Wed, 25 Oct 2017 07:45:04 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D03C1384B2 for ; Wed, 25 Oct 2017 07:45:04 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id m72so16166906wmc.0 for ; Wed, 25 Oct 2017 07:45:04 -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;  bh=ZQyEsLY8ghIVgWmiJ+gH+UiX9JzG/s51IBfG7cjp4hY=; b=E/rVxhajyvtglDNHu0wRFhGQPDfX/oVfEQGLZ0VsWIv7b2h9v2U4/Hlq7ey9y9RzDA 60Nll/am8DdTeWSibpumDm4QARrNUIZUDFWvhzpfanelGHErZvYxYtChhk/83RkhYoCg 9nBbk2VOsnx1Djh/V3OU7SbUpnu67Da05NHOEHlQ8hNR8xjEbqsnRj17UvSkG0EyHjLn LPt4L2IyN4VWUmaobbqFS2lNq1CzcVSFm3swunoxtaQZK6i93krVboL1vFPc94SW0CuR IhCKlTtB8MMceVUU59vqI7kxdM0vwNiRmrv1NjxUUQHUI0S1k7e6/8SBVnXWOwh6GXM8 tGlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ZQyEsLY8ghIVgWmiJ+gH+UiX9JzG/s51IBfG7cjp4hY=; b=tmvdbJkTyZZ2wubsO7yDuixuQ1UEDNnncCScrh47IMJ6XWMoRTPCxqAbNnSRe5SFSP Ti22lVdr7VPwPsm4gRXEpgzjLd48+WlJtyYNiooAhc0Y66vF9YdYCOHLtj6/eCoB0k82 qmETmxZgBeeu9Txqhlt3yXsEyW1EbKhiQXY7KwcWTRkwLj7QJuSns8w9CLzws3e19wdo LMwlOiSvxZC3qGowFHxZ5G1zxbzduJTXve9E6yoV8aZIA8G6JKJaW207Vrya03fZaCcm 3duAdx8ASpdiJ7olanocnr1lzPSCvpchZSWwcnriZTIxCB+QqTQAE7BqafzzhHwEDBJP b2Ww==
X-Gm-Message-State: AMCzsaUtJWNRz1X6tWNL47A3k9okIHDOw7EuDLJ4gzCAYpD1zyTziaGL JndO66w12w5ZfGIe5haQfhA+hvMaYi+Sq8U/tCE=
X-Google-Smtp-Source: ABhQp+Q1K/FH9TDeb3HsMFcJQKBja1huj7kl26rpT3KxueUQhzILLYhjqcn4mlsCsvX4J9oKhJwKMWwtC0sRVQLyA1c=
X-Received: by 10.28.146.20 with SMTP id u20mr2213136wmd.49.1508942702635; Wed, 25 Oct 2017 07:45:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Wed, 25 Oct 2017 07:44:21 -0700 (PDT)
In-Reply-To: <20171025143016.le7le5gxoqpalhvc@elstar.local>
References:  <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com> <20171025143016.le7le5gxoqpalhvc@elstar.local>
From: "M. Ranganathan" 
Date: Wed, 25 Oct 2017 10:44:21 -0400
Message-ID: 
To: Juergen Schoenwaelder ,  "Einar Nilsen-Nygaard (einarnn)" , "M. Ranganathan" , "opsawg@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11442fbcc6f662055c6019ca"
Archived-At: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 14:45:07 -0000

--001a11442fbcc6f662055c6019ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Juergen, Einar,

On Wed, Oct 25, 2017 at 10:30 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> RFC 7858 defines DNS over TLS and this uses port 853 over TCP. ;-)
> It is generally risky to hard code things based on the assumption
> that something never changes or is always needed.
>
> /js
>
>

I just want to disallow the following:


        "rule-name": "myctl0-todev",
              "matches": {
                "ietf-mud:mud-acl": {
                  "my-controller": [
                    null
                  ]
                },
                "ipv4-acl": {
                    "ietf-acldns:src-dnsname": "www.nist.gov",
                   "protocol": 6,
                  "source-port-range": {
                    "lower-port": 443,
                    "upper-port": 443
                  }
                },
                "tcp-acl": {
                  "ietf-mud:direction-initiated": "from-device"
                }
              },
              "actions": {
                "forwarding": "accept"
              }


It is possible to express this as two separate ACL entries. I believe the
current YANG model would accept this.



> On Wed, Oct 25, 2017 at 02:23:09PM +0000, Einar Nilsen-Nygaard (einarnn)
> wrote:
> > Technically, you could express both of these constraints.
> >
> > But why would we want to do this? One developer=E2=80=99s clarity may b=
e
> another=E2=80=99s verbosity, and what if someone actually does want to dr=
op certain
> DNS requests?
>

The working model in MUD is to implicitly DENY any communication that is
not expressly allowed. It seems redundant to start with this working
assumption and then allow DENY rules anyway.


Thanks,

Ranga.



> >
> > Cheers,
> >
> > Einar
> >
>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>



--=20
M. Ranganathan

--001a11442fbcc6f662055c6019ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGRpdiBkaXI9Imx0ciI+SGkgSnVlcmdlbiwgRWluYXIsPGJyPjxkaXY+PGRpdiBjbGFzcz0iZ21h
aWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBPY3QgMjUsIDIw
MTcgYXQgMTA6MzAgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8c3BhbiBkaXI9Imx0ciI+Jmx0
OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiIHRh
cmdldD0iX2JsYW5rIj5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+Jmd0
Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9
Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwy
MDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij5SRkMgNzg1OCBkZWZpbmVzIEROUyBvdmVyIFRMUyBh
bmQgdGhpcyB1c2VzIHBvcnQgODUzIG92ZXIgVENQLiA7LSk8YnI+DQpJdCBpcyBnZW5lcmFsbHkg
cmlza3kgdG8gaGFyZCBjb2RlIHRoaW5ncyBiYXNlZCBvbiB0aGUgYXNzdW1wdGlvbjxicj4NCnRo
YXQgc29tZXRoaW5nIG5ldmVyIGNoYW5nZXMgb3IgaXMgYWx3YXlzIG5lZWRlZC48YnI+DQo8YnI+
DQovanM8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbC1IT0VuWmIiPjxkaXYgY2xhc3M9ImdtYWlsLWg1
Ij48YnI+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjxicj48L2Rpdj48ZGl2Pkkg
anVzdCB3YW50IHRvIGRpc2FsbG93IHRoZSBmb2xsb3dpbmc6PGJyPjwvZGl2PjxkaXY+PGJyPjxi
cj48L2Rpdj48ZGl2PsKgwqDCoMKgwqDCoMKgICZxdW90O3J1bGUtbmFtZSZxdW90OzogJnF1b3Q7
bXljdGwwLXRvZGV2JnF1b3Q7LCA8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgJnF1b3Q7
bWF0Y2hlcyZxdW90OzogeyA8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICZxdW90
O2lldGYtbXVkOm11ZC1hY2wmcXVvdDs6IHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCAmcXVvdDtteS1jb250cm9sbGVyJnF1b3Q7OiBbPGJyPsKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgIG51bGw8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCBdPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9LDxicj7CoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgJnF1b3Q7aXB2NC1hY2wmcXVvdDs6IHs8YnI+wqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCDCoCAmcXVvdDtpZXRmLWFjbGRuczpzcmMtZG5z
bmFtZSZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cDovL3d3dy5uaXN0LmdvdiI+d3d3Lm5pc3Qu
Z292PC9hPiZxdW90Oyw8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqAgJnF1
b3Q7cHJvdG9jb2wmcXVvdDs6IDYsPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgJnF1b3Q7c291cmNlLXBvcnQtcmFuZ2UmcXVvdDs6IHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgJnF1b3Q7bG93ZXItcG9ydCZxdW90OzogNDQzLDxicj7CoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAmcXVvdDt1cHBlci1wb3J0JnF1b3Q7
OiA0NDM8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9PGJyPsKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9LDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgJnF1b3Q7dGNwLWFjbCZxdW90Ozogezxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgICZxdW90O2lldGYtbXVkOmRpcmVjdGlvbi1pbml0aWF0ZWQmcXVvdDs6ICZxdW90O2Zy
b20tZGV2aWNlJnF1b3Q7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9PGJyPsKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0sPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
ICZxdW90O2FjdGlvbnMmcXVvdDs6IHs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
ICZxdW90O2ZvcndhcmRpbmcmcXVvdDs6ICZxdW90O2FjY2VwdCZxdW90Ozxicj7CoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCB9PGJyPjxicj48YnI+PC9kaXY+PGRpdj5JdCBpcyBwb3NzaWJsZSB0
byBleHByZXNzIHRoaXMgYXMgdHdvIHNlcGFyYXRlIEFDTCBlbnRyaWVzLiBJIGJlbGlldmUgdGhl
IGN1cnJlbnQgWUFORyBtb2RlbCB3b3VsZCBhY2NlcHQgdGhpcy48YnI+PC9kaXY+PGRpdj48YnI+
wqA8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4
IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFk
ZGluZy1sZWZ0OjFleCI+PGRpdiBjbGFzcz0iZ21haWwtSE9FblpiIj48ZGl2IGNsYXNzPSJnbWFp
bC1oNSI+DQpPbiBXZWQsIE9jdCAyNSwgMjAxNyBhdCAwMjoyMzowOVBNICswMDAwLCBFaW5hciBO
aWxzZW4tTnlnYWFyZCAoZWluYXJubikgd3JvdGU6PGJyPg0KJmd0OyBUZWNobmljYWxseSwgeW91
IGNvdWxkIGV4cHJlc3MgYm90aCBvZiB0aGVzZSBjb25zdHJhaW50cy48YnI+DQomZ3Q7PGJyPg0K
Jmd0OyBCdXQgd2h5IHdvdWxkIHdlIHdhbnQgdG8gZG8gdGhpcz8gT25lIGRldmVsb3BlcuKAmXMg
Y2xhcml0eSBtYXkgYmUgYW5vdGhlcuKAmXMgdmVyYm9zaXR5LCBhbmQgd2hhdCBpZiBzb21lb25l
IGFjdHVhbGx5IGRvZXMgd2FudCB0byBkcm9wIGNlcnRhaW4gRE5TIHJlcXVlc3RzPzxicj48L2Rp
dj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgd29ya2luZyBtb2Rl
bCBpbiBNVUQgaXMgdG8gaW1wbGljaXRseSBERU5ZIGFueSBjb21tdW5pY2F0aW9uIHRoYXQgaXMg
bm90IGV4cHJlc3NseSBhbGxvd2VkLiBJdCBzZWVtcyByZWR1bmRhbnQgdG8gc3RhcnQgd2l0aCB0
aGlzIHdvcmtpbmcgYXNzdW1wdGlvbiBhbmQgdGhlbiBhbGxvdyBERU5ZIHJ1bGVzIGFueXdheS4g
PGJyPjxicj48YnI+PC9kaXY+PGRpdj5UaGFua3MsPGJyPjxicj48L2Rpdj48ZGl2PlJhbmdhLjxi
cj48L2Rpdj48ZGl2Pjxicj7CoDxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVv
dGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlk
IHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBjbGFzcz0iZ21haWwtSE9F
blpiIj48ZGl2IGNsYXNzPSJnbWFpbC1oNSI+DQomZ3Q7PGJyPg0KJmd0OyBDaGVlcnMsPGJyPg0K
Jmd0Ozxicj4NCiZndDsgRWluYXI8YnI+DQomZ3Q7PGJyPjxicj4NCjxicj4NCjwvZGl2PjwvZGl2
PjxzcGFuIGNsYXNzPSJnbWFpbC1IT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4Ij4tLTxicj4N
Ckp1ZXJnZW4gU2Nob2Vud2FlbGRlcsKgIMKgIMKgIMKgIMKgIMKgSmFjb2JzIFVuaXZlcnNpdHkg
QnJlbWVuIGdHbWJIPGJyPg0KUGhvbmU6IDxhIGhyZWY9InRlbDolMkI0OSUyMDQyMSUyMDIwMCUy
MDM1ODciIHZhbHVlPSIrNDk0MjEyMDAzNTg3Ij4rNDkgNDIxIDIwMCAzNTg3PC9hPsKgIMKgIMKg
IMKgIMKgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+DQpGYXg6wqAg
wqA8YSBocmVmPSJ0ZWw6JTJCNDklMjA0MjElMjAyMDAlMjAzMTAzIiB2YWx1ZT0iKzQ5NDIxMjAw
MzEwMyI+KzQ5IDQyMSAyMDAgMzEwMzwvYT7CoCDCoCDCoCDCoCDCoCZsdDs8YSBocmVmPSJodHRw
Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS48d2JyPmRlLzwvYT4mZ3Q7PGJyPg0K
PC9mb250Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+
LS0gPGJyPjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSI+TS4gUmFuZ2FuYXRoYW48YnI+PC9k
aXY+DQo8L2Rpdj48L2Rpdj48L2Rpdj4NCg==
--001a11442fbcc6f662055c6019ca--


From nobody Wed Oct 25 08:01:58 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 8CC3513F3CF for ; Wed, 25 Oct 2017 08:01:55 -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 lJGH5TYrFwlf for ; Wed, 25 Oct 2017 08:01:53 -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 CD8591388A0 for ; Wed, 25 Oct 2017 08:01:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15291; q=dns/txt; s=iport; t=1508943713; x=1510153313; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Ve57bEJ6H7VXiWuRk99gH+I4eT9lRhWsmpMF//N9dyE=; b=EkZ9xG57QHr1MtvJjH9K5CKP8rpNRwq+KIhnig/zDZJAWPlJqPyptDuB UV16ej1NM4qRaJwlxgiKDQc+lDup7mdDJ21xjYxIDc5WPNvTlSdiQNGtp Y5mYlezKXIu+cP8mtgHx0TqrRh2APsRnLmL/Vin97ujHSxEQ8TARmkOOM o=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.43,432,1503360000";  d="asc'?scan'208,217";a="698241756"
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; 25 Oct 2017 15:01:50 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9PF1oSK007227; Wed, 25 Oct 2017 15:01:50 GMT
To: "M. Ranganathan" , Juergen Schoenwaelder , "Einar Nilsen-Nygaard (einarnn)" , "opsawg@ietf.org" 
References:  <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com> <20171025143016.le7le5gxoqpalhvc@elstar.local> 
From: Eliot Lear 
Message-ID: <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com>
Date: Wed, 25 Oct 2017 17:01:50 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OIuOsVCI7rfKnXtHpqpP5FJLoARiJlNQw"
Archived-At: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 15:01:55 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--OIuOsVCI7rfKnXtHpqpP5FJLoARiJlNQw
Content-Type: multipart/mixed; boundary="m8f51H9KUAq1w8qV7sR0AjKLKoGwQMH46";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" ,
 Juergen Schoenwaelder ,
 "Einar Nilsen-Nygaard (einarnn)" ,
 "opsawg@ietf.org" 
Message-ID: <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com>
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
References: 
 <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com>
 <20171025143016.le7le5gxoqpalhvc@elstar.local>
 
In-Reply-To: 

--m8f51H9KUAq1w8qV7sR0AjKLKoGwQMH46
Content-Type: multipart/alternative;
 boundary="------------89F2DFF8A944AE4BD86928A0"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------89F2DFF8A944AE4BD86928A0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SSBkaWQgYWRkIHNvbWUgdGV4dCBpbnRvIHRoZSBsYXN0IGRyYWZ0IGV4cGxpY3RseSB3YXJu
aW5nIGFnYWluc3QgdGhpcwpzb3J0IG9mIGNvbnN0cnVjdC4KCkVsaW90CgoKT24gMTAvMjUv
MTcgNDo0NCBQTSwgTS4gUmFuZ2FuYXRoYW4gd3JvdGU6Cj4gSGkgSnVlcmdlbiwgRWluYXIs
Cj4KPiBPbiBXZWQsIE9jdCAyNSwgMjAxNyBhdCAxMDozMCBBTSwgSnVlcmdlbiBTY2hvZW53
YWVsZGVyCj4gPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZQo+IDxtYWls
dG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6Cj4KPiAg
ICAgUkZDIDc4NTggZGVmaW5lcyBETlMgb3ZlciBUTFMgYW5kIHRoaXMgdXNlcyBwb3J0IDg1
MyBvdmVyIFRDUC4gOy0pCj4gICAgIEl0IGlzIGdlbmVyYWxseSByaXNreSB0byBoYXJkIGNv
ZGUgdGhpbmdzIGJhc2VkIG9uIHRoZSBhc3N1bXB0aW9uCj4gICAgIHRoYXQgc29tZXRoaW5n
IG5ldmVyIGNoYW5nZXMgb3IgaXMgYWx3YXlzIG5lZWRlZC4KPgo+ICAgICAvanMKPgo+Cj4K
PiBJIGp1c3Qgd2FudCB0byBkaXNhbGxvdyB0aGUgZm9sbG93aW5nOgo+Cj4KPiDCoMKgwqDC
oMKgwqDCoCAicnVsZS1uYW1lIjogIm15Y3RsMC10b2RldiIsCj4gwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgIm1hdGNoZXMiOiB7Cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgICJpZXRmLW11ZDptdWQtYWNsIjogewo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgIm15LWNvbnRyb2xsZXIiOiBbCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgbnVsbAo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgXQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9LAo+IMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCAiaXB2NC1hY2wiOiB7Cj4gwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCDCoCAiaWV0Zi1hY2xkbnM6c3JjLWRuc25hbWUiOiAid3d3Lm5p
c3QuZ292Cj4gPGh0dHA6Ly93d3cubmlzdC5nb3Y+IiwKPiDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCDCoCAicHJvdG9jb2wiOiA2LAo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgInNvdXJjZS1wb3J0LXJhbmdlIjogewo+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJsb3dlci1wb3J0IjogNDQzLAo+IMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJ1cHBlci1wb3J0IjogNDQzCj4gwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9Cj4gwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIH0sCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJ0Y3At
YWNsIjogewo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgImlldGYtbXVk
OmRpcmVjdGlvbi1pbml0aWF0ZWQiOiAiZnJvbS1kZXZpY2UiCj4gwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIH0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9LAo+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJhY3Rpb25zIjogewo+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCAiZm9yd2FyZGluZyI6ICJhY2NlcHQiCj4gwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgfQo+Cj4KPiBJdCBpcyBwb3NzaWJsZSB0byBleHByZXNzIHRoaXMg
YXMgdHdvIHNlcGFyYXRlIEFDTCBlbnRyaWVzLiBJIGJlbGlldmUKPiB0aGUgY3VycmVudCBZ
QU5HIG1vZGVsIHdvdWxkIGFjY2VwdCB0aGlzLgo+Cj4gwqAKPgo+ICAgICBPbiBXZWQsIE9j
dCAyNSwgMjAxNyBhdCAwMjoyMzowOVBNICswMDAwLCBFaW5hciBOaWxzZW4tTnlnYWFyZAo+
ICAgICAoZWluYXJubikgd3JvdGU6Cj4gICAgID4gVGVjaG5pY2FsbHksIHlvdSBjb3VsZCBl
eHByZXNzIGJvdGggb2YgdGhlc2UgY29uc3RyYWludHMuCj4gICAgID4KPiAgICAgPiBCdXQg
d2h5IHdvdWxkIHdlIHdhbnQgdG8gZG8gdGhpcz8gT25lIGRldmVsb3BlcuKAmXMgY2xhcml0
eSBtYXkgYmUKPiAgICAgYW5vdGhlcuKAmXMgdmVyYm9zaXR5LCBhbmQgd2hhdCBpZiBzb21l
b25lIGFjdHVhbGx5IGRvZXMgd2FudCB0bwo+ICAgICBkcm9wIGNlcnRhaW4gRE5TIHJlcXVl
c3RzPwo+Cj4KPiBUaGUgd29ya2luZyBtb2RlbCBpbiBNVUQgaXMgdG8gaW1wbGljaXRseSBE
RU5ZIGFueSBjb21tdW5pY2F0aW9uIHRoYXQKPiBpcyBub3QgZXhwcmVzc2x5IGFsbG93ZWQu
IEl0IHNlZW1zIHJlZHVuZGFudCB0byBzdGFydCB3aXRoIHRoaXMKPiB3b3JraW5nIGFzc3Vt
cHRpb24gYW5kIHRoZW4gYWxsb3cgREVOWSBydWxlcyBhbnl3YXkuCj4KPgo+IFRoYW5rcywK
Pgo+IFJhbmdhLgo+Cj4gwqAKPgo+ICAgICA+Cj4gICAgID4gQ2hlZXJzLAo+ICAgICA+Cj4g
ICAgID4gRWluYXIKPiAgICAgPgo+Cj4KPiAgICAgLS0KPiAgICAgSnVlcmdlbiBTY2hvZW53
YWVsZGVywqAgwqAgwqAgwqAgwqAgwqBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgK
PiAgICAgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgPHRlbDolMkI0OSUyMDQyMSUyMDIwMCUy
MDM1ODc+wqAgwqAgwqAgwqAKPiAgICAgwqBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVu
IHwgR2VybWFueQo+ICAgICBGYXg6wqAgwqArNDkgNDIxIDIwMCAzMTAzIDx0ZWw6JTJCNDkl
MjA0MjElMjAyMDAlMjAzMTAzPsKgIMKgIMKgIMKgCj4gICAgIMKgPGh0dHA6Ly93d3cuamFj
b2JzLXVuaXZlcnNpdHkuZGUvIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4+
Cj4KPgo+Cj4KPiAtLSAKPiBNLiBSYW5nYW5hdGhhbgo+Cj4KPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE9QU0FXRyBtYWlsaW5nIGxpc3QK
PiBPUFNBV0dAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29wc2F3ZwoK
--------------89F2DFF8A944AE4BD86928A0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
I did add some text into the last draft explictly warning against
      this sort of construct.

    
Eliot

    

    

    
On 10/25/17 4:44 PM, M. Ranganathan
      wrote:

    

    

      
      
Hi Juergen, Einar,

        

          


            
On Wed, Oct 25, 2017 at 10:30 AM,
              Juergen Schoenwaelder <j.schoenwael=
der@jacobs-university.de>
              wrote:

              
RFC 7858 defines DNS
                over TLS and this uses port 853 over TCP. ;-)

                It is generally risky to hard code things based on the
                assumption

                that something never changes or is always needed.

                

                /js

                

                  


                  

                

              

              


                

              

              
I just want to disallow the following:

              

              


                

              

              
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "rule-name"=
: "myctl0-todev", 

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "matches": { 

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "ietf-mud:mud-acl": {

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "my-controller": [

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 null

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ]

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "ipv4-acl": {

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "ietf-acldns:src-dns=
name": "w=
ww.nist.gov",

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 "protocol": 6,

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "source-port-range": {

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "lower-port": 4=
43,

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "upper-port": 4=
43

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 },

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "tcp-acl": {

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "ietf-mud:direction-initiat=
ed":
                "from-device"

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 },

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "actions": {

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "forwarding": "accept"

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 }

                

                

              

              
It is possible to express this as two separate ACL
                entries. I believe the current YANG model would accept
                this.

              

              


                =C2=A0

              

                

                  

                    On Wed, Oct 25, 2017 at 02:23:09PM +0000, Einar
                    Nilsen-Nygaard (einarnn) wrote:

                    > Technically, you could express both of these
                    constraints.

                    >

                    > But why would we want to do this? One
                    developer=E2=80=99s clarity may be another=E2=80=99s =
verbosity, and
                    what if someone actually does want to drop certain
                    DNS requests?

                  

                

              

              


              

              
The working model in MUD is to implicitly DENY any
                communication that is not expressly allowed. It seems
                redundant to start with this working assumption and then
                allow DENY rules anyway. 

                

                

              

              
Thanks,

                

              

              
Ranga.

              

              


                =C2=A0

              

              

                

                  

                    >

                    > Cheers,

                    >

                    > Einar

                    >

                    

                    

                  

                

                --
                    Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0Jacobs University
                    Bremen gGmbH

                    Phone: +4=
9
                      421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C=
ampus Ring 1 | 28759
                    Bremen | Germany

                    Fax:=C2=A0 =C2=A0+4=
9
                      421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&=
lt;http://www.jacobs-universi=
ty.de/>

                  

            

            

            

            

            -- 

            
M. Ranganathan

            

          

        

      

      

      

      

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


    

    

  


--------------89F2DFF8A944AE4BD86928A0--

--m8f51H9KUAq1w8qV7sR0AjKLKoGwQMH46--

--OIuOsVCI7rfKnXtHpqpP5FJLoARiJlNQw
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

iQEcBAEBCAAGBQJZ8KdeAAoJEIe2a0bZ0nozAu8H/A72FuzHX/PZWuYOoXSRDMLV
2BUuFSZa7sMY+5kjEMMGedHAD2x/9IMasD4T2P2qazwWfA1Eun1y923WObXfSga8
gErLLKEJrx3YjZWHxUuNevODg2pJWCEpLDJAADfUY5Kil9tk/PQK2D3ZnvBjadpO
4N6q4z2qOVEnlw8VHhcfWt4Kh7OgwhmnEdw/rmR7Mvx/nSwtpCjTcJ4/0foqTHc3
B9wZyVmJST/GSY0Rfu1GlB++JA9C/7U6gXXGwdpk2HdesLNCbCifP2IABO1KL6CF
ct/IFlKINjSF6PjJfKOFE2r0xUnu4EadAUnNlQdHURdErEGg0Vo+bVohaYJMC28=
=OOPK
-----END PGP SIGNATURE-----

--OIuOsVCI7rfKnXtHpqpP5FJLoARiJlNQw--


From nobody Wed Oct 25 08:58: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 9B27113B12A for ; Wed, 25 Oct 2017 08:58:32 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 tJyrk7Q6bw3G for ; Wed, 25 Oct 2017 08:58:30 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F39138F21 for ; Wed, 25 Oct 2017 08:58:29 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 85BFDF39; Wed, 25 Oct 2017 17:58:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id EMz6Noc-mfoR; Wed, 25 Oct 2017 17:58:28 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Oct 2017 17:58:28 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71E072010B; Wed, 25 Oct 2017 17:58:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id h5b1UNyzKHkr; Wed, 25 Oct 2017 17:58:27 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBFCC2010A; Wed, 25 Oct 2017 17:58:27 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C4A10413CAC2; Wed, 25 Oct 2017 17:57:00 +0200 (CEST)
Date: Wed, 25 Oct 2017 17:57:00 +0200
From: Juergen Schoenwaelder 
To: Eliot Lear 
Cc: "M. Ranganathan" , "Einar Nilsen-Nygaard (einarnn)" , "opsawg@ietf.org" 
Message-ID: <20171025155700.c3av5tp7hxc76krn@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Eliot Lear , "M. Ranganathan" , "Einar Nilsen-Nygaard (einarnn)" , "opsawg@ietf.org" 
References:  <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com> <20171025143016.le7le5gxoqpalhvc@elstar.local>  <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 15:58:33 -0000

May I ask what this warning is and where I find it? And yes, I am still
reading and learning so be patient with me.

/js

On Wed, Oct 25, 2017 at 05:01:50PM +0200, Eliot Lear wrote:
> I did add some text into the last draft explictly warning against this
> sort of construct.
> 
> Eliot
> 
> 
> On 10/25/17 4:44 PM, M. Ranganathan wrote:
> > Hi Juergen, Einar,
> >
> > On Wed, Oct 25, 2017 at 10:30 AM, Juergen Schoenwaelder
> >  > > wrote:
> >
> >     RFC 7858 defines DNS over TLS and this uses port 853 over TCP. ;-)
> >     It is generally risky to hard code things based on the assumption
> >     that something never changes or is always needed.
> >
> >     /js
> >
> >
> >
> > I just want to disallow the following:
> >
> >
> >         "rule-name": "myctl0-todev",
> >               "matches": {
> >                 "ietf-mud:mud-acl": {
> >                   "my-controller": [
> >                     null
> >                   ]
> >                 },
> >                 "ipv4-acl": {
> >                     "ietf-acldns:src-dnsname": "www.nist.gov
> > ",
> >                    "protocol": 6,
> >                   "source-port-range": {
> >                     "lower-port": 443,
> >                     "upper-port": 443
> >                   }
> >                 },
> >                 "tcp-acl": {
> >                   "ietf-mud:direction-initiated": "from-device"
> >                 }
> >               },
> >               "actions": {
> >                 "forwarding": "accept"
> >               }
> >
> >
> > It is possible to express this as two separate ACL entries. I believe
> > the current YANG model would accept this.
> >
> >  
> >
> >     On Wed, Oct 25, 2017 at 02:23:09PM +0000, Einar Nilsen-Nygaard
> >     (einarnn) wrote:
> >     > Technically, you could express both of these constraints.
> >     >
> >     > But why would we want to do this? One developer’s clarity may be
> >     another’s verbosity, and what if someone actually does want to
> >     drop certain DNS requests?
> >
> >
> > The working model in MUD is to implicitly DENY any communication that
> > is not expressly allowed. It seems redundant to start with this
> > working assumption and then allow DENY rules anyway.
> >
> >
> > Thanks,
> >
> > Ranga.
> >
> >  
> >
> >     >
> >     > Cheers,
> >     >
> >     > Einar
> >     >
> >
> >
> >     --
> >     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >     Phone: +49 421 200 3587        
> >      Campus Ring 1 | 28759 Bremen | Germany
> >     Fax:   +49 421 200 3103        
> >      >
> >
> >
> >
> >
> > -- 
> > M. Ranganathan
> >
> >
> > _______________________________________________
> > OPSAWG mailing list
> > OPSAWG@ietf.org
> > https://www.ietf.org/mailman/listinfo/opsawg
> 




-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Oct 25 09:08:43 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 8833F13AE15 for ; Wed, 25 Oct 2017 09:08:41 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 0qSJDgFC_4my for ; Wed, 25 Oct 2017 09:08:40 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F61139059 for ; Wed, 25 Oct 2017 09:08:39 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7EB91374; Wed, 25 Oct 2017 18:08:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ws9sniSEiHEM; Wed, 25 Oct 2017 18:08:38 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 25 Oct 2017 18:08:38 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B4422010B; Wed, 25 Oct 2017 18:08:38 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DvOajiFjoFqE; Wed, 25 Oct 2017 18:08:37 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE8192010A; Wed, 25 Oct 2017 18:08:37 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 63EEE413CAFC; Wed, 25 Oct 2017 18:07:12 +0200 (CEST)
Date: Wed, 25 Oct 2017 18:07:12 +0200
From: Juergen Schoenwaelder 
To: Eliot Lear 
Cc: "M. Ranganathan" , opsawg@ietf.org
Message-ID: <20171025160712.opnegb3vjbceiu53@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Eliot Lear , "M. Ranganathan" , opsawg@ietf.org
References:   <02a12c7d-8a4f-3aa1-c39a-562c472c9b4d@cisco.com> <88a0cec9-cb0b-f3c6-294b-b5707ba35bc0@cisco.com> <3baf711f-a600-3581-f7b4-92f184ab1b4a@cisco.com> <52b1e0b7-f78e-66b7-0220-e05d5c7e849b@cisco.com>  <6255213d-b097-d0ca-67f7-91207960532e@cisco.com> <20171024155147.luowaylud3argvca@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [OPSAWG] MUD : actions { forwarding : drop } utility.
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, 25 Oct 2017 16:08:41 -0000

On Tue, Oct 24, 2017 at 06:43:21PM +0200, Eliot Lear wrote:
> Giid evening Juergen,
> 
> 
> On 10/24/17 5:51 PM, Juergen Schoenwaelder wrote:
> >
> > What you describe seem to be different policies. Are you saying that
> > these different policies are bad or a huge management problem and
> > hence we hard-code a default policy that is considered "good" in most
> > situations? If you say removing the implied default rules results in a
> > management burden, what is the reasoning? 
> 
> Here is a worst case scenario, Juergen: suppose you have 600 different
> types of device on your network and each manufacturer has implemented
> its own class for DNS support.  That would mean that the network
> administrator would essentially have to populate 600 classes.  Better to
> have a single class, given its commonality.  There are very few such
> common services on a network, but there are presumably one or two others
> that will come to be, and thus the ability to extend this list over time.

[...]

> Make sense?

Likely but I guess I have to do more reading to understand what
'populate classes' means for the network administrator...

[. . . . ]

Done some more reading. It is still unclear to me what 'populate
classes' means. 

Some general comments (now that I read the ID):

- s/only"accept"/only "accept"/

- the definition of tree diagrams is being moved from
  [I-D.ietf-netmod-rfc6087bis] to [I-D.ietf-netmod-yang-tree-diagrams]

- I read:

   Great care should be used when invoking the controller class.  For

  I am not sure what it means to invoke a controller class. So far, I
  thought that a 'controller class' is simply a set of IP addresses
  belonging to controllers. Hm.

   The other module abstracts away IP addresses into certain classes

   Controller:  Devices that the local network administrator admits to
      the particular class.

  I guess I am confused by the usage of the word 'class'; the word
  seems to be used in different contexts with different meanings and
  hence I also confused what populate classes may mean.

- Should the titles of 7.1 and 7.2 be changed to src-dnsname and
  dst-dnsname to align with the YANG definitions? Or should the text
  in 7.1 and 7.2 not simply become part of the description of
  src-dnsname and dst-dnsname?

- Likely a wording issue:

    Four of "acl" liste entries that implement default MUD nodes is
    listed below.

  Did you mean:

    Four "acl" list entries that implement default MUD nodes are
    listed below.

Back to the thread, which rule does appendix B with the 'default MUD
nodes' really play?

(a) Are these MUD rules that are assumed by a controller to be always
    there even if they are not?

(b) Or are these a set of rules that manufacturers may include in
    their MUD files?

I assume it is (a) but I find the text not entirely clear. The first
sentence reads like these rules are automatically considered to be
there (by the controller) but the second sentence says that a
manufacturer can overwrite this if necessary. Well, the sentence are
not explicit about which entity is doing what.

   [...] This is considered the default
   behavior and the ACEs are in effect appended to whatever other "ace"
   entries that a MUD file contains.  To block DNS or NTP one repeats
   the matching statement but replaces the "forwarding" action "accept"
   with "drop".

So why is (b) not workable and (a) required?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         g


From nobody Wed Oct 25 09:45:37 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 A39F213ADBD for ; Wed, 25 Oct 2017 09:45:36 -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 tgYgvC4-y75I for ; Wed, 25 Oct 2017 09:45:34 -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 2DA4F13941E for ; Wed, 25 Oct 2017 09:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7312; q=dns/txt; s=iport; t=1508949934; x=1510159534; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=F85yKnTWdQJbzl2q6iJ4eDXVqzZ6tSGpRU7u6WsF/Kk=; b=RhwlN0mrpfrYmRjUfh3mR2wgFGymBSQ/A9Lxnvh6Dckm03VshVpMNIvy U9c2t0wYUect4cOfd71tp6HTeNZtCN3IV5B7BfbBhuUEszQWu3OIbX/Dx MRBggAGUISBT2mGRo31Bp5HRt8P2bCpQ2+kglib/WM7sOJgdrCBSEyjH/ U=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.43,432,1503360000";  d="asc'?scan'208";a="698243230"
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; 25 Oct 2017 16:45:32 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9PGjWiD026165; Wed, 25 Oct 2017 16:45:32 GMT
To: "M. Ranganathan" , "Einar Nilsen-Nygaard (einarnn)" , "opsawg@ietf.org" 
References:  <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com> <20171025143016.le7le5gxoqpalhvc@elstar.local>  <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com> <20171025155700.c3av5tp7hxc76krn@elstar.local>
From: Eliot Lear 
Message-ID: <2968c7d4-d973-1119-2f63-e9445d943667@cisco.com>
Date: Wed, 25 Oct 2017 18:45:32 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171025155700.c3av5tp7hxc76krn@elstar.local>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8ttGtBSOvac7EXDMLlmxjGv27FS2a3ojM"
Archived-At: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 16:45:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8ttGtBSOvac7EXDMLlmxjGv27FS2a3ojM
Content-Type: multipart/mixed; boundary="84sib2lE0dNdnjpPVmPu50E576rHG2bGm";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" ,
 "Einar Nilsen-Nygaard (einarnn)" ,
 "opsawg@ietf.org" 
Message-ID: <2968c7d4-d973-1119-2f63-e9445d943667@cisco.com>
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
References: 
 <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com>
 <20171025143016.le7le5gxoqpalhvc@elstar.local>
 
 <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com>
 <20171025155700.c3av5tp7hxc76krn@elstar.local>
In-Reply-To: <20171025155700.c3av5tp7hxc76krn@elstar.local>

--84sib2lE0dNdnjpPVmPu50E576rHG2bGm
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Content-Language: en-US

U3VyZS7CoCBTZWN0aW9uIDIuMToKCj4gwqDCoCBBIHZhbGlkIE1VRCBmaWxlIHdpbGwgY29u
dGFpbiB0d28gcm9vdCBvYmplY3RzLCBhICJtdWQiIGNvbnRhaW5lciBhbmQKPiDCoMKgIGFu
ICJhY2Nlc3MtbGlzdHMiIGNvbnRhaW5lci7CoCBFeHRlbnNpb25zIG1heSBhZGQgYWRkaXRp
b25hbCByb290Cj4gwqDCoCBvYmplY3RzIGFzIHJlcXVpcmVkLsKgIEFzIGEgcmVtaW5kZXIs
IHdoZW4gcGFyc2luZyBhY2Nlc3MtbGlzdHMsCj4gwqDCoCBlbGVtZW50cyB3aXRoaW4gYSAi
bWF0Y2giIGJsb2NrIGFyZSBsb2dpY2FsbHkgQU5EZWQuwqAgSW4gZ2VuZXJhbCwgYQo+IMKg
wqAgc2luZ2xlIGFic3RyYWN0aW9uIGluIGEgbWF0Y2ggc3RhdGVtZW50IHNob3VsZCBiZSB1
c2VkLsKgIEZvcgo+IMKgwqAgaW5zdGFuY2UsIGl0IG1ha2VzIGxpdHRsZSBzZW5zZSB0byBt
YXRjaCBib3RoICJteS1jb250cm9sbGVyIiBhbmQKPiDCoMKgICJjb250cm9sbGVyIiB3aXRo
IGFuIGFyZ3VtZW50LCBzaW5jZSB0aGV5IGFyZSBoaWdobHkgdW5saWtlbHkgdG8gYmUKPiDC
oMKgIHRoZSBzYW1lIHZhbHVlLgoKCk9uIDEwLzI1LzE3IDU6NTcgUE0sIEp1ZXJnZW4gU2No
b2Vud2FlbGRlciB3cm90ZToKPiBNYXkgSSBhc2sgd2hhdCB0aGlzIHdhcm5pbmcgaXMgYW5k
IHdoZXJlIEkgZmluZCBpdD8gQW5kIHllcywgSSBhbSBzdGlsbAo+IHJlYWRpbmcgYW5kIGxl
YXJuaW5nIHNvIGJlIHBhdGllbnQgd2l0aCBtZS4KPgo+IC9qcwo+Cj4gT24gV2VkLCBPY3Qg
MjUsIDIwMTcgYXQgMDU6MDE6NTBQTSArMDIwMCwgRWxpb3QgTGVhciB3cm90ZToKPj4gSSBk
aWQgYWRkIHNvbWUgdGV4dCBpbnRvIHRoZSBsYXN0IGRyYWZ0IGV4cGxpY3RseSB3YXJuaW5n
IGFnYWluc3QgdGhpcwo+PiBzb3J0IG9mIGNvbnN0cnVjdC4KPj4KPj4gRWxpb3QKPj4KPj4K
Pj4gT24gMTAvMjUvMTcgNDo0NCBQTSwgTS4gUmFuZ2FuYXRoYW4gd3JvdGU6Cj4+PiBIaSBK
dWVyZ2VuLCBFaW5hciwKPj4+Cj4+PiBPbiBXZWQsIE9jdCAyNSwgMjAxNyBhdCAxMDozMCBB
TSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyCj4+PiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11
bml2ZXJzaXR5LmRlCj4+PiA8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy
c2l0eS5kZT4+IHdyb3RlOgo+Pj4KPj4+ICAgICBSRkMgNzg1OCBkZWZpbmVzIEROUyBvdmVy
IFRMUyBhbmQgdGhpcyB1c2VzIHBvcnQgODUzIG92ZXIgVENQLiA7LSkKPj4+ICAgICBJdCBp
cyBnZW5lcmFsbHkgcmlza3kgdG8gaGFyZCBjb2RlIHRoaW5ncyBiYXNlZCBvbiB0aGUgYXNz
dW1wdGlvbgo+Pj4gICAgIHRoYXQgc29tZXRoaW5nIG5ldmVyIGNoYW5nZXMgb3IgaXMgYWx3
YXlzIG5lZWRlZC4KPj4+Cj4+PiAgICAgL2pzCj4+Pgo+Pj4KPj4+Cj4+PiBJIGp1c3Qgd2Fu
dCB0byBkaXNhbGxvdyB0aGUgZm9sbG93aW5nOgo+Pj4KPj4+Cj4+PiDCoMKgwqDCoMKgwqDC
oCAicnVsZS1uYW1lIjogIm15Y3RsMC10b2RldiIsCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCAibWF0Y2hlcyI6IHsKPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCAiaWV0Zi1tdWQ6bXVkLWFjbCI6IHsKPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgIm15LWNvbnRyb2xsZXIiOiBbCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCBudWxsCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIF0KPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9LAo+Pj4gwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJpcHY0LWFjbCI6IHsKPj4+IMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqAgImlldGYtYWNsZG5zOnNyYy1kbnNuYW1l
IjogInd3dy5uaXN0Lmdvdgo+Pj4gPGh0dHA6Ly93d3cubmlzdC5nb3Y+IiwKPj4+IMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIMKgICJwcm90b2NvbCI6IDYsCj4+PiDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJzb3VyY2UtcG9ydC1yYW5nZSI6IHsK
Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICJsb3dlci1wb3J0
IjogNDQzLAo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgInVw
cGVyLXBvcnQiOiA0NDMKPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
fQo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0sCj4+PiDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgInRjcC1hY2wiOiB7Cj4+PiDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgICJpZXRmLW11ZDpkaXJlY3Rpb24taW5pdGlhdGVkIjogImZy
b20tZGV2aWNlIgo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0KPj4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0sCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCAiYWN0aW9ucyI6IHsKPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAi
Zm9yd2FyZGluZyI6ICJhY2NlcHQiCj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9
Cj4+Pgo+Pj4KPj4+IEl0IGlzIHBvc3NpYmxlIHRvIGV4cHJlc3MgdGhpcyBhcyB0d28gc2Vw
YXJhdGUgQUNMIGVudHJpZXMuIEkgYmVsaWV2ZQo+Pj4gdGhlIGN1cnJlbnQgWUFORyBtb2Rl
bCB3b3VsZCBhY2NlcHQgdGhpcy4KPj4+Cj4+PiDCoAo+Pj4KPj4+ICAgICBPbiBXZWQsIE9j
dCAyNSwgMjAxNyBhdCAwMjoyMzowOVBNICswMDAwLCBFaW5hciBOaWxzZW4tTnlnYWFyZAo+
Pj4gICAgIChlaW5hcm5uKSB3cm90ZToKPj4+ICAgICA+IFRlY2huaWNhbGx5LCB5b3UgY291
bGQgZXhwcmVzcyBib3RoIG9mIHRoZXNlIGNvbnN0cmFpbnRzLgo+Pj4gICAgID4KPj4+ICAg
ICA+IEJ1dCB3aHkgd291bGQgd2Ugd2FudCB0byBkbyB0aGlzPyBPbmUgZGV2ZWxvcGVy4oCZ
cyBjbGFyaXR5IG1heSBiZQo+Pj4gICAgIGFub3RoZXLigJlzIHZlcmJvc2l0eSwgYW5kIHdo
YXQgaWYgc29tZW9uZSBhY3R1YWxseSBkb2VzIHdhbnQgdG8KPj4+ICAgICBkcm9wIGNlcnRh
aW4gRE5TIHJlcXVlc3RzPwo+Pj4KPj4+Cj4+PiBUaGUgd29ya2luZyBtb2RlbCBpbiBNVUQg
aXMgdG8gaW1wbGljaXRseSBERU5ZIGFueSBjb21tdW5pY2F0aW9uIHRoYXQKPj4+IGlzIG5v
dCBleHByZXNzbHkgYWxsb3dlZC4gSXQgc2VlbXMgcmVkdW5kYW50IHRvIHN0YXJ0IHdpdGgg
dGhpcwo+Pj4gd29ya2luZyBhc3N1bXB0aW9uIGFuZCB0aGVuIGFsbG93IERFTlkgcnVsZXMg
YW55d2F5Lgo+Pj4KPj4+Cj4+PiBUaGFua3MsCj4+Pgo+Pj4gUmFuZ2EuCj4+Pgo+Pj4gwqAK
Pj4+Cj4+PiAgICAgPgo+Pj4gICAgID4gQ2hlZXJzLAo+Pj4gICAgID4KPj4+ICAgICA+IEVp
bmFyCj4+PiAgICAgPgo+Pj4KPj4+Cj4+PiAgICAgLS0KPj4+ICAgICBKdWVyZ2VuIFNjaG9l
bndhZWxkZXLCoCDCoCDCoCDCoCDCoCDCoEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i
SAo+Pj4gICAgIFBob25lOiArNDkgNDIxIDIwMCAzNTg3IDx0ZWw6JTJCNDklMjA0MjElMjAy
MDAlMjAzNTg3PsKgIMKgIMKgIMKgCj4+PiAgICAgwqBDYW1wdXMgUmluZyAxIHwgMjg3NTkg
QnJlbWVuIHwgR2VybWFueQo+Pj4gICAgIEZheDrCoCDCoCs0OSA0MjEgMjAwIDMxMDMgPHRl
bDolMkI0OSUyMDQyMSUyMDIwMCUyMDMxMDM+wqAgwqAgwqAgwqAKPj4+ICAgICDCoDxodHRw
Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVy
c2l0eS5kZS8+Pgo+Pj4KPj4+Cj4+Pgo+Pj4KPj4+IC0tIAo+Pj4gTS4gUmFuZ2FuYXRoYW4K
Pj4+Cj4+Pgo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KPj4+IE9QU0FXRyBtYWlsaW5nIGxpc3QKPj4+IE9QU0FXR0BpZXRmLm9yZwo+Pj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cKPgo+Cj4KCg==

--84sib2lE0dNdnjpPVmPu50E576rHG2bGm--

--8ttGtBSOvac7EXDMLlmxjGv27FS2a3ojM
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

iQEcBAEBCAAGBQJZ8L+sAAoJEIe2a0bZ0nozEq4IAMLUizbYCEfSGKDqpARAl8bt
AfyK2BisHI3ET6FXKhqDOsBxY/IzFDrd09Pmrpb5Wj3iSk6e0EqNiCYFZkY12xTp
QafEEEjJUyCKcHC9EpZlJ0k6eLIe8pJe5BGCz9POiOnmCcpZfkZeLZxj0SHK+KfX
DwHjW2R725QwD9hVHv9hLcUepMUyaUJaa2NrVwHiDnoX4ZW69IQBlkvEWE789bOZ
xAQoB4M6xskk6zvPzTeIlMo8VKlmBh+xd/vbV+mi2C1TVla1YnGC2G9T2z4lbFkD
xuGaiGMmh88HtpfnGEluljt/7khIKcwFym1Ys/YtWprlMlQ+OArYNH85FrFEzKQ=
=U//l
-----END PGP SIGNATURE-----

--8ttGtBSOvac7EXDMLlmxjGv27FS2a3ojM--


From nobody Wed Oct 25 10:12: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 38DC713B098 for ; Wed, 25 Oct 2017 10:12:30 -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 ejJVIzthAsci for ; Wed, 25 Oct 2017 10:12:28 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 76B0B138726 for ; Wed, 25 Oct 2017 10:12:28 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id r196so3342514wmf.2 for ; Wed, 25 Oct 2017 10:12:28 -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=RY42AOd+RGScm3cpMAazpPsVWZhaqHlYk6aqtHFPpNM=; b=do0Yj7nXnBqg+T0ZMqMku1swqQuyR2A8I82+TK3KDyhDSJ+EkXoQM8UEiTimDkOJHW niHE68OSNmiqFKH2tBVNXMjuyNgGnShmd8nDrxK/lC/3Z6a9zIDFGZvrfAJA+KtEahRQ +jpUzwsuhZrx+GenLmaMI/GTx128SWGF/vdz2ZVkhPyNMZ176ZpW1Kt+07Qgm9vTl1K7 Tbyfjwy3hz+42zHoocM0kL/UCZV+WjLmpM8GCTgZOtLZeFpT+4B+0uys1hE704NcmgyK MONjrGgPGvan6xTa08/bE/FmZFUQVOpP0E05lXj7huIanHaIxpueEc/sDm0l8FXlgmgE Em0A==
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=RY42AOd+RGScm3cpMAazpPsVWZhaqHlYk6aqtHFPpNM=; b=c0kX/q5LCTDjaGuXGWQkXqFNC0wsxbDEpIMcTBgDO692KDwM9laKti1j+KkRjRiGfx 5HMTRvT229Nzabbp1CvjY7Uvxyw9Sc/M7mU3lkOR8s943qTaoKar2kWVtBxY+gdjPxAn 9qvGMJqwVBfibBtjiNOY5vfAWVP/jSYQSIcMFiZAtBPgXg6vO+nBbOOqhWpVN8nznv1F cMZ3yjedYXg9LqNL83G6DTD6Gp0feR/VOcXAjSJjGyQwrOWbzIYtg0/P5qHDCh0vIhGm MKDukizCF/DzjT/niTZSpxBoRNhYpV9tgeGRDql3PVH8o/9a1J8Vb+Dgwxre93zlwuI1 Dbrw==
X-Gm-Message-State: AMCzsaWPFmzYlJnL05eQKE2YOBaz7T5zsAl3A6xmNc5P0mbCypxTuL0o Sfvz+rUTVhbaS6B9PC1l+ZKOoBncGKDPfHjakBQ=
X-Google-Smtp-Source: ABhQp+RFwi5RotR8NfWEhWEy+yyH1sfOl19ewrNxv1HEg2E/sg66Ppvtw/8NVoSJTymB8RARTPoSQkIJRQqbuzGwymM=
X-Received: by 10.28.63.134 with SMTP id m128mr2650097wma.137.1508951546652; Wed, 25 Oct 2017 10:12:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Wed, 25 Oct 2017 10:11:45 -0700 (PDT)
In-Reply-To: <2968c7d4-d973-1119-2f63-e9445d943667@cisco.com>
References:  <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com> <20171025143016.le7le5gxoqpalhvc@elstar.local>  <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com> <20171025155700.c3av5tp7hxc76krn@elstar.local> <2968c7d4-d973-1119-2f63-e9445d943667@cisco.com>
From: "M. Ranganathan" 
Date: Wed, 25 Oct 2017 13:11:45 -0400
Message-ID: 
To: Eliot Lear 
Cc: "Einar Nilsen-Nygaard (einarnn)" , "opsawg@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1148be06ebeedd055c62285a"
Archived-At: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 17:12:30 -0000

--001a1148be06ebeedd055c62285a
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 25, 2017 at 12:45 PM, Eliot Lear  wrote:

> Sure.  Section 2.1:
>
> >    A valid MUD file will contain two root objects, a "mud" container and
> >    an "access-lists" container.  Extensions may add additional root
> >    objects as required.  As a reminder, when parsing access-lists,
> >    elements within a "match" block are logically ANDed.  In general, a
> >    single abstraction in a match statement should be used.  For
> >    instance, it makes little sense to match both "my-controller" and
> >    "controller" with an argument, since they are highly unlikely to be
> >    the same value.
>
>
Since these are sets, I think a better statement could be:

"an intersection is computed between elements within a match block" (rather
than ANDed).

If possible it would be nice to impose a restriction on single abstraction
in a match statement (I see no benefit in allowing more than one element).
However, I do not know if it is possible to enforce such a restriction via
YANG.

Ranga



>
>
>


-- 
M. Ranganathan

--001a1148be06ebeedd055c62285a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Oct 25, 2017 at 12:45 PM, Eliot Lear <lear@cisco.com> wrote:
Sure.=C2=A0 Section 2.1:



> =C2=A0=C2=A0 A valid MUD file will contain two root objects, a "m=
ud" container and

> =C2=A0=C2=A0 an "access-lists" container.=C2=A0 Extensions m=
ay add additional root

> =C2=A0=C2=A0 objects as required.=C2=A0 As a reminder, when parsing ac=
cess-lists,

> =C2=A0=C2=A0 elements within a "match" block are logically A=
NDed.=C2=A0 In general, a

> =C2=A0=C2=A0 single abstraction in a match statement should be used.=
=C2=A0 For

> =C2=A0=C2=A0 instance, it makes little sense to match both "my-co=
ntroller" and

> =C2=A0=C2=A0 "controller" with an argument, since they are h=
ighly unlikely to be

> =C2=A0=C2=A0 the same value.



<=
br>
Since these are sets, I think a better statement could be: 
"an intersection is computed between elements within =
a match block" (rather than ANDed).

If possible it w=
ould be nice to impose a restriction on single abstraction in a match state=
ment (I see no benefit in allowing more than one element). However, I do no=
t know if it is possible to enforce such a restriction via YANG.

Ranga

=C2=A0









-- 
M. Ranganathan
<=
/div>



--001a1148be06ebeedd055c62285a--


From nobody Wed Oct 25 11:41: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 5F93A139435 for ; Wed, 25 Oct 2017 11:41:21 -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, HTML_MESSAGE=0.001, 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 AmXSj3CUtxMW for ; Wed, 25 Oct 2017 11:41:19 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD7A138103 for ; Wed, 25 Oct 2017 11:41:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10500; q=dns/txt; s=iport; t=1508956879; x=1510166479; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4RhF+X5AOYnYhg/KZU8P1AyhniIGyIGUdxrGj6h8FpI=; b=J7WzmSUJ92GrE5vYXb0TnjmVzG9Zq9kM4rOQxtsSkjryHJcyggFG7yG+ Yf+/FVtS8LEmeIfbQSztb5CwYrK1AaWFiWEWwuJgQbpXnNo2FvZfdazQF 7J+7vYymX1epWfaMb54460MkbBLBomKXsJUeErMUvuZiRdPPEZAktfGgI o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAACV2fBZ/4UNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1+BUicHg3OKH48LgXqIS4gthUKCEQqFOwIahFM/GAECAQEBAQE?= =?us-ascii?q?BAWsohR4BBAEjVgULAgEIPwMCAgIfERQRAgQOBYk8TAMNCKllgieHOw2DLwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2DLoIHg2KDAYJeghEVgxUvgjIFiiuXDDwCiHq?= =?us-ascii?q?HAoR5ghWREY0NhTmDDgIRGQGBOAEfOIFbehV2AYI2SYQWdop5gREBAQE?=
X-IronPort-AV: E=Sophos; i="5.43,432,1503360000"; d="scan'208,217"; a="22133398"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2017 18:41:19 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v9PIfIVF025144 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Oct 2017 18:41:18 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 25 Oct 2017 14:41:17 -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.1320.000; Wed, 25 Oct 2017 14:41:17 -0400
From: "Einar Nilsen-Nygaard (einarnn)" 
To: "M. Ranganathan" 
CC: Eliot Lear , "opsawg@ietf.org" 
Thread-Topic: [OPSAWG] MUD : ietf-acldns YANG model question.
Thread-Index: AQHTTZbBtXE74WLzFUmKLI3mXHHTnaL04XQAgAAB+QCAAAPwgIAABOIAgAAPagCAAA2PAIAAB1OAgAAZCAA=
Date: Wed, 25 Oct 2017 18:41:17 +0000
Message-ID: 
References:  <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com> <20171025143016.le7le5gxoqpalhvc@elstar.local>  <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com> <20171025155700.c3av5tp7hxc76krn@elstar.local> <2968c7d4-d973-1119-2f63-e9445d943667@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.1.7)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.225.82]
Content-Type: multipart/alternative; boundary="_000_A218904875AE42DFA25652322C00EE2Aciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 18:41:21 -0000

--_000_A218904875AE42DFA25652322C00EE2Aciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UmFuZ2EsDQoNCkxvb2tpbmcgYXQgdGhpczoNCg0KICBhdWdtZW50IC9hY2w6YWNjZXNzLWxpc3Rz
L2FjbDphY2wvYWNsOmFjZXMvYWNsOmFjZS9hY2w6bWF0Y2hlczoNCiAgICArLS1ydyBtdWQtYWNs
DQogICAgICAgKy0tcncgbWFudWZhY3R1cmVyPyAgICAgICAgaW5ldDpob3N0DQogICAgICAgKy0t
cncgc2FtZS1tYW51ZmFjdHVyZXI/ICAgZW1wdHkNCiAgICAgICArLS1ydyBtb2RlbD8gICAgICAg
ICAgICAgICBpbmV0OnVyaQ0KICAgICAgICstLXJ3IGxvY2FsLW5ldHdvcmtzPyAgICAgIGVtcHR5
DQogICAgICAgKy0tcncgY29udHJvbGxlcj8gICAgICAgICAgaW5ldDp1cmkNCiAgICAgICArLS1y
dyBteS1jb250cm9sbGVyPyAgICAgICBlbXB0eQ0KDQpJdCB3b3VsZCBiZSBwb3NzaWJsZSB0bywg
Zm9yIGV4YW1wbGU6DQoNCg0KICAqICAgTWFrZSB0aGUgbXVkLWFjbCBjb250YWluZXIganVzdCBj
b250YWluIGEgY2hvaWNlIG9mIGFsbCA2IGVsZW1lbnRzLiBBdCB0aGF0IHBvaW50LCB5b3Ugd291
bGQgb25seSBiZSBzcGVjaWZ5aW5nIG9uZSBvZiB0aGVtLg0KICAqICAgSWYgbm90IGFsbCB0aGUg
ZWxlbWVudHMgYXJlIG11dHVhbGx5IGV4Y2x1c2l2ZSwgeW91IGNvdWxkIGhhdmUgc3BlY2lmaWMg
Y29uc3RyYWludHMgdGhhdCBzYXkg4oCcd2hlbiBjb250cm9sbGVyIGlzIHByZXNlbnQsIG15LWNv
bnRyb2xsZXIgY2Fubm90IGJlIHByZXNlbnTigJ0gYW5kIHZpY2UtdmVyc2EuIFRoaXMgd291bGQg
bWFrZSBzcGVjaWZ5aW5nIGJvdGggZWxlbWVudHMgaWxsZWdhbCBwZXIgdGhlIGNvbnN0cmFpbnRz
Lg0KDQpFYWNoIGFwcHJvdmUgd291bGQgaW5mb3JtIHRoZSBjbGllbnQgYW5kIHNlcnZlciB3aGF0
IGlzIOKAnHZhbGlk4oCdLiBUaGUgZmlyc3QgYXBwcm9hY2ggd291bGQgZWZmZWN0aXZlbHkgZm9y
Y2UgbXVsdGlwbGUg4oCcYWNjZXNzIGNvbnRyb2wgZW50cmllc+KAnSwgbWVhbmluZyBvbmUgZm9y
IGVhY2ggY29uZGl0aW9uIHlvdSB3YW50ZWQgdG8gdGVzdC4NCg0KQ2hlZXJzLA0KDQpFaW5hcg0K
DQpPbiAyNSBPY3QgMjAxNywgYXQgMTg6MTEsIE0uIFJhbmdhbmF0aGFuIDxtcmFuZ2FAZ21haWwu
Y29tPG1haWx0bzptcmFuZ2FAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KDQpPbiBXZWQsIE9jdCAy
NSwgMjAxNyBhdCAxMjo0NSBQTSwgRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxl
YXJAY2lzY28uY29tPj4gd3JvdGU6DQpTdXJlLiAgU2VjdGlvbiAyLjE6DQoNCj4gICAgQSB2YWxp
ZCBNVUQgZmlsZSB3aWxsIGNvbnRhaW4gdHdvIHJvb3Qgb2JqZWN0cywgYSAibXVkIiBjb250YWlu
ZXIgYW5kDQo+ICAgIGFuICJhY2Nlc3MtbGlzdHMiIGNvbnRhaW5lci4gIEV4dGVuc2lvbnMgbWF5
IGFkZCBhZGRpdGlvbmFsIHJvb3QNCj4gICAgb2JqZWN0cyBhcyByZXF1aXJlZC4gIEFzIGEgcmVt
aW5kZXIsIHdoZW4gcGFyc2luZyBhY2Nlc3MtbGlzdHMsDQo+ICAgIGVsZW1lbnRzIHdpdGhpbiBh
ICJtYXRjaCIgYmxvY2sgYXJlIGxvZ2ljYWxseSBBTkRlZC4gIEluIGdlbmVyYWwsIGENCj4gICAg
c2luZ2xlIGFic3RyYWN0aW9uIGluIGEgbWF0Y2ggc3RhdGVtZW50IHNob3VsZCBiZSB1c2VkLiAg
Rm9yDQo+ICAgIGluc3RhbmNlLCBpdCBtYWtlcyBsaXR0bGUgc2Vuc2UgdG8gbWF0Y2ggYm90aCAi
bXktY29udHJvbGxlciIgYW5kDQo+ICAgICJjb250cm9sbGVyIiB3aXRoIGFuIGFyZ3VtZW50LCBz
aW5jZSB0aGV5IGFyZSBoaWdobHkgdW5saWtlbHkgdG8gYmUNCj4gICAgdGhlIHNhbWUgdmFsdWUu
DQoNCg0KU2luY2UgdGhlc2UgYXJlIHNldHMsIEkgdGhpbmsgYSBiZXR0ZXIgc3RhdGVtZW50IGNv
dWxkIGJlOg0KDQoiYW4gaW50ZXJzZWN0aW9uIGlzIGNvbXB1dGVkIGJldHdlZW4gZWxlbWVudHMg
d2l0aGluIGEgbWF0Y2ggYmxvY2siIChyYXRoZXIgdGhhbiBBTkRlZCkuDQoNCklmIHBvc3NpYmxl
IGl0IHdvdWxkIGJlIG5pY2UgdG8gaW1wb3NlIGEgcmVzdHJpY3Rpb24gb24gc2luZ2xlIGFic3Ry
YWN0aW9uIGluIGEgbWF0Y2ggc3RhdGVtZW50IChJIHNlZSBubyBiZW5lZml0IGluIGFsbG93aW5n
IG1vcmUgdGhhbiBvbmUgZWxlbWVudCkuIEhvd2V2ZXIsIEkgZG8gbm90IGtub3cgaWYgaXQgaXMg
cG9zc2libGUgdG8gZW5mb3JjZSBzdWNoIGEgcmVzdHJpY3Rpb24gdmlhIFlBTkcuDQoNClJhbmdh
DQoNCg0KDQoNCg0KDQoNCi0tDQpNLiBSYW5nYW5hdGhhbg0KDQo=

--_000_A218904875AE42DFA25652322C00EE2Aciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <73DDE048F38F33438F493C8FF110D6BB@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClJhbmdhLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+TG9va2luZyBhdCB0aGlzOjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs
YXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyBhdWdtZW50IC9hY2w6
YWNjZXNzLWxpc3RzL2FjbDphY2wvYWNsOmFjZXMvYWNsOmFjZS9hY2w6bWF0Y2hlczo8L2ZvbnQ+
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNw
OyAmbmJzcDsgJiM0MzstLXJ3IG11ZC1hY2w8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm
b250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj
NDM7LS1ydyBtYW51ZmFjdHVyZXI/ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luZXQ6aG9z
dDwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllciIgY2xhc3M9
IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLXJ3IHNhbWUtbWFudWZhY3R1cmVy
PyAmbmJzcDsgZW1wdHk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNv
dXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBtb2Rl
bD8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluZXQ6
dXJpPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFz
cz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tcncgbG9jYWwtbmV0d29ya3M/
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZW1wdHk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxm
b250IGZhY2U9IkNvdXJpZXIiIGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj
NDM7LS1ydyBjb250cm9sbGVyPyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW5l
dDp1cmk8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXIiIGNs
YXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS1ydyBteS1jb250cm9sbGVy
PyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbXB0eTwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXQgd291bGQgYmUg
cG9zc2libGUgdG8sIGZvciBleGFtcGxlOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXY+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIGNsYXNzPSJNYWlsT3V0bGluZSI+DQo8bGkg
Y2xhc3M9IiI+TWFrZSB0aGUgbXVkLWFjbCBjb250YWluZXIganVzdCBjb250YWluIGEgY2hvaWNl
IG9mIGFsbCA2IGVsZW1lbnRzLiBBdCB0aGF0IHBvaW50LCB5b3Ugd291bGQgb25seSBiZSBzcGVj
aWZ5aW5nIG9uZSBvZiB0aGVtLjwvbGk+PGxpIGNsYXNzPSIiPklmIG5vdCBhbGwgdGhlIGVsZW1l
bnRzIGFyZSBtdXR1YWxseSBleGNsdXNpdmUsIHlvdSBjb3VsZCBoYXZlIHNwZWNpZmljIGNvbnN0
cmFpbnRzIHRoYXQgc2F5IOKAnHdoZW4gY29udHJvbGxlciBpcyBwcmVzZW50LCBteS1jb250cm9s
bGVyIGNhbm5vdCBiZSBwcmVzZW504oCdIGFuZCB2aWNlLXZlcnNhLiBUaGlzIHdvdWxkIG1ha2Ug
c3BlY2lmeWluZyBib3RoIGVsZW1lbnRzIGlsbGVnYWwgcGVyIHRoZSBjb25zdHJhaW50cy48L2xp
PjwvdWw+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij5FYWNoIGFwcHJvdmUgd291bGQgaW5mb3JtIHRoZSBjbGllbnQgYW5kIHNlcnZlciB3aGF0IGlz
IOKAnHZhbGlk4oCdLiBUaGUgZmlyc3QgYXBwcm9hY2ggd291bGQgZWZmZWN0aXZlbHkgZm9yY2Ug
bXVsdGlwbGUg4oCcYWNjZXNzIGNvbnRyb2wgZW50cmllc+KAnSwgbWVhbmluZyBvbmUgZm9yIGVh
Y2ggY29uZGl0aW9uIHlvdSB3YW50ZWQgdG8gdGVzdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5DaGVlcnMs
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij5FaW5hcjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2
IGNsYXNzPSIiPk9uIDI1IE9jdCAyMDE3LCBhdCAxODoxMSwgTS4gUmFuZ2FuYXRoYW4gJmx0Ozxh
IGhyZWY9Im1haWx0bzptcmFuZ2FAZ21haWwuY29tIiBjbGFzcz0iIj5tcmFuZ2FAZ21haWwuY29t
PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp
bmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0i
Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJn
bWFpbF9xdW90ZSI+T24gV2VkLCBPY3QgMjUsIDIwMTcgYXQgMTI6NDUgUE0sIEVsaW90IExlYXIg
PHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2Nv
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmxlYXJAY2lzY28uY29tPC9hPiZndDs8L3Nw
YW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg
c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRp
bmctbGVmdDoxZXgiPg0KU3VyZS4mbmJzcDsgU2VjdGlvbiAyLjE6PGJyIGNsYXNzPSIiPg0KPGJy
IGNsYXNzPSIiPg0KJmd0OyAmbmJzcDsmbmJzcDsgQSB2YWxpZCBNVUQgZmlsZSB3aWxsIGNvbnRh
aW4gdHdvIHJvb3Qgb2JqZWN0cywgYSAmcXVvdDttdWQmcXVvdDsgY29udGFpbmVyIGFuZDxiciBj
bGFzcz0iIj4NCiZndDsgJm5ic3A7Jm5ic3A7IGFuICZxdW90O2FjY2Vzcy1saXN0cyZxdW90OyBj
b250YWluZXIuJm5ic3A7IEV4dGVuc2lvbnMgbWF5IGFkZCBhZGRpdGlvbmFsIHJvb3Q8YnIgY2xh
c3M9IiI+DQomZ3Q7ICZuYnNwOyZuYnNwOyBvYmplY3RzIGFzIHJlcXVpcmVkLiZuYnNwOyBBcyBh
IHJlbWluZGVyLCB3aGVuIHBhcnNpbmcgYWNjZXNzLWxpc3RzLDxiciBjbGFzcz0iIj4NCiZndDsg
Jm5ic3A7Jm5ic3A7IGVsZW1lbnRzIHdpdGhpbiBhICZxdW90O21hdGNoJnF1b3Q7IGJsb2NrIGFy
ZSBsb2dpY2FsbHkgQU5EZWQuJm5ic3A7IEluIGdlbmVyYWwsIGE8YnIgY2xhc3M9IiI+DQomZ3Q7
ICZuYnNwOyZuYnNwOyBzaW5nbGUgYWJzdHJhY3Rpb24gaW4gYSBtYXRjaCBzdGF0ZW1lbnQgc2hv
dWxkIGJlIHVzZWQuJm5ic3A7IEZvcjxiciBjbGFzcz0iIj4NCiZndDsgJm5ic3A7Jm5ic3A7IGlu
c3RhbmNlLCBpdCBtYWtlcyBsaXR0bGUgc2Vuc2UgdG8gbWF0Y2ggYm90aCAmcXVvdDtteS1jb250
cm9sbGVyJnF1b3Q7IGFuZDxiciBjbGFzcz0iIj4NCiZndDsgJm5ic3A7Jm5ic3A7ICZxdW90O2Nv
bnRyb2xsZXImcXVvdDsgd2l0aCBhbiBhcmd1bWVudCwgc2luY2UgdGhleSBhcmUgaGlnaGx5IHVu
bGlrZWx5IHRvIGJlPGJyIGNsYXNzPSIiPg0KJmd0OyAmbmJzcDsmbmJzcDsgdGhlIHNhbWUgdmFs
dWUuPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iSE9FblpiIj4NCjxkaXYgY2xhc3M9Img1Ij48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0i
Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2luY2UgdGhlc2UgYXJlIHNl
dHMsIEkgdGhpbmsgYSBiZXR0ZXIgc3RhdGVtZW50IGNvdWxkIGJlOiA8YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+JnF1b3Q7YW4gaW50ZXJzZWN0aW9u
IGlzIGNvbXB1dGVkIGJldHdlZW4gZWxlbWVudHMgd2l0aGluIGEgbWF0Y2ggYmxvY2smcXVvdDsg
KHJhdGhlciB0aGFuIEFORGVkKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+SWYgcG9zc2libGUgaXQgd291bGQgYmUgbmljZSB0byBpbXBvc2UgYSBy
ZXN0cmljdGlvbiBvbiBzaW5nbGUgYWJzdHJhY3Rpb24gaW4gYSBtYXRjaCBzdGF0ZW1lbnQgKEkg
c2VlIG5vIGJlbmVmaXQgaW4gYWxsb3dpbmcgbW9yZSB0aGFuIG9uZSBlbGVtZW50KS4gSG93ZXZl
ciwgSSBkbyBub3Qga25vdyBpZiBpdCBpcyBwb3NzaWJsZSB0byBlbmZvcmNlIHN1Y2ggYSByZXN0
cmljdGlvbiB2aWEgWUFORy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk
aXYgY2xhc3M9IiI+UmFuZ2E8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KJm5ic3A7PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFz
cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHgg
I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8ZGl2
IGNsYXNzPSJoNSI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsZWFyPSJhbGwiIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21h
aWxfc2lnbmF0dXJlIiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIj5NLiBSYW5nYW5h
dGhhbjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N
Cg==

--_000_A218904875AE42DFA25652322C00EE2Aciscocom_--


From nobody Wed Oct 25 12:53:58 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 3AF6E13954E for ; Wed, 25 Oct 2017 12:53:48 -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 4TmhlaE5J3sU for ; Wed, 25 Oct 2017 12:53:46 -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 E1F30138AEE for ; Wed, 25 Oct 2017 12:53:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13546; q=dns/txt; s=iport; t=1508961226; x=1510170826; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=mpqwwziR1aJuDs0/hBVV6umN/ZyJQKhQsK0ghM3T2vg=; b=UyZpGM4XRZp9WPB6AB4RSD3wWEWdChxsiwQ0+k5SiIyLPeqQT6UXCZ9M XQwmpcY2sqV2S5S4DZFUtinAiNZDbQhq+gSsgNb3gpFGYF/CUQEZhg7cL mHbf0DGL9iyT1E5TJv1/kck23oBm5BG+saFPT60I6WaXbq5gPXWEwPDYP I=;
X-Files: signature.asc : 481
X-IronPort-AV: E=Sophos;i="5.43,433,1503360000";  d="asc'?scan'208,217";a="656581141"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2017 19:53:44 +0000
Received: from [10.61.74.219] (ams3-vpn-dhcp2779.cisco.com [10.61.74.219]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9PJrhxn004846; Wed, 25 Oct 2017 19:53:43 GMT
To: "Einar Nilsen-Nygaard (einarnn)" , "M. Ranganathan" 
Cc: "opsawg@ietf.org" 
References:  <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com> <20171025143016.le7le5gxoqpalhvc@elstar.local>  <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com> <20171025155700.c3av5tp7hxc76krn@elstar.local> <2968c7d4-d973-1119-2f63-e9445d943667@cisco.com>  
From: Eliot Lear 
Message-ID: 
Date: Wed, 25 Oct 2017 21:53:43 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rriqrxaHi8iLWVgrhgksP6Nr8EufAcUKc"
Archived-At: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
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, 25 Oct 2017 19:53:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--rriqrxaHi8iLWVgrhgksP6Nr8EufAcUKc
Content-Type: multipart/mixed; boundary="qjw5WM2HVDQ3luarmP5UQCsT0FjghiOk3";
 protected-headers="v1"
From: Eliot Lear 
To: "Einar Nilsen-Nygaard (einarnn)" ,
 "M. Ranganathan" 
Cc: "opsawg@ietf.org" 
Message-ID: 
Subject: Re: [OPSAWG] MUD : ietf-acldns YANG model question.
References: 
 <8C15B4F7-8596-40D7-9A1C-4253ED114FEF@cisco.com>
 <20171025143016.le7le5gxoqpalhvc@elstar.local>
 
 <5c4b244e-9c98-9629-80a4-5be3c8391b31@cisco.com>
 <20171025155700.c3av5tp7hxc76krn@elstar.local>
 <2968c7d4-d973-1119-2f63-e9445d943667@cisco.com>
 
 
In-Reply-To: 

--qjw5WM2HVDQ3luarmP5UQCsT0FjghiOk3
Content-Type: multipart/alternative;
 boundary="------------070F9FCE1725ED0A369394EF"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------070F9FCE1725ED0A369394EF
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I'd be ok with doing a choice.

Eliot


On 10/25/17 8:41 PM, Einar Nilsen-Nygaard (einarnn) wrote:
> Ranga,
>
> Looking at this:
>
> =C2=A0 augment /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches:
> =C2=A0 =C2=A0 +--rw mud-acl
> =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw manufacturer? =C2=A0 =C2=A0 =C2=A0 =C2=
=A0inet:host
> =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw same-manufacturer? =C2=A0 empty
> =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw model? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 inet:uri
> =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw local-networks? =C2=A0 =C2=A0 =C2=A0em=
pty
> =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw controller? =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0inet:uri
> =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw my-controller? =C2=A0 =C2=A0 =C2=A0 em=
pty
>
> It would be possible to, for example:
>
>   * Make the mud-acl container just contain a choice of all 6
>     elements. At that point, you would only be specifying one of them.
>   * If not all the elements are mutually exclusive, you could have
>     specific constraints that say =E2=80=9Cwhen controller is present,
>     my-controller cannot be present=E2=80=9D and vice-versa. This would=
 make
>     specifying both elements illegal per the constraints.
>
>
> Each approve would inform the client and server what is =E2=80=9Cvalid=E2=
=80=9D. The
> first approach would effectively force multiple =E2=80=9Caccess control=

> entries=E2=80=9D, meaning one for each condition you wanted to test.
>
> Cheers,
>
> Einar
>
>> On 25 Oct 2017, at 18:11, M. Ranganathan > > wrote:
>>
>>
>>
>> On Wed, Oct 25, 2017 at 12:45 PM, Eliot Lear > > wrote:
>>
>>     Sure.=C2=A0 Section 2.1:
>>
>>     > =C2=A0=C2=A0 A valid MUD file will contain two root objects, a "=
mud"
>>     container and
>>     > =C2=A0=C2=A0 an "access-lists" container.=C2=A0 Extensions may a=
dd additional root
>>     > =C2=A0=C2=A0 objects as required.=C2=A0 As a reminder, when pars=
ing access-lists,
>>     > =C2=A0=C2=A0 elements within a "match" block are logically ANDed=
=2E=C2=A0 In
>>     general, a
>>     > =C2=A0=C2=A0 single abstraction in a match statement should be u=
sed.=C2=A0 For
>>     > =C2=A0=C2=A0 instance, it makes little sense to match both
>>     "my-controller" and
>>     > =C2=A0=C2=A0 "controller" with an argument, since they are highl=
y
>>     unlikely to be
>>     > =C2=A0=C2=A0 the same value.
>>
>>
>> Since these are sets, I think a better statement could be:
>>
>> "an intersection is computed between elements within a match block"
>> (rather than ANDed).
>>
>> If possible it would be nice to impose a restriction on single
>> abstraction in a match statement (I see no benefit in allowing more
>> than one element). However, I do not know if it is possible to
>> enforce such a restriction via YANG.
>>
>> Ranga
>>
>> =C2=A0
>>
>>
>>
>>
>>
>>
>> --=20
>> M. Ranganathan
>


--------------070F9FCE1725ED0A369394EF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
I'd be ok with doing a choice.

    
Eliot

    

    

    
On 10/25/17 8:41 PM, Einar
      Nilsen-Nygaard (einarnn) wrote:

    

    

      
      Ranga,
      


      

      
Looking at this:

      


      

      

        
=C2=A0 augment
            /acl:access-lists/acl:acl/acl:aces/acl:ace/acl:matches:

        
=C2=A0 =C2=A0 +=
--rw mud-acl

        
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0+--rw
            manufacturer? =C2=A0 =C2=A0 =C2=A0 =C2=A0inet:host
        
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0+--rw
            same-manufacturer? =C2=A0 empty

        
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0+--rw model?
            =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:uri

        
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0+--rw
            local-networks? =C2=A0 =C2=A0 =C2=A0empty

        
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0+--rw
            controller? =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inet:uri=


        
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0+--rw
            my-controller? =C2=A0 =C2=A0 =C2=A0 empty

      

      


      

      
It would be possible to, for example:

      

        


        

        

          
    
            
  • Make the mud-acl container just contain a
              choice of all 6 elements. At that point, you would only be
              specifying one of them.
    • 
            
  • If not all the elements are mutually exclusive=
,
              you could have specific constraints that say =E2=80=9Cwhen
              controller is present, my-controller cannot be present=E2=80=
=9D
              and vice-versa. This would make specifying both elements
              illegal per the constraints.
    • 
          

          


          

          
Each approve would inform the client and server=

            what is =E2=80=9Cvalid=E2=80=9D. The first approach would eff=
ectively force
            multiple =E2=80=9Caccess control entries=E2=80=9D, meaning on=
e for each
            condition you wanted to test.

          


          

          

            
Cheers,

            


            

            
Einar

          

          


          

        

        

          

            
On 25 Oct 2017, at 18:11, M. Ranganathan <=
mranga@gmail.com> wrote:<=
/div>
            

            

              


                


                  
On Wed, Oct 25, 2017 at 12:4=
5
                    PM, Eliot Lear 
                      <lear@cisco.com>
                    wrote:

                    

                      Sure.=C2=A0 Section 2.1:

                      

                      > =C2=A0=C2=A0 A valid MUD file will contain two=
 root
                      objects, a "mud" container and

                      > =C2=A0=C2=A0 an "access-lists" container.=C2=A0=
 Extensions
                      may add additional root

                      > =C2=A0=C2=A0 objects as required.=C2=A0 As a r=
eminder, when
                      parsing access-lists,

                      > =C2=A0=C2=A0 elements within a "match" block a=
re
                      logically ANDed.=C2=A0 In general, a
=

                      > =C2=A0=C2=A0 single abstraction in a match sta=
tement
                      should be used.=C2=A0 For

                      > =C2=A0=C2=A0 instance, it makes little sense t=
o match
                      both "my-controller" and

                      > =C2=A0=C2=A0 "controller" with an argument, si=
nce they
                      are highly unlikely to be

                      > =C2=A0=C2=A0 the same value.

                      

                        


                        

                      

                    

                    


                    

                    
Since these are sets, I think a bette=
r
                      statement could be: 

                      

                    

                    
"an intersection is computed between
                      elements within a match block" (rather than
                      ANDed).

                      

                    

                    
If possible it would be nice to impos=
e
                      a restriction on single abstraction in a match
                      statement (I see no benefit in allowing more than
                      one element). However, I do not know if it is
                      possible to enforce such a restriction via YANG.
                      

                    

                    
Ranga

                    

                    


                      =C2=A0

                    

                    

                      

                        


                          

                        

                      

                    

                  

                  

                  

                  

                  -- 

                  
M. Ranganathan

                  

                

              

            

          

        

        

      

    

    

  


--------------070F9FCE1725ED0A369394EF--

--qjw5WM2HVDQ3luarmP5UQCsT0FjghiOk3--

--rriqrxaHi8iLWVgrhgksP6Nr8EufAcUKc
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

iQEcBAEBCAAGBQJZ8OvIAAoJEIe2a0bZ0noz7+kH/3ls48ot+ox/HYW3fuEP0cyA
00l+gA6KM8pJ3oaDAJaGa+2NdqhjP1E5dc4vzZGoowyEWuYeEMo0qU0nOLRxREU9
FCmlsYl35jjuuG17IjOWdbcKmD6iWk3BMEWrT+mT48LsO2svjIopVoHVo7B+VayI
RmQcLFHva19fESX5nf/7mgLwdnZtAEWI2+4UPjkhBWPmkfVCaH0yTaLSbl1ZG13V
CFEmXdK5C7RsFh1sX3WVbeCrLHQSSr7+l8y2Njm5X0ZloP5LJQjiO/JVVGA8LmQ6
DXv9mHPH5uDNcEXg53JuOnmuoa7g/Cp6z6MUPiKPLzwZpzY7Ne4MHbfMdT/vH8A=
=09z/
-----END PGP SIGNATURE-----

--rriqrxaHi8iLWVgrhgksP6Nr8EufAcUKc--


From nobody Thu Oct 26 10:12: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 3F20613F5CC for ; Thu, 26 Oct 2017 10:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level: 
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Hzi3mUHTBZaz for ; Thu, 26 Oct 2017 10:12:50 -0700 (PDT)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 E886713F5CB for ; Thu, 26 Oct 2017 10:12:49 -0700 (PDT)
Received: by mail-wr0-x235.google.com with SMTP id w105so3900611wrc.0 for ; Thu, 26 Oct 2017 10:12:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=H4B2CVa+FK1D90ERaDVsy+weM+vqHayHAqA1ASVxAiw=; b=bcClOQ2Z47VY9Z20OTeEUGsIvlSHGmlDfndoyq4kbIxWnz0XUU6idSuxa9R38NfiWZ k9gOQyN8fQCZthk/rLiSlENWJM54lqsUx7ljbiyAhrNZLNHvvSp2wupVmJWhtxJQNx/l BBp0ZqOK8YbKb5Hxtt0tm4U1eMpucE+zduhiXPlLM30oFTXsyjedWQnPrPkMs69j0Tkg eXGbatwd5trxnUKVWbmlyODspKsGdguxfv5YXrXTZ1N62/9IP/aBXXxrl6IkaqnzzVgc TWUdjgctR5misMuvXzPg2BGku9JBJmAvxWmHFtIWNIwg+m2HzIIcZhz/6enp4uOwNzX5 7D/Q==
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=H4B2CVa+FK1D90ERaDVsy+weM+vqHayHAqA1ASVxAiw=; b=KlHMKvzs39Y3mK8bH3j31JYt95EyNOQM/vVwKxeSFfwQbPtGTkVjJoSDHZJ2vUlz+T LGIMMCyfnGCka3JHJP7PxM4iRrpwOKup80M6BZnJZBNuYhwuJJ/dPbERfpHVHjhnUrpt RUahtYnF+Awg3RUwq1t6Lyfdwz7JCL6IdxEfDvTOCFfU55e5OYp9ETKXfMLbFIAqAcu8 Pb9KmyF4FcFoTCQXNjPUBW4dcfhu3NTbu2fkqDAQ+6CSWzhOhq2YT7kSIauDPjHm56we CstVh6gCqudFc8wwNkd/zdKhNPyzWFAOFM4YUK6pSFfDIycZuCUon0rhAddcQDLaJzz2 gZdw==
X-Gm-Message-State: AMCzsaVQmIBDAlapRxoVcLdTfAiUAjCzjP41btYi4xkZQCBWyy63ExL3 lJ63k8+PArXLnvu0A1fZ/PR2W2cvvnzVoj1e0Bxvww==
X-Google-Smtp-Source: ABhQp+RRxByi8IUmFOXG+8NlWwh7mTN9zqLy5bLTrLCtjz/abrWyKxgdT3c4jj8PwW3soIJ2PP0dHZjmMSAz+vn7v2U=
X-Received: by 10.223.148.38 with SMTP id 35mr6383610wrq.49.1509037967883; Thu, 26 Oct 2017 10:12:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Thu, 26 Oct 2017 10:12:07 -0700 (PDT)
From: "M. Ranganathan" 
Date: Thu, 26 Oct 2017 13:12:07 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a114cb40807459c055c76482f"
Archived-At: 
Subject: [OPSAWG] MUD draft 13 nit : Scope of ACL Name
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, 26 Oct 2017 17:12:51 -0000

--001a114cb40807459c055c76482f
Content-Type: text/plain; charset="UTF-8"

         leaf acl-name {
             type leafref {
               path "/acl:access-lists/acl:acl/acl:acl-name";
             }
             description
               "The name of the ACL for this entry.";
           }
           leaf acl-type {
             type identityref {
               base acl:acl-base;
             }
             description
               "The type of the ACL for this entry.  The name is
                scoped ONLY to the MUD file, and may not be unique
                in any other circumstance.";
           }






This is a nit (perhaps has already been reported):

Does the description comment on scope belong with the acl-name node?

Thanks

-- 
M. Ranganathan

--001a114cb40807459c055c76482f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


         leaf acl-name {
             type leafref {
               path "/acl:access-lists/acl:acl/acl:acl-name";
             }
             description
               "The name of the ACL for this entry.";
           }
           leaf acl-type {
             type identityref {
               base acl:acl-base;
             }
             description
               "The type of the ACL for this entry.  The name is
                scoped ONLY to the MUD file, and may not be unique
                in any other circumstance.";
           }





This is a nit (=
perhaps has already been reported):

Does the description =
comment on scope belong with the acl-name node?

Thanks

-- 
M. Ranganatha=
n




--001a114cb40807459c055c76482f--


From nobody Thu Oct 26 10:14:51 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 353BA13EF48 for ; Thu, 26 Oct 2017 10:14:50 -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 NkCMsAao_LBD for ; Thu, 26 Oct 2017 10:14:48 -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 53E37139059 for ; Thu, 26 Oct 2017 10:14:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5524; q=dns/txt; s=iport; t=1509038088; x=1510247688; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=FERbaeQI6wDBpKQF9vJ/Tdgg2HLOMfDwhen1ndZ7B94=; b=I9vsbGlYSf0E2PFRO+dqdEH0yuqqd7f60jhVi+8YhhbDCgx4VqkqruI5 jREHqZlcUEhqcqYc/u6sv5RLCYaKyCMev6dtOYTSwz4b5mD2o5L2y+x+B YXgmWWboVcVZFRUexHd4d2kXF1bS/KwcyPr+Hhl+vT8J402xmMaKw66he 4=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAAC6F/JZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N6ih90kBeQfIVEghEHAxgBCoRJTwKFABgBAgEBAQEBAQF?= =?us-ascii?q?rKIUeAQEBAwEBIUsbCwQUKgICJzAGAQwGAgEBihwQqTaCJyaKTAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQ4KBYMuhWmDAYgZgmEFkVeQJIRBgiOOFYtyhzmWCoE5Hzi?= =?us-ascii?q?BaDQhCB0VSYJkhGE/NoxGAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,301,1505779200";  d="asc'?scan'208,217";a="698264848"
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; 26 Oct 2017 17:14:46 +0000
Received: from [10.61.96.63] (dhcp-10-61-96-63.cisco.com [10.61.96.63]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9QHEjpo015725; Thu, 26 Oct 2017 17:14:46 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References: 
From: Eliot Lear 
Message-ID: <6e4b760c-3a32-674c-de40-3481bf7ca2d7@cisco.com>
Date: Thu, 26 Oct 2017 19:14:38 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1GsbOL4vCfIRQfPLpGQkvJ07umKuxD9I6"
Archived-At: 
Subject: Re: [OPSAWG] MUD draft 13 nit : Scope of ACL Name
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, 26 Oct 2017 17:14:50 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1GsbOL4vCfIRQfPLpGQkvJ07umKuxD9I6
Content-Type: multipart/mixed; boundary="nHrBPEfKbN2JwKDwDmQmpVrAORrWVWKwH";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" , opsawg@ietf.org
Message-ID: <6e4b760c-3a32-674c-de40-3481bf7ca2d7@cisco.com>
Subject: Re: [OPSAWG] MUD draft 13 nit : Scope of ACL Name
References: 
In-Reply-To: 

--nHrBPEfKbN2JwKDwDmQmpVrAORrWVWKwH
Content-Type: multipart/alternative;
 boundary="------------74F147B2772A16D1A1F877F8"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------74F147B2772A16D1A1F877F8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

The acl name comes directly from draft-ietf-netmod-acl.=C2=A0 However, if=
 it
is not clear, the scope is intended to be solely within a MUD file
itself.=C2=A0 I can add words to that effect as part of LC if nobody obje=
cts.

Eliot


On 10/26/17 7:12 PM, M. Ranganathan wrote:
>          leaf acl-name {
>              type leafref {
>                path "/acl:access-lists/acl:acl/acl:acl-name";
>              }
>              description
>                "The name of the ACL for this entry.";
>            }
>            leaf acl-type {
>              type identityref {
>                base acl:acl-base;
>              }
>              description
>                "The type of the ACL for this entry.  The name is
>                 scoped ONLY to the MUD file, and may not be unique
>                 in any other circumstance.";
>            }
>
>
>
>
>
> This is a nit (perhaps has already been reported):
>
> Does the description comment on scope belong with the acl-name node?
>
> Thanks
>
> --=20
> M. Ranganathan
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


--------------74F147B2772A16D1A1F877F8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
The acl name comes directly from draft-ietf-netmod-acl.=C2=A0 Howe=
ver,
      if it is not clear, the scope is intended to be solely within a
      MUD file itself.=C2=A0 I can add words to that effect as part of LC=
 if
      nobody objects.

    
Eliot

    

    

    
On 10/26/17 7:12 PM, M. Ranganathan
      wrote:

    

    

      
      

        

          
         leaf acl-name {
             type leafref {
               path "/acl:access-lists/acl:acl/acl:acl-name";
             }
             description
               "The name of the ACL for this entry.";
           }
           leaf acl-type {
             type identityref {
               base acl:acl-base;
             }
             description
               "The type of the ACL for this entry.  The name is
                scoped ONLY to the MUD file, and may not be unique
                in any other circumstance.";
           }

          

          

          

          

        

        


        

        
This is a nit (perhaps has already been reported):

          

        

        
Does the description comment on scope belong with the
          acl-name node?

          

        

        Thanks

        

          


            -- 

            
M. Ranganathan

            

          

        

      

      

      

      

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


    

    

  


--------------74F147B2772A16D1A1F877F8--

--nHrBPEfKbN2JwKDwDmQmpVrAORrWVWKwH--

--1GsbOL4vCfIRQfPLpGQkvJ07umKuxD9I6
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

iQEcBAEBCAAGBQJZ8hf/AAoJEIe2a0bZ0noz1QMH/2KAsIcOy6wp2xcC8wVpFruF
iKDTgfBHX3Y1J6iozSct+8KgGgAKNdmSJKyPZyiDCeIwHVOF4nZWXsMwbvfkluzl
O4Yd+DR99kUASrzIbCdBmKz0N2Y8s7c1JLHbO3nNCwtnu/ljThhOA4pX745nC0E/
2K9yDFOxpu+cwrIjwubBJV8S2cunsk1MvwTPYFQ0nXkISBnYE3uX0pq+5USFm7Qy
QrKOOV/uLQwv9ozqLGhZMuC58ounr7++YLmyir1M7yhSi8X3i4EuuThHsAu9AO19
V0i0Wgr779AdlBEHQkf2ANuF8Olj2oEOliIaSkNngMIdb7eKD1if7KRPEUQQxCU=
=gEGp
-----END PGP SIGNATURE-----

--1GsbOL4vCfIRQfPLpGQkvJ07umKuxD9I6--


From nobody Thu Oct 26 10:26:51 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 5555613F3C0 for ; Thu, 26 Oct 2017 10:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 AKG7nnxeGdD7 for ; Thu, 26 Oct 2017 10:26:47 -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 1006213D179 for ; Thu, 26 Oct 2017 10:26:47 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id p96so3895236wrb.7 for ; Thu, 26 Oct 2017 10:26:46 -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=8HFwN0w4dHa8S7vIXwQlPPSAZ89eJ5U2uYDHzWnUSwc=; b=hekoaRQRTf9rVHqENkXaxK0AGbz/aIePdbTVWymEkelpIUPrZPR/yLHknh9Wddrhge mjKzUb3KoO+PZFjHyQ4Ymoe6huD/3XBLYRfWVZX8tCMYcntWxzjrI+/nOXGbbpXfkSfi exGbvCswxtKJyrHvScieqXd/M2JmiMnGLBR/OkmC2V+aXRi2GVRParOwmXDUOgfxpvBO jqE5wSvTMY+t0mRhiTWqCsYF2FVbpQKs2atA0AVBk065hPGGp5x+wVa3rKj4CPDfcQI4 zYo/3q91rYnGhe+0TBNtUwnsDf1MOaYptefS4P2jsQJe1e0OCDNJFK5IwK5mhFjA/wgj prDg==
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=8HFwN0w4dHa8S7vIXwQlPPSAZ89eJ5U2uYDHzWnUSwc=; b=TtZaukGL99+sk8v+5xeA4OsTKhZ8uPG0575Hb3fcIeQFQmwbsofdRTA/YhNwVwwAPh DQv9YQKPlCGqBW1KkfUW46QEpCamNx8aOsdKhIvSSrhh2+ZFeVltJtXvpHcVCT0+JQHj 5iv1aAlOKQppyOgn5UqvFw5ngGd3aLagmiiYex8DK5JGUKamIHS8mjm21K9dBj27tJx2 syiSRuazUDB63fQX6sYpPyWAATasnlM6TRSLSqDgEk8mI4ye5DHu98t+dYtwf4XJ/G91 ZjirQFcp4J6BFmVW5hiTAzF0G47h2njeiXdovIfHrrqIIYgbPBEQilstepVVG8hiIais FmMg==
X-Gm-Message-State: AMCzsaXhtih31pBq83qTdfdo0ee8xro5gdUzF1SqClFre1sT0o3LfcfU AwA4Rex2I/NjpMxKNX47V/1ObNg4bvzxgh0LCf4=
X-Google-Smtp-Source: ABhQp+SNFdJCv+ooQaB4o8wa5plkHgHZdMGFtewarBvBgIaKkXNG6VUC8/kFegLL2y16InA+Z06homVrxppi0MdfoXs=
X-Received: by 10.223.148.38 with SMTP id 35mr6418282wrq.49.1509038805517; Thu, 26 Oct 2017 10:26:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Thu, 26 Oct 2017 10:26:04 -0700 (PDT)
In-Reply-To: <6e4b760c-3a32-674c-de40-3481bf7ca2d7@cisco.com>
References:  <6e4b760c-3a32-674c-de40-3481bf7ca2d7@cisco.com>
From: "M. Ranganathan" 
Date: Thu, 26 Oct 2017 13:26:04 -0400
Message-ID: 
To: Eliot Lear 
Cc: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a114cb408f48a4d055c7679e4"
Archived-At: 
Subject: Re: [OPSAWG] MUD draft 13 nit : Scope of ACL Name
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, 26 Oct 2017 17:26:49 -0000

--001a114cb408f48a4d055c7679e4
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 26, 2017 at 1:14 PM, Eliot Lear  wrote:

> The acl name comes directly from draft-ietf-netmod-acl.  However, if it is
> not clear, the scope is intended to be solely within a MUD file itself.  I
> can add words to that effect as part of LC if nobody objects.
>
> Eliot
>


Hi Eliot:

I had mean to suggest the following change:



       leaf acl-name {
             type leafref {
               path "/acl:access-lists/acl:acl/acl:acl-name";
             }
             description
               "The name of the ACL for this entry.The name is
                scoped ONLY to the MUD file, and may not be unique
                in any other circumstance.";
            }
            leaf acl-type {
             type identityref {
               base acl:acl-base;
             }
             description
               "The type of the ACL for this entry.  ";
           }

However, I have a suggested change to the naming scheme :


I would like to suggest that an ACL name be directly derived from a a
MUD URL instead of scoping it this way (so that it can be specified
independently of the MUD file while achieving the scoping goal you had
in mind).

That would ease the pain of implementation.

Can you make this a requirement?

Thanks,

Ranga.


> On 10/26/17 7:12 PM, M. Ranganathan wrote:
>
>          leaf acl-name {
>              type leafref {
>                path "/acl:access-lists/acl:acl/acl:acl-name";
>              }
>              description
>                "The name of the ACL for this entry.";
>            }
>            leaf acl-type {
>              type identityref {
>                base acl:acl-base;
>              }
>              description
>                "The type of the ACL for this entry.  The name is
>                 scoped ONLY to the MUD file, and may not be unique
>                 in any other circumstance.";
>            }
>
>
>
>
>
>
> This is a nit (perhaps has already been reported):
>
> Does the description comment on scope belong with the acl-name node?
>
> Thanks
>
> --
> M. Ranganathan
>
>
> _______________________________________________
> OPSAWG mailing listOPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg
>
>
>


-- 
M. Ranganathan

--001a114cb408f48a4d055c7679e4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 26, 2017 at 1:14 PM, Eliot Lear <lear@cisco.com> wrote:

 =20
   =20
 =20
  

    
The acl name comes directly from draft-ietf-netmod-acl.=C2=A0 Howeve=
r,
      if it is not clear, the scope is intended to be solely within a
      MUD file itself.=C2=A0 I can add words to that effect as part of LC i=
f
      nobody objects.

    
Eliot


Hi Eliot:
I had mean to suggest the following change:

=C2=A0
       leaf acl-n=
ame {
             type leafref {
               path "/acl:access-lists/acl:acl/acl:acl-name"=
;
             }
             description
               "The name of the ACL for this entry.The name is
                scoped ONLY to the MUD file, and may not be unique
                in any other circumstance.";
            } 
    =
        leaf acl-type {
             type identityref {
               base acl:acl-base;
             }
             description
               "The type of the ACL for this entry.  ";
           }

However, I have a suggested change to the naming scheme :

I would like to suggest that an ACL name be directly derived from a a MUD =
URL instead of scoping it this way (so that it can be specified independent=
ly of the MUD file while achieving the scoping goal you had in mind).
That would =
ease the pain of implementation.

Can you make this a requirement?

Thanks,

=

Ranga.


    

    

    
On 10/26/17 7=
:12 PM, M. Ranganathan
      wrote:

    

    

     =20
      

        

          
         =
leaf acl-name {
             type leafref {
               path "/acl:access-lists/acl:acl/acl:acl-name"=
;
             }
             description
               "The name of the ACL for this entry.";
           }
           leaf acl-type {
             type identityref {
               base acl:acl-base;
             }
             description
               "The type of the ACL for this entry.  The name is
                scoped ONLY to the MUD file, and may not be unique
                in any other circumstance.";
           }

          

          

          

          

        

        


        

        
This is a nit (perhaps has already been reported):

          

        

        
Does the description comment on scope belong with the
          acl-name node?

          

        

        Thanks

        

          


            -- 

            
M. Ra=
nganathan

            

          

        

      

      

      
<=
/fieldset>
      

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


    

    

  






-- 
M. Ranganathan




--001a114cb408f48a4d055c7679e4--


From nobody Thu Oct 26 11:18:43 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 2C78613F442 for ; Thu, 26 Oct 2017 11:18:42 -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 watTJ6LapoZN for ; Thu, 26 Oct 2017 11:18:40 -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 510B6139504 for ; Thu, 26 Oct 2017 11:18:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4061; q=dns/txt; s=iport; t=1509041920; x=1510251520; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=arSBIwNPPu/BicZZA01YRqBABfU/BNUeKZitxunI3yY=; b=aCkgN0FkfeTHVVKCZXVy4OGdeDNhHReCUb8cqMK6b6g6oogKw+wL5T4Z jUlNdPslMpr12+GJkBkHqd5lJ3tRJGeogiCrk/XTG5pwEQUa4UmSTflTT Nvc+6Pqhtcpt12DfoJDEiyvEAXy/mfb+/s4hL4EVNqaInD6NSPrYkanW6 k=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAADFJfJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhTGEIYofdJAXkHyFRIIRBwOFOwKFABgBAgEBAQEBAQFrKIUeAQU?= =?us-ascii?q?jVhALBAETKgICVwYNCAEBihypUIInJopRAQEBAQEBAQEBAQEBAQEBAQEBAQEBD?= =?us-ascii?q?g+DLoVpgwGIGYJhBZFXkCSEQYIjjhWLcoc5lgqBOR84gWg0IQgdFYMuhGA/jHw?= =?us-ascii?q?BAQE?=
X-IronPort-AV: E=Sophos;i="5.44,301,1505779200";  d="asc'?scan'208,217";a="655696600"
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; 26 Oct 2017 18:18:38 +0000
Received: from [10.61.96.63] (dhcp-10-61-96-63.cisco.com [10.61.96.63]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9QIIc03029399; Thu, 26 Oct 2017 18:18:38 GMT
To: "M. Ranganathan" 
Cc: opsawg@ietf.org
References:  <6e4b760c-3a32-674c-de40-3481bf7ca2d7@cisco.com> 
From: Eliot Lear 
Message-ID: <18abcb2b-a171-829d-89c7-1792757a55ce@cisco.com>
Date: Thu, 26 Oct 2017 20:18:31 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4GtslWk4d4aHaubKtC8EMe7CiVMReL9gk"
Archived-At: 
Subject: Re: [OPSAWG] MUD draft 13 nit : Scope of ACL Name
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, 26 Oct 2017 18:18:42 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--4GtslWk4d4aHaubKtC8EMe7CiVMReL9gk
Content-Type: multipart/mixed; boundary="AnOJfcSkj5BniDMv4bsHon0nDmlp6nFbV";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" 
Cc: opsawg@ietf.org
Message-ID: <18abcb2b-a171-829d-89c7-1792757a55ce@cisco.com>
Subject: Re: [OPSAWG] MUD draft 13 nit : Scope of ACL Name
References: 
 <6e4b760c-3a32-674c-de40-3481bf7ca2d7@cisco.com>
 
In-Reply-To: 

--AnOJfcSkj5BniDMv4bsHon0nDmlp6nFbV
Content-Type: multipart/alternative;
 boundary="------------06A42B96CDA08EC52CCD34BC"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------06A42B96CDA08EC52CCD34BC
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 10/26/17 7:26 PM, M. Ranganathan wrote:
>
> I would like to suggest that an ACL name be directly derived from a a M=
UD URL instead of scoping it this way (so that it can be specified indepe=
ndently of the MUD file while achieving the scoping goal you had in mind)=
=2E
>
> That would ease the pain of implementation.
>
> Can you make this a requirement?
>

That's a reference to an object outside of our model.=C2=A0=C2=A0 I think=
 I could
write those words, but to be safe, your code should still bind the
scoping to that file.=C2=A0 And so I'm not sure of the point.

Eliot

--------------06A42B96CDA08EC52CCD34BC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    

    
On 10/26/17 7:26 PM, M. Ranganathan
      wrote:

    

    

      


        

          

            

              
I w=
ould like to suggest that an ACL name be directly derived from a a MUD UR=
L instead of scoping it this way (so that it can be specified independent=
ly of the MUD file while achieving the scoping goal you had in mind).



              
Tha=
t would ease the pain of implementation.



              
Can=
 you make this a requirement?



            

          

        

      

    

    

    That's a reference to an object outside of our model.=C2=A0=C2=A0 I t=
hink I
    could write those words, but to be safe, your code should still bind
    the scoping to that file.=C2=A0 And so I'm not sure of the point.
=

    

    Eliot

  


--------------06A42B96CDA08EC52CCD34BC--

--AnOJfcSkj5BniDMv4bsHon0nDmlp6nFbV--

--4GtslWk4d4aHaubKtC8EMe7CiVMReL9gk
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

iQEcBAEBCAAGBQJZ8ib3AAoJEIe2a0bZ0nozzxwH/05xFTC+bOOIxlxOJUNHXLSh
52bTKFfMaWnUIc+P8n8tMd1dMPV9YxZl7olEAk6TQIRkzuU7FwspY8wrLHP+ejvH
TYchgYfjRled6VxAg/Pu+6n1Zni5yp3IH3MGgsTyFzZy0ynkaMSsbAU+gjItPXsI
iW+rQhCY8nZy1KTFsyyHnnAACX92puU31ZPMHY2A4wA6YWczdh4iZKOR42TbMpkI
Wo/l3X8cAVNlGdawJFsS67bHF6YpcAhlXcEcj6zu8QDZIAXV9XqsbSZolqG7lkPX
VpRckejWsUbBPe2T7QSljxYUOPPg+Vd9WEFdOBOi2FiFDjYfCLqlLVa8XXCsQD8=
=5FXR
-----END PGP SIGNATURE-----

--4GtslWk4d4aHaubKtC8EMe7CiVMReL9gk--


From nobody Thu Oct 26 13:08: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 41FCD13899A for ; Thu, 26 Oct 2017 13:08:39 -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 te2OtMVlN9W7 for ; Thu, 26 Oct 2017 13:08:38 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC39713836A for ; Thu, 26 Oct 2017 13:08:37 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id 196so435218wma.1 for ; Thu, 26 Oct 2017 13:08:37 -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=CooAFNR6uNzAMdEKXLtOaBrpj7CwIFTUY4bRo2i1XJ8=; b=l8RmVm14cJVe5+/QNzjSS+tib4fo4gitBkGiTO/AAqC55qb2ZUKfBm2xHLK8tV/y8j FdOATDd2iSvJpa5E0Pc4U4X0HsB4DBiwbyogwT+Qd9cn6haSRUSRceX6rDEfVsD82nYv kRFbRFj7Aa/zO07SshOBs00oQTT4Y1k7Fu7gp7zxSemiz/ijmNhiz2PRmZ5typMJj3uu 7gTyc+B5fe/0wn75aXVHp7l++Nahqor9N4/6YqqnSCWkzqQ7DPtbmbWAqk/UYAX5aWaX uw9d4PNh4l8m5395CiD5rU4bcRl1sXRNA0VWdRozIj4pJDnhamL29ACtz9F9QqwfvjF+ gz7w==
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=CooAFNR6uNzAMdEKXLtOaBrpj7CwIFTUY4bRo2i1XJ8=; b=UGrSOP22PoXKqX49Yensbo6Nni02gzNMMVSwpct2rq6+W5Qz2Z+G87+F9m278RHioy NUJ7C65zAnacxhxzKHo9jiBvD9Hao6Z57PrubXTouyxGdFusZPj6euRdtoVTQFBy0Sxz r8OuKe36oY/wVbK7vXTf8TqIsVqT6qH9gJ1tn08X1tIRdBd2I5C0lKghkZWEsu6D2/mW TAyEqD3rwzCn1oPmuIqEz5oHG+6Wl2WihzxLEfN4SAgYrgPueQ10bhZqw6rUcL+A8ToT mXIhtOJjRD73WbjEx87uuQ8SNslazZ/FftgQrlrbXJxHX9QuHsN+J2gY8H5b3ZViqago vmzw==
X-Gm-Message-State: AMCzsaWi+RCHvcrrPKhn0x6gYN5yMNZnd1Ts/VXIxmVCcOR4LOCMlNRv rwPvVwzSvVKTYhXxMBeZOPJPM0N3ENW2w2rUE+w=
X-Google-Smtp-Source: ABhQp+QlVyy45BeQJ6MNfxiCQoJCBTr6oItd/iCc5lmxt3jQhtn+LDPND0ZAkUaWvzRNZW4mS8u9MbEBfvvhCPi7KaQ=
X-Received: by 10.28.63.134 with SMTP id m128mr71374wma.137.1509048516097; Thu, 26 Oct 2017 13:08:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Thu, 26 Oct 2017 13:07:55 -0700 (PDT)
In-Reply-To: <18abcb2b-a171-829d-89c7-1792757a55ce@cisco.com>
References:  <6e4b760c-3a32-674c-de40-3481bf7ca2d7@cisco.com>  <18abcb2b-a171-829d-89c7-1792757a55ce@cisco.com>
From: "M. Ranganathan" 
Date: Thu, 26 Oct 2017 16:07:55 -0400
Message-ID: 
To: Eliot Lear 
Cc: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1148be06c03aff055c78bc4e"
Archived-At: 
Subject: Re: [OPSAWG] MUD draft 13 nit : Scope of ACL Name
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, 26 Oct 2017 20:08:39 -0000

--001a1148be06c03aff055c78bc4e
Content-Type: text/plain; charset="UTF-8"

On Thu, Oct 26, 2017 at 2:18 PM, Eliot Lear  wrote:

>
>
> On 10/26/17 7:26 PM, M. Ranganathan wrote:
>
>
> I would like to suggest that an ACL name be directly derived from a a MUD URL instead of scoping it this way (so that it can be specified independently of the MUD file while achieving the scoping goal you had in mind).
>
>
> That would ease the pain of implementation.
>
>
> Can you make this a requirement?
>
>
>
> That's a reference to an object outside of our model.   I think I could
> write those words, but to be safe, your code should still bind the scoping
> to that file.  And so I'm not sure of the point.
>


I would suggest something a little more drastic - i.e. remove the notion of
scoping by file and tie the ACL names to a MUD file using a unique ACL
names (that could be derived from the MUD URL for example).

The ACLs can be changed independently of the MUD files (except for the ACL
names) that way. That would be the utility.





>
> Eliot
>



-- 
M. Ranganathan

--001a1148be06c03aff055c78bc4e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Oct 26, 2017 at 2:18 PM, Eliot Lear <lear@cisco.com> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 10/26/17 7:26 PM=
, M. Ranganathan
      wrote:

    

    

      


        

          

            

              
I would like to suggest that an ACL name be directly derive=
d from a a MUD URL instead of scoping it this way (so that it can be specif=
ied independently of the MUD file while achieving the scoping goal you had =
in mind).



              
That would ease the pain of implementation.



              
Can you make this a requirement?



            

          

        

      

    

    

    That's a reference to an object outside of our model.=C2=A0=C2=A0 I=
 think I
    could write those words, but to be safe, your code should still bind
    the scoping to that file.=C2=A0 And so I'm not sure of the point.


I would suggest something a littl=
e more drastic - i.e. remove the notion of scoping by file and tie the ACL =
names to a MUD file using a unique ACL names (that could be derived from th=
e MUD URL for example).

The ACLs can be changed independe=
ntly of the MUD files (except for the ACL names) that way. That would be th=
e utility.



=C2=A0
=


    

    Eliot

  






-- 
M. Ranganathan




--001a1148be06c03aff055c78bc4e--


From nobody Thu Oct 26 14:50: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 28FA713899A for ; Thu, 26 Oct 2017 14:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_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 M3mfqyxNGWEQ for ; Thu, 26 Oct 2017 14:50:36 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4949013F623 for ; Thu, 26 Oct 2017 14:50:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10396; q=dns/txt; s=iport; t=1509054622; x=1510264222; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+x0vW7aoEkFOI3dyt+0dZnQkfX+Vg6MajuqOi2pg8wo=; b=DY8eJ3d0F3QhPrDEbtWrNzkdLf/NZ3r2oDTGkYifKAm3ry6qnTlvoFGc 96DDW1MPEux2X12fmiOh5PP7RoEyB7mLssJ9QTi2U7hpYTyK+exMydHK4 LC9Ii3hD3lsVxjjFLH7OTbrrAHcPjygR6cMShid8Oijfa94ML51zsWDjF k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAADWV/JZ/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzEuZG4nB4Nzih+PEIFUiHSILoVEghEKGAEKhElPAhqEJz8YAQI?= =?us-ascii?q?BAQEBAQEBayiFHgIBAwEBIUsLEAIBCD8DAgICHwYLFBECBA4FiTxMAxUQqRuCJ?= =?us-ascii?q?yaHEg2DIwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgy6CB4NiC4J2gl6CERWDFS+?= =?us-ascii?q?CMgWRV49oPAKPfoR5kyuNFIU7gw4CERkBgTgBHziBaHoVSS0BgjZJgg6CCHeKT?= =?us-ascii?q?4ERAQEB?=
X-IronPort-AV: E=Sophos; i="5.44,301,1505779200"; d="scan'208,217"; a="22130353"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Oct 2017 21:50:21 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v9QLoLhb010596 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Oct 2017 21:50:21 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 26 Oct 2017 17:50:20 -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.1320.000; Thu, 26 Oct 2017 17:50:20 -0400
From: "Einar Nilsen-Nygaard (einarnn)" 
To: "M. Ranganathan" 
CC: Eliot Lear , "opsawg@ietf.org" 
Thread-Topic: [OPSAWG] MUD draft 13 nit : Scope of ACL Name
Thread-Index: AQHTTn23tGxCxBlSAkOpWSsZEtKkuaL2oeEAgAADMQCAAA6ogIAAHpGAgAAco4A=
Date: Thu, 26 Oct 2017 21:50:20 +0000
Message-ID: <8F56D399-4D20-4814-A88F-B01DC2CCDE0E@cisco.com>
References:  <6e4b760c-3a32-674c-de40-3481bf7ca2d7@cisco.com>  <18abcb2b-a171-829d-89c7-1792757a55ce@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.1.7)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.225.82]
Content-Type: multipart/alternative; boundary="_000_8F56D3994D204814A88FB01DC2CCDE0Eciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] MUD draft 13 nit : Scope of ACL Name
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, 26 Oct 2017 21:50:39 -0000

--_000_8F56D3994D204814A88FB01DC2CCDE0Eciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UmFuZ2EsDQoNClRoZSBkZXNjcmlwdGlvbiBvZiBzY29waW5nIG9uIHRoZSBBQ0wgbmFtZSBpcyBy
ZWFsbHkganVzdCB0byB3YXJuIGltcGxlbWVudG9ycyAocHJpbWFyaWx5IHRob3NlIGNvbnN1bWlu
ZyB0aGUgTVVEIGZpbGUpIHRoYXQgdGhleSBjYW5ub3QganVzdCBhc3N1bWUgdGhhdCB0aGUgbmFt
ZSAoQU5ZIG5hbWUpIHVzZWQgaW4gdGhlIE1VRCBmaWxlIHdvdWxkIGJlIGd1YXJhbnRlZWQgdG8g
YmUgdW5pcXVlIGlmIGp1c3QgbGlmdGVkIGFuZCB1c2VkIHRvIHByb3Zpc2lvbiB0aGUgQUNMIHRv
IGEgbmV0Y29uZiBzZXJ2ZXIgdGhhdCBtYXkgaGF2ZSBBQ0xzIHByb3Zpc2lvbmVkIGZyb20gb3Ro
ZXIgc291cmNlcy4gRnVydGhlciwgdGhlIOKAnGFjbC1uYW1l4oCdIGlzIGNvbnN0cmFpbmVkIHRv
IGJlIGEgc3RyaW5nIG9mIG1heGltdW0gbGVuZ3RoIDY0IG9jdGV0cywgd2hpY2ggcHJvYmFibHkg
bWVhbnMgdGhhdCBkZXJpdmluZyBmcm9tIGEgTVVEIFVSTCB3b3VsZCBiZSBpbXByYWN0aWNhbC4N
Cg0KVGh1cyBhbnkgYXR0ZW1wdCB0byBkbyBhbnl0aGluZyBvdGhlciB0aGFuIGFjY2VwdCB0aGF0
IHRoZSBhY2wtbmFtZXMgdXNlZCBtdXN0IGJlIHVuaXF1ZSBpbiB0aGUgc2NvcGUgb2YgdGhlIE1V
RCBmaWxlIHRoZXkgYXJlIGRlZmluZWQgaW4sIGJ1dCBtdXN0IGJlIGV4YW1pbmVkIGZvciB1bmlx
dWVuZXNzIHByaW9yIHRvIHByb3Zpc2lvbmluZyB0byBhIE5FVENPTkYgc2VydmVyLCBpcyBwcm9i
YWJseSBub3QgcHJhY3RpY2FsLg0KDQpBbnl3YXksIEkgc3VzcGVjdCB0aGF0IEFDTHMgZnJvbSBN
VUQgZmlsZXMgd2lsbCByYXJlbHkgYmUgcHJvdmlzaW9uZWQgZGlyZWN0bHkgdG8gZGV2aWNlcy4g
TW9zdCBsaWtlbHkgdGhleSB3aWxsIGJlIHByb2Nlc3NlZCBieSB0aGUgIk1VRCBjb250cm9sbGVy
4oCdIGFuZCBjb21iaW5lZCB3aXRoIG90aGVyIHBvbGljaWVzIGRlZmluZWQgYnkgbmV0d29yayBh
ZG1pbmlzdHJhdG9ycy4gSU9XLCBNVUQgZmlsZXMgd2lsbCBhbG1vc3QgZGVmaW5pdGVseSBub3Qg
YmUgdGhlIG9ubHkgc291cmNlIG9mIGFjY2VzcyBwb2xpY3kuDQoNCkNoZWVycywNCg0KRWluYXIN
Cg0KT24gMjYgT2N0IDIwMTcsIGF0IDIxOjA3LCBNLiBSYW5nYW5hdGhhbiA8bXJhbmdhQGdtYWls
LmNvbTxtYWlsdG86bXJhbmdhQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gVGh1LCBPY3Qg
MjYsIDIwMTcgYXQgMjoxOCBQTSwgRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxl
YXJAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KT24gMTAvMjYvMTcgNzoyNiBQTSwgTS4gUmFuZ2Fu
YXRoYW4gd3JvdGU6DQoNCg0KSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgdGhhdCBhbiBBQ0wgbmFt
ZSBiZSBkaXJlY3RseSBkZXJpdmVkIGZyb20gYSBhIE1VRCBVUkwgaW5zdGVhZCBvZiBzY29waW5n
IGl0IHRoaXMgd2F5IChzbyB0aGF0IGl0IGNhbiBiZSBzcGVjaWZpZWQgaW5kZXBlbmRlbnRseSBv
ZiB0aGUgTVVEIGZpbGUgd2hpbGUgYWNoaWV2aW5nIHRoZSBzY29waW5nIGdvYWwgeW91IGhhZCBp
biBtaW5kKS4NCg0KDQoNClRoYXQgd291bGQgZWFzZSB0aGUgcGFpbiBvZiBpbXBsZW1lbnRhdGlv
bi4NCg0KDQoNCkNhbiB5b3UgbWFrZSB0aGlzIGEgcmVxdWlyZW1lbnQ/DQoNCg0KDQpUaGF0J3Mg
YSByZWZlcmVuY2UgdG8gYW4gb2JqZWN0IG91dHNpZGUgb2Ygb3VyIG1vZGVsLiAgIEkgdGhpbmsg
SSBjb3VsZCB3cml0ZSB0aG9zZSB3b3JkcywgYnV0IHRvIGJlIHNhZmUsIHlvdXIgY29kZSBzaG91
bGQgc3RpbGwgYmluZCB0aGUgc2NvcGluZyB0byB0aGF0IGZpbGUuICBBbmQgc28gSSdtIG5vdCBz
dXJlIG9mIHRoZSBwb2ludC4NCg0KDQpJIHdvdWxkIHN1Z2dlc3Qgc29tZXRoaW5nIGEgbGl0dGxl
IG1vcmUgZHJhc3RpYyAtIGkuZS4gcmVtb3ZlIHRoZSBub3Rpb24gb2Ygc2NvcGluZyBieSBmaWxl
IGFuZCB0aWUgdGhlIEFDTCBuYW1lcyB0byBhIE1VRCBmaWxlIHVzaW5nIGEgdW5pcXVlIEFDTCBu
YW1lcyAodGhhdCBjb3VsZCBiZSBkZXJpdmVkIGZyb20gdGhlIE1VRCBVUkwgZm9yIGV4YW1wbGUp
Lg0KDQpUaGUgQUNMcyBjYW4gYmUgY2hhbmdlZCBpbmRlcGVuZGVudGx5IG9mIHRoZSBNVUQgZmls
ZXMgKGV4Y2VwdCBmb3IgdGhlIEFDTCBuYW1lcykgdGhhdCB3YXkuIFRoYXQgd291bGQgYmUgdGhl
IHV0aWxpdHkuDQoNCg0KDQoNCg0KRWxpb3QNCg0KDQoNCi0tDQpNLiBSYW5nYW5hdGhhbg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0FXRyBtYWls
aW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9yZzxtYWlsdG86T1BTQVdHQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg0K

--_000_8F56D3994D204814A88FB01DC2CCDE0Eciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClJhbmdhLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xh
c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGRlc2NyaXB0aW9uIG9mIHNjb3Bpbmcg
b24gdGhlIEFDTCBuYW1lIGlzIHJlYWxseSBqdXN0IHRvIHdhcm4gaW1wbGVtZW50b3JzIChwcmlt
YXJpbHkgdGhvc2UgY29uc3VtaW5nIHRoZSBNVUQgZmlsZSkgdGhhdCB0aGV5IGNhbm5vdCBqdXN0
IGFzc3VtZSB0aGF0IHRoZSBuYW1lIChBTlkgbmFtZSkgdXNlZCBpbiB0aGUgTVVEIGZpbGUgd291
bGQgYmUgZ3VhcmFudGVlZCB0byBiZSB1bmlxdWUgaWYganVzdCBsaWZ0ZWQNCiBhbmQgdXNlZCB0
byBwcm92aXNpb24gdGhlIEFDTCB0byBhIG5ldGNvbmYgc2VydmVyIHRoYXQgbWF5IGhhdmUgQUNM
cyBwcm92aXNpb25lZCBmcm9tIG90aGVyIHNvdXJjZXMuIEZ1cnRoZXIsIHRoZSDigJxhY2wtbmFt
ZeKAnSBpcyBjb25zdHJhaW5lZCB0byBiZSBhIHN0cmluZyBvZiBtYXhpbXVtIGxlbmd0aCA2NCBv
Y3RldHMsIHdoaWNoIHByb2JhYmx5IG1lYW5zIHRoYXQgZGVyaXZpbmcgZnJvbSBhIE1VRCBVUkwg
d291bGQgYmUgaW1wcmFjdGljYWwuPGJyIGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8
L2Rpdj4NCjxkaXY+VGh1cyBhbnkgYXR0ZW1wdCB0byBkbyBhbnl0aGluZyBvdGhlciB0aGFuIGFj
Y2VwdCB0aGF0IHRoZSBhY2wtbmFtZXMgdXNlZCBtdXN0IGJlIHVuaXF1ZSBpbiB0aGUgc2NvcGUg
b2YgdGhlIE1VRCBmaWxlIHRoZXkgYXJlIGRlZmluZWQgaW4sIGJ1dCBtdXN0IGJlIGV4YW1pbmVk
IGZvciB1bmlxdWVuZXNzIHByaW9yIHRvIHByb3Zpc2lvbmluZyB0byBhIE5FVENPTkYgc2VydmVy
LCBpcyBwcm9iYWJseSBub3QgcHJhY3RpY2FsLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8
L2Rpdj4NCjxkaXY+QW55d2F5LCBJIHN1c3BlY3QgdGhhdCBBQ0xzIGZyb20gTVVEIGZpbGVzIHdp
bGwgcmFyZWx5IGJlIHByb3Zpc2lvbmVkIGRpcmVjdGx5IHRvIGRldmljZXMuIE1vc3QgbGlrZWx5
IHRoZXkgd2lsbCBiZSBwcm9jZXNzZWQgYnkgdGhlICZxdW90O01VRCBjb250cm9sbGVy4oCdIGFu
ZCBjb21iaW5lZCB3aXRoIG90aGVyIHBvbGljaWVzIGRlZmluZWQgYnkgbmV0d29yayBhZG1pbmlz
dHJhdG9ycy4gSU9XLCBNVUQgZmlsZXMgd2lsbCBhbG1vc3QgZGVmaW5pdGVseQ0KIG5vdCBiZSB0
aGUgb25seSBzb3VyY2Ugb2YgYWNjZXNzIHBvbGljeS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj5DaGVlcnMsPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N
CjwvZGl2Pg0KPGRpdj5FaW5hcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5P
biAyNiBPY3QgMjAxNywgYXQgMjE6MDcsIE0uIFJhbmdhbmF0aGFuICZsdDs8YSBocmVmPSJtYWls
dG86bXJhbmdhQGdtYWlsLmNvbSIgY2xhc3M9IiI+bXJhbmdhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy
b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNs
YXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi
Pk9uIFRodSwgT2N0IDI2LCAyMDE3IGF0IDI6MTggUE0sIEVsaW90IExlYXIgPHNwYW4gZGlyPSJs
dHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSIgdGFyZ2V0
PSJfYmxhbmsiIGNsYXNzPSIiPmxlYXJAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxi
ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp
bjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgi
Pg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj48c3BhbiBj
bGFzcz0iIj4NCjxwIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvcD4NCjxiciBjbGFzcz0iIj4N
CjxkaXYgY2xhc3M9Im1fMzA5OTgzNzIxODQ2MDY5ODg1NW1vei1jaXRlLXByZWZpeCI+T24gMTAv
MjYvMTcgNzoyNiBQTSwgTS4gUmFuZ2FuYXRoYW4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz
PSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9
ImdtYWlsX3F1b3RlIj4NCjxkaXYgY2xhc3M9IiI+DQo8cHJlIGNsYXNzPSJtXzMwOTk4MzcyMTg0
NjA2OTg4NTVnbWFpbC1tXzQyMjEwNDc1MjczODg0NTI0NzJnbWFpbC1uZXdwYWdlIj5JIHdvdWxk
IGxpa2UgdG8gc3VnZ2VzdCB0aGF0IGFuIEFDTCBuYW1lIGJlIGRpcmVjdGx5IGRlcml2ZWQgZnJv
bSBhIGEgTVVEIFVSTCBpbnN0ZWFkIG9mIHNjb3BpbmcgaXQgdGhpcyB3YXkgKHNvIHRoYXQgaXQg
Y2FuIGJlIHNwZWNpZmllZCBpbmRlcGVuZGVudGx5IG9mIHRoZSBNVUQgZmlsZSB3aGlsZSBhY2hp
ZXZpbmcgdGhlIHNjb3BpbmcgZ29hbCB5b3UgaGFkIGluIG1pbmQpLg0KDQo8L3ByZT4NCjxwcmUg
Y2xhc3M9Im1fMzA5OTgzNzIxODQ2MDY5ODg1NWdtYWlsLW1fNDIyMTA0NzUyNzM4ODQ1MjQ3Mmdt
YWlsLW5ld3BhZ2UiPlRoYXQgd291bGQgZWFzZSB0aGUgcGFpbiBvZiBpbXBsZW1lbnRhdGlvbi4N
Cg0KPC9wcmU+DQo8cHJlIGNsYXNzPSJtXzMwOTk4MzcyMTg0NjA2OTg4NTVnbWFpbC1tXzQyMjEw
NDc1MjczODg0NTI0NzJnbWFpbC1uZXdwYWdlIj5DYW4geW91IG1ha2UgdGhpcyBhIHJlcXVpcmVt
ZW50Pw0KDQo8L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9zcGFuPlRoYXQncyBhIHJlZmVyZW5jZSB0byBhbiBvYmpl
Y3Qgb3V0c2lkZSBvZiBvdXIgbW9kZWwuJm5ic3A7Jm5ic3A7IEkgdGhpbmsgSSBjb3VsZCB3cml0
ZSB0aG9zZSB3b3JkcywgYnV0IHRvIGJlIHNhZmUsIHlvdXIgY29kZSBzaG91bGQgc3RpbGwgYmlu
ZCB0aGUgc2NvcGluZyB0byB0aGF0IGZpbGUuJm5ic3A7IEFuZCBzbyBJJ20gbm90IHN1cmUgb2Yg
dGhlIHBvaW50LjxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4IiBjbGFz
cz0iIj48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgd291bGQgc3VnZ2VzdCBzb21ldGhpbmcg
YSBsaXR0bGUgbW9yZSBkcmFzdGljIC0gaS5lLiByZW1vdmUgdGhlIG5vdGlvbiBvZiBzY29waW5n
IGJ5IGZpbGUgYW5kIHRpZSB0aGUgQUNMIG5hbWVzIHRvIGEgTVVEIGZpbGUgdXNpbmcgYSB1bmlx
dWUgQUNMIG5hbWVzICh0aGF0IGNvdWxkIGJlIGRlcml2ZWQgZnJvbSB0aGUgTVVEIFVSTCBmb3Ig
ZXhhbXBsZSkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPlRoZSBBQ0xzIGNhbiBiZSBjaGFuZ2VkIGluZGVwZW5kZW50bHkgb2YgdGhlIE1VRCBmaWxl
cyAoZXhjZXB0IGZvciB0aGUgQUNMIG5hbWVzKSB0aGF0IHdheS4gVGhhdCB3b3VsZCBiZSB0aGUg
dXRpbGl0eS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz
cz0iIj48YnIgY2xhc3M9IiI+DQombmJzcDs8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1
b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1s
ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiB0ZXh0PSIjMDAwMDAw
IiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iSE9FblpiIj48Zm9udCBj
b2xvcj0iIzg4ODg4OCIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KRWxpb3Q8YnIgY2xhc3M9IiI+
DQo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9
IiI+DQo8YnIgY2xlYXI9ImFsbCIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLSA8YnIgY2xh
c3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiIGRhdGEtc21hcnRtYWlsPSJnbWFp
bF9zaWduYXR1cmUiPk0uIFJhbmdhbmF0aGFuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnIgY2xhc3M9IiI+DQpPUFNBV0cgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i
bWFpbHRvOk9QU0FXR0BpZXRmLm9yZyIgY2xhc3M9IiI+T1BTQVdHQGlldGYub3JnPC9hPjxiciBj
bGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b3BzYXdnIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29w
c2F3ZzwvYT48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_8F56D3994D204814A88FB01DC2CCDE0Eciscocom_--


From nobody Fri Oct 27 11:14: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 80CE113F3AC; Fri, 27 Oct 2017 11:14:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= 
To: 
Cc: draft-ietf-opsawg-nat-yang.all@ietf.org, opsawg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150912805550.22087.2939629492652644040@ietfa.amsl.com>
Date: Fri, 27 Oct 2017 11:14:15 -0700
Archived-At: 
Subject: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
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, 27 Oct 2017 18:14:15 -0000

Reviewer: Jürgen Schönwälder
Review result: Not Ready

Summary

>From a YANG modeling point of view, the module is rather straight
forward and I did not discover anything that seems fundamentally
problematic. That said, there are a number of details where I doubt
the model is correct and things where I believe things are incomplete.
Given that there are many different NAT functions, I also expected to
see usage of YANG features.

One fundamental question one could raise is whether this model should
have been broken down into a generic NAT core model plus extensions of
the core model for the different types of NATs. Well, a single model
with YANG features is an inline version of that as this still requires
to mark clearly which parts are specific to certain types or NATs.

I did not compile the module myself since the IETF tracker says no
errors using pyang and yanglint (and I would not have run anything
different). (Is it OK for YANG doctors to trust the tracker tools?
Well, since this is labelled as an early review and I expect more
updates, I assume this is fine.)

I can't tell whether the model makes sense from a NAT point of view. I
am not an expert in the various types of NATs and surely more reviews
of NAT experts would be good (and they would have likely spotted some
things I have spotted, so I guess the usual problem of getting enough
substantial reviews).

Details

- We use revision statements only for published modules. Hence, please
  replace the revision statements with

  // RFC Ed. update to match the date of the latest edits
  revision 2017-xx-yy {
    description
      "Initial revision.";
    reference
      "RFC XXXX: A YANG Data Model for Network Address Translation
                 (NAT) and Network Prefix Translation (NPT)";
  }

- We usually follow a different template for the contact statement
  that has more context and just a list of names and email addresses.

- We usually write

     reference
       "RFC 3022: Traditional IP Network Address Translator
                  (Traditional NAT)";

  instead of just

     reference
       "RFC 3022.";

  since not everybody remembers all the numbers equally well.

- Is there a reference for dst-nat?

- What is the vrf-routing-instance identity good for? Its used only in
  the leaf external-vrf-instance and the description of that leaf is
  not telling me how this is going to be used. Who is going to derive
  identities? I fear you are trying to achieve something where using
  identities is really the wrong approach. Section 2.10 does not tell
  how this is supposed to work either. I assume this needs to be
  checked by the routing area experts to make sure things fit with
  their modeling of VRFs.

- s/start-port-numbert/start-port-number/

- Are comments like

  // port numbers: single or port-range

  necessary given that there are description statements? Note that
  comments may be removed by tools while description statements
  usually are preserved. So it is important to have anything important
  covered in description statements.

- What is a PSID algorithm? Spell out acronyms on first usage.

- The leafs start-port-number and end-port-number are commented out in
  port-range, probably in favour of the uses port-number. If they are
  not needed anymore, they should be removed.

- I do not understand port-set-algo from the descriptions. What is the
  psid-offset applied? What is a 'sharing ration for an IPv4 address'?
  Is this stuff IPv4 specific? Is the psid something that has a
  certain meaning outside of this YANG module? If so, where do I find
  more details (missing reference statement?)?

- mapping-entry/index: is this an arbitrary identifier? how are these
  identifiers allocated? Are they created by the NAT or are they created
  via configuration? Or even both? Well, I guess it is both given the
  mapping-entry/type leaf.

- mapping-entry/type: instead 'manually configured', I would write
  'explicitly configured' (configuration does not have to be a manual
  process). I also find the other enum labels at least a bit confusing.

        enum "dynamic-explicit" {
          description
            "This mapping is created by an
             outgoing packet.";
        }
        
        enum "dynamic-implicit" {
          description
            "This mapping is created by an
             explicit  dynamic message.";
        }

  Note the 'implicit' vs 'explicit' clash here. Perhaps this should be
  aligned with the definition of dynamic and implicit mappings:

   o  Dynamic implicit mapping: is created implicitly as a side effect
      of traffic such as an outgoing TCP SYN or an outgoing UDP packet.
      A validity lifetime is associated with this mapping.

   o  Dynamic explicit mapping: is created as a result of an explicit
      request, e.g., PCP message [RFC6887].  A validity lifetime is
      associated with this mapping.

  But then it seems you really messed things up here. I would even
  write these definitions differently since 'outgoing' is unclear and
  potentially confusing.

   o  Dynamic implicit mapping: is created implicitly as a side effect
      of processing a packet (e.g., an initial TCP SYN packet) that
      requires a new mapping. A validity lifetime is associated with
      this mapping.

   o  Dynamic explicit mapping: is created as a result of an explicit
      request, e.g., PCP message [RFC6887].  A validity lifetime is
      associated with this mapping.

   Similarly, I would change the description of

        enum "dynamic-implicit" {
          description
            "This mapping is created implicitely as a side effect
             of processing a packet that requires a new mapping.";
        }

        enum "dynamic-explicit" {
          description
            "This mapping is created as a result of an explicit
             request, e.g., a PCP message.";
        }

- We should perhaps have a type for an IP protocol number, ideally in
  inet-types. (Just a reminder to myself.) That said, I do not
  understand what this sentence means:

    No transport protocol is indicated if a mapping applies for
    any protocol.

  Perhaps you wanted to say this:

    If this leaf is not instantiated, then the mapping applies to any
    protocol.

- container internal-src-port:
- container external-src-port:
- container internal-dst-port:
- container external-dst-port:

         It is used also to carry the internal
         source ICMP identifier.";

  I think details are lacking here. What is the ICMP identifier? What
  does 'carry' mean and how does this relate to the port-number
  grouping?

  See above, I do not understand the ICMP identifier statement.

- lifetime:

  Spell out 3WHS. I think there should be a units statement. And is
  this a ticking lifetime, i.e., this changes on every get request? Is
  this useful? Have alternatives been considered such as reporting the
  point in time when the mapping was established? Or is the idea that
  the lifetime reports the time left until the mapping will be garbage
  collected? What does "tracks the connection" really mean here?

- I suggest to remove empty lines in say leaf definitions. Instead

      leaf id {
        type uint32;

        description
          "NAT instance identifier.";

        reference
          "RFC 7659.";
      }

  write

      leaf id {
        type uint32;
        description
          "NAT instance identifier.";
        reference
          "RFC 7659: Definitions of Managed Objects for Network
                     Address Translators (NATs)";
      }

- It seems you try to be aligned with the NATV2-MIB module but there
  is no explicit discussion about this in the document. I suggest that
  you a section (for example before the tree diagram) where you
  discuss how this YANG module coexists with the NATV2-MIB module.

  For example, I see that Natv2InstanceIndex in the MIB module
  excludes 0 as an instance identifier while your id leaf above allows
  the usage of 0.

- container nat-capabilities:

  Here we find a bunch of "config true" leafs and I wonder how these
  work. There are things a NAT implementation is capable to do, and
  there are things that are enabled in a NAT deployment and of course
  you can't enable something in a deployment that has not been
  implemented. So are these 'capabilities' more like NAT features
  enabled (since we have "config true" nodes) or are these more
  implemented capabilities (but then "config true" may be wrong)?
  Depending on the answer, did you consider using YANG features?

- nat-flavor and nat44-flavor:

  Does it make sense to have two objects here? Can I put basic-nat
  into nat-flavor? Are the differences between lets say napt and
  basic-nat really nat44 specific?

  Note that you also derive restricted-nat from nat44 but this option
  is not mentioned in the description of nat44-flavor. I think the
  description should be more open since in principle I can derive even
  more identities in the future.

- boolean capability flags

  Do these need references so one can lookup what the exact meaning of
  these 'capabilities' are? It would surely help me and it will help
  implementors that need to decide whether a certain vendor feature
  fits any of these.

- nat-pass-through-pref

  Perhaps spell out nat-pass-through-prefix (pref might also be
  understood as preference). And perhaps change the wording in the
  description

  OLD
	    "The IP address subnets that match
             should not be translated. According to

  NEW
	    "IP addresses matching this prefix are
             not be translated. According to

- Sometimes you repeat prefixes in leaf definitions (e.g.,
  nat-pass-through-port) while at other times you do not.

- nat-pass-through-port

  You seem to have copy pasted the description of
  nat-pass-through-pref.  Is this a single port? So I need multiple
  nat-pass-through entries for multiple ports. Fine. But is there a
  special meaning if both nat-pass-through-pref and
  nat-pass-through-port are configured in a single list entry? Does
  this mean the port is scoped to the prefix?

- Some nat type specific parameter lists are flat, for others there is
  an additional container. Is this by design?

- I meanwhile think there really should be features. Certain lists
  only make sense for implementations that support certain NAT
  types. Having features defined allows code generators to easily
  generate stubs that actually match the capabilities of an
  implementation. And you automatically benefit from feature
  announcements.

- s/attachedto/attached to/

- s/prefixs./prefixes./

- nat64-prefix

  What is the purpose of //default "64:ff9b::/96"; ??

- stateless-enable

  Does this enable leaf make sense on a list entry? Perhaps it does
  but the description is fairly general and hence I am asking.

- external-ip-address-pool/pool-id

  This seems to relate to a Natv2PoolIndex, which again excludes the
  value 0. I have not checked all such related things, so please go
  and check yourself.

- external-ip-address-pool

  The description says

            Both contiguous and non-contiguous pools
            can be configured for NAT purposes.";

  but it seems more accurate to say that a pool is a set of prefixes
  since this is what the model suggests.

- supported-transport-protocols

  I am again not clear whether you are reporting implementation
  capabilities here or enabled features or something else. Is the
  configuration of transport-protocol-id and transport-protocol-name
  mutually exclusive? If so, should this be a choice? If I can
  configure both, I assume they have to be consistent.

- transport-protocol-name

  Is this restricted to the acronyms that are used in the IANA
  protocol numbers registry?

- s/masck/mask/

- subscriber-mask-v6

  The name seems to indicate that this only applies to IPv6 prefixes
  handed out to CPEs. Perhaps this should be stated explicitely (but
  yes it is unlike to ever get an IPv4 prefix). But then, the
  subscriber-match has an IPv4 prefix example.

- quota-type

  Is this a good name for the leaf? This seems to indicate for which
  transport protocol a port-limit is enforced. And this list is
  restricted to TCP, UDP, and ICMP while other parts of the model are
  more flexible in supporting additional transport protocols. So is it
  consistent to a rather restricted enum here?

- port-set-timeout

  Needs a units statement.

- timeouts

  Can I make the timeouts arbitrarily small, in the extreme case 0
  seconds? In some cases I find text like "for at least 6 seconds".
  Does this mean that the range is really uint32 { range "6..max"; }?
  Or is it still OK to configure the value 3 and the 'must' is really
  a 'should'?

- port-timeout

  I doubt this is of type inet:port-number and there likely needs to
  be a units statement.

- alg-name

  Is there a list of well-known ALG names? IANA? Or is this a random
  string that one needs to guess form the vendor's documentation,
  i.e., this is potentially not interoperable out of the box? Is there
  a way to obtain the number of ALGs supported or is the idea to do
  trial and error probing to find out (which is even harder if there
  are no well-known ALG names)?

- all-algs-enable

  This says "Enable/disable all ALGs." but I _assume_ that I set this
  to false and to enable specific ALGs. Perhaps this interaction needs
  to be spelled out.

- Is there any throttling mechanism needed in case my NAT is
  constantly operating around the notification thresholds?

- Add units to the mapping limit definitions ("subscribers",
  "mappings", ...)

- limit-per-subnet

  This is type inet:ip-prefix? I guess you wanted something else here.

- Why are some limits mandatory, others not?

- If you write 'limit per subscriber', how is a subscriber identified?
  I assume these are global per subscriber limits, i.e., all
  subscribers receive the same limit.

- limit-per-subnet

          leaf limit-per-subnet {
            type inet:ip-prefix;

            description
              "Rate-limit the number of new mappings
	       and sessions per subnet.";
          }

  I do not see how this works. The other limit-per-XXX objects are
  numbers - presumably defining the limit. This is a prefix?

- logging-info

  Is this information complete? Perhaps it is for plain syslog
  (without any security) but I doubt the info is complete for the
  other transports mentioned, at least not for FTP. And surely, if you
  want to protect the logging information, then you will neeed way
  more parameters. And what does 'retrieving' logging entries mean?  I
  assume with syslog and ipfix you push log messages. I am less sure
  about FTP. Perhaps less is more and simply provide support for
  syslog and leave the other options for extensions. You have a choice
  in place, so not need to go and deal with all possible complexity
  here.

- For the statistics, we used to use plural form for counters back in
  SNMP land and I think this was good practice. So go with
  sent-packets, sent-bytes, rcvd-packets, rcvd-bytes, dropped-packets,
  dropped-bytes, ...

- total-mappings, total-tcp-mappings, total-udp-mappings,
  total-icmp-mappings: These may use yang:gauge32.

- address-allocated, address-free -> addresses-allocated, addresses-free
  (may also be yang:gauge32)

- Some of these gauges might fluctuate fast (maybe consider
  exponentially smoothed gauges, but this might also be left for an
  extension).

- The security considerations text should follow the new boilerplate
  that also covers RESTCONF. I think it would help to be more specific
  about the security aspects of this data model. This text is quite
  generic. With a NAT, things even have privacy aspects. If I can
  force a specific NAT mapping, I can track a subscriber.

- At least one example has syntax errors. Examples should ideally be
  validated by tools so that the examples are syntactically correct and
  valid regarding the data model.



From nobody Sat Oct 28 07:05:37 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 9533913F550; Sat, 28 Oct 2017 07:05:30 -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.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150919953057.2627.7990473745194211968@ietfa.amsl.com>
Date: Sat, 28 Oct 2017 07:05:30 -0700
Archived-At: 
Subject: [OPSAWG] Secdir last call review of draft-ietf-opsawg-mud-13
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: Sat, 28 Oct 2017 14:05:31 -0000

Reviewer: Adam Montville
Review result: Ready

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

The draft is ready.

All previously identified potential issues (see [1]) seem to have been
addressed. For the security ADs, please review the summary I wrote at [1],
which is still applicable.

For the opsawg folks, if (when?) you get around to describing how software
packages might be able to convey their intended use and/or preferred
configuration, let me know - I'd like to help.

[1] https://www.ietf.org/mail-archive/web/secdir/current/msg07563.html


From nobody Sun Oct 29 01:38:18 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 85F9413F937; Sun, 29 Oct 2017 01:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=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 JJCtm11Vz7Hg; Sun, 29 Oct 2017 01:38:12 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CC113F93C; Sun, 29 Oct 2017 01:38:07 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3912565B; Sun, 29 Oct 2017 09:38:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 3UZgDZ8BvpOH; Sun, 29 Oct 2017 09:38:03 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sun, 29 Oct 2017 09:38:05 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21F2B2010F; Sun, 29 Oct 2017 09:38:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 44WrmblLqYGu; Sun, 29 Oct 2017 09:38:02 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E23222010E; Sun, 29 Oct 2017 09:38:02 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id DCBA841418EF; Sun, 29 Oct 2017 09:36:36 +0100 (CET)
Date: Sun, 29 Oct 2017 09:36:36 +0100
From: Juergen Schoenwaelder 
To: yang-doctors@ietf.org
Cc: draft-ietf-opsawg-nat-yang.all@ietf.org, opsawg@ietf.org
Message-ID: <20171029083636.35fhzpj5i5zqb7of@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: yang-doctors@ietf.org, draft-ietf-opsawg-nat-yang.all@ietf.org, opsawg@ietf.org
References: <150912805550.22087.2939629492652644040@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <150912805550.22087.2939629492652644040@ietfa.amsl.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [OPSAWG] [yang-doctors] Yangdoctors early review of draft-ietf-opsawg-nat-yang-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: Sun, 29 Oct 2017 08:38:17 -0000

One additional nit: You may want to think about the name of the toplevel
node. Here is what is currently published:

    +--rw interfaces            ietf-interfaces         RFC 7223
    +--rw ipfix                 ietf-ipfix-psamp	RFC 6728
    +--rw key-chains            ietf-key-chain		RFC 8177
    +--rw lmap                  ietf-lmap-control       RFC 8194
    +--ro modules-state         ietf-yang-library	RFC 7895
    +--rw nacm                  ietf-netconf-acm        RFC 6536
    +--ro netconf-state         ietf-netconf-monitoring RFC 6022
    +--rw routing               ietf-routing            RFC 8022
    +--rw snmp                  ietf-snmp               RFC 7407
    +--rw system                ietf-system		RFC 7317
    +--ro system-state          ietf-system     	RFC 7317

    +--ro interfaces-state      ietf-interfaces         RFC 7223 (to be deprecated)
    +--ro routing-state         ietf-routing            RFC 8022 (to be obsoleted)

Calling the toplevel node simply 'nat' may be more inline with the
existing names (which are not all perfect but if we ignore the -state
nodes there is a certain level of consistency - a not toplevel node
uses 'module').

/js

On Fri, Oct 27, 2017 at 11:14:15AM -0700, Jürgen Schönwälder wrote:
> Reviewer: Jürgen Schönwälder
> Review result: Not Ready
> 
> Summary
> 
> >From a YANG modeling point of view, the module is rather straight
> forward and I did not discover anything that seems fundamentally
> problematic. That said, there are a number of details where I doubt
> the model is correct and things where I believe things are incomplete.
> Given that there are many different NAT functions, I also expected to
> see usage of YANG features.
> 
> One fundamental question one could raise is whether this model should
> have been broken down into a generic NAT core model plus extensions of
> the core model for the different types of NATs. Well, a single model
> with YANG features is an inline version of that as this still requires
> to mark clearly which parts are specific to certain types or NATs.
> 
> I did not compile the module myself since the IETF tracker says no
> errors using pyang and yanglint (and I would not have run anything
> different). (Is it OK for YANG doctors to trust the tracker tools?
> Well, since this is labelled as an early review and I expect more
> updates, I assume this is fine.)
> 
> I can't tell whether the model makes sense from a NAT point of view. I
> am not an expert in the various types of NATs and surely more reviews
> of NAT experts would be good (and they would have likely spotted some
> things I have spotted, so I guess the usual problem of getting enough
> substantial reviews).
> 
> Details
> 
> - We use revision statements only for published modules. Hence, please
>   replace the revision statements with
> 
>   // RFC Ed. update to match the date of the latest edits
>   revision 2017-xx-yy {
>     description
>       "Initial revision.";
>     reference
>       "RFC XXXX: A YANG Data Model for Network Address Translation
>                  (NAT) and Network Prefix Translation (NPT)";
>   }
> 
> - We usually follow a different template for the contact statement
>   that has more context and just a list of names and email addresses.
> 
> - We usually write
> 
>      reference
>        "RFC 3022: Traditional IP Network Address Translator
>                   (Traditional NAT)";
> 
>   instead of just
> 
>      reference
>        "RFC 3022.";
> 
>   since not everybody remembers all the numbers equally well.
> 
> - Is there a reference for dst-nat?
> 
> - What is the vrf-routing-instance identity good for? Its used only in
>   the leaf external-vrf-instance and the description of that leaf is
>   not telling me how this is going to be used. Who is going to derive
>   identities? I fear you are trying to achieve something where using
>   identities is really the wrong approach. Section 2.10 does not tell
>   how this is supposed to work either. I assume this needs to be
>   checked by the routing area experts to make sure things fit with
>   their modeling of VRFs.
> 
> - s/start-port-numbert/start-port-number/
> 
> - Are comments like
> 
>   // port numbers: single or port-range
> 
>   necessary given that there are description statements? Note that
>   comments may be removed by tools while description statements
>   usually are preserved. So it is important to have anything important
>   covered in description statements.
> 
> - What is a PSID algorithm? Spell out acronyms on first usage.
> 
> - The leafs start-port-number and end-port-number are commented out in
>   port-range, probably in favour of the uses port-number. If they are
>   not needed anymore, they should be removed.
> 
> - I do not understand port-set-algo from the descriptions. What is the
>   psid-offset applied? What is a 'sharing ration for an IPv4 address'?
>   Is this stuff IPv4 specific? Is the psid something that has a
>   certain meaning outside of this YANG module? If so, where do I find
>   more details (missing reference statement?)?
> 
> - mapping-entry/index: is this an arbitrary identifier? how are these
>   identifiers allocated? Are they created by the NAT or are they created
>   via configuration? Or even both? Well, I guess it is both given the
>   mapping-entry/type leaf.
> 
> - mapping-entry/type: instead 'manually configured', I would write
>   'explicitly configured' (configuration does not have to be a manual
>   process). I also find the other enum labels at least a bit confusing.
> 
>         enum "dynamic-explicit" {
>           description
>             "This mapping is created by an
>              outgoing packet.";
>         }
>         
>         enum "dynamic-implicit" {
>           description
>             "This mapping is created by an
>              explicit  dynamic message.";
>         }
> 
>   Note the 'implicit' vs 'explicit' clash here. Perhaps this should be
>   aligned with the definition of dynamic and implicit mappings:
> 
>    o  Dynamic implicit mapping: is created implicitly as a side effect
>       of traffic such as an outgoing TCP SYN or an outgoing UDP packet.
>       A validity lifetime is associated with this mapping.
> 
>    o  Dynamic explicit mapping: is created as a result of an explicit
>       request, e.g., PCP message [RFC6887].  A validity lifetime is
>       associated with this mapping.
> 
>   But then it seems you really messed things up here. I would even
>   write these definitions differently since 'outgoing' is unclear and
>   potentially confusing.
> 
>    o  Dynamic implicit mapping: is created implicitly as a side effect
>       of processing a packet (e.g., an initial TCP SYN packet) that
>       requires a new mapping. A validity lifetime is associated with
>       this mapping.
> 
>    o  Dynamic explicit mapping: is created as a result of an explicit
>       request, e.g., PCP message [RFC6887].  A validity lifetime is
>       associated with this mapping.
> 
>    Similarly, I would change the description of
> 
>         enum "dynamic-implicit" {
>           description
>             "This mapping is created implicitely as a side effect
>              of processing a packet that requires a new mapping.";
>         }
> 
>         enum "dynamic-explicit" {
>           description
>             "This mapping is created as a result of an explicit
>              request, e.g., a PCP message.";
>         }
> 
> - We should perhaps have a type for an IP protocol number, ideally in
>   inet-types. (Just a reminder to myself.) That said, I do not
>   understand what this sentence means:
> 
>     No transport protocol is indicated if a mapping applies for
>     any protocol.
> 
>   Perhaps you wanted to say this:
> 
>     If this leaf is not instantiated, then the mapping applies to any
>     protocol.
> 
> - container internal-src-port:
> - container external-src-port:
> - container internal-dst-port:
> - container external-dst-port:
> 
>          It is used also to carry the internal
>          source ICMP identifier.";
> 
>   I think details are lacking here. What is the ICMP identifier? What
>   does 'carry' mean and how does this relate to the port-number
>   grouping?
> 
>   See above, I do not understand the ICMP identifier statement.
> 
> - lifetime:
> 
>   Spell out 3WHS. I think there should be a units statement. And is
>   this a ticking lifetime, i.e., this changes on every get request? Is
>   this useful? Have alternatives been considered such as reporting the
>   point in time when the mapping was established? Or is the idea that
>   the lifetime reports the time left until the mapping will be garbage
>   collected? What does "tracks the connection" really mean here?
> 
> - I suggest to remove empty lines in say leaf definitions. Instead
> 
>       leaf id {
>         type uint32;
> 
>         description
>           "NAT instance identifier.";
> 
>         reference
>           "RFC 7659.";
>       }
> 
>   write
> 
>       leaf id {
>         type uint32;
>         description
>           "NAT instance identifier.";
>         reference
>           "RFC 7659: Definitions of Managed Objects for Network
>                      Address Translators (NATs)";
>       }
> 
> - It seems you try to be aligned with the NATV2-MIB module but there
>   is no explicit discussion about this in the document. I suggest that
>   you a section (for example before the tree diagram) where you
>   discuss how this YANG module coexists with the NATV2-MIB module.
> 
>   For example, I see that Natv2InstanceIndex in the MIB module
>   excludes 0 as an instance identifier while your id leaf above allows
>   the usage of 0.
> 
> - container nat-capabilities:
> 
>   Here we find a bunch of "config true" leafs and I wonder how these
>   work. There are things a NAT implementation is capable to do, and
>   there are things that are enabled in a NAT deployment and of course
>   you can't enable something in a deployment that has not been
>   implemented. So are these 'capabilities' more like NAT features
>   enabled (since we have "config true" nodes) or are these more
>   implemented capabilities (but then "config true" may be wrong)?
>   Depending on the answer, did you consider using YANG features?
> 
> - nat-flavor and nat44-flavor:
> 
>   Does it make sense to have two objects here? Can I put basic-nat
>   into nat-flavor? Are the differences between lets say napt and
>   basic-nat really nat44 specific?
> 
>   Note that you also derive restricted-nat from nat44 but this option
>   is not mentioned in the description of nat44-flavor. I think the
>   description should be more open since in principle I can derive even
>   more identities in the future.
> 
> - boolean capability flags
> 
>   Do these need references so one can lookup what the exact meaning of
>   these 'capabilities' are? It would surely help me and it will help
>   implementors that need to decide whether a certain vendor feature
>   fits any of these.
> 
> - nat-pass-through-pref
> 
>   Perhaps spell out nat-pass-through-prefix (pref might also be
>   understood as preference). And perhaps change the wording in the
>   description
> 
>   OLD
> 	    "The IP address subnets that match
>              should not be translated. According to
> 
>   NEW
> 	    "IP addresses matching this prefix are
>              not be translated. According to
> 
> - Sometimes you repeat prefixes in leaf definitions (e.g.,
>   nat-pass-through-port) while at other times you do not.
> 
> - nat-pass-through-port
> 
>   You seem to have copy pasted the description of
>   nat-pass-through-pref.  Is this a single port? So I need multiple
>   nat-pass-through entries for multiple ports. Fine. But is there a
>   special meaning if both nat-pass-through-pref and
>   nat-pass-through-port are configured in a single list entry? Does
>   this mean the port is scoped to the prefix?
> 
> - Some nat type specific parameter lists are flat, for others there is
>   an additional container. Is this by design?
> 
> - I meanwhile think there really should be features. Certain lists
>   only make sense for implementations that support certain NAT
>   types. Having features defined allows code generators to easily
>   generate stubs that actually match the capabilities of an
>   implementation. And you automatically benefit from feature
>   announcements.
> 
> - s/attachedto/attached to/
> 
> - s/prefixs./prefixes./
> 
> - nat64-prefix
> 
>   What is the purpose of //default "64:ff9b::/96"; ??
> 
> - stateless-enable
> 
>   Does this enable leaf make sense on a list entry? Perhaps it does
>   but the description is fairly general and hence I am asking.
> 
> - external-ip-address-pool/pool-id
> 
>   This seems to relate to a Natv2PoolIndex, which again excludes the
>   value 0. I have not checked all such related things, so please go
>   and check yourself.
> 
> - external-ip-address-pool
> 
>   The description says
> 
>             Both contiguous and non-contiguous pools
>             can be configured for NAT purposes.";
> 
>   but it seems more accurate to say that a pool is a set of prefixes
>   since this is what the model suggests.
> 
> - supported-transport-protocols
> 
>   I am again not clear whether you are reporting implementation
>   capabilities here or enabled features or something else. Is the
>   configuration of transport-protocol-id and transport-protocol-name
>   mutually exclusive? If so, should this be a choice? If I can
>   configure both, I assume they have to be consistent.
> 
> - transport-protocol-name
> 
>   Is this restricted to the acronyms that are used in the IANA
>   protocol numbers registry?
> 
> - s/masck/mask/
> 
> - subscriber-mask-v6
> 
>   The name seems to indicate that this only applies to IPv6 prefixes
>   handed out to CPEs. Perhaps this should be stated explicitely (but
>   yes it is unlike to ever get an IPv4 prefix). But then, the
>   subscriber-match has an IPv4 prefix example.
> 
> - quota-type
> 
>   Is this a good name for the leaf? This seems to indicate for which
>   transport protocol a port-limit is enforced. And this list is
>   restricted to TCP, UDP, and ICMP while other parts of the model are
>   more flexible in supporting additional transport protocols. So is it
>   consistent to a rather restricted enum here?
> 
> - port-set-timeout
> 
>   Needs a units statement.
> 
> - timeouts
> 
>   Can I make the timeouts arbitrarily small, in the extreme case 0
>   seconds? In some cases I find text like "for at least 6 seconds".
>   Does this mean that the range is really uint32 { range "6..max"; }?
>   Or is it still OK to configure the value 3 and the 'must' is really
>   a 'should'?
> 
> - port-timeout
> 
>   I doubt this is of type inet:port-number and there likely needs to
>   be a units statement.
> 
> - alg-name
> 
>   Is there a list of well-known ALG names? IANA? Or is this a random
>   string that one needs to guess form the vendor's documentation,
>   i.e., this is potentially not interoperable out of the box? Is there
>   a way to obtain the number of ALGs supported or is the idea to do
>   trial and error probing to find out (which is even harder if there
>   are no well-known ALG names)?
> 
> - all-algs-enable
> 
>   This says "Enable/disable all ALGs." but I _assume_ that I set this
>   to false and to enable specific ALGs. Perhaps this interaction needs
>   to be spelled out.
> 
> - Is there any throttling mechanism needed in case my NAT is
>   constantly operating around the notification thresholds?
> 
> - Add units to the mapping limit definitions ("subscribers",
>   "mappings", ...)
> 
> - limit-per-subnet
> 
>   This is type inet:ip-prefix? I guess you wanted something else here.
> 
> - Why are some limits mandatory, others not?
> 
> - If you write 'limit per subscriber', how is a subscriber identified?
>   I assume these are global per subscriber limits, i.e., all
>   subscribers receive the same limit.
> 
> - limit-per-subnet
> 
>           leaf limit-per-subnet {
>             type inet:ip-prefix;
> 
>             description
>               "Rate-limit the number of new mappings
> 	       and sessions per subnet.";
>           }
> 
>   I do not see how this works. The other limit-per-XXX objects are
>   numbers - presumably defining the limit. This is a prefix?
> 
> - logging-info
> 
>   Is this information complete? Perhaps it is for plain syslog
>   (without any security) but I doubt the info is complete for the
>   other transports mentioned, at least not for FTP. And surely, if you
>   want to protect the logging information, then you will neeed way
>   more parameters. And what does 'retrieving' logging entries mean?  I
>   assume with syslog and ipfix you push log messages. I am less sure
>   about FTP. Perhaps less is more and simply provide support for
>   syslog and leave the other options for extensions. You have a choice
>   in place, so not need to go and deal with all possible complexity
>   here.
> 
> - For the statistics, we used to use plural form for counters back in
>   SNMP land and I think this was good practice. So go with
>   sent-packets, sent-bytes, rcvd-packets, rcvd-bytes, dropped-packets,
>   dropped-bytes, ...
> 
> - total-mappings, total-tcp-mappings, total-udp-mappings,
>   total-icmp-mappings: These may use yang:gauge32.
> 
> - address-allocated, address-free -> addresses-allocated, addresses-free
>   (may also be yang:gauge32)
> 
> - Some of these gauges might fluctuate fast (maybe consider
>   exponentially smoothed gauges, but this might also be left for an
>   extension).
> 
> - The security considerations text should follow the new boilerplate
>   that also covers RESTCONF. I think it would help to be more specific
>   about the security aspects of this data model. This text is quite
>   generic. With a NAT, things even have privacy aspects. If I can
>   force a specific NAT mapping, I can track a subscriber.
> 
> - At least one example has syntax errors. Examples should ideally be
>   validated by tools so that the examples are syntactically correct and
>   valid regarding the data model.
> 
> 
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Oct 29 06:13: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 B3FCF13FE8F for ; Sun, 29 Oct 2017 06:13:02 -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=[AC_DIV_BONANZA=0.001, 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 DybCWBdd3U7p for ; Sun, 29 Oct 2017 06:13:01 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 2BDF113F746 for ; Sun, 29 Oct 2017 06:13:01 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id p75so10845128wmg.3 for ; Sun, 29 Oct 2017 06:13:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=ZIKy7v6mbhJFMEyRyMU+5Am9vuuiWkjeU9n2GIaCHjM=; b=ulPbc6Kf0jlwfxauM3k4XKsamB6ICYpb/hoJFFXTtoHMLkTr6tv7U2koCs7guxdqCF 9Ci//QsbG/zCmIakXaEpIahV36qB9BbOf7xSdSPSjR8j+cQE2nCXrL9WwYK2lBPdA12l dOKCn5CE5kdOTBrmO6dsbqtl/WeAFyc8h3i6MKwznoZqOIPxrIxfqblYf8Wxajdm+9aH iNBHcmgg5jtD/dGpCu3ag7csfIDcDcSA9YHVvvH4CMGu7piiZuQmtpRqgoLPkP33N1jK E0c5RWLKf/7tT7WMiHQ1t3i/UQzgRyz2gYrv82OAns6oNdqPGCCPbFIvKEK4lHpI3uGU iySA==
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=ZIKy7v6mbhJFMEyRyMU+5Am9vuuiWkjeU9n2GIaCHjM=; b=HtDPHnwnOZ9MS/AzT+bYJMsLtnt/gTiQ4PjiWjsahiAsaj5/AOO41p/aYdVwM17B3r wFCFyAxXT95O4tJvxuzrR1QHof04Cqv4+762AOQoA31c0U7Icx4Irx35sePy3LpkkftE z6Yn7dqNF1+glPeNI/wuS3Z2lAqsubkyeSyg2kIBVrP+gFZZM7Mgv2YPA6gDD3K+wpaM 4BpoRKBoQYo6CrEpoi5/9hcDXR0fSwUhk0RhUHk0mefP/Wzqa4CCaS8NdICkzHzExU0e ivdCcNfkwHsjnZUlr1oFOUUcnb8HpjacrtVly/+wR83xrNBr0yT7/C763MkDJmhbrOgQ aSsQ==
X-Gm-Message-State: AMCzsaW20z+Fvo/Cec3oe5uQR81yZN8Y7m3AUtsH/GSFmXLkoDDFEHoZ GdBBKqeB003jAHMMu63tprlM3IP6xar6q1eVtzr48A==
X-Google-Smtp-Source: ABhQp+Rks7ZTITECjQoCnn3kl3VOmZbdYQ2Tdg0Va2kq6JTysgX0b+A/gdx+jCzztqCzg1+GQm/WcyksMdfG7x0A7zI=
X-Received: by 10.28.146.20 with SMTP id u20mr1597223wmd.49.1509282779268; Sun, 29 Oct 2017 06:12:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Sun, 29 Oct 2017 06:12:18 -0700 (PDT)
From: "M. Ranganathan" 
Date: Sun, 29 Oct 2017 09:12:18 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a11442fbcec8a8e055caf47df"
Archived-At: 
Subject: [OPSAWG] MUD draft 13: ietf-acldns Another YANG question
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, 29 Oct 2017 13:13:02 -0000

--001a11442fbcec8a8e055caf47df
Content-Type: text/plain; charset="UTF-8"

I see that a grouping is used in ietf-acldns i.e.


 dns-matches {
    description "Domain names for matching.";

    leaf src-dnsname {
      type inet:host;
      description "domain name to be matched against";
    }
    leaf dst-dnsname {
      type inet:host;
      description "domain name to be matched against";
    }
  }


  augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/" +
     "acl:matches/acl:ipv4-acl" {
    description "Adding domain names to matching";
    uses dns-matches;
   }


This allows src-dnsname and dst-dnsname to appear in from-device-policy and
to-device-policy.

Is it possible to restrict this such that src-dnsname only appears in
to-device-policy and dst-dnsname only appears in from-device-policy.

If not possible via YANG, can language be added to the spec to indicate the
restriction above?

Thanks,

Ranga.

-- 
M. Ranganathan

--001a11442fbcec8a8e055caf47df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I see that a grouping is used in ietf-=
acldns i.e.


=C2=A0dns-matches {
=C2=A0=C2=A0=C2=A0 descriptio=
n "Domain names for matching.";

=C2=A0=C2=A0=C2=A0 leaf sr=
c-dnsname {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type inet:host;
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 description "domain name to be matched against&q=
uot;;
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 leaf dst-dnsname {
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type inet:host;
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 description "domain name to be matched against";
=C2=A0=
=C2=A0=C2=A0 }
=C2=A0 }


=C2=A0 augment "/acl:access-list=
s/acl:acl/acl:aces/acl:ace/" +
=C2=A0=C2=A0=C2=A0=C2=A0 "acl:m=
atches/acl:ipv4-acl" {
=C2=A0=C2=A0=C2=A0 description "Adding =
domain names to matching";
=C2=A0=C2=A0=C2=A0 uses dns-matches;
=
=C2=A0=C2=A0 }


This allows src-dnsname and dst-dnsname to =
appear in from-device-policy and to-device-policy.

Is it possi=
ble to restrict this such that src-dnsname only appears in to-device-policy=
 and dst-dnsname only appears in from-device-policy.

If n=
ot possible via YANG, can language be added to the spec to indicate the res=
triction above?

Thanks,

Ranga.
<=
div>

-- 
M. Ranganathan




--001a11442fbcec8a8e055caf47df--


From nobody Sun Oct 29 07:47:38 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 E37ED13AF04 for ; Sun, 29 Oct 2017 07:47:37 -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=[AC_DIV_BONANZA=0.001, 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 fhYrfbn9wKxP for ; Sun, 29 Oct 2017 07:47:36 -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 9B75513F556 for ; Sun, 29 Oct 2017 07:47:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7509; q=dns/txt; s=iport; t=1509288455; x=1510498055; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=6ijg4IKQuuUYwwDZDQuy2vu0KYOv0HmhTQB7k8GjnzQ=; b=SEEt647CcCnuWzqJF3dBUbvlaco8riTSP/RgAuuGxEc2AgXjAmv5nPdS BTCN/hOLlnMbzuPOHguO/ZxszmdiIMUzJMCQr6oaLzfL/T2DcaV0rSqxG yaGj8c+mTuoQ4bQUqOTl7zQZw6UzKR/R6cXR1/bLQ6my7w9o5fj6xi+XX 8=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAADD6PVZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N8ih90kBmQfYVFghEHAxgBCoRJTwKFChgBAgEBAQEBAQF?= =?us-ascii?q?rKIUeAQEBAwEBIUsbCQIYKgICJzAGAQwGAgEBih8QiXidZ4InJopUAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBDgoFgy6FbIMBiCaCYQWRWocoiQGEQoIjjheLdIc5iGC?= =?us-ascii?q?NMIE5HziBaDQhCB0VSYJkhGBANotOAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,314,1505779200";  d="asc'?scan'208,217";a="698310999"
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; 29 Oct 2017 14:47:33 +0000
Received: from [10.61.239.244] ([10.61.239.244]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9TElWkR016996; Sun, 29 Oct 2017 14:47:33 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References: 
From: Eliot Lear 
Message-ID: 
Date: Sun, 29 Oct 2017 15:47:28 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3CKs7xP8GHfOkANQSiP61aHoOMEVbmuGG"
Archived-At: 
Subject: Re: [OPSAWG] MUD draft 13: ietf-acldns Another YANG question
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, 29 Oct 2017 14:47:38 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--3CKs7xP8GHfOkANQSiP61aHoOMEVbmuGG
Content-Type: multipart/mixed; boundary="vRW4oxuhfSA6bRprGveTDj3nB1a25EDOE";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" , opsawg@ietf.org
Message-ID: 
Subject: Re: [OPSAWG] MUD draft 13: ietf-acldns Another YANG question
References: 
In-Reply-To: 

--vRW4oxuhfSA6bRprGveTDj3nB1a25EDOE
Content-Type: multipart/alternative;
 boundary="------------C344C4F4592FB92E2EBD1D0C"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------C344C4F4592FB92E2EBD1D0C
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 10/29/17 2:12 PM, M. Ranganathan wrote:
> I see that a grouping is used in ietf-acldns i.e.
>
>
> =C2=A0dns-matches {
> =C2=A0=C2=A0=C2=A0 description "Domain names for matching.";
>
> =C2=A0=C2=A0=C2=A0 leaf src-dnsname {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type inet:host;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description "domain name to be matched a=
gainst";
> =C2=A0=C2=A0=C2=A0 }
> =C2=A0=C2=A0=C2=A0 leaf dst-dnsname {
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type inet:host;
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description "domain name to be matched a=
gainst";
> =C2=A0=C2=A0=C2=A0 }
> =C2=A0 }
>
>
> =C2=A0 augment "/acl:access-lists/acl:acl/acl:aces/acl:ace/" +
> =C2=A0=C2=A0=C2=A0=C2=A0 "acl:matches/acl:ipv4-acl" {
> =C2=A0=C2=A0=C2=A0 description "Adding domain names to matching";
> =C2=A0=C2=A0=C2=A0 uses dns-matches;
> =C2=A0=C2=A0 }
>
>
> This allows src-dnsname and dst-dnsname to appear in
> from-device-policy and to-device-policy.
>
> Is it possible to restrict this such that src-dnsname only appears in
> to-device-policy and dst-dnsname only appears in from-device-policy.
>
> If not possible via YANG, can language be added to the spec to
> indicate the restriction above?

I would have no objection adding some clarifying language in the draft.

Eliot
>
> Thanks,
>
> Ranga.
>
> --=20
> M. Ranganathan
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg


--------------C344C4F4592FB92E2EBD1D0C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    

    
On 10/29/17 2:12 PM, M. Ranganathan
      wrote:

    

    

      
      

        

          

            

              
I see that a grouping is used in ietf-acldns i.e.

                

                

                =C2=A0dns-matches {

                =C2=A0=C2=A0=C2=A0 description "Domain names for matching=
=2E";

                

                =C2=A0=C2=A0=C2=A0 leaf src-dnsname {

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type inet:host;

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description "domain name t=
o be matched against";

                =C2=A0=C2=A0=C2=A0 }

                =C2=A0=C2=A0=C2=A0 leaf dst-dnsname {

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type inet:host;

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description "domain name t=
o be matched against";

                =C2=A0=C2=A0=C2=A0 }

                =C2=A0 }

                

                

                =C2=A0 augment "/acl:access-lists/acl:acl/acl:aces/acl:ac=
e/"
                +

                =C2=A0=C2=A0=C2=A0=C2=A0 "acl:matches/acl:ipv4-acl" {
=

                =C2=A0=C2=A0=C2=A0 description "Adding domain names to ma=
tching";

                =C2=A0=C2=A0=C2=A0 uses dns-matches;

                =C2=A0=C2=A0 }

                

                

              

              This allows src-dnsname and dst-dnsname to appear in
              from-device-policy and to-device-policy.

              

            

            Is it possible to restrict this such that src-dnsname only
            appears in to-device-policy and dst-dnsname only appears in
            from-device-policy.

            

          

          
If not possible via YANG, can language be added to the
            spec to indicate the restriction above?

          

        

      

    

    

    I would have no objection adding some clarifying language in the
    draft.

    

    Eliot

    

      

        

          


          

          Thanks,

          

        

        Ranga.

        

          

            

              

                

                  

                    

                      

                        

                          

                            


                              -- 

                              
M.
                                Ranganathan

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

        

      

      

      

      

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


    

    

  


--------------C344C4F4592FB92E2EBD1D0C--

--vRW4oxuhfSA6bRprGveTDj3nB1a25EDOE--

--3CKs7xP8GHfOkANQSiP61aHoOMEVbmuGG
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

iQEcBAEBCAAGBQJZ9eoBAAoJEIe2a0bZ0nozZu8H/3SgvivpFWcw99TVZ7XjrTgs
zhRmiZxrvYHO8KVDRGZRc9mrEXwMX2OTNOHrh5xFIj2LfRE1jSRe3xIqSe8XAvkU
58fuf2jw/iKIHhFiE6qrN1S0QCwWYU/edLKC1V6LBc3W/XTLgUNxNdafTsiq3yUf
G6hx5Pu+AJFoOyUa9xSXy7hJaU6A6bfg9D9TUwH7e9pioPzMYMd9tjRKmThbKe2N
lr3IkekewbEKa1ilSp55n7uZ5rL6XPID4bicmUyW27XibaMCXeAulm5rNskKK1je
/3fXvYhh2FLmYgMj4+tPcgSXmc6Qf5MULaqO8h6IapayeqbQ9WHeZ6YgQPduX+Q=
=/xOA
-----END PGP SIGNATURE-----

--3CKs7xP8GHfOkANQSiP61aHoOMEVbmuGG--


From nobody Sun Oct 29 09:22: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 D264213F5B1 for ; Sun, 29 Oct 2017 09:22:44 -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 bs8RnXgBxqkN for ; Sun, 29 Oct 2017 09:22:43 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAC913F49F for ; Sun, 29 Oct 2017 09:22:43 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id y39so10252167wrd.4 for ; Sun, 29 Oct 2017 09:22:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=iU3+N3VzPgIVw/4M1OospKTu1TxvY03QdTFFBFrV/l8=; b=dQ7v1Z2wWaAZEIqpFewqQf/QgeGFqHdyLVoHi/yHxw3hO2hX1IqsNsPLBvOSS2UM0u eTxd3r+Hz7ITG3ajJMRjj3jAkT3m/t3YCLoj9GZj+RPbK53kVy2B7gg5JCsPEm9V4jrx 7kK+aSbbhzV5YISDq588Ttd4dSP8bJWF0jpNKzrlAqt6XJGiSi9Xzcn1TtgkL3NCQDkJ 8ulnCxvUo2lzIXwjwek+S5G1whKHP44CJQ9jTtvqpUfHO80Pexz30JQbq0/r2nECSZMW mjPyAu2djtP5v2s4sjmVh/CkWNClya9d45UxhpbWGcFGI2nHlsDFgJGwkQHoOfHJ49/O DJiQ==
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=iU3+N3VzPgIVw/4M1OospKTu1TxvY03QdTFFBFrV/l8=; b=GfqjzbSDfegME7kvPHJJXEreFFXqJmjkDwsNeiWrdv36fA1z5BPfW0X7gaSWAFrDhF lidBsEfJ2tfUd3hrzTcqoNqzDD9zbtuZ9MY3nozWQ6zXiiE1awa/4aFv1DNhvUeKfL6O gxvCb5+c2mWcL9E6cJxcX3Qgor0GfoBEIo5T1pstJZyeapCFn4lrukvauh/89v02ORKE 1WD11bOXcWMYqQDBJWIQ+NWMmidAvqZtUGBvuaUWxoHyEJj3F2JLubIgQiAqCAug5XC+ 0EQIjqq27oJdEBxy4YVdU3jfG5nF2zf6N79w06D4LG/Vi/ODscDm7XO5p17TkXs9E7yi Zqqg==
X-Gm-Message-State: AMCzsaVOtdCk04tzL5O9jFla7d/+WcRMr3CLNGu00c3f7RpnOzEETzka 9diBcziSyMhWYZr06ierJ0NzuFIio9dwN50iCFtUow==
X-Google-Smtp-Source: ABhQp+SS2FN/BwLwBVF5fyY28sxL3MrkjOaDl4Uiuxy0wFgWpO+XmA93pe06Puu/6OBUQnaZPLCt+16/FNNbS21OEBc=
X-Received: by 10.223.150.116 with SMTP id c49mr5031695wra.246.1509294161258;  Sun, 29 Oct 2017 09:22:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.152.149 with HTTP; Sun, 29 Oct 2017 09:22:00 -0700 (PDT)
From: "M. Ranganathan" 
Date: Sun, 29 Oct 2017 12:22:00 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="001a1147d4ac57eec7055cb1ee32"
Archived-At: 
Subject: [OPSAWG] MUD draft 13: ietf-acldns suggested augmentation.
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, 29 Oct 2017 16:22:45 -0000

--001a1147d4ac57eec7055cb1ee32
Content-Type: text/plain; charset="UTF-8"

The MUD draft says ACL names should be scoped by file.

The following augmentation to ietf-acldns would make the association
explicit :

51a52,61
>   augment "/acl:access-lists/acl:acl/" {
>     description
>          "MUD URI to associate the  ACL to a MUD scope";
>     leaf mud-url {
>         type inet:uri;
>         description
>            "The MUD URI to associate with this ACL";
>     }
>   }
>


Thereby, scoping by file would be avoided.

Thanks,

Ranga

-- 
M. Ranganathan

--001a1147d4ac57eec7055cb1ee32
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The MUD draft says ACL names should be=
 scoped by file. 

The following augmentation to ietf-acldns wo=
uld make the association explicit :

51a52,61
>=C2=A0=C2=A0 aug=
ment "/acl:access-lists/acl:acl/" {
>=C2=A0=C2=A0=C2=A0=C2=
=A0 description 
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 "MUD URI to associate the=C2=A0 ACL to a MUD scope";
>=
=C2=A0=C2=A0=C2=A0=C2=A0 leaf mud-url {
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 type inet:uri;
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 description
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "The MUD URI to associate with this ACL=
";
>=C2=A0=C2=A0=C2=A0=C2=A0 }
>=C2=A0=C2=A0 }
> 

Thereby, scoping by file would be avoided.

Than=
ks,

Ranga
=

-- 
M. Ranganathan




--001a1147d4ac57eec7055cb1ee32--


From nobody Sun Oct 29 09:34:46 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 9FBB313F5C6 for ; Sun, 29 Oct 2017 09:34:44 -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 8Q411b9CPofY for ; Sun, 29 Oct 2017 09:34:43 -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 80E0D13B42C for ; Sun, 29 Oct 2017 09:34:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6347; q=dns/txt; s=iport; t=1509294882; x=1510504482; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=xM5vinzsvWXTHSmoHN4PljC7TQZTbNv/F+DH3QkEUAU=; b=K4PmKEH/IfqsY/YWS/hmSQ9bgmqjHjozofi4nC5mbFgzX9lkTwmMZ0ix HXz01QdtS1dqfUvQjl4IiitaMciBZ2ASJUtGGjeIpJH671G4USPTQmJV0 iQUaHCoNAxD2s9YJyYfcMoXVyY1aA4XxgDYB9fgNv1i4i43dGBWIgzVbn 4=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAACoAvZZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhENuJ4N8ih90j3MmkH2FRYIRBwMYAQqESU8CGoRwGAECAQEBAQE?= =?us-ascii?q?BAWsohR4BAQEDAQEhSxsJAgQUKgICAiUwBgEMBgIBAYofEIoHnWeCJyaKVAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQ4KBYMuhWwLgnaIJoJhBaIDhEKCI44Xi3SHOZY?= =?us-ascii?q?QgTkfOIFoNCEIHRVJgmSEYEA2i1MBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,315,1505779200";  d="asc'?scan'208,217";a="655743045"
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; 29 Oct 2017 16:34:40 +0000
Received: from [10.61.239.244] ([10.61.239.244]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v9TGYdXE022165; Sun, 29 Oct 2017 16:34:40 GMT
To: "M. Ranganathan" , opsawg@ietf.org
References: 
From: Eliot Lear 
Message-ID: <0703ada7-6421-b2f8-4823-7c0063bd46f6@cisco.com>
Date: Sun, 29 Oct 2017 17:34:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NESrrtdl1j54GGhJTxnwnlHrGpFDg60j0"
Archived-At: 
Subject: Re: [OPSAWG] MUD draft 13: ietf-acldns suggested augmentation.
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, 29 Oct 2017 16:34:45 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--NESrrtdl1j54GGhJTxnwnlHrGpFDg60j0
Content-Type: multipart/mixed; boundary="OHggGibODJW7R54Hbbn9H3wJxdFoPHqe7";
 protected-headers="v1"
From: Eliot Lear 
To: "M. Ranganathan" , opsawg@ietf.org
Message-ID: <0703ada7-6421-b2f8-4823-7c0063bd46f6@cisco.com>
Subject: Re: [OPSAWG] MUD draft 13: ietf-acldns suggested augmentation.
References: 
In-Reply-To: 

--OHggGibODJW7R54Hbbn9H3wJxdFoPHqe7
Content-Type: multipart/alternative;
 boundary="------------796191E20BBA2880D9192BD3"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------796191E20BBA2880D9192BD3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SSdtIG5vdCBzdXJlIHRoYXQgZG9lcyB3aGF0IHlvdSB3YW50IGl0IHRvIGRvLCBSYW5nYS7C
oCBBbGwgaXQgZG9lcyBpcwphZGQgYW4gaW5mb3JtYXRpb24gZWxlbWVudCB0aGF0IGlzIGFj
dHVhbGx5IGFscmVhZHkgcHJlc2VudCB3aXRoaW4gdGhlCk1VRCBtb2RlbC7CoCBCdXQgeW91
IGNhbiBkbyB0aGF0IGluIHlvdXIgb3duIGltcGxlbWVudGF0aW9uLCBhbmQgbm8gaGFybQp3
aWxsIGNvbWUgb2YgaXQuCgpFbGlvdAoKT24gMTAvMjkvMTcgNToyMiBQTSwgTS4gUmFuZ2Fu
YXRoYW4gd3JvdGU6Cj4gVGhlIE1VRCBkcmFmdCBzYXlzIEFDTCBuYW1lcyBzaG91bGQgYmUg
c2NvcGVkIGJ5IGZpbGUuCj4KPiBUaGUgZm9sbG93aW5nIGF1Z21lbnRhdGlvbiB0byBpZXRm
LWFjbGRucyB3b3VsZCBtYWtlIHRoZSBhc3NvY2lhdGlvbgo+IGV4cGxpY2l0IDoKPgo+IDUx
YTUyLDYxCj4gPsKgwqAgYXVnbWVudCAiL2FjbDphY2Nlc3MtbGlzdHMvYWNsOmFjbC8iIHsK
PiA+wqDCoMKgwqAgZGVzY3JpcHRpb24KPiA+wqDCoMKgwqDCoMKgwqDCoMKgICJNVUQgVVJJ
IHRvIGFzc29jaWF0ZSB0aGXCoCBBQ0wgdG8gYSBNVUQgc2NvcGUiOwo+ID7CoMKgwqDCoCBs
ZWFmIG11ZC11cmwgewo+ID7CoMKgwqDCoMKgwqDCoMKgIHR5cGUgaW5ldDp1cmk7Cj4gPsKg
wqDCoMKgwqDCoMKgwqAgZGVzY3JpcHRpb24KPiA+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAi
VGhlIE1VRCBVUkkgdG8gYXNzb2NpYXRlIHdpdGggdGhpcyBBQ0wiOwo+ID7CoMKgwqDCoCB9
Cj4gPsKgwqAgfQo+ID4KPgo+Cj4gVGhlcmVieSwgc2NvcGluZyBieSBmaWxlIHdvdWxkIGJl
IGF2b2lkZWQuCj4KPiBUaGFua3MsCj4KPiBSYW5nYQo+Cj4gLS0gCj4gTS4gUmFuZ2FuYXRo
YW4KPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KPiBPUFNBV0cgbWFpbGluZyBsaXN0Cj4gT1BTQVdHQGlldGYub3JnCj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cKCg==
--------------796191E20BBA2880D9192BD3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
I'm not sure that does what you want it to do, Ranga.=C2=A0 All it=

      does is add an information element that is actually already
      present within the MUD model.=C2=A0 But you can do that in your own=

      implementation, and no harm will come of it.

    

    Eliot

    

    
On 10/29/17 5:22 PM, M. Ranganathan
      wrote:

    

    

      
      

        

          

            

              
The MUD draft says ACL names should be scoped by
                file. 

                

              

              The following augmentation to ietf-acldns would make the
              association explicit :

              

              51a52,61

              >=C2=A0=C2=A0 augment "/acl:access-lists/acl:acl/" {
=

              >=C2=A0=C2=A0=C2=A0=C2=A0 description 

              >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
"MUD URI to associate the=C2=A0 ACL to a MUD
              scope";

              >=C2=A0=C2=A0=C2=A0=C2=A0 leaf mud-url {

              >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type i=
net:uri;

              >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 descri=
ption

              >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 "The MUD URI to associate with this ACL";

              >=C2=A0=C2=A0=C2=A0=C2=A0 }

              >=C2=A0=C2=A0 }

              > 

              

              

            

            Thereby, scoping by file would be avoided.

            

          

          Thanks,

          

        

        Ranga

        

          

            

              

                

                  

                    


                      -- 

                      
M. Ranganathan

                      

                    

                  

                

              

            

          

        

      

      

      

      

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


    

    

  


--------------796191E20BBA2880D9192BD3--

--OHggGibODJW7R54Hbbn9H3wJxdFoPHqe7--

--NESrrtdl1j54GGhJTxnwnlHrGpFDg60j0
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

iQEcBAEBCAAGBQJZ9gMYAAoJEIe2a0bZ0noziTIH+QHuLu5DwWZsEc8s01VF/QP2
q/dJv91zA1n/Yse+cCDq/e7Go0wJ5tbsYsqzEHiQiOVBgQo1dTlS7jPxd5DZzBrM
NfyKkcP69ZGJczOBvvJLcvOjpEy0MfKxxbj41nOB6Mi0fyxSKFgj7BWAqDmeDqHR
nliYxNDx00nTYtNtr9jGhtPWm4q6VlCgn0OV93mmFHiM18tB31jVUGb0iRTpRS81
5De31l9OXMUsqKpRFoGKDcH/IOEnT++WzC2xq+wItnWTQPviTMarcY7NwuMvkBXC
RMX2fH0HbVNsj8H0XZNaPT4tc309b28mdURe9KlULPocY+Gh8Q9jR4IMCt0m8A4=
=ov2j
-----END PGP SIGNATURE-----

--NESrrtdl1j54GGhJTxnwnlHrGpFDg60j0--


From nobody Sun Oct 29 15:58: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 7928D13F562 for ; Sun, 29 Oct 2017 15:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_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 Dixd_UklzWWz for ; Sun, 29 Oct 2017 15:58:04 -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 3AF8F13F501 for ; Sun, 29 Oct 2017 15:58:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8405; q=dns/txt; s=iport; t=1509317884; x=1510527484; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6jcB/pH9/ctCvORa9o6yl3cFVgO1qwNDdL+p6coKBc4=; b=bb5LMj/bICGyaQurqp9d0rcSE4DgDxHuk/2VdiuogZe+DqoLav2YmRKi LJYD0Q5KmaRhg2WjGi0w9u752ui7+vgGEjTgWHkYjkNCDmwPr6Qd5nCGJ 4Hoe3ensK6Ky1WEDREPDYafUYy9vkqLXqrFN8UuVLAjdyrEp4p1ms/X1v E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAADAW/ZZ/4cNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbieDfIofjxGSeYVFghEKGAEKhElPAhqEMT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFHgIBAwEBIUsLEAIBCD8DAgICJQsUEQIEAQ0FiT9kEKdjgieKeQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgy6CB4NlgwGIJi+CMgWRWocoiQEClHqTLYhgjQM?= =?us-ascii?q?CERkBgTgBHziBaHoVSS0BgjaEX3eLTgEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,316,1505779200"; d="scan'208,217"; a="23313120"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Oct 2017 22:58:03 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9TMw2Dr013550 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 29 Oct 2017 22:58:03 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 29 Oct 2017 18:58:02 -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.1320.000; Sun, 29 Oct 2017 18:58:02 -0400
From: "Einar Nilsen-Nygaard (einarnn)" 
To: Eliot Lear , "M. Ranganathan" 
CC: "opsawg@ietf.org" 
Thread-Topic: [OPSAWG] MUD draft 13: ietf-acldns Another YANG question
Thread-Index: AQHTULetaJ4uER9KlESPlhbst0fhsaL7K00AgABGAvk=
Date: Sun, 29 Oct 2017 22:58:02 +0000
Message-ID: <6E2B6C3C-82C8-4DE2-AB58-3222CEBFB8B5@cisco.com>
References: ,  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_6E2B6C3C82C84DE2AB583222CEBFB8B5ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] MUD draft 13: ietf-acldns Another YANG question
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, 29 Oct 2017 22:58:05 -0000

--_000_6E2B6C3C82C84DE2AB583222CEBFB8B5ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXTigJlzIG5vdCBlbnRpcmVseSBjbGVhciB0byBtZSB3aHkgd2Ugd291bGQgdHJ5IGFuZCBkbyB0
aGF0LCBldmVuIGlmIHdlIGNvdWxkICh3aGljaCB3ZSBjYW7igJl0KS4gSSBjYW4gc2VlIHBvdGVu
dGlhbGx5IHNlbnNpYmxlIHVzZSBjYXNlcyB3aGVyZSB5b3UgbWF5IG5lZWQgYm90aCBpbiB0aGUg
Y29udGV4dCBvZiBNVUQuIEFsc28sIHRoZSBhY2xkbnMgbW9kZWwgYXVnbWVudGF0aW9uIGhhcyBi
cm9hZGVyIGFwcGxpY2FiaWxpdHkgYmV5b25kIE1VRCwgc28gYW55IGF0dGVtcHQgdG8gaW1wb3Nl
IE1VRC1zcGVjaWZpYyByZXN0cmljdGlvbnMgd291bGQgYmUgYSBtaXN0YWtlLg0KDQpJZiBFbGlv
dCB3aXNoZXMgdG8gSSBhZGQg4oCcaGVyZeKAmXMgaG93IHdlIHNlZSB0aGlzIG1vZGVsIGJlaW5n
IHVzZWQgaW4gdGhlIGNvbnRleHQgb2YgTVVE4oCdLCBhbmQgbWFrZSBzb21lIGJlc3QtcHJhY3Rp
Y2UgcmVjb21tZW5kYXRpb25zLCBJ4oCZbSBmaW5lIHdpdGggdGhhdC4gQnV0IGl0IHNob3VsZG7i
gJl0IGJlIGEgTVVTVCBOT1QsIElNTy4NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQpPbiBPY3QgMjks
IDIwMTcsIGF0IDE0OjQ4LCBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbTxtYWlsdG86bGVhckBj
aXNjby5jb20+PiB3cm90ZToNCg0KDQoNCk9uIDEwLzI5LzE3IDI6MTIgUE0sIE0uIFJhbmdhbmF0
aGFuIHdyb3RlOg0KSSBzZWUgdGhhdCBhIGdyb3VwaW5nIGlzIHVzZWQgaW4gaWV0Zi1hY2xkbnMg
aS5lLg0KDQoNCiBkbnMtbWF0Y2hlcyB7DQogICAgZGVzY3JpcHRpb24gIkRvbWFpbiBuYW1lcyBm
b3IgbWF0Y2hpbmcuIjsNCg0KICAgIGxlYWYgc3JjLWRuc25hbWUgew0KICAgICAgdHlwZSBpbmV0
Omhvc3Q7DQogICAgICBkZXNjcmlwdGlvbiAiZG9tYWluIG5hbWUgdG8gYmUgbWF0Y2hlZCBhZ2Fp
bnN0IjsNCiAgICB9DQogICAgbGVhZiBkc3QtZG5zbmFtZSB7DQogICAgICB0eXBlIGluZXQ6aG9z
dDsNCiAgICAgIGRlc2NyaXB0aW9uICJkb21haW4gbmFtZSB0byBiZSBtYXRjaGVkIGFnYWluc3Qi
Ow0KICAgIH0NCiAgfQ0KDQoNCiAgYXVnbWVudCAiL2FjbDphY2Nlc3MtbGlzdHMvYWNsOmFjbC9h
Y2w6YWNlcy9hY2w6YWNlLyIgKw0KICAgICAiYWNsOm1hdGNoZXMvYWNsOmlwdjQtYWNsIiB7DQog
ICAgZGVzY3JpcHRpb24gIkFkZGluZyBkb21haW4gbmFtZXMgdG8gbWF0Y2hpbmciOw0KICAgIHVz
ZXMgZG5zLW1hdGNoZXM7DQogICB9DQoNCg0KVGhpcyBhbGxvd3Mgc3JjLWRuc25hbWUgYW5kIGRz
dC1kbnNuYW1lIHRvIGFwcGVhciBpbiBmcm9tLWRldmljZS1wb2xpY3kgYW5kIHRvLWRldmljZS1w
b2xpY3kuDQoNCklzIGl0IHBvc3NpYmxlIHRvIHJlc3RyaWN0IHRoaXMgc3VjaCB0aGF0IHNyYy1k
bnNuYW1lIG9ubHkgYXBwZWFycyBpbiB0by1kZXZpY2UtcG9saWN5IGFuZCBkc3QtZG5zbmFtZSBv
bmx5IGFwcGVhcnMgaW4gZnJvbS1kZXZpY2UtcG9saWN5Lg0KDQpJZiBub3QgcG9zc2libGUgdmlh
IFlBTkcsIGNhbiBsYW5ndWFnZSBiZSBhZGRlZCB0byB0aGUgc3BlYyB0byBpbmRpY2F0ZSB0aGUg
cmVzdHJpY3Rpb24gYWJvdmU/DQoNCkkgd291bGQgaGF2ZSBubyBvYmplY3Rpb24gYWRkaW5nIHNv
bWUgY2xhcmlmeWluZyBsYW5ndWFnZSBpbiB0aGUgZHJhZnQuDQoNCkVsaW90DQoNClRoYW5rcywN
Cg0KUmFuZ2EuDQoNCi0tDQpNLiBSYW5nYW5hdGhhbg0KDQoNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FX
R0BpZXRmLm9yZzxtYWlsdG86T1BTQVdHQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KT1BTQVdHIG1haWxpbmcgbGlzdA0KT1BTQVdHQGlldGYub3Jn
PG1haWx0bzpPUFNBV0dAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29wc2F3Zw0K

--_000_6E2B6C3C82C84DE2AB583222CEBFB8B5ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PjwvZGl2Pg0KPGRpdj5JdOKAmXMgbm90IGVudGlyZWx5IGNsZWFyIHRvIG1lIHdoeSB3ZSB3
b3VsZCB0cnkgYW5kIGRvIHRoYXQsIGV2ZW4gaWYgd2UgY291bGQgKHdoaWNoIHdlIGNhbuKAmXQp
LiBJIGNhbiBzZWUgcG90ZW50aWFsbHkgc2Vuc2libGUgdXNlIGNhc2VzIHdoZXJlIHlvdSBtYXkg
bmVlZCBib3RoIGluIHRoZSBjb250ZXh0IG9mIE1VRC4gQWxzbywgdGhlIGFjbGRucyBtb2RlbCBh
dWdtZW50YXRpb24gaGFzIGJyb2FkZXIgYXBwbGljYWJpbGl0eSBiZXlvbmQNCiBNVUQsIHNvIGFu
eSBhdHRlbXB0IHRvIGltcG9zZSBNVUQtc3BlY2lmaWMgcmVzdHJpY3Rpb25zIHdvdWxkIGJlIGEg
bWlzdGFrZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklmIEVsaW90IHdpc2hlcyB0
byBJIGFkZCDigJxoZXJl4oCZcyBob3cgd2Ugc2VlIHRoaXMgbW9kZWwgYmVpbmcgdXNlZCBpbiB0
aGUgY29udGV4dCBvZiBNVUTigJ0sIGFuZCBtYWtlIHNvbWUgYmVzdC1wcmFjdGljZSByZWNvbW1l
bmRhdGlvbnMsIEnigJltIGZpbmUgd2l0aCB0aGF0LiBCdXQgaXQgc2hvdWxkbuKAmXQgYmUgYSBN
VVNUIE5PVCwgSU1PLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hlZXJzLDwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RWluYXI8L2Rpdj4NCjxkaXY+PGJyPg0KT24gT2N0
IDI5LCAyMDE3LCBhdCAxNDo0OCwgRWxpb3QgTGVhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlYXJA
Y2lzY28uY29tIj5sZWFyQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPHA+PGJyPg0KPC9wPg0KPGJyPg0K
PGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxMC8yOS8xNyAyOjEyIFBNLCBNLiBSYW5n
YW5hdGhhbiB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9
Im1pZDpDQUhpdTRKTzdLPVQmIzQzO0ZtNVIwRjBTTzVZRUYtY3VVU1ZCU2kwN09raHJ5Q0hIb1dv
cVpRQG1haWwuZ21haWwuY29tIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj5JIHNlZSB0aGF0IGEgZ3JvdXBpbmcgaXMgdXNlZCBpbiBpZXRmLWFjbGRucyBpLmUu
PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ZG5zLW1hdGNoZXMgezxicj4NCiZuYnNwOyZuYnNwOyZu
YnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtEb21haW4gbmFtZXMgZm9yIG1hdGNoaW5nLiZxdW90Ozs8
YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBzcmMtZG5zbmFtZSB7PGJyPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW5ldDpob3N0Ozxicj4NCiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtkb21haW4gbmFtZSB0byBi
ZSBtYXRjaGVkIGFnYWluc3QmcXVvdDs7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQom
bmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBkc3QtZG5zbmFtZSB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW5ldDpob3N0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBkZXNjcmlwdGlvbiAmcXVvdDtkb21haW4gbmFtZSB0byBiZSBtYXRjaGVkIGFn
YWluc3QmcXVvdDs7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQombmJzcDsgfTxicj4N
Cjxicj4NCjxicj4NCiZuYnNwOyBhdWdtZW50ICZxdW90Oy9hY2w6YWNjZXNzLWxpc3RzL2FjbDph
Y2wvYWNsOmFjZXMvYWNsOmFjZS8mcXVvdDsgJiM0Mzs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgJnF1b3Q7YWNsOm1hdGNoZXMvYWNsOmlwdjQtYWNsJnF1b3Q7IHs8YnI+DQombmJzcDsm
bmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7QWRkaW5nIGRvbWFpbiBuYW1lcyB0byBtYXRj
aGluZyZxdW90Ozs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgdXNlcyBkbnMtbWF0Y2hlczs8YnI+
DQombmJzcDsmbmJzcDsgfTxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KVGhpcyBhbGxvd3Mgc3Jj
LWRuc25hbWUgYW5kIGRzdC1kbnNuYW1lIHRvIGFwcGVhciBpbiBmcm9tLWRldmljZS1wb2xpY3kg
YW5kIHRvLWRldmljZS1wb2xpY3kuPGJyPg0KPGJyPg0KPC9kaXY+DQpJcyBpdCBwb3NzaWJsZSB0
byByZXN0cmljdCB0aGlzIHN1Y2ggdGhhdCBzcmMtZG5zbmFtZSBvbmx5IGFwcGVhcnMgaW4gdG8t
ZGV2aWNlLXBvbGljeSBhbmQgZHN0LWRuc25hbWUgb25seSBhcHBlYXJzIGluIGZyb20tZGV2aWNl
LXBvbGljeS48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+SWYgbm90IHBvc3NpYmxlIHZpYSBZQU5H
LCBjYW4gbGFuZ3VhZ2UgYmUgYWRkZWQgdG8gdGhlIHNwZWMgdG8gaW5kaWNhdGUgdGhlIHJlc3Ry
aWN0aW9uIGFib3ZlPzxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
Cjxicj4NCkkgd291bGQgaGF2ZSBubyBvYmplY3Rpb24gYWRkaW5nIHNvbWUgY2xhcmlmeWluZyBs
YW5ndWFnZSBpbiB0aGUgZHJhZnQuPGJyPg0KPGJyPg0KRWxpb3Q8YnI+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIiBjaXRlPSJtaWQ6Q0FIaXU0Sk83Sz1UJiM0MztGbTVSMEYwU081WUVGLWN1VVNW
QlNpMDdPa2hyeUNISG9Xb3FaUUBtYWlsLmdtYWlsLmNvbSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KVGhhbmtzLDxicj4NCjxicj4NCjwvZGl2Pg0KUmFuZ2Eu
PGJyIGNsZWFyPSJhbGwiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KLS0gPGJyPg0KPGRpdiBj
bGFzcz0iZ21haWxfc2lnbmF0dXJlIj5NLiBSYW5nYW5hdGhhbjxicj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGZpZWxkc2V0IGNsYXNzPSJt
aW1lQXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4gPGJyPg0KPHByZSB3cmFwPSIiPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNBV0cgbWFpbGlu
ZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86
T1BTQVdHQGlldGYub3JnIj5PUFNBV0dAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1s
aW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29wc2F3ZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2c8L2E+
DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj4NCjxzcGFuPk9QU0FXRyBtYWlsaW5n
IGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOk9QU0FXR0BpZXRmLm9yZyI+
T1BTQVdHQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3ZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vcHNhd2c8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_6E2B6C3C82C84DE2AB583222CEBFB8B5ciscocom_--


From nobody Sun Oct 29 16:05: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 B220613F588 for ; Sun, 29 Oct 2017 16:05:03 -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, HTML_MESSAGE=0.001, 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 44eprcHtXV3v for ; Sun, 29 Oct 2017 16:05:02 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BECE0138C11 for ; Sun, 29 Oct 2017 16:05:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9325; q=dns/txt; s=iport; t=1509318301; x=1510527901; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CSjiPyLuXO648fuJkR5DLDqcOrnp5RZ8Y7IjJpZU/iY=; b=cPqOxlD2+as66YT8yk0ZaIvLiDukgpNOPvInDIty/ZBqK6OY61DKjxTS g8WS677701Q2BerSQtyRSSV24aiNjpT2bnVIYFSspQv2QgpJPmBQhwEKd SV0b1U+EQh8EiVuY1O293SlkOtZ9QvAhNOvN4D7LrRMuyPyQCMjYJg7Ti I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAADYXfZZ/5tdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzEuZG4ng3yKH48RknmFRYIRChgBCoRJTwIahDE/GAECAQEBAQE?= =?us-ascii?q?BAWsohR4CAQMBASFLCxACAQg/AwICAiULFBECBAENBYk/ZBCnZ4IninkBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYMuggeDZYMBhUeCXy+CMgWiAwKUepMtlWMCERk?= =?us-ascii?q?BgTgBHziBaHoVSS0BgjaCXByBZ3eLTgEBAQ?=
X-IronPort-AV: E=Sophos; i="5.44,316,1505779200"; d="scan'208,217"; a="23313587"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Oct 2017 23:05:00 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v9TN503X009707 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 29 Oct 2017 23:05:00 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 29 Oct 2017 19:05:00 -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.1320.000; Sun, 29 Oct 2017 19:04:59 -0400
From: "Einar Nilsen-Nygaard (einarnn)" 
To: Eliot Lear , "M. Ranganathan" 
CC: "opsawg@ietf.org" 
Thread-Topic: [OPSAWG] MUD draft 13: ietf-acldns suggested augmentation.
Thread-Index: AQHTUNIrMQrSSyLf/k2jozXxos3r+qL7SQGAgAAqC9Q=
Date: Sun, 29 Oct 2017 23:04:59 +0000
Message-ID: <93D87B69-7EDE-49CD-8D54-EECE922F393F@cisco.com>
References: ,  <0703ada7-6421-b2f8-4823-7c0063bd46f6@cisco.com>
In-Reply-To: <0703ada7-6421-b2f8-4823-7c0063bd46f6@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_93D87B697EDE49CD8D54EECE922F393Fciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] MUD draft 13: ietf-acldns suggested augmentation.
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, 29 Oct 2017 23:05:04 -0000

--_000_93D87B697EDE49CD8D54EECE922F393Fciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBkb27igJl0IHRoaW5rIHlvdSBjYW4gZG8gYW55dGhpbmcgaW4geW91ciBvd24gaW1wbGVtZW50
YXRpb24gdGhhdCBpcyB1c2VmdWwgYXMgdG8gYmUgdXNlZnVsIGl0IHdvdWxkIG5lZWQgdG8gYmUg
c29tZXRoaW5nIG1hbnVmYWN0dXJlcnMgYWxzbyBwbGFjZWQgaW4gTVVEIGZpbGVzLiBBbmQgc3Vj
aCBhIGxlYWYgd291bGQgaGF2ZSBubyByZWxldmFuY2UgaW4gdGhlIGltcGxlbWVudGF0aW9uIG9m
IHRoZSBBQ0wuIEluIGZhY3QsIGF0IHRoaXMgcG9pbnQgSSBjYW7igJl0IHNlZSBhbnkgdXRpbGl0
eSBmb3IgaXQgYXQgYWxsLg0KDQpUaGUgTVVEIGZpbGUgaXMgaW50ZW5kZWQgdG8gYmUgYSBzZWxm
LWNvbnRhaW5lZCBwYXJjZWwgb2YgaW5mb3JtYXRpb24sIGFuZCwgYXMgSSBzYWlkIGJlZm9yZSwg
dGhlIG5vdGUgYWJvdXQgdGhlIHNjb3Bpbmcgb2YgdGhlIEFDTCBuYW1lcyBpcyBwdXJlbHkgdG8g
cmVtaW5kIGNvbnN1bWVycyB0aGF0IHRoZSBuYW1lcyBvZiBBQ0xzIGFyZSBkZWZpbmVkIG9ubHkg
d2l0aGluIHRoZSBzY29wZSBvZiB0aGUgTVVEIGZpbGUgYW5kIHRoZXJlIGlzIG5vIGF1dG9tYXRp
YyBkaXNhbWJpZ3VhdGlvbiB3aXRoIHJlc3BlY3QgdG8gdGhlIG90aGVyIEFDTHMgdGhlIG5ldHdv
cmsgYWRtaW4gbWF5IGFsc28gYmUgd29ya2luZyB3aXRoLiBUaGUgTVVEIGZpbGUgd2lsbCBhbHdh
eXMgYmUgcHJlLXByb2Nlc3NlZCBiZWZvcmUgYW55IEFDTHMgYXJlIHBsYWNlZCBvbiBhIGRldmlj
ZSwgYW5kIHRoZSBBQ0xzIGluIHRoZSBNVVMgZmlsZSBtYXkgbm90IGV2ZW4gbWFuaWZlc3QgYXMg
c3RhbmRhbG9uZSBBQ0xzLiBUaGV5IG1heSBqdXN0IGJlY29tZSBhIHN0YW56YSBpbiBhbiBhbHJl
YWR5LWV4aXN0aW5nIEFDTCwgb3IgdGhleSBtYXkgYmVjb21lIGZpbHRlciBydWxlcyBpbiBhIFJB
RElVUyBBY2Nlc3MtQWNjZXB0IHBhY2tldCENCg0KQXMgc3VjaCwgYW55dGhpbmcgd2UgZG8gdG8g
dHJ5IGFuZCBtYWtlIHRoZXNlIG5hbWVzIGdsb2JhbGx5IHVuaXF1ZSBqdXN0LCBJTU8sIGFkZHMg
dW5uZWNlc3NhcnkgY29tcGxleGl0eSB0byB0aGUgb3ZlcmFsbCBtb2RlbC4NCg0KSSBzdWdnZXN0
IHdlIHRha2UgdGhlIOKAnHNjb3BpbmfigJ0gdGV4dCBvdXQgb2YgdGhlIFlBTkcgZGVmaW5pdGlv
biwgYW5kIGFkZCBzb21lIHRleHQgYWxsdWRpbmcgdG8gd2hhdCBJIHNheSBhYm92ZSB0byB0aGUg
Ym9keSBvZiB0aGUgZG9jdW1lbnQuDQoNCkNoZWVycywNCg0KRWluYXINCg0KT24gT2N0IDI5LCAy
MDE3LCBhdCAxNjozNCwgRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lz
Y28uY29tPj4gd3JvdGU6DQoNCg0KSSdtIG5vdCBzdXJlIHRoYXQgZG9lcyB3aGF0IHlvdSB3YW50
IGl0IHRvIGRvLCBSYW5nYS4gIEFsbCBpdCBkb2VzIGlzIGFkZCBhbiBpbmZvcm1hdGlvbiBlbGVt
ZW50IHRoYXQgaXMgYWN0dWFsbHkgYWxyZWFkeSBwcmVzZW50IHdpdGhpbiB0aGUgTVVEIG1vZGVs
LiAgQnV0IHlvdSBjYW4gZG8gdGhhdCBpbiB5b3VyIG93biBpbXBsZW1lbnRhdGlvbiwgYW5kIG5v
IGhhcm0gd2lsbCBjb21lIG9mIGl0Lg0KDQpFbGlvdA0KDQpPbiAxMC8yOS8xNyA1OjIyIFBNLCBN
LiBSYW5nYW5hdGhhbiB3cm90ZToNClRoZSBNVUQgZHJhZnQgc2F5cyBBQ0wgbmFtZXMgc2hvdWxk
IGJlIHNjb3BlZCBieSBmaWxlLg0KDQpUaGUgZm9sbG93aW5nIGF1Z21lbnRhdGlvbiB0byBpZXRm
LWFjbGRucyB3b3VsZCBtYWtlIHRoZSBhc3NvY2lhdGlvbiBleHBsaWNpdCA6DQoNCjUxYTUyLDYx
DQo+ICAgYXVnbWVudCAiL2FjbDphY2Nlc3MtbGlzdHMvYWNsOmFjbC8iIHsNCj4gICAgIGRlc2Ny
aXB0aW9uDQo+ICAgICAgICAgICJNVUQgVVJJIHRvIGFzc29jaWF0ZSB0aGUgIEFDTCB0byBhIE1V
RCBzY29wZSI7DQo+ICAgICBsZWFmIG11ZC11cmwgew0KPiAgICAgICAgIHR5cGUgaW5ldDp1cmk7
DQo+ICAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAgICAiVGhlIE1VRCBVUkkgdG8gYXNz
b2NpYXRlIHdpdGggdGhpcyBBQ0wiOw0KPiAgICAgfQ0KPiAgIH0NCj4NCg0KDQpUaGVyZWJ5LCBz
Y29waW5nIGJ5IGZpbGUgd291bGQgYmUgYXZvaWRlZC4NCg0KVGhhbmtzLA0KDQpSYW5nYQ0KDQot
LQ0KTS4gUmFuZ2FuYXRoYW4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpPUFNBV0cgbWFpbGluZyBsaXN0DQpPUFNBV0dAaWV0Zi5vcmc8bWFp
bHRvOk9QU0FXR0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb3BzYXdnDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9yZzxtYWlsdG86T1BTQVdH
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cN
Cg==

--_000_93D87B697EDE49CD8D54EECE922F393Fciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2PjwvZGl2Pg0KPGRpdj5JIGRvbuKAmXQgdGhpbmsgeW91IGNhbiBkbyBhbnl0aGluZyBpbiB5
b3VyIG93biBpbXBsZW1lbnRhdGlvbiB0aGF0IGlzIHVzZWZ1bCBhcyB0byBiZSB1c2VmdWwgaXQg
d291bGQgbmVlZCB0byBiZSBzb21ldGhpbmcgbWFudWZhY3R1cmVycyBhbHNvIHBsYWNlZCBpbiBN
VUQgZmlsZXMuIEFuZCBzdWNoIGEgbGVhZiB3b3VsZCBoYXZlIG5vIHJlbGV2YW5jZSBpbiB0aGUg
aW1wbGVtZW50YXRpb24gb2YgdGhlIEFDTC4gSW4gZmFjdCwgYXQgdGhpcw0KIHBvaW50IEkgY2Fu
4oCZdCBzZWUgYW55IHV0aWxpdHkgZm9yIGl0IGF0IGFsbC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2PlRoZSBNVUQgZmlsZSBpcyBpbnRlbmRlZCB0byBiZSBhIHNlbGYtY29udGFpbmVk
IHBhcmNlbCBvZiBpbmZvcm1hdGlvbiwgYW5kLCBhcyBJIHNhaWQgYmVmb3JlLCB0aGUgbm90ZSBh
Ym91dCB0aGUgc2NvcGluZyBvZiB0aGUgQUNMIG5hbWVzIGlzIHB1cmVseSB0byByZW1pbmQgY29u
c3VtZXJzIHRoYXQgdGhlIG5hbWVzIG9mIEFDTHMgYXJlIGRlZmluZWQgb25seSB3aXRoaW4gdGhl
IHNjb3BlIG9mIHRoZSBNVUQgZmlsZSBhbmQgdGhlcmUgaXMNCiBubyBhdXRvbWF0aWMgZGlzYW1i
aWd1YXRpb24gd2l0aCByZXNwZWN0IHRvIHRoZSBvdGhlciBBQ0xzIHRoZSBuZXR3b3JrIGFkbWlu
IG1heSBhbHNvIGJlIHdvcmtpbmcgd2l0aC4gVGhlIE1VRCBmaWxlIHdpbGwNCjxiPmFsd2F5czwv
Yj4mbmJzcDtiZSBwcmUtcHJvY2Vzc2VkIGJlZm9yZSBhbnkgQUNMcyBhcmUgcGxhY2VkIG9uIGEg
ZGV2aWNlLCBhbmQgdGhlIEFDTHMgaW4gdGhlIE1VUyBmaWxlIG1heSBub3QgZXZlbiBtYW5pZmVz
dCBhcyBzdGFuZGFsb25lIEFDTHMuIFRoZXkgbWF5IGp1c3QgYmVjb21lIGEgc3RhbnphIGluIGFu
IGFscmVhZHktZXhpc3RpbmcgQUNMLCBvciB0aGV5IG1heSBiZWNvbWUgZmlsdGVyIHJ1bGVzIGlu
IGEgUkFESVVTIEFjY2Vzcy1BY2NlcHQNCiBwYWNrZXQhPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj5BcyBzdWNoLCBhbnl0aGluZyB3ZSBkbyB0byB0cnkgYW5kIG1ha2UgdGhlc2UgbmFt
ZXMgZ2xvYmFsbHkgdW5pcXVlIGp1c3QsIElNTywgYWRkcyB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5
IHRvIHRoZSBvdmVyYWxsIG1vZGVsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBz
dWdnZXN0IHdlIHRha2UgdGhlIOKAnHNjb3BpbmfigJ0gdGV4dCBvdXQgb2YgdGhlIFlBTkcgZGVm
aW5pdGlvbiwgYW5kIGFkZCBzb21lIHRleHQgYWxsdWRpbmcgdG8gd2hhdCBJIHNheSBhYm92ZSB0
byB0aGUgYm9keSBvZiB0aGUgZG9jdW1lbnQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj5DaGVlcnMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5FaW5hcjwvZGl2Pg0KPGRp
dj48YnI+DQpPbiBPY3QgMjksIDIwMTcsIGF0IDE2OjM0LCBFbGlvdCBMZWFyICZsdDs8YSBocmVm
PSJtYWlsdG86bGVhckBjaXNjby5jb20iPmxlYXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJy
Pg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8cD5JJ20g
bm90IHN1cmUgdGhhdCBkb2VzIHdoYXQgeW91IHdhbnQgaXQgdG8gZG8sIFJhbmdhLiZuYnNwOyBB
bGwgaXQgZG9lcyBpcyBhZGQgYW4gaW5mb3JtYXRpb24gZWxlbWVudCB0aGF0IGlzIGFjdHVhbGx5
IGFscmVhZHkgcHJlc2VudCB3aXRoaW4gdGhlIE1VRCBtb2RlbC4mbmJzcDsgQnV0IHlvdSBjYW4g
ZG8gdGhhdCBpbiB5b3VyIG93biBpbXBsZW1lbnRhdGlvbiwgYW5kIG5vIGhhcm0gd2lsbCBjb21l
IG9mIGl0Ljxicj4NCjwvcD4NCkVsaW90PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUt
cHJlZml4Ij5PbiAxMC8yOS8xNyA1OjIyIFBNLCBNLiBSYW5nYW5hdGhhbiB3cm90ZTo8YnI+DQo8
L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpDQUhpdTRKUGFHUVZlWS1h
UUxnbnhLSl9HN1pLdlNmUm0xYkRQQU44THYtZzJYRi1lcVFAbWFpbC5nbWFpbC5jb20iPg0KPGRp
diBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2PlRoZSBNVUQgZHJhZnQgc2F5
cyBBQ0wgbmFtZXMgc2hvdWxkIGJlIHNjb3BlZCBieSBmaWxlLiA8YnI+DQo8YnI+DQo8L2Rpdj4N
ClRoZSBmb2xsb3dpbmcgYXVnbWVudGF0aW9uIHRvIGlldGYtYWNsZG5zIHdvdWxkIG1ha2UgdGhl
IGFzc29jaWF0aW9uIGV4cGxpY2l0IDo8YnI+DQo8YnI+DQo1MWE1Miw2MTxicj4NCiZndDsmbmJz
cDsmbmJzcDsgYXVnbWVudCAmcXVvdDsvYWNsOmFjY2Vzcy1saXN0cy9hY2w6YWNsLyZxdW90OyB7
PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbiA8YnI+DQomZ3Q7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx
dW90O01VRCBVUkkgdG8gYXNzb2NpYXRlIHRoZSZuYnNwOyBBQ0wgdG8gYSBNVUQgc2NvcGUmcXVv
dDs7PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIG11ZC11cmwgezxicj4N
CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlw
ZSBpbmV0OnVyaTs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtUaGUgTVVE
IFVSSSB0byBhc3NvY2lhdGUgd2l0aCB0aGlzIEFDTCZxdW90Ozs8YnI+DQomZ3Q7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7IH08YnI+DQomZ3Q7IDxicj4N
Cjxicj4NCjxicj4NCjwvZGl2Pg0KVGhlcmVieSwgc2NvcGluZyBieSBmaWxlIHdvdWxkIGJlIGF2
b2lkZWQuPGJyPg0KPGJyPg0KPC9kaXY+DQpUaGFua3MsPGJyPg0KPGJyPg0KPC9kaXY+DQpSYW5n
YTxiciBjbGVhcj0iYWxsIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+PGJyPg0KLS0gPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfc2lnbmF0dXJlIj5NLiBS
YW5nYW5hdGhhbjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxmaWVsZHNldCBjbGFzcz0ibWlt
ZUF0dGFjaG1lbnRIZWFkZXIiPjwvZmllbGRzZXQ+IDxicj4NCjxwcmUgd3JhcD0iIj5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT1BTQVdHIG1haWxpbmcg
bGlzdA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOk9Q
U0FXR0BpZXRmLm9yZyI+T1BTQVdHQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGlu
ay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
cHNhd2ciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnPC9hPg0K
PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5PUFNBV0cgbWFpbGluZyBs
aXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzpPUFNBV0dAaWV0Zi5vcmciPk9Q
U0FXR0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2ciPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb3BzYXdnPC9hPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_93D87B697EDE49CD8D54EECE922F393Fciscocom_--


From nobody Mon Oct 30 01:19: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 2BC8013F794; Mon, 30 Oct 2017 01:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 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, 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 t2qup2orQtI1; Mon, 30 Oct 2017 01:19:18 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0105613F78E; Mon, 30 Oct 2017 01:19:17 -0700 (PDT)
Received: from 172.18.9.243 (EHLO lhreml702-cah.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSR78832; Mon, 30 Oct 2017 03:19:17 -0500 (CDT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 30 Oct 2017 08:19:13 +0000
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.148]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Mon, 30 Oct 2017 16:19:09 +0800
From: Tianran Zhou 
To: li zhenqiang , "opsawg@ietf.org" , opsawg-chairs 
Thread-Topic: WGLC request for draft-ietf-opsawg-ipfix-bgp-community-03.txt
Thread-Index: AQHTSXj7CQZMWHWVIES5ODba8dCuHKL8DqsA
Date: Mon, 30 Oct 2017 08:19:09 +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: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21A6CD4C25NKGEML515MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [OPSAWG] WGLC request for draft-ietf-opsawg-ipfix-bgp-community-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: Mon, 30 Oct 2017 08:19:20 -0000

--_000_BBA82579FD347748BEADC4C445EA0F21A6CD4C25NKGEML515MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Zhenqiang and the coauthors,

Based on your latest post, the co-chairs would like to suggest the followin=
g improvements before issuing the LC.

1. It's still not clear why the proposed IEs are necessary and useful, alth=
ough you have some simple words in the introduction. It's better to add a s=
eparate use case section to expand the two references [Community-TE] and [R=
FC4384], and to address your operation experience on using them.
This will also help to motivate the audience to understand and use this IE =
extension.

2. Given that both standard and large communities will stay in deployment a=
nd they both accomplish equivalent function, and large can carry all the va=
lue spaces of standard ones, one option is to define a container for large =
with a predefined field for mapping in a standard community value. This is =
a technique issue that need to be discussed. If you insist your way, please=
 add some texts in the draft to clarify why two were chosen.  Perhaps you h=
ave operational experience that explains why the multiple containers help.

3. You have added an operational considerations section as was requested in=
 Prague.  Perhaps a bit more text on the "why" concerning the approach is a=
lso required to help inform those who might deploy this.

Thanks,
Ignas, Joe, Tianran


From: li zhenqiang [mailto:li_zhenqiang@hotmail.com]
Sent: Friday, October 20, 2017 3:57 PM
To: opsawg@ietf.org; opsawg-chairs
Subject: WGLC request for draft-ietf-opsawg-ipfix-bgp-community-03.txt

Dear WG Chairs and all,

I updated the following draft according to the comments received from the l=
ist and the Praha meeting. The purpose to introduce new IEs in IPFIX is exp=
lained more clearly in the introducation part and emphesized in the abstrac=
t part. We changed one section title from  Message Length Considerations to=
  Operational Considerations, and explained, at present for the field netwo=
rk, one IPFIX message has enough space to fit all the community information=
 related to a specific traffic flow .

Since no more technical issues remain to be solved, as requested in the Pra=
ha meeting, we think this doc is ready to do WGLC. Thank you very much.


Name: draft-ietf-opsawg-ipfix-bgp-community
Revision: 03
Title: Export BGP community information in IP Flow Information Export (IPFI=
X)
Document date: 2017-10-17
Group: opsawg
Pages: 17
URL: https://www.ietf.org/internet-drafts/draft-ietf-opsawg-ipfix-bgp-commu=
nity-03.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-commun=
ity/
Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community=
-03
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-bgp=
-community-03
Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-ipfix-bgp-commu=
nity-03

Abstract:
   This draft updates RFC7012 IPFIX information model by introducing
   several information elements to enable IPFIX to export the BGP
   community information, including BGP standard community defined in
   RFC1997, BGP extended community defined in RFC4360, and BGP large
   community defined in RFC8092.  Network traffic flow information can
   then be accumulated and analysed at the granularity specified by the
   BGP communities, which is suitable for and needed by some traffic
   optimization applications located in IPFIX collector, SDN controller
   or PCE (Path Computation Element).

________________________________
li_zhenqiang@hotmail.com

--_000_BBA82579FD347748BEADC4C445EA0F21A6CD4C25NKGEML515MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Zhenqiang and the coauthor=
s,


 


Based on your latest post, th=
e co-chairs would like to suggest the following improvements before issuing=
 the LC.


 


1. It’s still not clear=
 why the proposed IEs are necessary and useful, although you have some simp=
le words in the introduction. It’s better to add a separate
 use case section to expand the two references This will also help to motiva=
te the audience to understand and use this IE extension.<=
/p>

 


2. Given that both standard a=
nd large communities will stay in deployment and they both accomplish equiv=
alent function, and large can carry all the value
 spaces of standard ones, one option is to define a container for large wit=
h a predefined field for mapping in a standard community value. This is a t=
echnique issue that need to be discussed. If you insist your way, please ad=
d some texts in the draft to clarify
 why two were chosen.  Perhaps you have operational experience that ex=
plains why the multiple containers help.


 


3. You have added an operatio=
nal considerations section as was requested in Prague.  Perhaps a bit =
more text on the "why" concerning the approach is also
 required to help inform those who might deploy this.


 


Thanks,


Ignas, Joe, Tianran


 


 








From: li zhenqiang [mailto:li_zhenqiang@hotmail.com]


Sent: Friday, October 20, 2017 3:57 PM

To: opsawg@ietf.org; opsawg-chairs

Subject: WGLC request for draft-ietf-opsawg-ipfix-bgp-community-03.t=
xt






 




Dear WG Chairs and all,






 






I updated the following draft according to the comments receiv=
ed from the list and the Praha meeting. The purpose to introduce new IEs in=
 IPFIX is explained
 more clearly in the introducation part and emphesized in the abstract part=
. We changed one section title from  Message Length Consider=
ations to  Operational&nb=
sp;Considerations, and explained, at present for the field network,
 one IPFIX message has enough space to fit all the community information re=
lated to a specific traffic flow .






 






Since no more technical issues remain to be solved, as request=
ed in the Praha meeting, we think this doc is ready to do WGLC. Thank you v=
ery much.






 






 








Name: draft-ietf-opsawg-ipfix-bgp-community<=
/p>





Revision: 03






Title: Export BGP community information in IP Flow Information=
 Export (IPFIX)






Document date: 2017-10-17






Group: opsawg






Pages: 17











 






Abstract:






   This draft updates RFC7012 IPFIX information mode=
l by introducing






   several information elements to enable IPFIX to e=
xport the BGP






   community information, including BGP standard com=
munity defined in






   RFC1997, BGP extended community defined in RFC436=
0, and BGP large






   community defined in RFC8092.  Network traff=
ic flow information can






   then be accumulated and analysed at the granulari=
ty specified by the






   BGP communities, which is suitable for and needed=
 by some traffic






   optimization applications located in IPFIX collec=
tor, SDN controller






   or PCE (Path Computation Element).








 

















--_000_BBA82579FD347748BEADC4C445EA0F21A6CD4C25NKGEML515MBSchi_--


From nobody Mon Oct 30 02:03:59 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 9514713F8DA; Mon, 30 Oct 2017 02:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.124
X-Spam-Level: 
X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av-Hgv6Cu84w; Mon, 30 Oct 2017 02:03:48 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254097.outbound.protection.outlook.com [40.92.254.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89FE13F8DD; Mon, 30 Oct 2017 02:03:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hMKb2k3Gmu9QfpGNmlO8iHquADwHXD01Zyqta2gozTo=; b=LEUoR/EoQn+tSXjdRDPgPmlhiXIPJy/hsmt23zrnXrWcA+6z+VA2k0gE1qO2KNEMu72/hCHWAz3db+75i5bGOllNoP/FWLpoMN9uNX1ufNcnRXWPbHnm7iF/J9B/YWoPcJf0tdZuYHnsQEWwaxtUkEjg/IM/sFDru3Y4ty0AdS7zT03/X7xsWchbmDMh/Dpa7lCqLOfxbuTcpHZOrvuwP/FKEKyN+EGqbkpJVKG0ReJmrEdlgxXV5TKOawKqoIy0j8B7tC87K2+dfNdxdb37SNjJG29x3WIE4uJTt9VsnfOXX4tt4RRRHwJy+CE1EUCEBM2No73R+F8cgXkHLD+ODA==
Received: from SG2APC01FT046.eop-APC01.prod.protection.outlook.com (10.152.250.52) by SG2APC01HT045.eop-APC01.prod.protection.outlook.com (10.152.251.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.77.10; Mon, 30 Oct 2017 09:03:36 +0000
Received: from HK2PR0601MB1492.apcprd06.prod.outlook.com (10.152.250.56) by SG2APC01FT046.mail.protection.outlook.com (10.152.251.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.156.4 via Frontend Transport; Mon, 30 Oct 2017 09:03:36 +0000
Received: from HK2PR0601MB1492.apcprd06.prod.outlook.com ([fe80::3013:7d7c:470b:70bc]) by HK2PR0601MB1492.apcprd06.prod.outlook.com ([fe80::3013:7d7c:470b:70bc%13]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 09:03:36 +0000
From: li zhenqiang 
To: Zhoutianran , opsawg , opsawg-chairs 
Thread-Topic: RE: WGLC request for draft-ietf-opsawg-ipfix-bgp-community-03.txt
Thread-Index: AQHTSXj7CQZMWHWVIES5ODba8dCuHA==
Date: Mon, 30 Oct 2017 09:03:36 +0000
Message-ID: 
References: , 
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:807A9066CC6DE61084E3DB4CE2EDBD30D675E1F2F62927E9CB543AD82DC09C48; UpperCasedChecksum:97FCF0DEF32E9B52D313B329CCFB5297EEBB6E5ABC196479ED43A64D985D6C14; SizeAsReceived:7251; Count:45
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [Lykn2CnxIrmGb9xsEgZOx20V8NdqWMAtfF1ElEgqlyU=]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SG2APC01HT045; 6:Ei7rBQoKb4l2aEf0dOU0Yuz156KISaZEqv2xvHP8cHIge5T0/f6lnLekb4t3SvlgxF/pnZ64Sa8hggxdP39UbxWOVxl7WePQ1Uj5UrO2G5KSXwkloDRFYj39/8ZH8MTErorwfgSeFYQ3PPlNf2hYK+zbyPcvlxrYlgHwY1JBGK4+z5mh64fIKNZnJIplxVzhAjNOytDJ7aanMGtKEK+HAyhk4layxZWTn9BWOuykcoLICFHmuN9CaQAk+VyvpmnMfXvhWV5yd8DdZCoiZdBhLxdYWeVAoKc5n5/x2PMPABpH5wPB4p/1ZV36CdViFhdcPuWXAyw0oRN0v5QZRKmzZw==; 5:yX106ntj0ijj4dWlcpERsjDIYvtNbiSt5ZtOzyKQI+qKw7bkvORw4pQjQpC4kAdaNv/ccCPh9lAfBPvw/QxNHCy+n5RR6IfvGCPco1kb5k141gccTlLHWRv1SURmm/KrpW4FZr+0JIO/lbSt8/8a7g==; 24:uKbFrEx6wPt/YTx+00YvfO1NJsC5yMiXz8gyGl4einZTLmPhol/Rg9TZW+jzd7nmcIVSUC9YA9NDi31/ynFXQ/jTINLS0DucCameFTdJ+Pg=; 7:IgSygCD52n/dZMGXuiwbCrHVziOS/izNNc8gCe/0cFztlTr7eZZXdx7hUcoe/ralvSS+NbgyALyx02gz+rCTaethUza/J08uPSkRFrJI0Sl9LOxRP3PR3G+VIDdcD+J8m6PExv0q+KNjfOiHJk8pv3neVfNrVPq1Qaqp+ro5uzCmhWlSVx99AoxPJwIp4H7q2c5YzMgvKKLUZ71kdquvG6u49dclmM1zuBcdvDS1+KY=
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: fff10a85-07ef-4b11-475c-08d51f751a59
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:SG2APC01HT045; 
x-ms-traffictypediagnostic: SG2APC01HT045:
x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105)(131327999870524)(50582790962513)(194151415913766);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:SG2APC01HT045; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SG2APC01HT045; 
x-forefront-prvs: 0476D4AB88
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SG2APC01HT045; H:HK2PR0601MB1492.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB1492A01359667B31843FA9B9FC590HK2PR0601MB1492_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 09:03:36.6955 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT045
Archived-At: 
Subject: Re: [OPSAWG] WGLC request for draft-ietf-opsawg-ipfix-bgp-community-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: Mon, 30 Oct 2017 09:03:50 -0000

--_000_HK2PR0601MB1492A01359667B31843FA9B9FC590HK2PR0601MB1492_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGVsbG8gVGlhbnJhbiBhbmQgdGhlIGNvLWNoYWlycywNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBm
b3IgeW91ciByZXZpZXcgYW5kIHN1Z2dlc3Rpb25zLiBJIHdpbGwgYWRkcmVzcyBhbGwgeW91ciBj
b21tZW50cyBpbiB0aGUgbmV4dCB2ZXNpb24uIEJ1dCBJIGFtIGFmcmFpZCBJIGNhbiBub3QgY2F0
Y2ggdGhlIHN1Ym1pdHRpb24gZGVhZGxpbmUgZm9yIHRoZSBjb21pbmcgbWVldGluZy4gU28sIHRo
ZSB1cGRhdGVkIHZlcnNpb24gd2lsbCBiZSB1cGxvYWRlZCBhZnRlciB0aGUgU2luZ2Fwb3JlIG1l
ZXRpbmcuDQoNCkJlc3QgUmVnYXJkcywNClpoZW5xaWFuZyBMaQ0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCmxpX3poZW5xaWFuZ0Bob3RtYWlsLmNvbQ0KDQpGcm9tOiBUaWFucmFu
IFpob3U8bWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20+DQpEYXRlOiAyMDE3LTEwLTMwIDE2
OjE5DQpUbzogbGkgemhlbnFpYW5nPG1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20+OyBv
cHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz47IG9wc2F3Zy1jaGFpcnM8bWFp
bHRvOm9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogV0dMQyByZXF1ZXN0IGZv
ciBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAzLnR4dA0KSGkgWmhlbnFp
YW5nIGFuZCB0aGUgY29hdXRob3JzLA0KDQpCYXNlZCBvbiB5b3VyIGxhdGVzdCBwb3N0LCB0aGUg
Y28tY2hhaXJzIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0aGUgZm9sbG93aW5nIGltcHJvdmVtZW50
cyBiZWZvcmUgaXNzdWluZyB0aGUgTEMuDQoNCjEuIEl04oCZcyBzdGlsbCBub3QgY2xlYXIgd2h5
IHRoZSBwcm9wb3NlZCBJRXMgYXJlIG5lY2Vzc2FyeSBhbmQgdXNlZnVsLCBhbHRob3VnaCB5b3Ug
aGF2ZSBzb21lIHNpbXBsZSB3b3JkcyBpbiB0aGUgaW50cm9kdWN0aW9uLiBJdOKAmXMgYmV0dGVy
IHRvIGFkZCBhIHNlcGFyYXRlIHVzZSBjYXNlIHNlY3Rpb24gdG8gZXhwYW5kIHRoZSB0d28gcmVm
ZXJlbmNlcyBbQ29tbXVuaXR5LVRFXSBhbmQgW1JGQzQzODRdLCBhbmQgdG8gYWRkcmVzcyB5b3Vy
IG9wZXJhdGlvbiBleHBlcmllbmNlIG9uIHVzaW5nIHRoZW0uDQpUaGlzIHdpbGwgYWxzbyBoZWxw
IHRvIG1vdGl2YXRlIHRoZSBhdWRpZW5jZSB0byB1bmRlcnN0YW5kIGFuZCB1c2UgdGhpcyBJRSBl
eHRlbnNpb24uDQoNCjIuIEdpdmVuIHRoYXQgYm90aCBzdGFuZGFyZCBhbmQgbGFyZ2UgY29tbXVu
aXRpZXMgd2lsbCBzdGF5IGluIGRlcGxveW1lbnQgYW5kIHRoZXkgYm90aCBhY2NvbXBsaXNoIGVx
dWl2YWxlbnQgZnVuY3Rpb24sIGFuZCBsYXJnZSBjYW4gY2FycnkgYWxsIHRoZSB2YWx1ZSBzcGFj
ZXMgb2Ygc3RhbmRhcmQgb25lcywgb25lIG9wdGlvbiBpcyB0byBkZWZpbmUgYSBjb250YWluZXIg
Zm9yIGxhcmdlIHdpdGggYSBwcmVkZWZpbmVkIGZpZWxkIGZvciBtYXBwaW5nIGluIGEgc3RhbmRh
cmQgY29tbXVuaXR5IHZhbHVlLiBUaGlzIGlzIGEgdGVjaG5pcXVlIGlzc3VlIHRoYXQgbmVlZCB0
byBiZSBkaXNjdXNzZWQuIElmIHlvdSBpbnNpc3QgeW91ciB3YXksIHBsZWFzZSBhZGQgc29tZSB0
ZXh0cyBpbiB0aGUgZHJhZnQgdG8gY2xhcmlmeSB3aHkgdHdvIHdlcmUgY2hvc2VuLiAgUGVyaGFw
cyB5b3UgaGF2ZSBvcGVyYXRpb25hbCBleHBlcmllbmNlIHRoYXQgZXhwbGFpbnMgd2h5IHRoZSBt
dWx0aXBsZSBjb250YWluZXJzIGhlbHAuDQoNCjMuIFlvdSBoYXZlIGFkZGVkIGFuIG9wZXJhdGlv
bmFsIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gYXMgd2FzIHJlcXVlc3RlZCBpbiBQcmFndWUuICBQ
ZXJoYXBzIGEgYml0IG1vcmUgdGV4dCBvbiB0aGUgIndoeSIgY29uY2VybmluZyB0aGUgYXBwcm9h
Y2ggaXMgYWxzbyByZXF1aXJlZCB0byBoZWxwIGluZm9ybSB0aG9zZSB3aG8gbWlnaHQgZGVwbG95
IHRoaXMuDQoNClRoYW5rcywNCklnbmFzLCBKb2UsIFRpYW5yYW4NCg0KDQpGcm9tOiBsaSB6aGVu
cWlhbmcgW21haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb21dDQpTZW50OiBGcmlkYXksIE9j
dG9iZXIgMjAsIDIwMTcgMzo1NyBQTQ0KVG86IG9wc2F3Z0BpZXRmLm9yZzsgb3BzYXdnLWNoYWly
cw0KU3ViamVjdDogV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3At
Y29tbXVuaXR5LTAzLnR4dA0KDQpEZWFyIFdHIENoYWlycyBhbmQgYWxsLA0KDQpJIHVwZGF0ZWQg
dGhlIGZvbGxvd2luZyBkcmFmdCBhY2NvcmRpbmcgdG8gdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZy
b20gdGhlIGxpc3QgYW5kIHRoZSBQcmFoYSBtZWV0aW5nLiBUaGUgcHVycG9zZSB0byBpbnRyb2R1
Y2UgbmV3IElFcyBpbiBJUEZJWCBpcyBleHBsYWluZWQgbW9yZSBjbGVhcmx5IGluIHRoZSBpbnRy
b2R1Y2F0aW9uIHBhcnQgYW5kIGVtcGhlc2l6ZWQgaW4gdGhlIGFic3RyYWN0IHBhcnQuIFdlIGNo
YW5nZWQgb25lIHNlY3Rpb24gdGl0bGUgZnJvbSAgTWVzc2FnZSBMZW5ndGggQ29uc2lkZXJhdGlv
bnMgdG8gIE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zLCBhbmQgZXhwbGFpbmVkLCBhdCBwcmVz
ZW50IGZvciB0aGUgZmllbGQgbmV0d29yaywgb25lIElQRklYIG1lc3NhZ2UgaGFzIGVub3VnaCBz
cGFjZSB0byBmaXQgYWxsIHRoZSBjb21tdW5pdHkgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBhIHNw
ZWNpZmljIHRyYWZmaWMgZmxvdyAuDQoNClNpbmNlIG5vIG1vcmUgdGVjaG5pY2FsIGlzc3VlcyBy
ZW1haW4gdG8gYmUgc29sdmVkLCBhcyByZXF1ZXN0ZWQgaW4gdGhlIFByYWhhIG1lZXRpbmcsIHdl
IHRoaW5rIHRoaXMgZG9jIGlzIHJlYWR5IHRvIGRvIFdHTEMuIFRoYW5rIHlvdSB2ZXJ5IG11Y2gu
DQoNCg0KTmFtZTogZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eQ0KUmV2aXNp
b246IDAzDQpUaXRsZTogRXhwb3J0IEJHUCBjb21tdW5pdHkgaW5mb3JtYXRpb24gaW4gSVAgRmxv
dyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKQ0KRG9jdW1lbnQgZGF0ZTogMjAxNy0xMC0xNw0K
R3JvdXA6IG9wc2F3Zw0KUGFnZXM6IDE3DQpVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy
bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAzLnR4dA0K
U3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3
Zy1pcGZpeC1iZ3AtY29tbXVuaXR5Lw0KSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAzDQpIdG1saXplZDog
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1p
cGZpeC1iZ3AtY29tbXVuaXR5LTAzDQpEaWZmOiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm
P3VybDI9ZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMw0KDQpBYnN0cmFj
dDoNCiAgIFRoaXMgZHJhZnQgdXBkYXRlcyBSRkM3MDEyIElQRklYIGluZm9ybWF0aW9uIG1vZGVs
IGJ5IGludHJvZHVjaW5nDQogICBzZXZlcmFsIGluZm9ybWF0aW9uIGVsZW1lbnRzIHRvIGVuYWJs
ZSBJUEZJWCB0byBleHBvcnQgdGhlIEJHUA0KICAgY29tbXVuaXR5IGluZm9ybWF0aW9uLCBpbmNs
dWRpbmcgQkdQIHN0YW5kYXJkIGNvbW11bml0eSBkZWZpbmVkIGluDQogICBSRkMxOTk3LCBCR1Ag
ZXh0ZW5kZWQgY29tbXVuaXR5IGRlZmluZWQgaW4gUkZDNDM2MCwgYW5kIEJHUCBsYXJnZQ0KICAg
Y29tbXVuaXR5IGRlZmluZWQgaW4gUkZDODA5Mi4gIE5ldHdvcmsgdHJhZmZpYyBmbG93IGluZm9y
bWF0aW9uIGNhbg0KICAgdGhlbiBiZSBhY2N1bXVsYXRlZCBhbmQgYW5hbHlzZWQgYXQgdGhlIGdy
YW51bGFyaXR5IHNwZWNpZmllZCBieSB0aGUNCiAgIEJHUCBjb21tdW5pdGllcywgd2hpY2ggaXMg
c3VpdGFibGUgZm9yIGFuZCBuZWVkZWQgYnkgc29tZSB0cmFmZmljDQogICBvcHRpbWl6YXRpb24g
YXBwbGljYXRpb25zIGxvY2F0ZWQgaW4gSVBGSVggY29sbGVjdG9yLCBTRE4gY29udHJvbGxlcg0K
ICAgb3IgUENFIChQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQpLg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KbGlfemhlbnFpYW5nQGhvdG1haWwuY29tPG1haWx0bzpsaV96aGVu
cWlhbmdAaG90bWFpbC5jb20+DQo=

--_000_HK2PR0601MB1492A01359667B31843FA9B9FC590HK2PR0601MB1492_
Content-Type: text/html; charset="utf-8"
Content-ID: <89D144C38D07E448B0E4725BE5407D4A@apcprd06.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu
NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy
Z2luLWxlZnQ6IDAuNWVtOyB9cCB7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4
OyB9ZGl2LmZveGRpdjIwMTcxMDMwMTYzNTM4NzU4MDYzIHsgfWJvZHkgeyBmb250LXNpemU6IDEw
LjVwdDsgZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kTsgY29sb3I6IHJnYigwLCAwLCAwKTsgbGlu
ZS1oZWlnaHQ6IDEuNTsgfTwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiA+
PC9vOnNoYXBlZGVmYXVsdHM+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPgo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiA+PC9vOmlkbWFwPgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
ZGl2PjxzcGFuPjwvc3Bhbj5IZWxsbyBUaWFucmFuIGFuZCB0aGUgY28tY2hhaXJzLDwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciByZXZp
ZXcgYW5kIHN1Z2dlc3Rpb25zLiBJIHdpbGwgYWRkcmVzcyBhbGwgeW91ciBjb21tZW50cyBpbiB0
aGUgbmV4dCB2ZXNpb24uIEJ1dCBJIGFtIGFmcmFpZCBJIGNhbiBub3QgY2F0Y2ggdGhlIHN1Ym1p
dHRpb24gZGVhZGxpbmUgZm9yIHRoZSBjb21pbmcgbWVldGluZy4gU28sIHRoZSB1cGRhdGVkIHZl
cnNpb24gd2lsbCBiZSB1cGxvYWRlZCBhZnRlciB0aGUgU2luZ2Fwb3JlIG1lZXRpbmcuPC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2PlpoZW5x
aWFuZyBMaTwvZGl2Pg0KPGhyIHN0eWxlPSJ3aWR0aDogMjEwcHg7IGhlaWdodDogMXB4OyIgY29s
b3I9IiNiNWM0ZGYiIHNpemU9IjEiIGFsaWduPSJsZWZ0Ij4NCjxkaXY+PHNwYW4+DQo8ZGl2IHN0
eWxlPSJNQVJHSU46IDEwcHg7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQi
Pg0KPGRpdj5saV96aGVucWlhbmdAaG90bWFpbC5jb208L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTog
MHB4OyBtYXJnaW4tbGVmdDogMC41ZW07Ij4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwY20gMGNtIDBjbSI+DQo8ZGl2IHN0eWxlPSJQQURESU5HLVJJR0hUOiA4cHg7IFBBRERJTkct
TEVGVDogOHB4OyBGT05ULVNJWkU6IDEycHg7Rk9OVC1GQU1JTFk6dGFob21hO0NPTE9SOiMwMDAw
MDA7IEJBQ0tHUk9VTkQ6ICNlZmVmZWY7IFBBRERJTkctQk9UVE9NOiA4cHg7IFBBRERJTkctVE9Q
OiA4cHgiPg0KPGRpdj48Yj5Gcm9tOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86emhvdXRpYW5y
YW5AaHVhd2VpLmNvbSIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy
bGluZTsiPlRpYW5yYW4gWmhvdTwvYT48L2Rpdj4NCjxkaXY+PGI+RGF0ZTo8L2I+Jm5ic3A7MjAx
Ny0xMC0zMCZuYnNwOzE2OjE5PC9kaXY+DQo8ZGl2PjxiPlRvOjwvYj4mbmJzcDs8YSBocmVmPSJt
YWlsdG86bGlfemhlbnFpYW5nQGhvdG1haWwuY29tIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQt
ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+bGkgemhlbnFpYW5nPC9hPjsNCjxhIGhyZWY9Im1haWx0
bzpvcHNhd2dAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1
bmRlcmxpbmU7Ij4NCm9wc2F3Z0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpvcHNhd2ct
Y2hhaXJzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5k
ZXJsaW5lOyI+DQpvcHNhd2ctY2hhaXJzPC9hPjwvZGl2Pg0KPGRpdj48Yj5TdWJqZWN0OjwvYj4m
bmJzcDtSRTogV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29t
bXVuaXR5LTAzLnR4dDwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJG
b3hEaXYyMDE3MTAzMDE2MzUzODc1ODA2MyI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNo
YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiID48L286c2hhcGVkZWZhdWx0
cz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5
b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiID48L286aWRt
YXA+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250
LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
SGkgWmhlbnFpYW5nIGFuZCB0aGUgY29hdXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt
c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw
dDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkJhc2VkIG9uIHlvdXIgbGF0ZXN0IHBvc3QsIHRoZSBjby1jaGFpcnMgd291bGQgbGlr
ZSB0byBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgaW1wcm92ZW1lbnRzIGJlZm9yZSBpc3N1aW5nIHRo
ZSBMQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBT
aW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw
Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4N
CjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4xLiBJdOKAmXMgc3RpbGwgbm90
IGNsZWFyIHdoeSB0aGUgcHJvcG9zZWQgSUVzIGFyZSBuZWNlc3NhcnkgYW5kIHVzZWZ1bCwgYWx0
aG91Z2ggeW91IGhhdmUgc29tZSBzaW1wbGUgd29yZHMgaW4gdGhlIGludHJvZHVjdGlvbi4gSXTi
gJlzIGJldHRlciB0byBhZGQgYSBzZXBhcmF0ZSB1c2UgY2FzZSBzZWN0aW9uDQogdG8gZXhwYW5k
IHRoZSB0d28gcmVmZXJlbmNlcyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPltDb21tdW5pdHktVEVdIGFuZCBbUkZDNDM4NF0sIGFuZCB0byBhZGRyZXNzIHlvdXIg
b3BlcmF0aW9uIGV4cGVyaWVuY2Ugb24gdXNpbmcgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm
b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIHdpbGwgYWxzbyBoZWxwIHRvIG1vdGl2YXRlIHRoZSBh
dWRpZW5jZSB0byB1bmRlcnN0YW5kIGFuZCB1c2UgdGhpcyBJRSBleHRlbnNpb24uPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBj
bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw
dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Mi4gR2l2ZW4gdGhhdCBib3RoIHN0YW5kYXJkIGFuZCBs
YXJnZSBjb21tdW5pdGllcyB3aWxsIHN0YXkgaW4gZGVwbG95bWVudCBhbmQgdGhleSBib3RoIGFj
Y29tcGxpc2ggZXF1aXZhbGVudCBmdW5jdGlvbiwgYW5kIGxhcmdlIGNhbiBjYXJyeSBhbGwgdGhl
IHZhbHVlIHNwYWNlcyBvZiBzdGFuZGFyZA0KIG9uZXMsIG9uZSBvcHRpb24gaXMgdG8gZGVmaW5l
IGEgY29udGFpbmVyIGZvciBsYXJnZSB3aXRoIGEgcHJlZGVmaW5lZCBmaWVsZCBmb3IgbWFwcGlu
ZyBpbiBhIHN0YW5kYXJkIGNvbW11bml0eSB2YWx1ZS4gVGhpcyBpcyBhIHRlY2huaXF1ZSBpc3N1
ZSB0aGF0IG5lZWQgdG8gYmUgZGlzY3Vzc2VkLiBJZiB5b3UgaW5zaXN0IHlvdXIgd2F5LCBwbGVh
c2UgYWRkIHNvbWUgdGV4dHMgaW4gdGhlIGRyYWZ0IHRvIGNsYXJpZnkgd2h5IHR3byB3ZXJlIGNo
b3Nlbi4mbmJzcDsNCiBQZXJoYXBzIHlvdSBoYXZlIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgdGhh
dCBleHBsYWlucyB3aHkgdGhlIG11bHRpcGxlIGNvbnRhaW5lcnMgaGVscC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu
MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy
aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm
b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90Oztjb2xvcjojMUY0OTdEIj4zLiBZb3UgaGF2ZSBhZGRlZCBhbiBvcGVyYXRpb25hbCBjb25z
aWRlcmF0aW9ucyBzZWN0aW9uIGFzIHdhcyByZXF1ZXN0ZWQgaW4gUHJhZ3VlLiZuYnNwOyBQZXJo
YXBzIGEgYml0IG1vcmUgdGV4dCBvbiB0aGUgJnF1b3Q7d2h5JnF1b3Q7IGNvbmNlcm5pbmcgdGhl
IGFwcHJvYWNoIGlzIGFsc28gcmVxdWlyZWQgdG8gaGVscCBpbmZvcm0NCiB0aG9zZSB3aG8gbWln
aHQgZGVwbG95IHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250
LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog
U2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46
IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsi
Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklnbmFzLCBKb2UsIFRpYW5y
YW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1T
dW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20g
MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu
NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw
Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w
MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPGI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gbGkgemhlbnFpYW5nIFttYWlsdG86
bGlfemhlbnFpYW5nQGhvdG1haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0
b2JlciAyMCwgMjAxNyAzOjU3IFBNPGJyPg0KPGI+VG86PC9iPiBvcHNhd2dAaWV0Zi5vcmc7IG9w
c2F3Zy1jaGFpcnM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gV0dMQyByZXF1ZXN0IGZvciBkcmFmdC1p
ZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw
Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4N
CjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u
dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRlYXIgV0cgQ2hhaXJzIGFu
ZCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0
OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw
Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5J
IHVwZGF0ZWQgdGhlIGZvbGxvd2luZyBkcmFmdCBhY2NvcmRpbmcgdG8gdGhlIGNvbW1lbnRzIHJl
Y2VpdmVkIGZyb20gdGhlIGxpc3QgYW5kIHRoZSBQcmFoYSBtZWV0aW5nLiBUaGUgcHVycG9zZSB0
byBpbnRyb2R1Y2UgbmV3IElFcyBpbiBJUEZJWCBpcyBleHBsYWluZWQgbW9yZSBjbGVhcmx5DQog
aW4gdGhlIGludHJvZHVjYXRpb24gcGFydCBhbmQgZW1waGVzaXplZCBpbiB0aGUgYWJzdHJhY3Qg
cGFydC4gV2UgY2hhbmdlZCBvbmUgc2VjdGlvbiB0aXRsZSBmcm9tICZuYnNwO01lc3NhZ2UmbmJz
cDtMZW5ndGgmbmJzcDtDb25zaWRlcmF0aW9uczxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl
Ij4mbmJzcDt0byAmbmJzcDs8L3NwYW4+T3BlcmF0aW9uYWwmbmJzcDtDb25zaWRlcmF0aW9ucywg
YW5kIGV4cGxhaW5lZCwgYXQgcHJlc2VudCBmb3IgdGhlIGZpZWxkIG5ldHdvcmssIG9uZSBJUEZJ
WA0KIG1lc3NhZ2UgaGFzIGVub3VnaCBzcGFjZSB0byBmaXQgYWxsIHRoZSBjb21tdW5pdHkgaW5m
b3JtYXRpb24gcmVsYXRlZCB0byBhIHNwZWNpZmljIHRyYWZmaWMgZmxvdyAuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2lt
U3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt
c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5TaW5jZSBubyBtb3JlIHRlY2hu
aWNhbCBpc3N1ZXMgcmVtYWluIHRvIGJlIHNvbHZlZCwgYXMgcmVxdWVzdGVkIGluIHRoZSBQcmFo
YSBtZWV0aW5nLCB3ZSB0aGluayB0aGlzIGRvYyBpcyByZWFkeSB0byBkbyBXR0xDLiBUaGFuayB5
b3UgdmVyeSBtdWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47
Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi
bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5OYW1lOiBkcmFmdC1pZXRm
LW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw
MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v
6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJldmlzaW9u
OiAwMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg
Zm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaXRsZTogRXhwb3J0IEJHUCBjb21tdW5pdHkgaW5m
b3JtYXRpb24gaW4gSVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQRklYKTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNp
bVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOmJsYWNrIj5Eb2N1bWVudCBkYXRlOiAyMDE3LTEwLTE3PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNt
IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si
Pkdyb3VwOiBvcHNhd2c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp
emU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UGFnZXM6IDE3PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2lt
U3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6YmxhY2siPlVSTDombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l
dC1kcmFmdHMvZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMy50eHQiIHN0
eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5odHRwczovL3d3
dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vcHNhd2ctaXBmaXgtYmdwLWNv
bW11bml0eS0wMy50eHQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u
dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlN0YXR1czombmJzcDs8YSBo
cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1p
cGZpeC1iZ3AtY29tbXVuaXR5LyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246
IHVuZGVybGluZTsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt
b3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHkvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+
rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IdG1s
aXplZDombmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1vcHNhd2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0
LWRlY29yYXRpb246IHVuZGVybGluZTsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1pZXRmLW9wc2F3Zy1pcGZpeC1iZ3AtY29tbXVuaXR5LTAzPC9hPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46
IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsi
Pg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs
YWNrIj5IdG1saXplZDombmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21tdW5pdHktMDMiIHN0eWxl
PSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5odHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJncC1jb21t
dW5pdHktMDM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRpZmY6Jm5ic3A7PGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3BzYXdnLWlwZml4LWJn
cC1jb21tdW5pdHktMDMiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl
cmxpbmU7Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vcHNh
d2ctaXBmaXgtYmdwLWNvbW11bml0eS0wMzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu
MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7o
va/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250
LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+
rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsgVGhpcyBkcmFmdCB1cGRhdGVzIFJGQzcwMTIgSVBGSVggaW5mb3JtYXRpb24gbW9k
ZWwgYnkgaW50cm9kdWNpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250
LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHNldmVy
YWwgaW5mb3JtYXRpb24gZWxlbWVudHMgdG8gZW5hYmxlIElQRklYIHRvIGV4cG9ydCB0aGUgQkdQ
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250
LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjb21tdW5pdHkgaW5mb3JtYXRpb24s
IGluY2x1ZGluZyBCR1Agc3RhbmRhcmQgY29tbXVuaXR5IGRlZmluZWQgaW48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1T
dW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7IFJGQzE5OTcsIEJHUCBleHRlbmRlZCBjb21tdW5pdHkgZGVm
aW5lZCBpbiBSRkM0MzYwLCBhbmQgQkdQIGxhcmdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u
6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw
OyZuYnNwOyBjb21tdW5pdHkgZGVmaW5lZCBpbiBSRkM4MDkyLiZuYnNwOyBOZXR3b3JrIHRyYWZm
aWMgZmxvdyBpbmZvcm1hdGlvbiBjYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0
OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp
u5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7
IHRoZW4gYmUgYWNjdW11bGF0ZWQgYW5kIGFuYWx5c2VkIGF0IHRoZSBncmFudWxhcml0eSBzcGVj
aWZpZWQgYnkgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBCR1AgY29tbXVu
aXRpZXMsIHdoaWNoIGlzIHN1aXRhYmxlIGZvciBhbmQgbmVlZGVkIGJ5IHNvbWUgdHJhZmZpYzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m
YW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgb3B0aW1pemF0aW9uIGFwcGxpY2F0aW9u
cyBsb2NhdGVkIGluIElQRklYIGNvbGxlY3RvciwgU0ROIGNvbnRyb2xsZXI8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1T
dW47Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7IG9yIFBDRSAoUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50KS48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw
dDsgZm9udC1mYW1pbHk6IFNpbVN1bjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuOyI+DQo8c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u
6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPGhy
IHNpemU9IjEiIHdpZHRoPSIyMTAiIHN0eWxlPSJ3aWR0aDoxMjYuMHB0IiBub3NoYWRlPSIiIGFs
aWduPSJsZWZ0Ij4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm
dDo2LjBwdDttYXJnaW4tdG9wOjYuMHB0O21hcmdpbi1yaWdodDo2LjBwdDttYXJnaW4tYm90dG9t
OjYuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20g
MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW47Ij4NCjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhy
ZWY9Im1haWx0bzpsaV96aGVucWlhbmdAaG90bWFpbC5jb20iIHN0eWxlPSJjb2xvcjogYmx1ZTsg
dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5saV96aGVucWlhbmdAaG90bWFpbC5jb208L2E+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_HK2PR0601MB1492A01359667B31843FA9B9FC590HK2PR0601MB1492_--


From nobody Mon Oct 30 07: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 54B0E139F18; Mon, 30 Oct 2017 07:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level: 
X-Spam-Status: No, score=-2.608 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, T_FILL_THIS_FORM_SHORT=0.01, 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 SkE6xHZE4lYH; Mon, 30 Oct 2017 07:41:22 -0700 (PDT)
Received: from 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 E9A0913F43A; Mon, 30 Oct 2017 07:41:21 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 99A1710087D; Mon, 30 Oct 2017 15:41:20 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 7A61E180064; Mon, 30 Oct 2017 15:41:20 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0361.001; Mon, 30 Oct 2017 15:41:20 +0100
From: 
To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , "yang-doctors@ietf.org" 
CC: "draft-ietf-opsawg-nat-yang.all@ietf.org" , "opsawg@ietf.org" 
Thread-Topic: Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
Thread-Index: AQHTT09nb4Xo03k7b0eBVGOEwFdqM6L8ajgA
Date: Mon, 30 Oct 2017 14:41:19 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A060DB1@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <150912805550.22087.2939629492652644040@ietfa.amsl.com>
In-Reply-To: <150912805550.22087.2939629492652644040@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.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-nat-yang-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, 30 Oct 2017 14:41:28 -0000

SGkgSsO8cmdlbiwNCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KUGxlYXNlIHNlZSBp
bmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N
Cj4gRGXCoDogSsO8cmdlbiBTY2jDtm53w6RsZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGph
Y29icy11bml2ZXJzaXR5LmRlXQ0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDI3IG9jdG9icmUgMjAx
NyAyMDoxNA0KPiDDgMKgOiB5YW5nLWRvY3RvcnNAaWV0Zi5vcmcNCj4gQ2PCoDogZHJhZnQtaWV0
Zi1vcHNhd2ctbmF0LXlhbmcuYWxsQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmcNCj4gT2JqZXTC
oDogWWFuZ2RvY3RvcnMgZWFybHkgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5n
LTA2DQo+IA0KPiBSZXZpZXdlcjogSsO8cmdlbiBTY2jDtm53w6RsZGVyDQo+IFJldmlldyByZXN1
bHQ6IE5vdCBSZWFkeQ0KPiANCj4gU3VtbWFyeQ0KPiANCj4gPkZyb20gYSBZQU5HIG1vZGVsaW5n
IHBvaW50IG9mIHZpZXcsIHRoZSBtb2R1bGUgaXMgcmF0aGVyIHN0cmFpZ2h0DQo+IGZvcndhcmQg
YW5kIEkgZGlkIG5vdCBkaXNjb3ZlciBhbnl0aGluZyB0aGF0IHNlZW1zIGZ1bmRhbWVudGFsbHkN
Cj4gcHJvYmxlbWF0aWMuDQoNCltNZWRdIE9LLg0KDQogVGhhdCBzYWlkLCB0aGVyZSBhcmUgYSBu
dW1iZXIgb2YgZGV0YWlscyB3aGVyZSBJIGRvdWJ0DQo+IHRoZSBtb2RlbCBpcyBjb3JyZWN0IGFu
ZCB0aGluZ3Mgd2hlcmUgSSBiZWxpZXZlIHRoaW5ncyBhcmUgaW5jb21wbGV0ZS4NCj4gR2l2ZW4g
dGhhdCB0aGVyZSBhcmUgbWFueSBkaWZmZXJlbnQgTkFUIGZ1bmN0aW9ucywgSSBhbHNvIGV4cGVj
dGVkIHRvDQo+IHNlZSB1c2FnZSBvZiBZQU5HIGZlYXR1cmVzLg0KDQpbTWVkXSBXZSB1c2VkIHRv
IG1ha2UgdXNlIG9mICJmZWF0dXJlcyIsIGJ1dCB0aGVyZSB3YXMgYSBjb21tZW50IGR1cmluZyB0
aGUgV0cgY2FsbCBmb3IgYWRvcHRpb24gdGhhdCByZXF1ZXN0ZWQgdXMgdG8gbWFrZSB1c2Ugb2Yg
aWRlbnRpdGllcywgaW5zdGVhZC4NCg0KPiANCj4gT25lIGZ1bmRhbWVudGFsIHF1ZXN0aW9uIG9u
ZSBjb3VsZCByYWlzZSBpcyB3aGV0aGVyIHRoaXMgbW9kZWwgc2hvdWxkDQo+IGhhdmUgYmVlbiBi
cm9rZW4gZG93biBpbnRvIGEgZ2VuZXJpYyBOQVQgY29yZSBtb2RlbCBwbHVzIGV4dGVuc2lvbnMg
b2YNCj4gdGhlIGNvcmUgbW9kZWwgZm9yIHRoZSBkaWZmZXJlbnQgdHlwZXMgb2YgTkFUcy4gV2Vs
bCwgYSBzaW5nbGUgbW9kZWwNCj4gd2l0aCBZQU5HIGZlYXR1cmVzIGlzIGFuIGlubGluZSB2ZXJz
aW9uIG9mIHRoYXQgYXMgdGhpcyBzdGlsbCByZXF1aXJlcw0KPiB0byBtYXJrIGNsZWFybHkgd2hp
Y2ggcGFydHMgYXJlIHNwZWNpZmljIHRvIGNlcnRhaW4gdHlwZXMgb3IgTkFUcy4NCj4gDQo+IEkg
ZGlkIG5vdCBjb21waWxlIHRoZSBtb2R1bGUgbXlzZWxmIHNpbmNlIHRoZSBJRVRGIHRyYWNrZXIg
c2F5cyBubw0KPiBlcnJvcnMgdXNpbmcgcHlhbmcgYW5kIHlhbmdsaW50IChhbmQgSSB3b3VsZCBu
b3QgaGF2ZSBydW4gYW55dGhpbmcNCj4gZGlmZmVyZW50KS4gKElzIGl0IE9LIGZvciBZQU5HIGRv
Y3RvcnMgdG8gdHJ1c3QgdGhlIHRyYWNrZXIgdG9vbHM/DQo+IFdlbGwsIHNpbmNlIHRoaXMgaXMg
bGFiZWxsZWQgYXMgYW4gZWFybHkgcmV2aWV3IGFuZCBJIGV4cGVjdCBtb3JlDQo+IHVwZGF0ZXMs
IEkgYXNzdW1lIHRoaXMgaXMgZmluZS4pDQo+IA0KPiBJIGNhbid0IHRlbGwgd2hldGhlciB0aGUg
bW9kZWwgbWFrZXMgc2Vuc2UgZnJvbSBhIE5BVCBwb2ludCBvZiB2aWV3LiBJDQo+IGFtIG5vdCBh
biBleHBlcnQgaW4gdGhlIHZhcmlvdXMgdHlwZXMgb2YgTkFUcyBhbmQgc3VyZWx5IG1vcmUgcmV2
aWV3cw0KPiBvZiBOQVQgZXhwZXJ0cyB3b3VsZCBiZSBnb29kIChhbmQgdGhleSB3b3VsZCBoYXZl
IGxpa2VseSBzcG90dGVkIHNvbWUNCj4gdGhpbmdzIEkgaGF2ZSBzcG90dGVkLCBzbyBJIGd1ZXNz
IHRoZSB1c3VhbCBwcm9ibGVtIG9mIGdldHRpbmcgZW5vdWdoDQo+IHN1YnN0YW50aWFsIHJldmll
d3MpLg0KDQpbTWVkXSBGWUksIHRoZSBtb2R1bGUgd2FzIHJldmlld2VkIGJ5IGV4cGVydHMgb2Yg
ZWFjaCBvZiB0cmFuc2xhdGlvbiBmbGF2b3JzIGNvdmVyZWQgaW4gdGhlIGRvY3VtZW50LiBBbGwg
dGhlIHJldmlld3Mgd2VyZSBzaGFyZWQgb24gdGhlIGxpc3QuIA0KDQo+IA0KPiBEZXRhaWxzDQo+
IA0KPiAtIFdlIHVzZSByZXZpc2lvbiBzdGF0ZW1lbnRzIG9ubHkgZm9yIHB1Ymxpc2hlZCBtb2R1
bGVzLiBIZW5jZSwgcGxlYXNlDQo+ICAgcmVwbGFjZSB0aGUgcmV2aXNpb24gc3RhdGVtZW50cyB3
aXRoDQo+IA0KPiAgIC8vIFJGQyBFZC4gdXBkYXRlIHRvIG1hdGNoIHRoZSBkYXRlIG9mIHRoZSBs
YXRlc3QgZWRpdHMNCj4gICByZXZpc2lvbiAyMDE3LXh4LXl5IHsNCj4gICAgIGRlc2NyaXB0aW9u
DQo+ICAgICAgICJJbml0aWFsIHJldmlzaW9uLiI7DQo+ICAgICByZWZlcmVuY2UNCj4gICAgICAg
IlJGQyBYWFhYOiBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0
aW9uDQo+ICAgICAgICAgICAgICAgICAgKE5BVCkgYW5kIE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0
aW9uIChOUFQpIjsNCj4gICB9DQo+IA0KDQpbTWVkXSBGaXhlZC4gVGhhbmtzLg0KDQo+IC0gV2Ug
dXN1YWxseSBmb2xsb3cgYSBkaWZmZXJlbnQgdGVtcGxhdGUgZm9yIHRoZSBjb250YWN0IHN0YXRl
bWVudA0KPiAgIHRoYXQgaGFzIG1vcmUgY29udGV4dCBhbmQganVzdCBhIGxpc3Qgb2YgbmFtZXMg
YW5kIGVtYWlsIGFkZHJlc3Nlcy4NCj4gDQoNCltNZWRdIEZpeGVkLg0KDQoNCj4gLSBXZSB1c3Vh
bGx5IHdyaXRlDQo+IA0KPiAgICAgIHJlZmVyZW5jZQ0KPiAgICAgICAgIlJGQyAzMDIyOiBUcmFk
aXRpb25hbCBJUCBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRvcg0KPiAgICAgICAgICAgICAgICAg
ICAoVHJhZGl0aW9uYWwgTkFUKSI7DQo+IA0KPiAgIGluc3RlYWQgb2YganVzdA0KPiANCj4gICAg
ICByZWZlcmVuY2UNCj4gICAgICAgICJSRkMgMzAyMi4iOw0KPiANCj4gICBzaW5jZSBub3QgZXZl
cnlib2R5IHJlbWVtYmVycyBhbGwgdGhlIG51bWJlcnMgZXF1YWxseSB3ZWxsLg0KDQpbTWVkXSBG
aXhlZC4gDQoNCj4gDQo+IC0gSXMgdGhlcmUgYSByZWZlcmVuY2UgZm9yIGRzdC1uYXQ/DQoNCltN
ZWRdIEkgZG9uJ3QgaGF2ZSBhbiBSRkMgdG8gY2l0ZSBoZXJlLiANCg0KPiANCj4gLSBXaGF0IGlz
IHRoZSB2cmYtcm91dGluZy1pbnN0YW5jZSBpZGVudGl0eSBnb29kIGZvcj8NCg0KW01lZF0gVGhp
cyBpcyB1c2VkIHRvIGJpbmQgYSBOQVQgZnVuY3Rpb24gdG8gYW4gZXh0ZXJuYWwgVlJGIHJvdXRp
bmcgaW5zdGFuY2UuIFBsZWFzZSBjaGVjayBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp
dmUvd2ViL29wc2F3Zy9jdXJyZW50L21zZzA1MTE3Lmh0bWwgDQoNCiBJdHMgdXNlZCBvbmx5IGlu
DQo+ICAgdGhlIGxlYWYgZXh0ZXJuYWwtdnJmLWluc3RhbmNlIGFuZCB0aGUgZGVzY3JpcHRpb24g
b2YgdGhhdCBsZWFmIGlzDQo+ICAgbm90IHRlbGxpbmcgbWUgaG93IHRoaXMgaXMgZ29pbmcgdG8g
YmUgdXNlZC4gV2hvIGlzIGdvaW5nIHRvIGRlcml2ZQ0KPiAgIGlkZW50aXRpZXM/IEkgZmVhciB5
b3UgYXJlIHRyeWluZyB0byBhY2hpZXZlIHNvbWV0aGluZyB3aGVyZSB1c2luZw0KPiAgIGlkZW50
aXRpZXMgaXMgcmVhbGx5IHRoZSB3cm9uZyBhcHByb2FjaC4gU2VjdGlvbiAyLjEwIGRvZXMgbm90
IHRlbGwNCj4gICBob3cgdGhpcyBpcyBzdXBwb3NlZCB0byB3b3JrIGVpdGhlci4gSSBhc3N1bWUg
dGhpcyBuZWVkcyB0byBiZQ0KPiAgIGNoZWNrZWQgYnkgdGhlIHJvdXRpbmcgYXJlYSBleHBlcnRz
IHRvIG1ha2Ugc3VyZSB0aGluZ3MgZml0IHdpdGgNCj4gICB0aGVpciBtb2RlbGluZyBvZiBWUkZz
Lg0KPiANCj4gLSBzL3N0YXJ0LXBvcnQtbnVtYmVydC9zdGFydC1wb3J0LW51bWJlci8NCg0KW01l
ZF0gRml4ZWQuDQoNCj4gDQo+IC0gQXJlIGNvbW1lbnRzIGxpa2UNCj4gDQo+ICAgLy8gcG9ydCBu
dW1iZXJzOiBzaW5nbGUgb3IgcG9ydC1yYW5nZQ0KPiANCj4gICBuZWNlc3NhcnkgZ2l2ZW4gdGhh
dCB0aGVyZSBhcmUgZGVzY3JpcHRpb24gc3RhdGVtZW50cz8gTm90ZSB0aGF0DQo+ICAgY29tbWVu
dHMgbWF5IGJlIHJlbW92ZWQgYnkgdG9vbHMgd2hpbGUgZGVzY3JpcHRpb24gc3RhdGVtZW50cw0K
PiAgIHVzdWFsbHkgYXJlIHByZXNlcnZlZC4gU28gaXQgaXMgaW1wb3J0YW50IHRvIGhhdmUgYW55
dGhpbmcgaW1wb3J0YW50DQo+ICAgY292ZXJlZCBpbiBkZXNjcmlwdGlvbiBzdGF0ZW1lbnRzLg0K
PiANCg0KW01lZF0gQ2xlYW5lZCBhbGwgdGhlc2UgY29tbWVudHMuIA0KDQo+IC0gV2hhdCBpcyBh
IFBTSUQgYWxnb3JpdGhtPyBTcGVsbCBvdXQgYWNyb255bXMgb24gZmlyc3QgdXNhZ2UuDQoNCltN
ZWRdIFBTSUQgc3RhbmRzIGZvciBQb3J0IFNldCBJZGVudGlmaWVyLiBUaGlzIGlzIGFuIGFsZ29y
aXRobSB0byBhc3NpZ24gbm9uLW92ZXJsYXBwaW5nIHBvcnQgc2V0cyB0byB1c2VycyBzZXJ2aWNl
ZCB3aXRoIHRoZSBzYW1lIHNoYXJlZCBJUHY0IGFkZHJlc3MuIFJlZmVyZW5jZXMgYXJlIGFkZGVk
IHRvIHRoZSBtb2R1bGUuDQoNCj4gDQo+IC0gVGhlIGxlYWZzIHN0YXJ0LXBvcnQtbnVtYmVyIGFu
ZCBlbmQtcG9ydC1udW1iZXIgYXJlIGNvbW1lbnRlZCBvdXQgaW4NCj4gICBwb3J0LXJhbmdlLCBw
cm9iYWJseSBpbiBmYXZvdXIgb2YgdGhlIHVzZXMgcG9ydC1udW1iZXIuIElmIHRoZXkgYXJlDQo+
ICAgbm90IG5lZWRlZCBhbnltb3JlLCB0aGV5IHNob3VsZCBiZSByZW1vdmVkLg0KDQpbTWVkXSBS
ZW1vdmVkLiANCg0KPiANCj4gLSBJIGRvIG5vdCB1bmRlcnN0YW5kIHBvcnQtc2V0LWFsZ28gZnJv
bSB0aGUgZGVzY3JpcHRpb25zLiBXaGF0IGlzIHRoZQ0KPiAgIHBzaWQtb2Zmc2V0IGFwcGxpZWQ/
IFdoYXQgaXMgYSAnc2hhcmluZyByYXRpb24gZm9yIGFuIElQdjQgYWRkcmVzcyc/DQo+ICAgSXMg
dGhpcyBzdHVmZiBJUHY0IHNwZWNpZmljPyBJcyB0aGUgcHNpZCBzb21ldGhpbmcgdGhhdCBoYXMg
YQ0KPiAgIGNlcnRhaW4gbWVhbmluZyBvdXRzaWRlIG9mIHRoaXMgWUFORyBtb2R1bGU/IElmIHNv
LCB3aGVyZSBkbyBJIGZpbmQNCj4gICBtb3JlIGRldGFpbHMgKG1pc3NpbmcgcmVmZXJlbmNlIHN0
YXRlbWVudD8pPw0KDQpbTWVkXSBJIHVwZGF0ZWQgdGhlIGRlc2NyaXB0aW9uIGFuZCBhZGRlZCBw
b2ludGVycyB0byB0aGUgYXV0aG9yaXRhdGl2ZSBzcGVjLiANCg0KPiANCj4gLSBtYXBwaW5nLWVu
dHJ5L2luZGV4OiBpcyB0aGlzIGFuIGFyYml0cmFyeSBpZGVudGlmaWVyPyBob3cgYXJlIHRoZXNl
DQo+ICAgaWRlbnRpZmllcnMgYWxsb2NhdGVkPyBBcmUgdGhleSBjcmVhdGVkIGJ5IHRoZSBOQVQg
b3IgYXJlIHRoZXkgY3JlYXRlZA0KPiAgIHZpYSBjb25maWd1cmF0aW9uPyBPciBldmVuIGJvdGg/
IFdlbGwsIEkgZ3Vlc3MgaXQgaXMgYm90aCBnaXZlbiB0aGUNCj4gICBtYXBwaW5nLWVudHJ5L3R5
cGUgbGVhZi4NCg0KW01lZF0gQm90aCBjYW4gYmUgc3VwcG9ydGVkLiANCg0KPiANCj4gLSBtYXBw
aW5nLWVudHJ5L3R5cGU6IGluc3RlYWQgJ21hbnVhbGx5IGNvbmZpZ3VyZWQnLCBJIHdvdWxkIHdy
aXRlDQo+ICAgJ2V4cGxpY2l0bHkgY29uZmlndXJlZCcgKGNvbmZpZ3VyYXRpb24gZG9lcyBub3Qg
aGF2ZSB0byBiZSBhIG1hbnVhbA0KDQpbTWVkXSBNYW51YWxseSBpcyBkZXJpdmVkIGZyb20gUkZD
Njg4Nywgd2hpY2ggc2F5czogDQoNCiAgICAgICogIEV4cGxpY2l0IHN0YXRpYyBtYXBwaW5ncyBh
cmUgY3JlYXRlZCBieSBtYW51YWwgY29uZmlndXJhdGlvbg0KICAgICAgICAgKGUuZy4sIHZpYSBj
b21tYW5kLWxpbmUgaW50ZXJmYWNlIG9yIG90aGVyIHVzZXIgaW50ZXJmYWNlKSBhbmQNCiAgICAg
ICAgIHBlcnNpc3QgdW50aWwgdGhlIHVzZXIgY2hhbmdlcyB0aGF0IG1hbnVhbCBjb25maWd1cmF0
aW9uLg0KDQoNCj4gICBwcm9jZXNzKS4gSSBhbHNvIGZpbmQgdGhlIG90aGVyIGVudW0gbGFiZWxz
IGF0IGxlYXN0IGEgYml0IGNvbmZ1c2luZy4NCj4gDQo+ICAgICAgICAgZW51bSAiZHluYW1pYy1l
eHBsaWNpdCIgew0KPiAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAgICAgIlRoaXMg
bWFwcGluZyBpcyBjcmVhdGVkIGJ5IGFuDQo+ICAgICAgICAgICAgICBvdXRnb2luZyBwYWNrZXQu
IjsNCj4gICAgICAgICB9DQo+IA0KPiAgICAgICAgIGVudW0gImR5bmFtaWMtaW1wbGljaXQiIHsN
Cj4gICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgICJUaGlzIG1hcHBpbmcgaXMg
Y3JlYXRlZCBieSBhbg0KPiAgICAgICAgICAgICAgZXhwbGljaXQgIGR5bmFtaWMgbWVzc2FnZS4i
Ow0KPiAgICAgICAgIH0NCj4gDQo+ICAgTm90ZSB0aGUgJ2ltcGxpY2l0JyB2cyAnZXhwbGljaXQn
IGNsYXNoIGhlcmUuIA0KDQpbTWVkXSBHb29kIGNhdGNoLiBUaGFua3MuDQoNClBlcmhhcHMgdGhp
cyBzaG91bGQgYmUNCj4gICBhbGlnbmVkIHdpdGggdGhlIGRlZmluaXRpb24gb2YgZHluYW1pYyBh
bmQgaW1wbGljaXQgbWFwcGluZ3M6DQo+IA0KPiAgICBvICBEeW5hbWljIGltcGxpY2l0IG1hcHBp
bmc6IGlzIGNyZWF0ZWQgaW1wbGljaXRseSBhcyBhIHNpZGUgZWZmZWN0DQo+ICAgICAgIG9mIHRy
YWZmaWMgc3VjaCBhcyBhbiBvdXRnb2luZyBUQ1AgU1lOIG9yIGFuIG91dGdvaW5nIFVEUCBwYWNr
ZXQuDQo+ICAgICAgIEEgdmFsaWRpdHkgbGlmZXRpbWUgaXMgYXNzb2NpYXRlZCB3aXRoIHRoaXMg
bWFwcGluZy4NCj4gDQo+ICAgIG8gIER5bmFtaWMgZXhwbGljaXQgbWFwcGluZzogaXMgY3JlYXRl
ZCBhcyBhIHJlc3VsdCBvZiBhbiBleHBsaWNpdA0KPiAgICAgICByZXF1ZXN0LCBlLmcuLCBQQ1Ag
bWVzc2FnZSBbUkZDNjg4N10uICBBIHZhbGlkaXR5IGxpZmV0aW1lIGlzDQo+ICAgICAgIGFzc29j
aWF0ZWQgd2l0aCB0aGlzIG1hcHBpbmcuDQo+IA0KPiAgIEJ1dCB0aGVuIGl0IHNlZW1zIHlvdSBy
ZWFsbHkgbWVzc2VkIHRoaW5ncyB1cCBoZXJlLiBJIHdvdWxkIGV2ZW4NCj4gICB3cml0ZSB0aGVz
ZSBkZWZpbml0aW9ucyBkaWZmZXJlbnRseSBzaW5jZSAnb3V0Z29pbmcnIGlzIHVuY2xlYXIgYW5k
DQo+ICAgcG90ZW50aWFsbHkgY29uZnVzaW5nLg0KPiANCj4gICAgbyAgRHluYW1pYyBpbXBsaWNp
dCBtYXBwaW5nOiBpcyBjcmVhdGVkIGltcGxpY2l0bHkgYXMgYSBzaWRlIGVmZmVjdA0KPiAgICAg
ICBvZiBwcm9jZXNzaW5nIGEgcGFja2V0IChlLmcuLCBhbiBpbml0aWFsIFRDUCBTWU4gcGFja2V0
KSB0aGF0DQo+ICAgICAgIHJlcXVpcmVzIGEgbmV3IG1hcHBpbmcuIEEgdmFsaWRpdHkgbGlmZXRp
bWUgaXMgYXNzb2NpYXRlZCB3aXRoDQo+ICAgICAgIHRoaXMgbWFwcGluZy4NCj4gDQo+ICAgIG8g
IER5bmFtaWMgZXhwbGljaXQgbWFwcGluZzogaXMgY3JlYXRlZCBhcyBhIHJlc3VsdCBvZiBhbiBl
eHBsaWNpdA0KPiAgICAgICByZXF1ZXN0LCBlLmcuLCBQQ1AgbWVzc2FnZSBbUkZDNjg4N10uICBB
IHZhbGlkaXR5IGxpZmV0aW1lIGlzDQo+ICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGlzIG1hcHBp
bmcuDQo+IA0KDQpbTWVkXSBXb3JrcyBmb3IgbWUuDQoNCj4gICAgU2ltaWxhcmx5LCBJIHdvdWxk
IGNoYW5nZSB0aGUgZGVzY3JpcHRpb24gb2YNCj4gDQo+ICAgICAgICAgZW51bSAiZHluYW1pYy1p
bXBsaWNpdCIgew0KPiAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAgICAgIlRoaXMg
bWFwcGluZyBpcyBjcmVhdGVkIGltcGxpY2l0ZWx5IGFzIGEgc2lkZSBlZmZlY3QNCj4gICAgICAg
ICAgICAgIG9mIHByb2Nlc3NpbmcgYSBwYWNrZXQgdGhhdCByZXF1aXJlcyBhIG5ldyBtYXBwaW5n
LiI7DQo+ICAgICAgICAgfQ0KPiANCj4gICAgICAgICBlbnVtICJkeW5hbWljLWV4cGxpY2l0IiB7
DQo+ICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAiVGhpcyBtYXBwaW5nIGlz
IGNyZWF0ZWQgYXMgYSByZXN1bHQgb2YgYW4gZXhwbGljaXQNCj4gICAgICAgICAgICAgIHJlcXVl
c3QsIGUuZy4sIGEgUENQIG1lc3NhZ2UuIjsNCj4gICAgICAgICB9DQo+IA0KDQpbTWVkXSBEZWFs
IQ0KDQo+IC0gV2Ugc2hvdWxkIHBlcmhhcHMgaGF2ZSBhIHR5cGUgZm9yIGFuIElQIHByb3RvY29s
IG51bWJlciwgaWRlYWxseSBpbg0KPiAgIGluZXQtdHlwZXMuIChKdXN0IGEgcmVtaW5kZXIgdG8g
bXlzZWxmLikgVGhhdCBzYWlkLCBJIGRvIG5vdA0KPiAgIHVuZGVyc3RhbmQgd2hhdCB0aGlzIHNl
bnRlbmNlIG1lYW5zOg0KPiANCj4gICAgIE5vIHRyYW5zcG9ydCBwcm90b2NvbCBpcyBpbmRpY2F0
ZWQgaWYgYSBtYXBwaW5nIGFwcGxpZXMgZm9yDQo+ICAgICBhbnkgcHJvdG9jb2wuDQo+IA0KPiAg
IFBlcmhhcHMgeW91IHdhbnRlZCB0byBzYXkgdGhpczoNCj4gDQo+ICAgICBJZiB0aGlzIGxlYWYg
aXMgbm90IGluc3RhbnRpYXRlZCwgdGhlbiB0aGUgbWFwcGluZyBhcHBsaWVzIHRvIGFueQ0KPiAg
ICAgcHJvdG9jb2wuDQoNCltNZWRdIFlvdSBnb3QgaXQuIEkgdXNlZCB5b3VyIHByb3Bvc2VkIHdv
cmRpbmcuIA0KDQo+IA0KPiAtIGNvbnRhaW5lciBpbnRlcm5hbC1zcmMtcG9ydDoNCj4gLSBjb250
YWluZXIgZXh0ZXJuYWwtc3JjLXBvcnQ6DQo+IC0gY29udGFpbmVyIGludGVybmFsLWRzdC1wb3J0
Og0KPiAtIGNvbnRhaW5lciBleHRlcm5hbC1kc3QtcG9ydDoNCj4gDQo+ICAgICAgICAgIEl0IGlz
IHVzZWQgYWxzbyB0byBjYXJyeSB0aGUgaW50ZXJuYWwNCj4gICAgICAgICAgc291cmNlIElDTVAg
aWRlbnRpZmllci4iOw0KPiANCj4gICBJIHRoaW5rIGRldGFpbHMgYXJlIGxhY2tpbmcgaGVyZS4g
V2hhdCBpcyB0aGUgSUNNUCBpZGVudGlmaWVyPyBXaGF0DQo+ICAgZG9lcyAnY2FycnknIG1lYW4g
YW5kIGhvdyBkb2VzIHRoaXMgcmVsYXRlIHRvIHRoZSBwb3J0LW51bWJlcg0KPiAgIGdyb3VwaW5n
Pw0KPiANCj4gICBTZWUgYWJvdmUsIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhlIElDTVAgaWRlbnRp
ZmllciBzdGF0ZW1lbnQuDQoNCltNZWRdICdJQ01QIElkZW50aWZpZXInIHVzYWdlIGlzIHRoZSBz
YW1lIGFzIGluIFJGQzYxNDYuIA0KDQpJIGFkZGVkIHRoaXMgTkVXIHRleHQ6DQoNCiAgICAgICAg
IEFzIGEgcmVtaW5kZXIsIGFsbCB0aGUgSUNNUCBRdWVyeSBtZXNzYWdlcyBjb250YWluIA0KICAg
ICAgICAgYW4gJ0lkZW50aWZpZXInIGZpZWxkLCB3aGljaCBpcyByZWZlcnJlZCB0byBpbiB0aGlz
IA0KICAgICAgICAgZG9jdW1lbnQgYXMgdGhlICdJQ01QIElkZW50aWZpZXInLiI7DQoNCj4gDQo+
IC0gbGlmZXRpbWU6DQo+IA0KPiAgIFNwZWxsIG91dCAzV0hTLg0KW01lZF0gUmVwbGFjZWQgd2l0
aCB0aHJlZS13YXkgaGFuZHNoYWtlLiANCg0KIEkgdGhpbmsgdGhlcmUgc2hvdWxkIGJlIGEgdW5p
dHMgc3RhdGVtZW50Lg0KW01lZF0gQWdyZWUuIEZpeGVkLg0KDQogQW5kIGlzDQo+ICAgdGhpcyBh
IHRpY2tpbmcgbGlmZXRpbWUsIGkuZS4sIHRoaXMgY2hhbmdlcyBvbiBldmVyeSBnZXQgcmVxdWVz
dD8gSXMNCj4gICB0aGlzIHVzZWZ1bD8gSGF2ZSBhbHRlcm5hdGl2ZXMgYmVlbiBjb25zaWRlcmVk
IHN1Y2ggYXMgcmVwb3J0aW5nIHRoZQ0KPiAgIHBvaW50IGluIHRpbWUgd2hlbiB0aGUgbWFwcGlu
ZyB3YXMgZXN0YWJsaXNoZWQ/IE9yIGlzIHRoZSBpZGVhIHRoYXQNCj4gICB0aGUgbGlmZXRpbWUg
cmVwb3J0cyB0aGUgdGltZSBsZWZ0IHVudGlsIHRoZSBtYXBwaW5nIHdpbGwgYmUgZ2FyYmFnZQ0K
PiAgIGNvbGxlY3RlZD8gV2hhdCBkb2VzICJ0cmFja3MgdGhlIGNvbm5lY3Rpb24iIHJlYWxseSBt
ZWFuIGhlcmU/DQoNCltNZWRdIFRoZSBpbml0aWFsIHZhbHVlIGluZGljYXRlcyB0aGUgZHVyYXRp
b24gdG8gbWFpbnRhaW4gYSBtYXBwaW5nLiBXaGVuIHJldHJpZXZlZCBpbiBhIGdldCBvcGVyYXRp
b24sIGl0IGluZGljYXRlcyB0aGUgcmVtYWluaW5nIHZhbGlkaXR5IGxpZmV0aW1lLiAgDQpJIHVw
ZGF0ZWQgdGhlIHRleHQgdG8gY2xhcmlmeSB0aGlzLg0KDQo+IA0KPiAtIEkgc3VnZ2VzdCB0byBy
ZW1vdmUgZW1wdHkgbGluZXMgaW4gc2F5IGxlYWYgZGVmaW5pdGlvbnMuIEluc3RlYWQNCj4gDQo+
ICAgICAgIGxlYWYgaWQgew0KPiAgICAgICAgIHR5cGUgdWludDMyOw0KPiANCj4gICAgICAgICBk
ZXNjcmlwdGlvbg0KPiAgICAgICAgICAgIk5BVCBpbnN0YW5jZSBpZGVudGlmaWVyLiI7DQo+IA0K
PiAgICAgICAgIHJlZmVyZW5jZQ0KPiAgICAgICAgICAgIlJGQyA3NjU5LiI7DQo+ICAgICAgIH0N
Cj4gDQo+ICAgd3JpdGUNCj4gDQo+ICAgICAgIGxlYWYgaWQgew0KPiAgICAgICAgIHR5cGUgdWlu
dDMyOw0KPiAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAiTkFUIGluc3RhbmNlIGlk
ZW50aWZpZXIuIjsNCj4gICAgICAgICByZWZlcmVuY2UNCj4gICAgICAgICAgICJSRkMgNzY1OTog
RGVmaW5pdGlvbnMgb2YgTWFuYWdlZCBPYmplY3RzIGZvciBOZXR3b3JrDQo+ICAgICAgICAgICAg
ICAgICAgICAgIEFkZHJlc3MgVHJhbnNsYXRvcnMgKE5BVHMpIjsNCj4gICAgICAgfQ0KPiANCltN
ZWRdIEZpeGVkLg0KDQoNCj4gLSBJdCBzZWVtcyB5b3UgdHJ5IHRvIGJlIGFsaWduZWQgd2l0aCB0
aGUgTkFUVjItTUlCIG1vZHVsZSBidXQgdGhlcmUNCj4gICBpcyBubyBleHBsaWNpdCBkaXNjdXNz
aW9uIGFib3V0IHRoaXMgaW4gdGhlIGRvY3VtZW50LiBJIHN1Z2dlc3QgdGhhdA0KPiAgIHlvdSBh
IHNlY3Rpb24gKGZvciBleGFtcGxlIGJlZm9yZSB0aGUgdHJlZSBkaWFncmFtKSB3aGVyZSB5b3UN
Cj4gICBkaXNjdXNzIGhvdyB0aGlzIFlBTkcgbW9kdWxlIGNvZXhpc3RzIHdpdGggdGhlIE5BVFYy
LU1JQiBtb2R1bGUuDQoNCltNZWRdIEkgd2lsbCBTZW50aGlsIChvbmUgb2YgdGhlIGNvLWF1dGhv
ciBvZiB0aGUgTkFUVjItTUlCIG1vZHVsZSkgY29tbWVudCBvbiB0aGlzLiAgDQoNCj4gDQo+ICAg
Rm9yIGV4YW1wbGUsIEkgc2VlIHRoYXQgTmF0djJJbnN0YW5jZUluZGV4IGluIHRoZSBNSUIgbW9k
dWxlDQo+ICAgZXhjbHVkZXMgMCBhcyBhbiBpbnN0YW5jZSBpZGVudGlmaWVyIHdoaWxlIHlvdXIg
aWQgbGVhZiBhYm92ZSBhbGxvd3MNCj4gICB0aGUgdXNhZ2Ugb2YgMC4NCj4gDQo+IC0gY29udGFp
bmVyIG5hdC1jYXBhYmlsaXRpZXM6DQo+IA0KPiAgIEhlcmUgd2UgZmluZCBhIGJ1bmNoIG9mICJj
b25maWcgdHJ1ZSIgbGVhZnMgYW5kIEkgd29uZGVyIGhvdyB0aGVzZQ0KPiAgIHdvcmsuIFRoZXJl
IGFyZSB0aGluZ3MgYSBOQVQgaW1wbGVtZW50YXRpb24gaXMgY2FwYWJsZSB0byBkbywgYW5kDQo+
ICAgdGhlcmUgYXJlIHRoaW5ncyB0aGF0IGFyZSBlbmFibGVkIGluIGEgTkFUIGRlcGxveW1lbnQg
YW5kIG9mIGNvdXJzZQ0KPiAgIHlvdSBjYW4ndCBlbmFibGUgc29tZXRoaW5nIGluIGEgZGVwbG95
bWVudCB0aGF0IGhhcyBub3QgYmVlbg0KPiAgIGltcGxlbWVudGVkLiBTbyBhcmUgdGhlc2UgJ2Nh
cGFiaWxpdGllcycgbW9yZSBsaWtlIE5BVCBmZWF0dXJlcw0KPiAgIGVuYWJsZWQgKHNpbmNlIHdl
IGhhdmUgImNvbmZpZyB0cnVlIiBub2Rlcykgb3IgYXJlIHRoZXNlIG1vcmUNCj4gICBpbXBsZW1l
bnRlZCBjYXBhYmlsaXRpZXMgKGJ1dCB0aGVuICJjb25maWcgdHJ1ZSIgbWF5IGJlIHdyb25nKT8N
Cg0KW01lZF0gVGhlc2UgYXJlIGFib3V0IHdoYXQgYW4gaW1wbGVtZW50YXRpb24gaXMgYWJsZSB0
byBkby4gV2hlbiBJIHNldCBjb25maWcgdG8gImZhbHNlIiwgcHlhbmcgaXMgY29tcGxhaW5pbmcu
DQoNCj4gICBEZXBlbmRpbmcgb24gdGhlIGFuc3dlciwgZGlkIHlvdSBjb25zaWRlciB1c2luZyBZ
QU5HIGZlYXR1cmVzPw0KDQpbTWVkXSBZZXMsIHdlIGNvbnNpZGVyZWQgdGhlIFlBTkcgZmVhdHVy
ZXMuDQoNCj4gDQo+IC0gbmF0LWZsYXZvciBhbmQgbmF0NDQtZmxhdm9yOg0KPiANCj4gICBEb2Vz
IGl0IG1ha2Ugc2Vuc2UgdG8gaGF2ZSB0d28gb2JqZWN0cyBoZXJlPyBDYW4gSSBwdXQgYmFzaWMt
bmF0DQo+ICAgaW50byBuYXQtZmxhdm9yPyBBcmUgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gbGV0
cyBzYXkgbmFwdCBhbmQNCj4gICBiYXNpYy1uYXQgcmVhbGx5IG5hdDQ0IHNwZWNpZmljPw0KDQpb
TWVkXSBUaGVzZSBhcmUgc3BlY2lmaWMgdG8gY2hhcmFjdGVyaXplIGEgTkFUNDQuIEZvciBleGFt
cGxlOg0KLSBOUFR2NiBpcyBieSBkZXNpZ24gYWN0aW5nIG9uIHByZWZpeGVzOyBwb3J0cyBhcmUg
bm90IHRvdWNoZWQNCi0gTkFUNjQgY2FuIGJlIHN0YXRlbGVzcyBvciBzdGF0ZWZ1bGwNCi0gRUFN
IHJlbGllcyBvbiBhZGRyZXNzIHJld3JpdGluZw0KDQo+IA0KPiAgIE5vdGUgdGhhdCB5b3UgYWxz
byBkZXJpdmUgcmVzdHJpY3RlZC1uYXQgZnJvbSBuYXQ0NCBidXQgdGhpcyBvcHRpb24NCj4gICBp
cyBub3QgbWVudGlvbmVkIGluIHRoZSBkZXNjcmlwdGlvbiBvZiBuYXQ0NC1mbGF2b3IuIA0KDQpb
TWVkXSBUaGF0IG9uZSBpcyByZW1vdmVkLCBiZWNhdXNlIGl0IGlzIGNvbmZsaWN0aW5nIHdpdGgg
dGhlIHVzZSBvZiAicmVzdHJpY3RlZC1wb3J0LXN1cHBvcnQiIHRoYXQgaXMgdmFsaWQgZm9yIGJv
dGggc3RhdGUgZnVsbCBOQVQ2NCBhbmQgTkFUNDQuIA0KDQoNCkkgdGhpbmsgdGhlDQo+ICAgZGVz
Y3JpcHRpb24gc2hvdWxkIGJlIG1vcmUgb3BlbiBzaW5jZSBpbiBwcmluY2lwbGUgSSBjYW4gZGVy
aXZlIGV2ZW4NCj4gICBtb3JlIGlkZW50aXRpZXMgaW4gdGhlIGZ1dHVyZS4NCj4gDQo+IC0gYm9v
bGVhbiBjYXBhYmlsaXR5IGZsYWdzDQo+IA0KPiAgIERvIHRoZXNlIG5lZWQgcmVmZXJlbmNlcyBz
byBvbmUgY2FuIGxvb2t1cCB3aGF0IHRoZSBleGFjdCBtZWFuaW5nIG9mDQo+ICAgdGhlc2UgJ2Nh
cGFiaWxpdGllcycgYXJlPyBJdCB3b3VsZCBzdXJlbHkgaGVscCBtZSBhbmQgaXQgd2lsbCBoZWxw
DQo+ICAgaW1wbGVtZW50b3JzIHRoYXQgbmVlZCB0byBkZWNpZGUgd2hldGhlciBhIGNlcnRhaW4g
dmVuZG9yIGZlYXR1cmUNCj4gICBmaXRzIGFueSBvZiB0aGVzZS4NCg0KW01lZF0gSSBhZGRlZCBy
ZWZlcmVuY2VzIGFzIGFwcHJvcHJpYXRlLiANCg0KPiANCj4gLSBuYXQtcGFzcy10aHJvdWdoLXBy
ZWYNCj4gDQo+ICAgUGVyaGFwcyBzcGVsbCBvdXQgbmF0LXBhc3MtdGhyb3VnaC1wcmVmaXggKHBy
ZWYgbWlnaHQgYWxzbyBiZQ0KPiAgIHVuZGVyc3Rvb2QgYXMgcHJlZmVyZW5jZSkuIEFuZCBwZXJo
YXBzIGNoYW5nZSB0aGUgd29yZGluZyBpbiB0aGUNCj4gICBkZXNjcmlwdGlvbg0KPiANCj4gICBP
TEQNCj4gCSAgICAiVGhlIElQIGFkZHJlc3Mgc3VibmV0cyB0aGF0IG1hdGNoDQo+ICAgICAgICAg
ICAgICBzaG91bGQgbm90IGJlIHRyYW5zbGF0ZWQuIEFjY29yZGluZyB0bw0KPiANCj4gICBORVcN
Cj4gCSAgICAiSVAgYWRkcmVzc2VzIG1hdGNoaW5nIHRoaXMgcHJlZml4IGFyZQ0KPiAgICAgICAg
ICAgICAgbm90IGJlIHRyYW5zbGF0ZWQuIEFjY29yZGluZyB0bw0KPiANCg0KW01lZF0gV29ya3Mg
Zm9yIG1lLg0KDQo+IC0gU29tZXRpbWVzIHlvdSByZXBlYXQgcHJlZml4ZXMgaW4gbGVhZiBkZWZp
bml0aW9ucyAoZS5nLiwNCj4gICBuYXQtcGFzcy10aHJvdWdoLXBvcnQpIHdoaWxlIGF0IG90aGVy
IHRpbWVzIHlvdSBkbyBub3QuDQo+IA0KDQpbTWVkXSBGaXhlZC4NCg0KPiAtIG5hdC1wYXNzLXRo
cm91Z2gtcG9ydA0KPiANCj4gICBZb3Ugc2VlbSB0byBoYXZlIGNvcHkgcGFzdGVkIHRoZSBkZXNj
cmlwdGlvbiBvZg0KPiAgIG5hdC1wYXNzLXRocm91Z2gtcHJlZi4gIElzIHRoaXMgYSBzaW5nbGUg
cG9ydD8NCg0KW01lZF0gWWVzLCB0aGlzIGlzIGEgc2luZ2xlIHBvcnQgdGhhdCBjYW4gYmUgc3Vw
cGxpZWQgd2l0aCBvciB3aXRob3V0IGEgcHJlZml4DQoNCiBTbyBJIG5lZWQgbXVsdGlwbGUNCj4g
ICBuYXQtcGFzcy10aHJvdWdoIGVudHJpZXMgZm9yIG11bHRpcGxlIHBvcnRzLg0KDQpbTWVkXSBZ
ZXMuDQoNCiBGaW5lLiBCdXQgaXMgdGhlcmUgYQ0KPiAgIHNwZWNpYWwgbWVhbmluZyBpZiBib3Ro
IG5hdC1wYXNzLXRocm91Z2gtcHJlZiBhbmQNCj4gICBuYXQtcGFzcy10aHJvdWdoLXBvcnQgYXJl
IGNvbmZpZ3VyZWQgaW4gYSBzaW5nbGUgbGlzdCBlbnRyeT8gRG9lcw0KPiAgIHRoaXMgbWVhbiB0
aGUgcG9ydCBpcyBzY29wZWQgdG8gdGhlIHByZWZpeD8NCj4gDQoNCltNZWRdIFllcy4gVGhlIHRl
eHQgd2FzIHVwZGF0ZWQgYWNjb3JkaW5nbHkuIA0KDQo+IC0gU29tZSBuYXQgdHlwZSBzcGVjaWZp
YyBwYXJhbWV0ZXIgbGlzdHMgYXJlIGZsYXQsIGZvciBvdGhlcnMgdGhlcmUgaXMNCj4gICBhbiBh
ZGRpdGlvbmFsIGNvbnRhaW5lci4gSXMgdGhpcyBieSBkZXNpZ24/DQoNCltNZWRdIFllcywgdGhl
IGRlc2lnbiB3YXMgYnVpbHQgd2l0aCBOQVQvTkFUNjQgYXMgdGhlIGNvcmUgZnVuY3Rpb25hbGl0
eS4gT3RoZXIgc3BlY2lmaWMtdGVjaG5pcXVlcyBhcmUgYWRkZWQgYXMgY29udGFpbmVycyBmb3Ig
Y2xhcml0eS4gDQoNCj4gDQo+IC0gSSBtZWFud2hpbGUgdGhpbmsgdGhlcmUgcmVhbGx5IHNob3Vs
ZCBiZSBmZWF0dXJlcy4gQ2VydGFpbiBsaXN0cw0KPiAgIG9ubHkgbWFrZSBzZW5zZSBmb3IgaW1w
bGVtZW50YXRpb25zIHRoYXQgc3VwcG9ydCBjZXJ0YWluIE5BVA0KPiAgIHR5cGVzLiBIYXZpbmcg
ZmVhdHVyZXMgZGVmaW5lZCBhbGxvd3MgY29kZSBnZW5lcmF0b3JzIHRvIGVhc2lseQ0KPiAgIGdl
bmVyYXRlIHN0dWJzIHRoYXQgYWN0dWFsbHkgbWF0Y2ggdGhlIGNhcGFiaWxpdGllcyBvZiBhbg0K
PiAgIGltcGxlbWVudGF0aW9uLiBBbmQgeW91IGF1dG9tYXRpY2FsbHkgYmVuZWZpdCBmcm9tIGZl
YXR1cmUNCj4gICBhbm5vdW5jZW1lbnRzLg0KPiANCg0KW01lZF0gQXMgSSBtZW50aW9uZWQgZWFy
bGllciwgd2UgdXNlZCB0byBtYWtlIHVzZSBvZiBmZWF0dXJlcyBpbiBlYXJseSB2ZXJzaW9ucyBv
ZiB0aGUgZHJhZnQuIEnigJltIHJlYWxseSBuZXV0cmFsIG9uIHRoaXMuICANCg0KPiAtIHMvYXR0
YWNoZWR0by9hdHRhY2hlZCB0by8NCj4gDQpbTWVkXSBGaXhlZC4NCg0KPiAtIHMvcHJlZml4cy4v
cHJlZml4ZXMuLw0KPiANCltNZWRdIEZpeGVkLg0KDQo+IC0gbmF0NjQtcHJlZml4DQo+IA0KPiAg
IFdoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgLy9kZWZhdWx0ICI2NDpmZjliOjovOTYiOyA/Pw0KDQpb
TWVkXSBUaGlzIGlzIG5vdyByZW1vdmVkIGdpdmVuIHRoYXQgdGhlcmUgaXMgbm8gcmVjb21tZW5k
YXRpb24gdG8gdXNlIGEgV2VsbC1rbm93biBQcmVmaXggb3IgYSBOZXR3b3JrLVNwZWNpZmljIFBy
ZWZpeCAoUkZDNjA1MikuIA0KDQo+IA0KPiAtIHN0YXRlbGVzcy1lbmFibGUNCj4gDQo+ICAgRG9l
cyB0aGlzIGVuYWJsZSBsZWFmIG1ha2Ugc2Vuc2Ugb24gYSBsaXN0IGVudHJ5PyBQZXJoYXBzIGl0
IGRvZXMNCj4gICBidXQgdGhlIGRlc2NyaXB0aW9uIGlzIGZhaXJseSBnZW5lcmFsIGFuZCBoZW5j
ZSBJIGFtIGFza2luZy4NCg0KW01lZF0gQm90aCBzdGF0ZWxlc3MgYW5kIHN0YXRlZnVsbCBOQVQ2
NHMgYXJlIGltcGxlbWVudGluZyB0aGUgc2FtZSBhZGRyZXNzIHRyYW5zbGF0aW9uIGFsZ29yaXRo
bSAoYW5kIGNvbnNlcXVlbnRseSB0aGUgc2FtZSBjb25maWd1cmF0aW9uIGRhdGEpLiBzdGF0ZWxl
c3MtZW5hYmxlIGlzIGFuIGV4cGxpY2l0IGluZGljYXRpb24gdG8gYSBOQVQ2NCB0byBpbmRpY2F0
ZSB3aGV0aGVyIGl0IHNob3VsZCBjb25zaWRlciBzb3VyY2UgSVB2NiBhZGRyZXNzZXMgYXMgSVB2
NC10cmFuc2xhdGFia2UgSVB2NiBhZGRyZXNzZXMgKFJGQzYwNTIpLiANCg0KPiANCj4gLSBleHRl
cm5hbC1pcC1hZGRyZXNzLXBvb2wvcG9vbC1pZA0KPiANCj4gICBUaGlzIHNlZW1zIHRvIHJlbGF0
ZSB0byBhIE5hdHYyUG9vbEluZGV4LCB3aGljaCBhZ2FpbiBleGNsdWRlcyB0aGUNCj4gICB2YWx1
ZSAwLiBJIGhhdmUgbm90IGNoZWNrZWQgYWxsIHN1Y2ggcmVsYXRlZCB0aGluZ3MsIHNvIHBsZWFz
ZSBnbw0KPiAgIGFuZCBjaGVjayB5b3Vyc2VsZi4NCg0KW01lZF0gSSB3aWxsIGxldCBTZW50aGls
IGNvbW1lbnQgb24gdGhpcyBvbmUuIA0KDQo+IA0KPiAtIGV4dGVybmFsLWlwLWFkZHJlc3MtcG9v
bA0KPiANCj4gICBUaGUgZGVzY3JpcHRpb24gc2F5cw0KPiANCj4gICAgICAgICAgICAgQm90aCBj
b250aWd1b3VzIGFuZCBub24tY29udGlndW91cyBwb29scw0KPiAgICAgICAgICAgICBjYW4gYmUg
Y29uZmlndXJlZCBmb3IgTkFUIHB1cnBvc2VzLiI7DQo+IA0KPiAgIGJ1dCBpdCBzZWVtcyBtb3Jl
IGFjY3VyYXRlIHRvIHNheSB0aGF0IGEgcG9vbCBpcyBhIHNldCBvZiBwcmVmaXhlcw0KPiAgIHNp
bmNlIHRoaXMgaXMgd2hhdCB0aGUgbW9kZWwgc3VnZ2VzdHMuDQoNCltNZWRdIFllcywgdGhhdCdz
IGl0LiBJIGNoYW5nZWQgdGhlIHRleHQgYXMgc3VnZ2VzdGVkLiANCg0KPiANCj4gLSBzdXBwb3J0
ZWQtdHJhbnNwb3J0LXByb3RvY29scw0KPiANCj4gICBJIGFtIGFnYWluIG5vdCBjbGVhciB3aGV0
aGVyIHlvdSBhcmUgcmVwb3J0aW5nIGltcGxlbWVudGF0aW9uDQo+ICAgY2FwYWJpbGl0aWVzIGhl
cmUgb3IgZW5hYmxlZCBmZWF0dXJlcyBvciBzb21ldGhpbmcgZWxzZS4gDQoNCltNZWRdIFRoaXMg
b25lIGlzIHRvIGNvbmZpZ3VyZSBleHBsaWNpdGx5IGEgdHJhbnNwb3J0IHByb3RvY29sIHRoYXQg
d2lsbCBiZSBoYW5kbGVkIGJ5IHRoZSBOQVQuDQoNCklzIHRoZQ0KPiAgIGNvbmZpZ3VyYXRpb24g
b2YgdHJhbnNwb3J0LXByb3RvY29sLWlkIGFuZCB0cmFuc3BvcnQtcHJvdG9jb2wtbmFtZQ0KPiAg
IG11dHVhbGx5IGV4Y2x1c2l2ZT8gDQoNCltNZWRdIE5vLiBBIGxpc3Qgb2YgcHJvdG9jb2xzIGNh
biBiZSBlbmFibGVkLg0KDQpJZiBzbywgc2hvdWxkIHRoaXMgYmUgYSBjaG9pY2U/IElmIEkgY2Fu
DQo+ICAgY29uZmlndXJlIGJvdGgsIEkgYXNzdW1lIHRoZXkgaGF2ZSB0byBiZSBjb25zaXN0ZW50
Lg0KPiANCj4gLSB0cmFuc3BvcnQtcHJvdG9jb2wtbmFtZQ0KPiANCj4gICBJcyB0aGlzIHJlc3Ry
aWN0ZWQgdG8gdGhlIGFjcm9ueW1zIHRoYXQgYXJlIHVzZWQgaW4gdGhlIElBTkENCj4gICBwcm90
b2NvbCBudW1iZXJzIHJlZ2lzdHJ5Pw0KDQpbTWVkXSBZZXMuICANCg0KPiANCj4gLSBzL21hc2Nr
L21hc2svDQpbTWVkXSBGaXhlZC4gDQoNCj4gDQo+IC0gc3Vic2NyaWJlci1tYXNrLXY2DQo+IA0K
PiAgIFRoZSBuYW1lIHNlZW1zIHRvIGluZGljYXRlIHRoYXQgdGhpcyBvbmx5IGFwcGxpZXMgdG8g
SVB2NiBwcmVmaXhlcw0KPiAgIGhhbmRlZCBvdXQgdG8gQ1BFcy4gUGVyaGFwcyB0aGlzIHNob3Vs
ZCBiZSBzdGF0ZWQgZXhwbGljaXRlbHkgKGJ1dA0KPiAgIHllcyBpdCBpcyB1bmxpa2UgdG8gZXZl
ciBnZXQgYW4gSVB2NCBwcmVmaXgpLiBCdXQgdGhlbiwgdGhlDQo+ICAgc3Vic2NyaWJlci1tYXRj
aCBoYXMgYW4gSVB2NCBwcmVmaXggZXhhbXBsZS4NCg0KW01lZF0gVGhpcyBpcyBJUHY2LXNwZWNp
ZmljLiBUaGUgdGV4dCBpcyBub3cgdXBkYXRlZC4gDQoNCj4gDQo+IC0gcXVvdGEtdHlwZQ0KPiAN
Cj4gICBJcyB0aGlzIGEgZ29vZCBuYW1lIGZvciB0aGUgbGVhZj8gVGhpcyBzZWVtcyB0byBpbmRp
Y2F0ZSBmb3Igd2hpY2gNCj4gICB0cmFuc3BvcnQgcHJvdG9jb2wgYSBwb3J0LWxpbWl0IGlzIGVu
Zm9yY2VkLiBBbmQgdGhpcyBsaXN0IGlzDQo+ICAgcmVzdHJpY3RlZCB0byBUQ1AsIFVEUCwgYW5k
IElDTVAgd2hpbGUgb3RoZXIgcGFydHMgb2YgdGhlIG1vZGVsIGFyZQ0KPiAgIG1vcmUgZmxleGli
bGUgaW4gc3VwcG9ydGluZyBhZGRpdGlvbmFsIHRyYW5zcG9ydCBwcm90b2NvbHMuIFNvIGlzIGl0
DQo+ICAgY29uc2lzdGVudCB0byBhIHJhdGhlciByZXN0cmljdGVkIGVudW0gaGVyZT8NCg0KW01l
ZF0gR29vZCBwb2ludC4gVXBkYXRlZCBhY2NvcmRpbmdseS4gDQoNCj4gDQo+IC0gcG9ydC1zZXQt
dGltZW91dA0KPiANCj4gICBOZWVkcyBhIHVuaXRzIHN0YXRlbWVudC4NCltNZWRdIERvbmUuDQoN
Cg0KPiANCj4gLSB0aW1lb3V0cw0KPiANCj4gICBDYW4gSSBtYWtlIHRoZSB0aW1lb3V0cyBhcmJp
dHJhcmlseSBzbWFsbCwgaW4gdGhlIGV4dHJlbWUgY2FzZSAwDQo+ICAgc2Vjb25kcz8gSW4gc29t
ZSBjYXNlcyBJIGZpbmQgdGV4dCBsaWtlICJmb3IgYXQgbGVhc3QgNiBzZWNvbmRzIi4NCj4gICBE
b2VzIHRoaXMgbWVhbiB0aGF0IHRoZSByYW5nZSBpcyByZWFsbHkgdWludDMyIHsgcmFuZ2UgIjYu
Lm1heCI7IH0/DQo+ICAgT3IgaXMgaXQgc3RpbGwgT0sgdG8gY29uZmlndXJlIHRoZSB2YWx1ZSAz
IGFuZCB0aGUgJ211c3QnIGlzIHJlYWxseQ0KPiAgIGEgJ3Nob3VsZCc/DQoNCltNZWRdIE9ubHkg
cmVjb21tZW5kZWQgdmFsdWVzIGFyZSBwcm92aWRlZC4gQW4gYWRtaW5pc3RyYXRvciBpcyBmcmVl
IHRvIHNldCB0aGUgdmFsdWVzIGl0IHNlZXMgYXBwcm9wcmlhdGUgZm9yIGhpcy9oZXIgZGVwbG95
bWVudC4gIA0KDQo+IA0KPiAtIHBvcnQtdGltZW91dA0KPiANCj4gICBJIGRvdWJ0IHRoaXMgaXMg
b2YgdHlwZSBpbmV0OnBvcnQtbnVtYmVyIGFuZCB0aGVyZSBsaWtlbHkgbmVlZHMgdG8NCj4gICBi
ZSBhIHVuaXRzIHN0YXRlbWVudC4NCg0KW01lZF0gR29vZCBjYXRjaC4gRml4ZWQuDQoNCj4gDQo+
IC0gYWxnLW5hbWUNCj4gDQo+ICAgSXMgdGhlcmUgYSBsaXN0IG9mIHdlbGwta25vd24gQUxHIG5h
bWVzPyBJQU5BPyBPciBpcyB0aGlzIGEgcmFuZG9tDQo+ICAgc3RyaW5nIHRoYXQgb25lIG5lZWRz
IHRvIGd1ZXNzIGZvcm0gdGhlIHZlbmRvcidzIGRvY3VtZW50YXRpb24sDQo+ICAgaS5lLiwgdGhp
cyBpcyBwb3RlbnRpYWxseSBub3QgaW50ZXJvcGVyYWJsZSBvdXQgb2YgdGhlIGJveD8gSXMgdGhl
cmUNCj4gICBhIHdheSB0byBvYnRhaW4gdGhlIG51bWJlciBvZiBBTEdzIHN1cHBvcnRlZCBvciBp
cyB0aGUgaWRlYSB0byBkbw0KPiAgIHRyaWFsIGFuZCBlcnJvciBwcm9iaW5nIHRvIGZpbmQgb3V0
ICh3aGljaCBpcyBldmVuIGhhcmRlciBpZiB0aGVyZQ0KPiAgIGFyZSBubyB3ZWxsLWtub3duIEFM
RyBuYW1lcyk/DQo+IA0KDQpbTWVkXSBUaGVyZSBpcyBubyAic3RhbmRhcmRpemVkL0lBTkEiIGxp
c3Qgb2YgQUxHcy4gVGhlcmUgaXMgYSBsaXN0IG9mIHdpZGVseSBkZXBsb3llZC9pbXBsZW1lbnRl
ZCBvbmVzLg0KRldJVywgd2UgdXNlZCB0byBoYXZlIHRoaXMgbGlzdDogDQoNCiAgICB8ICAgICAg
ICArLS1ydyBmdHAtYWxnLWVuYWJsZT8gICAgICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyBkbnMtYWxnLWVuYWJsZT8gICAgICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyB0ZnRwLWFsZy1lbmFibGU/ICAgICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyBtc3JwYy1hbGctZW5hYmxlPyAgICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyBuZXRiaW9zLWFsZy1lbmFibGU/ICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyByY21kLWFsZy1lbmFibGU/ICAgICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyBsZGFwLWFsZy1lbmFibGU/ICAgICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyBzaXAtYWxnLWVuYWJsZT8gICAgICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyBydHNwLWFsZy1lbmFibGU/ICAgICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyBoMzIzLWFsZy1lbmFibGU/ICAgICAgICAgICAgIGJvb2xlYW4NCiAgICB8ICAgICAg
ICArLS1ydyBhbGwtYWxncy1lbmFibGU/ICAgICAgICAgICAgIGJvb2xlYW4NCg0KV2UgY2hhbmdl
ZCB0aGUgZGVzaWduIHRvIHRoaXMgb25lIGJlY2F1c2UgaXQgaXMgZWFzaWx5IGV4dGVuc2libGUu
IA0KDQo+IC0gYWxsLWFsZ3MtZW5hYmxlDQo+IA0KPiAgIFRoaXMgc2F5cyAiRW5hYmxlL2Rpc2Fi
bGUgYWxsIEFMR3MuIiBidXQgSSBfYXNzdW1lXyB0aGF0IEkgc2V0IHRoaXMNCj4gICB0byBmYWxz
ZSBhbmQgdG8gZW5hYmxlIHNwZWNpZmljIEFMR3MuIFBlcmhhcHMgdGhpcyBpbnRlcmFjdGlvbiBu
ZWVkcw0KPiAgIHRvIGJlIHNwZWxsZWQgb3V0Lg0KDQpbTWVkXSBVcGRhdGVkLg0KDQo+IA0KPiAt
IElzIHRoZXJlIGFueSB0aHJvdHRsaW5nIG1lY2hhbmlzbSBuZWVkZWQgaW4gY2FzZSBteSBOQVQg
aXMNCj4gICBjb25zdGFudGx5IG9wZXJhdGluZyBhcm91bmQgdGhlIG5vdGlmaWNhdGlvbiB0aHJl
c2hvbGRzPw0KDQpbTWVkXSBUaGlzIGlzIGRlcGxveW1lbnQtIGFuZCBpbXBsZW1lbnRhdGlvbi1z
cGVjaWZpYy4gV2UgZG9uJ3QgaGF2ZSBhIHN0YW5kYXJkIGRvY3VtZW50IHRvIGNpZS4gDQoNCj4g
DQo+IC0gQWRkIHVuaXRzIHRvIHRoZSBtYXBwaW5nIGxpbWl0IGRlZmluaXRpb25zICgic3Vic2Ny
aWJlcnMiLA0KPiAgICJtYXBwaW5ncyIsIC4uLikNCltNZWRdIFdpbGwgYmUgY2hlY2tlZC4gDQoN
Cj4gDQo+IC0gbGltaXQtcGVyLXN1Ym5ldA0KPiANCj4gICBUaGlzIGlzIHR5cGUgaW5ldDppcC1w
cmVmaXg/IEkgZ3Vlc3MgeW91IHdhbnRlZCBzb21ldGhpbmcgZWxzZSBoZXJlLg0KDQpbTWVkXSBJ
IGNvbmZpcm0uIEEgc3Vic2NyaWJlciBpcyBhc3N1bWVkIHRvIGJlIGlkZW50aWZpZWQgYnkgYSBw
cmVmaXguIA0KDQo+IA0KPiAtIFdoeSBhcmUgc29tZSBsaW1pdHMgbWFuZGF0b3J5LCBvdGhlcnMg
bm90Pw0KW01lZF0gQmVjYXVzZSB0aG9zZSB0aGF0IGFyZSByZXF1aXJlZCBmb3IgbW9zdCBvZiBl
eGlzdGluZyBOQVQgaW1wbGVtZW50YXRpb25zLiANCg0KPiANCj4gLSBJZiB5b3Ugd3JpdGUgJ2xp
bWl0IHBlciBzdWJzY3JpYmVyJywgaG93IGlzIGEgc3Vic2NyaWJlciBpZGVudGlmaWVkPw0KPiAg
IEkgYXNzdW1lIHRoZXNlIGFyZSBnbG9iYWwgcGVyIHN1YnNjcmliZXIgbGltaXRzLCBpLmUuLCBh
bGwNCj4gICBzdWJzY3JpYmVycyByZWNlaXZlIHRoZSBzYW1lIGxpbWl0Lg0KDQpbTWVkXSBBIHN1
YnNjcmliZXIgY2FuIGJlIGlkZW50aWZpZWQgYnkgYSBzdWJzY3JpYmVyLW1hc2sgb3IgYW4gZXhw
bGljaXQgcHJlZml4LiANCg0KPiANCj4gLSBsaW1pdC1wZXItc3VibmV0DQo+IA0KPiAgICAgICAg
ICAgbGVhZiBsaW1pdC1wZXItc3VibmV0IHsNCj4gICAgICAgICAgICAgdHlwZSBpbmV0OmlwLXBy
ZWZpeDsNCj4gDQo+ICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICAgICAgIlJh
dGUtbGltaXQgdGhlIG51bWJlciBvZiBuZXcgbWFwcGluZ3MNCj4gCSAgICAgICBhbmQgc2Vzc2lv
bnMgcGVyIHN1Ym5ldC4iOw0KPiAgICAgICAgICAgfQ0KPiANCj4gICBJIGRvIG5vdCBzZWUgaG93
IHRoaXMgd29ya3MuIFRoZSBvdGhlciBsaW1pdC1wZXItWFhYIG9iamVjdHMgYXJlDQo+ICAgbnVt
YmVycyAtIHByZXN1bWFibHkgZGVmaW5pbmcgdGhlIGxpbWl0LiBUaGlzIGlzIGEgcHJlZml4Pw0K
DQpbTWVkXSBZZXMuIA0KDQo+IA0KPiAtIGxvZ2dpbmctaW5mbw0KPiANCj4gICBJcyB0aGlzIGlu
Zm9ybWF0aW9uIGNvbXBsZXRlPyBQZXJoYXBzIGl0IGlzIGZvciBwbGFpbiBzeXNsb2cNCj4gICAo
d2l0aG91dCBhbnkgc2VjdXJpdHkpIGJ1dCBJIGRvdWJ0IHRoZSBpbmZvIGlzIGNvbXBsZXRlIGZv
ciB0aGUNCj4gICBvdGhlciB0cmFuc3BvcnRzIG1lbnRpb25lZCwgYXQgbGVhc3Qgbm90IGZvciBG
VFAuIEFuZCBzdXJlbHksIGlmIHlvdQ0KPiAgIHdhbnQgdG8gcHJvdGVjdCB0aGUgbG9nZ2luZyBp
bmZvcm1hdGlvbiwgdGhlbiB5b3Ugd2lsbCBuZWVlZCB3YXkNCj4gICBtb3JlIHBhcmFtZXRlcnMu
IEFuZCB3aGF0IGRvZXMgJ3JldHJpZXZpbmcnIGxvZ2dpbmcgZW50cmllcyBtZWFuPyAgSQ0KPiAg
IGFzc3VtZSB3aXRoIHN5c2xvZyBhbmQgaXBmaXggeW91IHB1c2ggbG9nIG1lc3NhZ2VzLiBJIGFt
IGxlc3Mgc3VyZQ0KPiAgIGFib3V0IEZUUC4gUGVyaGFwcyBsZXNzIGlzIG1vcmUgYW5kIHNpbXBs
eSBwcm92aWRlIHN1cHBvcnQgZm9yDQo+ICAgc3lzbG9nIGFuZCBsZWF2ZSB0aGUgb3RoZXIgb3B0
aW9ucyBmb3IgZXh0ZW5zaW9ucy4gWW91IGhhdmUgYSBjaG9pY2UNCj4gICBpbiBwbGFjZSwgc28g
bm90IG5lZWQgdG8gZ28gYW5kIGRlYWwgd2l0aCBhbGwgcG9zc2libGUgY29tcGxleGl0eQ0KPiAg
IGhlcmUuDQo+IA0KDQpbTWVkXSBJdCBpcyBvdXQgb2Ygc2NvcGUgb2Ygc3BlY2lmeSB0aGUgZXhh
Y3QgbG9nZ2luZyBpbmZvcm1hdGlvbi4gVGhvc2UgY29uc2lkZXJhdGlvbnMgYXJlIG91dCBvZiBz
Y29wZS4gV2Ugb25seSBmb2N1cyBvbiB0aGUgcHJvdG9jb2wgYW5kIHRoZSBzZXJ2ZXIgaW5mb3Jt
YXRpb24uIA0KDQo+IC0gRm9yIHRoZSBzdGF0aXN0aWNzLCB3ZSB1c2VkIHRvIHVzZSBwbHVyYWwg
Zm9ybSBmb3IgY291bnRlcnMgYmFjayBpbg0KPiAgIFNOTVAgbGFuZCBhbmQgSSB0aGluayB0aGlz
IHdhcyBnb29kIHByYWN0aWNlLiBTbyBnbyB3aXRoDQo+ICAgc2VudC1wYWNrZXRzLCBzZW50LWJ5
dGVzLCByY3ZkLXBhY2tldHMsIHJjdmQtYnl0ZXMsIGRyb3BwZWQtcGFja2V0cywNCj4gICBkcm9w
cGVkLWJ5dGVzLCAuLi4NCg0KW01lZF0gQWN0dWFsbHksIHdlIHVzZWQgYm90aCBvZiB0aGVtLiBJ
IHVwZGF0ZWQgd2hlbiByZXF1aXJlZC4gDQoNCj4gDQo+IC0gdG90YWwtbWFwcGluZ3MsIHRvdGFs
LXRjcC1tYXBwaW5ncywgdG90YWwtdWRwLW1hcHBpbmdzLA0KPiAgIHRvdGFsLWljbXAtbWFwcGlu
Z3M6IFRoZXNlIG1heSB1c2UgeWFuZzpnYXVnZTMyLg0KW01lZF0gT0suDQoNCj4gDQo+IC0gYWRk
cmVzcy1hbGxvY2F0ZWQsIGFkZHJlc3MtZnJlZSAtPiBhZGRyZXNzZXMtYWxsb2NhdGVkLCBhZGRy
ZXNzZXMtZnJlZQ0KPiAgIChtYXkgYWxzbyBiZSB5YW5nOmdhdWdlMzIpDQo+IA0KW01lZF0gT0su
DQoNCj4gLSBTb21lIG9mIHRoZXNlIGdhdWdlcyBtaWdodCBmbHVjdHVhdGUgZmFzdCAobWF5YmUg
Y29uc2lkZXINCj4gICBleHBvbmVudGlhbGx5IHNtb290aGVkIGdhdWdlcywgYnV0IHRoaXMgbWln
aHQgYWxzbyBiZSBsZWZ0IGZvciBhbg0KPiAgIGV4dGVuc2lvbikuDQoNCltNZWRdIFdlIGNhbiBs
ZWF2ZSB0aG9zZSBmb3IgYSBmdXR1cmUgZXh0ZW5zaW9uLiANCg0KPiANCj4gLSBUaGUgc2VjdXJp
dHkgY29uc2lkZXJhdGlvbnMgdGV4dCBzaG91bGQgZm9sbG93IHRoZSBuZXcgYm9pbGVycGxhdGUN
Cj4gICB0aGF0IGFsc28gY292ZXJzIFJFU1RDT05GLg0KDQpbTWVkXSBVcGRhdGVkLg0KDQoNCiBJ
IHRoaW5rIGl0IHdvdWxkIGhlbHAgdG8gYmUgbW9yZSBzcGVjaWZpYw0KPiAgIGFib3V0IHRoZSBz
ZWN1cml0eSBhc3BlY3RzIG9mIHRoaXMgZGF0YSBtb2RlbC4gVGhpcyB0ZXh0IGlzIHF1aXRlDQo+
ICAgZ2VuZXJpYy4NCg0KW01lZF0gVGhlIHRleHQgQWNrcyB0aGF0IGFsbCBpbmZvcm1hdGlvbiBh
cmUgc2Vuc2l0aXZlLiBUaGV5IG11c3QgYmUgcHJvdGVjdGVkIGFuZCBzZWN1cmUgbWVhbnMgbXVz
dCBiZSB1c2VkLiANCg0KIFdpdGggYSBOQVQsIHRoaW5ncyBldmVuIGhhdmUgcHJpdmFjeSBhc3Bl
Y3RzLiBJZiBJIGNhbg0KPiAgIGZvcmNlIGEgc3BlY2lmaWMgTkFUIG1hcHBpbmcsIEkgY2FuIHRy
YWNrIGEgc3Vic2NyaWJlci4NCg0KW01lZF0gSU1ITywgdGhpcyBpcyBub3Qgc3BlY2lmaWMgdG8g
dGhlIE5BVC4gTWFuZGF0aW5nIHNlY3VyZSBtZWFucyB0byBjb250cm9sIHRoZSBOQVQgaXMgYSBn
dWFyZCBhZ2FpbnN0IHN1Y2ggYXR0YWNrLiAgDQoNCj4gDQo+IC0gQXQgbGVhc3Qgb25lIGV4YW1w
bGUgaGFzIHN5bnRheCBlcnJvcnMuIEV4YW1wbGVzIHNob3VsZCBpZGVhbGx5IGJlDQo+ICAgdmFs
aWRhdGVkIGJ5IHRvb2xzIHNvIHRoYXQgdGhlIGV4YW1wbGVzIGFyZSBzeW50YWN0aWNhbGx5IGNv
cnJlY3QgYW5kDQo+ICAgdmFsaWQgcmVnYXJkaW5nIHRoZSBkYXRhIG1vZGVsLg0KPiANCltNZWRd
IFdpbGwgZG91YmxlIGNoZWNrLg0KDQoNCg==


From nobody Mon Oct 30 07:42:51 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 A37CD139F18; Mon, 30 Oct 2017 07:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level: 
X-Spam-Status: No, score=-2.608 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, T_FILL_THIS_FORM_SHORT=0.01, 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 oAD_jG6hh824; Mon, 30 Oct 2017 07:42:39 -0700 (PDT)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF7713F89B; Mon, 30 Oct 2017 07:42:39 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id B75B9C07DB; Mon, 30 Oct 2017 15:42:37 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 8DEE54005B; Mon, 30 Oct 2017 15:42:37 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0361.001; Mon, 30 Oct 2017 15:42:36 +0100
From: 
To: Juergen Schoenwaelder , "yang-doctors@ietf.org" 
CC: "draft-ietf-opsawg-nat-yang.all@ietf.org" , "opsawg@ietf.org" 
Thread-Topic: [yang-doctors] Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
Thread-Index: AQHTT09nb4Xo03k7b0eBVGOEwFdqM6L6cq0AgAIJRmA=
Date: Mon, 30 Oct 2017 14:42:36 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A060DD0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <150912805550.22087.2939629492652644040@ietfa.amsl.com> <20171029083636.35fhzpj5i5zqb7of@elstar.local>
In-Reply-To: <20171029083636.35fhzpj5i5zqb7of@elstar.local>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] [yang-doctors] Yangdoctors early review of draft-ietf-opsawg-nat-yang-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, 30 Oct 2017 14:42:44 -0000

Re-,

OK, thanks.

Cheers,
Med

> -----Message d'origine-----
> De=A0: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de=
]
> Envoy=E9=A0: dimanche 29 octobre 2017 09:37
> =C0=A0: yang-doctors@ietf.org
> Cc=A0: draft-ietf-opsawg-nat-yang.all@ietf.org; opsawg@ietf.org
> Objet=A0: Re: [yang-doctors] Yangdoctors early review of draft-ietf-opsaw=
g-
> nat-yang-06
>=20
> One additional nit: You may want to think about the name of the toplevel
> node. Here is what is currently published:
>=20
>     +--rw interfaces            ietf-interfaces         RFC 7223
>     +--rw ipfix                 ietf-ipfix-psamp	RFC 6728
>     +--rw key-chains            ietf-key-chain		RFC 8177
>     +--rw lmap                  ietf-lmap-control       RFC 8194
>     +--ro modules-state         ietf-yang-library	RFC 7895
>     +--rw nacm                  ietf-netconf-acm        RFC 6536
>     +--ro netconf-state         ietf-netconf-monitoring RFC 6022
>     +--rw routing               ietf-routing            RFC 8022
>     +--rw snmp                  ietf-snmp               RFC 7407
>     +--rw system                ietf-system		RFC 7317
>     +--ro system-state          ietf-system     	RFC 7317
>=20
>     +--ro interfaces-state      ietf-interfaces         RFC 7223 (to be
> deprecated)
>     +--ro routing-state         ietf-routing            RFC 8022 (to be
> obsoleted)
>=20
> Calling the toplevel node simply 'nat' may be more inline with the
> existing names (which are not all perfect but if we ignore the -state
> nodes there is a certain level of consistency - a not toplevel node
> uses 'module').
>=20
> /js
>=20
> On Fri, Oct 27, 2017 at 11:14:15AM -0700, J=FCrgen Sch=F6nw=E4lder wrote:
> > Reviewer: J=FCrgen Sch=F6nw=E4lder
> > Review result: Not Ready
> >
> > Summary
> >
> > >From a YANG modeling point of view, the module is rather straight
> > forward and I did not discover anything that seems fundamentally
> > problematic. That said, there are a number of details where I doubt
> > the model is correct and things where I believe things are incomplete.
> > Given that there are many different NAT functions, I also expected to
> > see usage of YANG features.
> >
> > One fundamental question one could raise is whether this model should
> > have been broken down into a generic NAT core model plus extensions of
> > the core model for the different types of NATs. Well, a single model
> > with YANG features is an inline version of that as this still requires
> > to mark clearly which parts are specific to certain types or NATs.
> >
> > I did not compile the module myself since the IETF tracker says no
> > errors using pyang and yanglint (and I would not have run anything
> > different). (Is it OK for YANG doctors to trust the tracker tools?
> > Well, since this is labelled as an early review and I expect more
> > updates, I assume this is fine.)
> >
> > I can't tell whether the model makes sense from a NAT point of view. I
> > am not an expert in the various types of NATs and surely more reviews
> > of NAT experts would be good (and they would have likely spotted some
> > things I have spotted, so I guess the usual problem of getting enough
> > substantial reviews).
> >
> > Details
> >
> > - We use revision statements only for published modules. Hence, please
> >   replace the revision statements with
> >
> >   // RFC Ed. update to match the date of the latest edits
> >   revision 2017-xx-yy {
> >     description
> >       "Initial revision.";
> >     reference
> >       "RFC XXXX: A YANG Data Model for Network Address Translation
> >                  (NAT) and Network Prefix Translation (NPT)";
> >   }
> >
> > - We usually follow a different template for the contact statement
> >   that has more context and just a list of names and email addresses.
> >
> > - We usually write
> >
> >      reference
> >        "RFC 3022: Traditional IP Network Address Translator
> >                   (Traditional NAT)";
> >
> >   instead of just
> >
> >      reference
> >        "RFC 3022.";
> >
> >   since not everybody remembers all the numbers equally well.
> >
> > - Is there a reference for dst-nat?
> >
> > - What is the vrf-routing-instance identity good for? Its used only in
> >   the leaf external-vrf-instance and the description of that leaf is
> >   not telling me how this is going to be used. Who is going to derive
> >   identities? I fear you are trying to achieve something where using
> >   identities is really the wrong approach. Section 2.10 does not tell
> >   how this is supposed to work either. I assume this needs to be
> >   checked by the routing area experts to make sure things fit with
> >   their modeling of VRFs.
> >
> > - s/start-port-numbert/start-port-number/
> >
> > - Are comments like
> >
> >   // port numbers: single or port-range
> >
> >   necessary given that there are description statements? Note that
> >   comments may be removed by tools while description statements
> >   usually are preserved. So it is important to have anything important
> >   covered in description statements.
> >
> > - What is a PSID algorithm? Spell out acronyms on first usage.
> >
> > - The leafs start-port-number and end-port-number are commented out in
> >   port-range, probably in favour of the uses port-number. If they are
> >   not needed anymore, they should be removed.
> >
> > - I do not understand port-set-algo from the descriptions. What is the
> >   psid-offset applied? What is a 'sharing ration for an IPv4 address'?
> >   Is this stuff IPv4 specific? Is the psid something that has a
> >   certain meaning outside of this YANG module? If so, where do I find
> >   more details (missing reference statement?)?
> >
> > - mapping-entry/index: is this an arbitrary identifier? how are these
> >   identifiers allocated? Are they created by the NAT or are they create=
d
> >   via configuration? Or even both? Well, I guess it is both given the
> >   mapping-entry/type leaf.
> >
> > - mapping-entry/type: instead 'manually configured', I would write
> >   'explicitly configured' (configuration does not have to be a manual
> >   process). I also find the other enum labels at least a bit confusing.
> >
> >         enum "dynamic-explicit" {
> >           description
> >             "This mapping is created by an
> >              outgoing packet.";
> >         }
> >
> >         enum "dynamic-implicit" {
> >           description
> >             "This mapping is created by an
> >              explicit  dynamic message.";
> >         }
> >
> >   Note the 'implicit' vs 'explicit' clash here. Perhaps this should be
> >   aligned with the definition of dynamic and implicit mappings:
> >
> >    o  Dynamic implicit mapping: is created implicitly as a side effect
> >       of traffic such as an outgoing TCP SYN or an outgoing UDP packet.
> >       A validity lifetime is associated with this mapping.
> >
> >    o  Dynamic explicit mapping: is created as a result of an explicit
> >       request, e.g., PCP message [RFC6887].  A validity lifetime is
> >       associated with this mapping.
> >
> >   But then it seems you really messed things up here. I would even
> >   write these definitions differently since 'outgoing' is unclear and
> >   potentially confusing.
> >
> >    o  Dynamic implicit mapping: is created implicitly as a side effect
> >       of processing a packet (e.g., an initial TCP SYN packet) that
> >       requires a new mapping. A validity lifetime is associated with
> >       this mapping.
> >
> >    o  Dynamic explicit mapping: is created as a result of an explicit
> >       request, e.g., PCP message [RFC6887].  A validity lifetime is
> >       associated with this mapping.
> >
> >    Similarly, I would change the description of
> >
> >         enum "dynamic-implicit" {
> >           description
> >             "This mapping is created implicitely as a side effect
> >              of processing a packet that requires a new mapping.";
> >         }
> >
> >         enum "dynamic-explicit" {
> >           description
> >             "This mapping is created as a result of an explicit
> >              request, e.g., a PCP message.";
> >         }
> >
> > - We should perhaps have a type for an IP protocol number, ideally in
> >   inet-types. (Just a reminder to myself.) That said, I do not
> >   understand what this sentence means:
> >
> >     No transport protocol is indicated if a mapping applies for
> >     any protocol.
> >
> >   Perhaps you wanted to say this:
> >
> >     If this leaf is not instantiated, then the mapping applies to any
> >     protocol.
> >
> > - container internal-src-port:
> > - container external-src-port:
> > - container internal-dst-port:
> > - container external-dst-port:
> >
> >          It is used also to carry the internal
> >          source ICMP identifier.";
> >
> >   I think details are lacking here. What is the ICMP identifier? What
> >   does 'carry' mean and how does this relate to the port-number
> >   grouping?
> >
> >   See above, I do not understand the ICMP identifier statement.
> >
> > - lifetime:
> >
> >   Spell out 3WHS. I think there should be a units statement. And is
> >   this a ticking lifetime, i.e., this changes on every get request? Is
> >   this useful? Have alternatives been considered such as reporting the
> >   point in time when the mapping was established? Or is the idea that
> >   the lifetime reports the time left until the mapping will be garbage
> >   collected? What does "tracks the connection" really mean here?
> >
> > - I suggest to remove empty lines in say leaf definitions. Instead
> >
> >       leaf id {
> >         type uint32;
> >
> >         description
> >           "NAT instance identifier.";
> >
> >         reference
> >           "RFC 7659.";
> >       }
> >
> >   write
> >
> >       leaf id {
> >         type uint32;
> >         description
> >           "NAT instance identifier.";
> >         reference
> >           "RFC 7659: Definitions of Managed Objects for Network
> >                      Address Translators (NATs)";
> >       }
> >
> > - It seems you try to be aligned with the NATV2-MIB module but there
> >   is no explicit discussion about this in the document. I suggest that
> >   you a section (for example before the tree diagram) where you
> >   discuss how this YANG module coexists with the NATV2-MIB module.
> >
> >   For example, I see that Natv2InstanceIndex in the MIB module
> >   excludes 0 as an instance identifier while your id leaf above allows
> >   the usage of 0.
> >
> > - container nat-capabilities:
> >
> >   Here we find a bunch of "config true" leafs and I wonder how these
> >   work. There are things a NAT implementation is capable to do, and
> >   there are things that are enabled in a NAT deployment and of course
> >   you can't enable something in a deployment that has not been
> >   implemented. So are these 'capabilities' more like NAT features
> >   enabled (since we have "config true" nodes) or are these more
> >   implemented capabilities (but then "config true" may be wrong)?
> >   Depending on the answer, did you consider using YANG features?
> >
> > - nat-flavor and nat44-flavor:
> >
> >   Does it make sense to have two objects here? Can I put basic-nat
> >   into nat-flavor? Are the differences between lets say napt and
> >   basic-nat really nat44 specific?
> >
> >   Note that you also derive restricted-nat from nat44 but this option
> >   is not mentioned in the description of nat44-flavor. I think the
> >   description should be more open since in principle I can derive even
> >   more identities in the future.
> >
> > - boolean capability flags
> >
> >   Do these need references so one can lookup what the exact meaning of
> >   these 'capabilities' are? It would surely help me and it will help
> >   implementors that need to decide whether a certain vendor feature
> >   fits any of these.
> >
> > - nat-pass-through-pref
> >
> >   Perhaps spell out nat-pass-through-prefix (pref might also be
> >   understood as preference). And perhaps change the wording in the
> >   description
> >
> >   OLD
> > 	    "The IP address subnets that match
> >              should not be translated. According to
> >
> >   NEW
> > 	    "IP addresses matching this prefix are
> >              not be translated. According to
> >
> > - Sometimes you repeat prefixes in leaf definitions (e.g.,
> >   nat-pass-through-port) while at other times you do not.
> >
> > - nat-pass-through-port
> >
> >   You seem to have copy pasted the description of
> >   nat-pass-through-pref.  Is this a single port? So I need multiple
> >   nat-pass-through entries for multiple ports. Fine. But is there a
> >   special meaning if both nat-pass-through-pref and
> >   nat-pass-through-port are configured in a single list entry? Does
> >   this mean the port is scoped to the prefix?
> >
> > - Some nat type specific parameter lists are flat, for others there is
> >   an additional container. Is this by design?
> >
> > - I meanwhile think there really should be features. Certain lists
> >   only make sense for implementations that support certain NAT
> >   types. Having features defined allows code generators to easily
> >   generate stubs that actually match the capabilities of an
> >   implementation. And you automatically benefit from feature
> >   announcements.
> >
> > - s/attachedto/attached to/
> >
> > - s/prefixs./prefixes./
> >
> > - nat64-prefix
> >
> >   What is the purpose of //default "64:ff9b::/96"; ??
> >
> > - stateless-enable
> >
> >   Does this enable leaf make sense on a list entry? Perhaps it does
> >   but the description is fairly general and hence I am asking.
> >
> > - external-ip-address-pool/pool-id
> >
> >   This seems to relate to a Natv2PoolIndex, which again excludes the
> >   value 0. I have not checked all such related things, so please go
> >   and check yourself.
> >
> > - external-ip-address-pool
> >
> >   The description says
> >
> >             Both contiguous and non-contiguous pools
> >             can be configured for NAT purposes.";
> >
> >   but it seems more accurate to say that a pool is a set of prefixes
> >   since this is what the model suggests.
> >
> > - supported-transport-protocols
> >
> >   I am again not clear whether you are reporting implementation
> >   capabilities here or enabled features or something else. Is the
> >   configuration of transport-protocol-id and transport-protocol-name
> >   mutually exclusive? If so, should this be a choice? If I can
> >   configure both, I assume they have to be consistent.
> >
> > - transport-protocol-name
> >
> >   Is this restricted to the acronyms that are used in the IANA
> >   protocol numbers registry?
> >
> > - s/masck/mask/
> >
> > - subscriber-mask-v6
> >
> >   The name seems to indicate that this only applies to IPv6 prefixes
> >   handed out to CPEs. Perhaps this should be stated explicitely (but
> >   yes it is unlike to ever get an IPv4 prefix). But then, the
> >   subscriber-match has an IPv4 prefix example.
> >
> > - quota-type
> >
> >   Is this a good name for the leaf? This seems to indicate for which
> >   transport protocol a port-limit is enforced. And this list is
> >   restricted to TCP, UDP, and ICMP while other parts of the model are
> >   more flexible in supporting additional transport protocols. So is it
> >   consistent to a rather restricted enum here?
> >
> > - port-set-timeout
> >
> >   Needs a units statement.
> >
> > - timeouts
> >
> >   Can I make the timeouts arbitrarily small, in the extreme case 0
> >   seconds? In some cases I find text like "for at least 6 seconds".
> >   Does this mean that the range is really uint32 { range "6..max"; }?
> >   Or is it still OK to configure the value 3 and the 'must' is really
> >   a 'should'?
> >
> > - port-timeout
> >
> >   I doubt this is of type inet:port-number and there likely needs to
> >   be a units statement.
> >
> > - alg-name
> >
> >   Is there a list of well-known ALG names? IANA? Or is this a random
> >   string that one needs to guess form the vendor's documentation,
> >   i.e., this is potentially not interoperable out of the box? Is there
> >   a way to obtain the number of ALGs supported or is the idea to do
> >   trial and error probing to find out (which is even harder if there
> >   are no well-known ALG names)?
> >
> > - all-algs-enable
> >
> >   This says "Enable/disable all ALGs." but I _assume_ that I set this
> >   to false and to enable specific ALGs. Perhaps this interaction needs
> >   to be spelled out.
> >
> > - Is there any throttling mechanism needed in case my NAT is
> >   constantly operating around the notification thresholds?
> >
> > - Add units to the mapping limit definitions ("subscribers",
> >   "mappings", ...)
> >
> > - limit-per-subnet
> >
> >   This is type inet:ip-prefix? I guess you wanted something else here.
> >
> > - Why are some limits mandatory, others not?
> >
> > - If you write 'limit per subscriber', how is a subscriber identified?
> >   I assume these are global per subscriber limits, i.e., all
> >   subscribers receive the same limit.
> >
> > - limit-per-subnet
> >
> >           leaf limit-per-subnet {
> >             type inet:ip-prefix;
> >
> >             description
> >               "Rate-limit the number of new mappings
> > 	       and sessions per subnet.";
> >           }
> >
> >   I do not see how this works. The other limit-per-XXX objects are
> >   numbers - presumably defining the limit. This is a prefix?
> >
> > - logging-info
> >
> >   Is this information complete? Perhaps it is for plain syslog
> >   (without any security) but I doubt the info is complete for the
> >   other transports mentioned, at least not for FTP. And surely, if you
> >   want to protect the logging information, then you will neeed way
> >   more parameters. And what does 'retrieving' logging entries mean?  I
> >   assume with syslog and ipfix you push log messages. I am less sure
> >   about FTP. Perhaps less is more and simply provide support for
> >   syslog and leave the other options for extensions. You have a choice
> >   in place, so not need to go and deal with all possible complexity
> >   here.
> >
> > - For the statistics, we used to use plural form for counters back in
> >   SNMP land and I think this was good practice. So go with
> >   sent-packets, sent-bytes, rcvd-packets, rcvd-bytes, dropped-packets,
> >   dropped-bytes, ...
> >
> > - total-mappings, total-tcp-mappings, total-udp-mappings,
> >   total-icmp-mappings: These may use yang:gauge32.
> >
> > - address-allocated, address-free -> addresses-allocated, addresses-fre=
e
> >   (may also be yang:gauge32)
> >
> > - Some of these gauges might fluctuate fast (maybe consider
> >   exponentially smoothed gauges, but this might also be left for an
> >   extension).
> >
> > - The security considerations text should follow the new boilerplate
> >   that also covers RESTCONF. I think it would help to be more specific
> >   about the security aspects of this data model. This text is quite
> >   generic. With a NAT, things even have privacy aspects. If I can
> >   force a specific NAT mapping, I can track a subscriber.
> >
> > - At least one example has syntax errors. Examples should ideally be
> >   validated by tools so that the examples are syntactically correct and
> >   valid regarding the data model.
> >
> >
> > _______________________________________________
> > yang-doctors mailing list
> > yang-doctors@ietf.org
> > https://www.ietf.org/mailman/listinfo/yang-doctors
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         


From nobody Mon Oct 30 08:43: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 559874B39; Mon, 30 Oct 2017 08:43:11 -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.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150937819128.7814.8545530347099207880@ietfa.amsl.com>
Date: Mon, 30 Oct 2017 08:43:11 -0700
Archived-At: 
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-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, 30 Oct 2017 15:43:11 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group WG of the IETF.

        Title           : 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-07.txt
	Pages           : 74
	Date            : 2017-10-30

Abstract:
   For the sake of network automation and the need for programming
   Network Address Translation (NAT) function in particular, a data
   model for configuring and managing the NAT is essential.  This
   document defines a YANG module for the NAT function.

   NAT44, Network Address and Protocol Translation from IPv6 Clients to
   IPv4 Servers (NAT64), Customer-side transLATor (CLAT), Explicit
   Address Mappings for Stateless IP/ICMP Translation (SIIT EAM), and
   IPv6 Network Prefix Translation (NPTv6) are covered in this document.

Editorial Note (To be removed by RFC Editor)

   Please update these statements with the RFC number to be assigned to
   this document:

      "This version of this YANG module is part of RFC XXXX;"

      "RFC XXXX: A YANG Data Model for Network Address Translation (NAT)
      and Network Prefix Translation (NPT)";

      "reference: RFC XXXX"


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-07
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-nat-yang-07


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

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


From nobody Mon Oct 30 08:57: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 C3BBC13FE5D for ; Mon, 30 Oct 2017 08:57:02 -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 c8hHnQr_mOlp for ; Mon, 30 Oct 2017 08:57:01 -0700 (PDT)
Received: from 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 EEB504D25 for ; Mon, 30 Oct 2017 08:48:01 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id AAE0E6079D for ; Mon, 30 Oct 2017 16:48:00 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 91D664004C for ; Mon, 30 Oct 2017 16:48:00 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0361.001; Mon, 30 Oct 2017 16:48:00 +0100
From: 
To: "opsawg@ietf.org" 
Thread-Topic: New Version Notification for draft-ietf-opsawg-nat-yang-07.txt
Thread-Index: AQHTUZXMNosW3+/ZO0uKS3KfgOSBG6L8iVgA
Date: Mon, 30 Oct 2017 15:48:00 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A060F66@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <150937819146.7814.5910762435725588331.idtracker@ietfa.amsl.com>
In-Reply-To: <150937819146.7814.5910762435725588331.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.4]
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-07.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, 30 Oct 2017 15:57:03 -0000

RGVhciBhbGwsIA0KDQpUaGlzIHZlcnNpb24gdHJpZXMgdG8gYWRkcmVzcyB0aGUgY29tbWVudHMg
ZnJvbSBKw7xlcmdlbi4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdp
bmUtLS0tLQ0KPiBEZcKgOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l
dC1kcmFmdHNAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogbHVuZGkgMzAgb2N0b2JyZSAyMDE3IDE2
OjQzDQo+IMOAwqA6IFFpbiBXdTsgU2VudGhpbCBTaXZha3VtYXI7IEJPVUNBREFJUiBNb2hhbWVk
IElNVC9PTE47IFN1cmVzaA0KPiBWaW5hcGFtdWxhOyBKQUNRVUVORVQgQ2hyaXN0aWFuIElNVC9P
TE4NCj4gT2JqZXTCoDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLW9w
c2F3Zy1uYXQteWFuZy0wNy50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh
ZnQtaWV0Zi1vcHNhd2ctbmF0LXlhbmctMDcudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz
dWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiBy
ZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nDQo+IFJl
dmlzaW9uOgkwNw0KPiBUaXRsZToJCUEgWUFORyBEYXRhIE1vZGVsIGZvciBOZXR3b3JrIEFkZHJl
c3MgVHJhbnNsYXRpb24gKE5BVCkNCj4gYW5kIE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0aW9uIChO
UFQpDQo+IERvY3VtZW50IGRhdGU6CTIwMTctMTAtMzANCj4gR3JvdXA6CQlvcHNhd2cNCj4gUGFn
ZXM6CQk3NA0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt
ZHJhZnRzL2RyYWZ0LWlldGYtb3BzYXdnLQ0KPiBuYXQteWFuZy0wNy50eHQNCj4gU3RhdHVzOiAg
ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3BzYXdn
LW5hdC0NCj4geWFuZy8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy0wNw0KPiBIdG1saXplZDogICAgICAgaHR0
cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW9wc2F3Zy0NCj4g
bmF0LXlhbmctMDcNCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp
ZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2F3Zy1uYXQtDQo+IHlhbmctMDcNCj4gDQo+IEFic3RyYWN0
Og0KPiAgICBGb3IgdGhlIHNha2Ugb2YgbmV0d29yayBhdXRvbWF0aW9uIGFuZCB0aGUgbmVlZCBm
b3IgcHJvZ3JhbW1pbmcNCj4gICAgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0aW9uIChOQVQpIGZ1
bmN0aW9uIGluIHBhcnRpY3VsYXIsIGEgZGF0YQ0KPiAgICBtb2RlbCBmb3IgY29uZmlndXJpbmcg
YW5kIG1hbmFnaW5nIHRoZSBOQVQgaXMgZXNzZW50aWFsLiAgVGhpcw0KPiAgICBkb2N1bWVudCBk
ZWZpbmVzIGEgWUFORyBtb2R1bGUgZm9yIHRoZSBOQVQgZnVuY3Rpb24uDQo+IA0KPiAgICBOQVQ0
NCwgTmV0d29yayBBZGRyZXNzIGFuZCBQcm90b2NvbCBUcmFuc2xhdGlvbiBmcm9tIElQdjYgQ2xp
ZW50cyB0bw0KPiAgICBJUHY0IFNlcnZlcnMgKE5BVDY0KSwgQ3VzdG9tZXItc2lkZSB0cmFuc0xB
VG9yIChDTEFUKSwgRXhwbGljaXQNCj4gICAgQWRkcmVzcyBNYXBwaW5ncyBmb3IgU3RhdGVsZXNz
IElQL0lDTVAgVHJhbnNsYXRpb24gKFNJSVQgRUFNKSwgYW5kDQo+ICAgIElQdjYgTmV0d29yayBQ
cmVmaXggVHJhbnNsYXRpb24gKE5QVHY2KSBhcmUgY292ZXJlZCBpbiB0aGlzIGRvY3VtZW50Lg0K
PiANCj4gRWRpdG9yaWFsIE5vdGUgKFRvIGJlIHJlbW92ZWQgYnkgUkZDIEVkaXRvcikNCj4gDQo+
ICAgIFBsZWFzZSB1cGRhdGUgdGhlc2Ugc3RhdGVtZW50cyB3aXRoIHRoZSBSRkMgbnVtYmVyIHRv
IGJlIGFzc2lnbmVkIHRvDQo+ICAgIHRoaXMgZG9jdW1lbnQ6DQo+IA0KPiAgICAgICAiVGhpcyB2
ZXJzaW9uIG9mIHRoaXMgWUFORyBtb2R1bGUgaXMgcGFydCBvZiBSRkMgWFhYWDsiDQo+IA0KPiAg
ICAgICAiUkZDIFhYWFg6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBOZXR3b3JrIEFkZHJlc3MgVHJh
bnNsYXRpb24gKE5BVCkNCj4gICAgICAgYW5kIE5ldHdvcmsgUHJlZml4IFRyYW5zbGF0aW9uIChO
UFQpIjsNCj4gDQo+ICAgICAgICJyZWZlcmVuY2U6IFJGQyBYWFhYIg0KPiANCj4gDQo+IA0KPiAN
Cj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g
dGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh
bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYg
U2VjcmV0YXJpYXQNCg0K


From nobody Mon Oct 30 09:33:53 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 F01817726; Mon, 30 Oct 2017 09:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 WcPBEe-6RSX4; Mon, 30 Oct 2017 09:33:47 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DCC66A5; Mon, 30 Oct 2017 09:23:38 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 28A39F78; Mon, 30 Oct 2017 17:23:37 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Vf1SITq94yuj; Mon, 30 Oct 2017 17:23:34 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 30 Oct 2017 17:23:37 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12BD72010E; Mon, 30 Oct 2017 17:23:37 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PR16tH9-vNGt; Mon, 30 Oct 2017 17:23:35 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E52472010F; Mon, 30 Oct 2017 17:23:35 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 2AFD64143D02; Mon, 30 Oct 2017 17:22:10 +0100 (CET)
Date: Mon, 30 Oct 2017 17:22:10 +0100
From: Juergen Schoenwaelder 
To: mohamed.boucadair@orange.com
Cc: "yang-doctors@ietf.org" , "draft-ietf-opsawg-nat-yang.all@ietf.org" ,  "opsawg@ietf.org" 
Message-ID: <20171030162210.ni72dxxmc45o3cak@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: mohamed.boucadair@orange.com, "yang-doctors@ietf.org" , "draft-ietf-opsawg-nat-yang.all@ietf.org" ,  "opsawg@ietf.org" 
References: <150912805550.22087.2939629492652644040@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A060DB1@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A060DB1@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-nat-yang-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, 30 Oct 2017 16:33:52 -0000

On Mon, Oct 30, 2017 at 02:41:19PM +0000, mohamed.boucadair@orange.com wrote:
>  That said, there are a number of details where I doubt
> > the model is correct and things where I believe things are incomplete.
> > Given that there are many different NAT functions, I also expected to
> > see usage of YANG features.
> 
> [Med] We used to make use of "features", but there was a comment during the WG call for adoption that requested us to make use of identities, instead.

But these are not the same thing. If I am not a nat64, then apparently
several objects to not apply to me. This is what features allow you to
express. Perhaps someone wanted identities for something different, I
do not know. I think it is reasonable to assume that not all NAT
implementations will support all types of NATs that the model supports
and hence the model should reflect this.

> > 
> > - What is the vrf-routing-instance identity good for?
> 
> [Med] This is used to bind a NAT function to an external VRF routing instance. Please check https://www.ietf.org/mail-archive/web/opsawg/current/msg05117.html 
>

I very much doubt that an identity identifies a VRF instance. I am not
questioning the need to identify a VRF, I am questioning that the
solution put in place achieves this.

> >   Its used only in
> >   the leaf external-vrf-instance and the description of that leaf is
> >   not telling me how this is going to be used. Who is going to derive
> >   identities? I fear you are trying to achieve something where using
> >   identities is really the wrong approach. Section 2.10 does not tell
> >   how this is supposed to work either. I assume this needs to be
> >   checked by the routing area experts to make sure things fit with
> >   their modeling of VRFs.

And this was my explanation why I believe this identity thing does not
work. You need to make work this out with the people modeling VRFs.
 
> > - mapping-entry/type: instead 'manually configured', I would write
> >   'explicitly configured' (configuration does not have to be a manual
> 
> [Med] Manually is derived from RFC6887, which says: 
> 
>       *  Explicit static mappings are created by manual configuration
>          (e.g., via command-line interface or other user interface) and
>          persist until the user changes that manual configuration.

Note the word 'explicit' there. I assume this boils down in NMDA terms
to configuration ending up in  and I prefer explicit
configuration since configuration ending up in  can very
well come from automated systems, i.e., there is not necessarily a
manual process.

>  And is
> >   this a ticking lifetime, i.e., this changes on every get request? Is
> >   this useful? Have alternatives been considered such as reporting the
> >   point in time when the mapping was established? Or is the idea that
> >   the lifetime reports the time left until the mapping will be garbage
> >   collected? What does "tracks the connection" really mean here?
> 
> [Med] The initial value indicates the duration to maintain a mapping. When retrieved in a get operation, it indicates the remaining validity lifetime.  
> I updated the text to clarify this.

This means this is constantly changing. If you would return the
timestamp when the lifetime ends the value would change rarely. The WG
needs to think about the choice. Note that constantly changing values
are potentially a burden with telemetry interfaces and caches but this
may not apply here. The WG should discuss what the right choice is
here.

> > - container nat-capabilities:
> > 
> >   Here we find a bunch of "config true" leafs and I wonder how these
> >   work. There are things a NAT implementation is capable to do, and
> >   there are things that are enabled in a NAT deployment and of course
> >   you can't enable something in a deployment that has not been
> >   implemented. So are these 'capabilities' more like NAT features
> >   enabled (since we have "config true" nodes) or are these more
> >   implemented capabilities (but then "config true" may be wrong)?
> 
> [Med] These are about what an implementation is able to do. When I set config to "false", pyang is complaining.

If leafs are not configurable, then they should be config false.
 
> >   Depending on the answer, did you consider using YANG features?
> 
> [Med] Yes, we considered the YANG features.

I do believe you want features. Now, if an implementation supports
multiple different NATs, how do I tell the NAT which type of NAT
function applies to a given packet? Is this always clear?

> > - Some nat type specific parameter lists are flat, for others there is
> >   an additional container. Is this by design?
> 
> [Med] Yes, the design was built with NAT/NAT64 as the core functionality. Other specific-techniques are added as containers for clarity. 
>

Hm. Perhaps a bit subtle without a description.
 
> >   Is this restricted to the acronyms that are used in the IANA
> >   protocol numbers registry?
> 
> [Med] Yes.  

So please state this.
 
> > - alg-name
> > 
> >   Is there a list of well-known ALG names? IANA? Or is this a random
> >   string that one needs to guess form the vendor's documentation,
> >   i.e., this is potentially not interoperable out of the box? Is there
> >   a way to obtain the number of ALGs supported or is the idea to do
> >   trial and error probing to find out (which is even harder if there
> >   are no well-known ALG names)?
> > 
> 
> [Med] There is no "standardized/IANA" list of ALGs. There is a list of widely deployed/implemented ones.
> FWIW, we used to have this list: 
> 
>     |        +--rw ftp-alg-enable?              boolean
>     |        +--rw dns-alg-enable?              boolean
>     |        +--rw tftp-alg-enable?             boolean
>     |        +--rw msrpc-alg-enable?            boolean
>     |        +--rw netbios-alg-enable?          boolean
>     |        +--rw rcmd-alg-enable?             boolean
>     |        +--rw ldap-alg-enable?             boolean
>     |        +--rw sip-alg-enable?              boolean
>     |        +--rw rtsp-alg-enable?             boolean
>     |        +--rw h323-alg-enable?             boolean
>     |        +--rw all-algs-enable?             boolean
> 
> We changed the design to this one because it is easily extensible.

Well, as long as it is clear what an ALG name is...
 
> [Med] Yes. 
> 
> > 
> > - logging-info
> > 
> >   Is this information complete? Perhaps it is for plain syslog
> >   (without any security) but I doubt the info is complete for the
> >   other transports mentioned, at least not for FTP. And surely, if you
> >   want to protect the logging information, then you will neeed way
> >   more parameters. And what does 'retrieving' logging entries mean?  I
> >   assume with syslog and ipfix you push log messages. I am less sure
> >   about FTP. Perhaps less is more and simply provide support for
> >   syslog and leave the other options for extensions. You have a choice
> >   in place, so not need to go and deal with all possible complexity
> >   here.
> > 
> 
> [Med] It is out of scope of specify the exact logging information. Those considerations are out of scope. We only focus on the protocol and the server information.

I think my comment was saying that the information is not sufficient to
talk to a server.

>  I think it would help to be more specific
> >   about the security aspects of this data model. This text is quite
> >   generic.
> 
> [Med] The text Acks that all information are sensitive. They must be protected and secure means must be used.

A generic statement - in the past you there usually was a problem
getting such generic statements through the approval process since
security people want authors to think through the security aspects of
individual objects or groups of related objects. But you can try of
course, perhaps the mindset has changed - and I am not a secdir
reviewer. ;-)

>  With a NAT, things even have privacy aspects. If I can
> >   force a specific NAT mapping, I can track a subscriber.
> 
> [Med] IMHO, this is not specific to the NAT. Mandating secure means to control the NAT is a guard against such attack.  

I think this is actually more subtle than one might think but this is
the job of the security directorate people to think about.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Tue Oct 31 02:55:58 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 316DE13B11B; Tue, 31 Oct 2017 02:55:52 -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 THuOWet4RVKQ; Tue, 31 Oct 2017 02:55:49 -0700 (PDT)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5700F13A66B; Tue, 31 Oct 2017 02:55:49 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id D2D0B608A3; Tue, 31 Oct 2017 10:55:47 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id AABF14004C; Tue, 31 Oct 2017 10:55:47 +0100 (CET)
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; Tue, 31 Oct 2017 10:55:47 +0100
From: 
To: Juergen Schoenwaelder 
CC: "yang-doctors@ietf.org" , "draft-ietf-opsawg-nat-yang.all@ietf.org" , "opsawg@ietf.org" 
Thread-Topic: Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
Thread-Index: AQHTT09nb4Xo03k7b0eBVGOEwFdqM6L8ajgAgAAc3gCAARxwQA==
Date: Tue, 31 Oct 2017 09:55:46 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A063187@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <150912805550.22087.2939629492652644040@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A060DB1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171030162210.ni72dxxmc45o3cak@elstar.local>
In-Reply-To: <20171030162210.ni72dxxmc45o3cak@elstar.local>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OPSAWG] Yangdoctors early review of draft-ietf-opsawg-nat-yang-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: Tue, 31 Oct 2017 09:55:52 -0000

Hi J=FCergen,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De=A0: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de=
]
> Envoy=E9=A0: lundi 30 octobre 2017 17:22
> =C0=A0: BOUCADAIR Mohamed IMT/OLN
> Cc=A0: yang-doctors@ietf.org; draft-ietf-opsawg-nat-yang.all@ietf.org;
> opsawg@ietf.org
> Objet=A0: Re: Yangdoctors early review of draft-ietf-opsawg-nat-yang-06
>=20
> On Mon, Oct 30, 2017 at 02:41:19PM +0000, mohamed.boucadair@orange.com
> wrote:
> >  That said, there are a number of details where I doubt
> > > the model is correct and things where I believe things are incomplete=
.
> > > Given that there are many different NAT functions, I also expected to
> > > see usage of YANG features.
> >
> > [Med] We used to make use of "features", but there was a comment during
> the WG call for adoption that requested us to make use of identities,
> instead.
>=20
> But these are not the same thing.

[Med] You are right. Sorry for not being clear.=20

What I meant is that the module used, for example, "if-feature nat64" and s=
o on to refer to NAT flavors. We replaced those with "when" statements that=
 points to the actual capabilities of an implementation.=20
Another change we made, is that we used to have "Boolean" to indicate the s=
upport of a given tarnation scheme (e.g., nat64-support, nat44-support), bu=
t we updated those to make use of identities.=20


 If I am not a nat64, then apparently
> several objects to not apply to me.

[Med] Yes. We tried to cover this by "when" statements.=20

 This is what features allow you to
> express. Perhaps someone wanted identities for something different, I
> do not know. I think it is reasonable to assume that not all NAT
> implementations will support all types of NATs that the model supports
> and hence the model should reflect this.
>=20

[Med] The module indicates what a given implementation has to support based=
 on its capabilities. This is handled by means of "when" statements.  =20

> > >
> > > - What is the vrf-routing-instance identity good for?
> >
> > [Med] This is used to bind a NAT function to an external VRF routing
> instance. Please check https://www.ietf.org/mail-
> archive/web/opsawg/current/msg05117.html
> >
>=20
> I very much doubt that an identity identifies a VRF instance. I am not
> questioning the need to identify a VRF, I am questioning that the
> solution put in place achieves this.

[Med] Thank you for clarifying. This is actually a good point. The options =
we considered are as follows:=20

(1) Use an Identity to avoid struggling with semantics of how a VRF can be =
defined.
(2) Point to draft-ietf-rtgwg-ni-model, likely (?) as a normative reference=
.=20
(3) Remove the VRF thing from the draft; future extensions can be defined.

Given that "VRFs" are not required for all NATs and some reviewers asked to=
 add VRFs in addition to interfaces, we went for option (1). Having a depen=
dency on a YANG module under development is not justified for all implement=
ations.=20

>=20
> > >   Its used only in
> > >   the leaf external-vrf-instance and the description of that leaf is
> > >   not telling me how this is going to be used. Who is going to derive
> > >   identities? I fear you are trying to achieve something where using
> > >   identities is really the wrong approach. Section 2.10 does not tell
> > >   how this is supposed to work either. I assume this needs to be
> > >   checked by the routing area experts to make sure things fit with
> > >   their modeling of VRFs.
>=20
> And this was my explanation why I believe this identity thing does not
> work. You need to make work this out with the people modeling VRFs.
>=20
> > > - mapping-entry/type: instead 'manually configured', I would write
> > >   'explicitly configured' (configuration does not have to be a manual
> >
> > [Med] Manually is derived from RFC6887, which says:
> >
> >       *  Explicit static mappings are created by manual configuration
> >          (e.g., via command-line interface or other user interface) and
> >          persist until the user changes that manual configuration.
>=20
> Note the word 'explicit' there. I assume this boils down in NMDA terms
> to configuration ending up in  and I prefer explicit
> configuration since configuration ending up in  can very
> well come from automated systems, i.e., there is not necessarily a
> manual process.

[Med] I hear you. FYI, there is no "manual" mention in the new revision of =
the draft.=20

>=20
> >  And is
> > >   this a ticking lifetime, i.e., this changes on every get request? I=
s
> > >   this useful? Have alternatives been considered such as reporting th=
e
> > >   point in time when the mapping was established? Or is the idea that
> > >   the lifetime reports the time left until the mapping will be garbag=
e
> > >   collected? What does "tracks the connection" really mean here?
> >
> > [Med] The initial value indicates the duration to maintain a mapping.
> When retrieved in a get operation, it indicates the remaining validity
> lifetime.
> > I updated the text to clarify this.
>=20
> This means this is constantly changing. If you would return the
> timestamp when the lifetime ends the value would change rarely.

[Med] That's another option which has implications on the NAT implementatio=
n itself. We modeled the YANG module to be aligned with current NAT impleme=
ntations. =20

 The WG
> needs to think about the choice. Note that constantly changing values
> are potentially a burden with telemetry interfaces and caches but this
> may not apply here. The WG should discuss what the right choice is
> here.
>=20
> > > - container nat-capabilities:
> > >
> > >   Here we find a bunch of "config true" leafs and I wonder how these
> > >   work. There are things a NAT implementation is capable to do, and
> > >   there are things that are enabled in a NAT deployment and of course
> > >   you can't enable something in a deployment that has not been
> > >   implemented. So are these 'capabilities' more like NAT features
> > >   enabled (since we have "config true" nodes) or are these more
> > >   implemented capabilities (but then "config true" may be wrong)?
> >
> > [Med] These are about what an implementation is able to do. When I set
> config to "false", pyang is complaining.
>=20
> If leafs are not configurable, then they should be config false.

[Med] I will revert config to false as we used to have in previous versions=
. As I said earlier, pyang will cry. I don't know how to fix that.=20

>=20
> > >   Depending on the answer, did you consider using YANG features?
> >
> > [Med] Yes, we considered the YANG features.
>=20
> I do believe you want features. Now, if an implementation supports
> multiple different NATs, how do I tell the NAT which type of NAT
> function applies to a given packet? Is this always clear?

[Med] The current module allows for implementations that support many trans=
lation flavors. In particular, it allows for a same NAT instance to enable =
many features in the same time.

There is no need to indicate explicitly the translation scheme(s) to enable=
 because this will be implicitly deduced from the configuration parameters.=
 For example:=20
- an implementation supplied with an external IPv4 address pool only, will =
automatically behave in the base NAT mode.
- an implementation supplied with an external IPv4 address pool and port-re=
lated parameters will behave in the NAPT mode.
- an implementation supplied with an external IPv4 address pool, port-relat=
ed parameters, and NAT64 prefixes will behave in the statefull NAT64 mode
- an implementation supplied with an external IPv4 address pool, port-relat=
ed parameters, dst-nat-enable=3Dtrue, and dst-ip-address-pool will behave i=
n the NAPT mode + destination NAT

and so on.=20


>=20
> > > - Some nat type specific parameter lists are flat, for others there i=
s
> > >   an additional container. Is this by design?
> >
> > [Med] Yes, the design was built with NAT/NAT64 as the core
> functionality. Other specific-techniques are added as containers for
> clarity.
> >
>=20
> Hm. Perhaps a bit subtle without a description.
>=20
> > >   Is this restricted to the acronyms that are used in the IANA
> > >   protocol numbers registry?
> >
> > [Med] Yes.
>=20
> So please state this.

[Med] Fixed in my local copy.=20

>=20
> > > - alg-name
> > >
> > >   Is there a list of well-known ALG names? IANA? Or is this a random
> > >   string that one needs to guess form the vendor's documentation,
> > >   i.e., this is potentially not interoperable out of the box? Is ther=
e
> > >   a way to obtain the number of ALGs supported or is the idea to do
> > >   trial and error probing to find out (which is even harder if there
> > >   are no well-known ALG names)?
> > >
> >
> > [Med] There is no "standardized/IANA" list of ALGs. There is a list of
> widely deployed/implemented ones.
> > FWIW, we used to have this list:
> >
> >     |        +--rw ftp-alg-enable?              boolean
> >     |        +--rw dns-alg-enable?              boolean
> >     |        +--rw tftp-alg-enable?             boolean
> >     |        +--rw msrpc-alg-enable?            boolean
> >     |        +--rw netbios-alg-enable?          boolean
> >     |        +--rw rcmd-alg-enable?             boolean
> >     |        +--rw ldap-alg-enable?             boolean
> >     |        +--rw sip-alg-enable?              boolean
> >     |        +--rw rtsp-alg-enable?             boolean
> >     |        +--rw h323-alg-enable?             boolean
> >     |        +--rw all-algs-enable?             boolean
> >
> > We changed the design to this one because it is easily extensible.
>=20
> Well, as long as it is clear what an ALG name is...

[Med] Actually, what is more important is the protocol/port.=20

BTW, I updated the module to indicate src and/or dst ports.=20

>=20
> > [Med] Yes.
> >
> > >
> > > - logging-info
> > >
> > >   Is this information complete? Perhaps it is for plain syslog
> > >   (without any security) but I doubt the info is complete for the
> > >   other transports mentioned, at least not for FTP. And surely, if yo=
u
> > >   want to protect the logging information, then you will neeed way
> > >   more parameters. And what does 'retrieving' logging entries mean?  =
I
> > >   assume with syslog and ipfix you push log messages. I am less sure
> > >   about FTP. Perhaps less is more and simply provide support for
> > >   syslog and leave the other options for extensions. You have a choic=
e
> > >   in place, so not need to go and deal with all possible complexity
> > >   here.
> > >
> >
> > [Med] It is out of scope of specify the exact logging information. Thos=
e
> considerations are out of scope. We only focus on the protocol and the
> server information.
>=20
> I think my comment was saying that the information is not sufficient to
> talk to a server.

[Med] It is only about the minimal set of information. The information is n=
ot complete on purpose. Protocol-specific information is out of scope of th=
is document.=20

>=20
> >  I think it would help to be more specific
> > >   about the security aspects of this data model. This text is quite
> > >   generic.
> >
> > [Med] The text Acks that all information are sensitive. They must be
> protected and secure means must be used.
>=20
> A generic statement - in the past you there usually was a problem
> getting such generic statements through the approval process since
> security people want authors to think through the security aspects of
> individual objects or groups of related objects. But you can try of
> course, perhaps the mindset has changed - and I am not a secdir
> reviewer. ;-)
>=20
> >  With a NAT, things even have privacy aspects. If I can
> > >   force a specific NAT mapping, I can track a subscriber.
> >
> > [Med] IMHO, this is not specific to the NAT. Mandating secure means to
> control the NAT is a guard against such attack.
>=20
> I think this is actually more subtle than one might think but this is
> the job of the security directorate people to think about.
>=20

[Med] You are probably right, but I prefer to leave those for the secdir re=
views.=20

> /js
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         


From nobody Tue Oct 31 03:18: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 1C8BE139B9F for ; Tue, 31 Oct 2017 03:18: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 VyV73Z2ejA83 for ; Tue, 31 Oct 2017 03:18: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 20E2812426E for ; Tue, 31 Oct 2017 03:18: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 DYY35643; Tue, 31 Oct 2017 10:18:28 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 31 Oct 2017 10:18:28 +0000
Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Tue, 31 Oct 2017 18:18:02 +0800
From: "dingxiaojian (A)" 
To: "opsawg@ietf.org" 
Thread-Topic: New Version Notification for draft-ding-opsawg-wavelength-use-case-00.txt
Thread-Index: AdNSMU2pwom2EKTqTsW/xDp0Hyh9VQ==
Date: Tue, 31 Oct 2017 10:18:01 +0000
Message-ID: <3B110B81B721B940871EC78F107D848C01028F94@DGGEMM506-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.134.227]
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.59F84DF4.017B, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.4.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9d58027fa959dbfe7bc8d861a8087b52
Archived-At: 
Subject: Re: [OPSAWG] New Version Notification for draft-ding-opsawg-wavelength-use-case-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: Tue, 31 Oct 2017 10:18:32 -0000

SGkgb3BzYXdnLA0KDQpXZSd2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgb24gZGVzY3JpYmluZyB0
aGUgbmV0d29yayBkYXRhIHJlcXVpcmVtZW50IG9mIGV2YWx1YXRlIHRoZSBwZXJmb3JtYW5jZQ0K
IG9mIHdhdmVsZW5ndGggZGl2aXNpb24gc2VydmljZS4gSG93ZXZlciwgdGhlIG9iamVjdGl2ZSBv
ZiB0aGlzIGRyYWZ0IGlzIG5vdCB0byBpbnRyb2R1Y2UgdGhlIHdhdmVsZW5ndGgNCiBkaXZpc2lv
biBzZXJ2aWNlIGluIGRldGFpbC4gSW5zdGVhZCwgd2UgbGlzdCB3aGF0IGtpbmQgb2YgZGF0YSBp
cyBuZWVkZWQgdG8gZXZhbHVhdGUgdGhlIHBlcmZvcm1hbmNlIG9mDQogd2F2ZWxlbmd0aCBkaXZp
c2lvbiBzZXJ2aWNlLCBhbmQgaG93IHRoZXNlIGRhdGEgaXMgdXNlZCBmb3IgZGlmZmVyZW50IHNj
ZW5hcmlvcyBvZiB3YXZlbGVuZ3RoIGRpdmlzaW9uIHNlcnZpY2UuIA0KQXQgbGFzdCwgd2Ugc3Vt
bWFyaXplIHNvbWUgZGF0YSBpc3N1ZXMuDQoNCldlIGFyZSB2ZXJ5IGFwcHJlY2lhdGVkIGlmIHlv
dSBtYXkgdGFrZSBhIGxvb2sgYXQgdGhlIGRyYWZ0IGFuZCBwcm92aWRlIGNvbW1lbnRzIG9uIHRo
ZSBsaXN0Lg0KDQpCZXN0IFJlZ2FyZHMsDQpYaWFvamlhbg0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg
SS1ELCBkcmFmdC1kaW5nLW9wc2F3Zy13YXZlbGVuZ3RoLXVzZS1jYXNlLTAwLnR4dA0KaGFzIGJl
ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYaWFvamlhbiBEaW5nIGFuZCBwb3N0ZWQgdG8g
dGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWRpbmctb3BzYXdnLXdhdmVsZW5n
dGgtdXNlLWNhc2UNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlOZXR3b3JrIERhdGEgVXNlIENhc2Ug
Zm9yIFdhdmVsZW5ndGggRGl2aXNpb24gU2VydmljZQ0KRG9jdW1lbnQgZGF0ZToJMjAxNy0xMC0z
MA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJNw0KVVJMOiAgICAgICAg
ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kaW5nLW9wc2F3
Zy13YXZlbGVuZ3RoLXVzZS1jYXNlLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRpbmctb3BzYXdnLXdhdmVsZW5ndGgtdXNlLWNh
c2UvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRp
bmctb3BzYXdnLXdhdmVsZW5ndGgtdXNlLWNhc2UtMDANCkh0bWxpemVkOiAgICAgICBodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWRpbmctb3BzYXdnLXdhdmVsZW5n
dGgtdXNlLWNhc2UtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz
IHVzZSBjYXNlcyB0aGF0IGRlbW9uc3RyYXRlIHRoZSBhcHBsaWNhYmlsaXR5DQogICBvZiBuZXR3
b3JrIGRhdGEgdG8gZXZhbHVhdGUgdGhlIHBlcmZvcm1hbmNlIG9mIHdhdmVsZW5ndGggZGl2aXNp
b24NCiAgIHNlcnZpY2UuICBUaGUgb2JqZWN0aXZlIG9mIHRoaXMgZHJhZnQgaXMgbm90IHRvIGNv
dmVyIHRoZSB3YXZlbGVuZ3RoDQogICBkaXZpc2lvbiBzZXJ2aWNlIGluIGRldGFpbC4gIFJhdGhl
ciwgdGhlIGludGVudGlvbiBpcyB0byBpbGx1c3RyYXRlDQogICB0aGUgcmVxdWlyZW1lbnRzIG9m
IG5ldHdvcmsgZGF0YSB1c2VkIHRvIGV2YWx1YXRlIHRoZSBwZXJmb3JtYW5jZSBvZg0KICAgd2F2
ZWxlbmd0aCBkaXZpc2lvbiBzZXJ2aWNlLg0KDQogICBHZW5lcmFsIGNoYXJhY3RlcmlzdGljcyBv
ZiBuZXR3b3JrIGRhdGEgYW5kIHR3byB0eXBpY2FsIHVzZSBjYXNlcyBhcmUNCiAgIHByZXNlbnRl
ZCBpbiB0aGlzIGRvY3VtZW50IHRvIGRlbW9uc3RyYXRlIHRoZSBkaWZmZXJlbnQgYXBwbGljYXRp
b24NCiAgIHNjZW5hcmlvcyBvZiBuZXR3b3JrIGRhdGEgaW4gd2F2ZWxlbmd0aCBkaXZpc2lvbiBz
ZXJ2aWNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh
dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz
c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0
IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=


From nobody Tue Oct 31 05:26:51 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 8FC2513F60D for ; Tue, 31 Oct 2017 05:26:49 -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 fHZ1plGdi89H for ; Tue, 31 Oct 2017 05:26:48 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9ECD1398CF for ; Tue, 31 Oct 2017 05:26:47 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id r196so22224543wmf.2 for ; Tue, 31 Oct 2017 05:26:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=X3gWvzIJnsShPjLqj/SqMcJXVYx7RfxIiSd94CNKGJo=; b=ozyHZzKE08S3n09c4TaWiX9XBBJYrYdZjDg3YrgMVrwq69vmOjRzn/3Hq8uIQK5Rht /J3rVarmeGt7hzWjSwaWkD1mpfxV00v184kAc2jsyozBeIH/oMdhmyqwj0PHR5QSyYl9 sIrWCjORrxPd5j3ikR9n1LcVSh+mQiwDLi3B4jgXVAaWtQXbdNtTrV8vJ9r0Utk+qf+F oJ0RxAFQ5c+u/UTtRG+5lpWQcBYIVHEBR440I6XdHU8GwfCbRwijszVbUjvrRx6OOyS2 IL3WF8gNQgIdQRKNYoEF1t9jyI2xrEWAffLVaCe89/uwUjV/aPMkje/sCv5TCJWRroJd V0Sg==
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=X3gWvzIJnsShPjLqj/SqMcJXVYx7RfxIiSd94CNKGJo=; b=VAJmhpUr1KLjo3VTk0BRdn0Q2srjC0Jkzw2DnNAECZXejm2iXPnJUnerulsVH5jonf gKm5Q/wYP60DDtwNWAdyL3qf4xJMzRGGVzb+pIP+DPpaMdk2Xlql1qKXqui+P2dBXLWs 1Kg2DcnRNG/uxaL63XeMF6E4sWffDqte1afQna26uaHqFvUKg9JILrQb1pZxmwu+HjQp 9EfIxFI42nPRgoOkOW8jwQTdcJhRniZTbdltJ8bOqLcw/6DHOB+qqRZVx1Tj2WlO1kOO x+qhgbLukbtOROyEG9FOVSg96y/IhBbyEFyRTUYJj0nm9pH5ITWOn5gjRJeGzJODEokr w8Ug==
X-Gm-Message-State: AMCzsaXQBuHRRMEC3ERMlHYzffqy2A/Z9BQVwPy560Y2Z8IhQ9l1ssnW kLTwjjW9/GqzyZPxDQcRvHGWsIWJQXA4guCe4fHvAw==
X-Google-Smtp-Source: ABhQp+RtRsY7axUQWy/9sYJd0iTxtCA5S4N9gqr6FkjLv4aS/KxgroN7a5nfx3/rLzhmSYFcrsOU23SMGAnL4fV/hUc=
X-Received: by 10.80.170.107 with SMTP id p40mr2688885edc.158.1509452806072; Tue, 31 Oct 2017 05:26:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.203.201 with HTTP; Tue, 31 Oct 2017 05:26:05 -0700 (PDT)
From: "M. Ranganathan" 
Date: Tue, 31 Oct 2017 08:26:05 -0400
Message-ID: 
To: opsawg@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0e49364fb0ea055cd6de75"
Archived-At: 
Subject: [OPSAWG] ietf-access-control-list@2017-10-03.yang : can access-lists use a grouping?
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, 31 Oct 2017 12:26:49 -0000

--94eb2c0e49364fb0ea055cd6de75
Content-Type: text/plain; charset="UTF-8"

Hello,

In the file

ietf-access-control-list@2017-10-03.yang

I see that access-lists is directly defined as a collection.


May I suggest making a grouping (say access-lists-grouping) and use a
"uses" statement in access-lists.

The use-case for this change request - I would like to use the grouping in
another YANG model using a "uses" statement.

Thanks in advance for considering it.

Regards,

Ranga.



-- 
M. Ranganathan

--94eb2c0e49364fb0ea055cd6de75
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello,

In the f=
ile=C2=A0 

ietf-access-control-list@2017-10-03.yang

I see tha=
t access-lists is directly defined as a collection.


May I =
suggest making a grouping (say access-lists-grouping) and use a "uses&=
quot; statement in access-lists.

The use-case for this change =
request - I would like to use the grouping in another YANG model using a &q=
uot;uses" statement.

Thanks in advance for considering it=
.

Regards,

Ranga.



-- 
M. R=
anganathan




--94eb2c0e49364fb0ea055cd6de75--